From sdanda@cisco.com Fri Nov 1 07:03:17 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E065311E818F for ; Fri, 1 Nov 2013 07:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WwF29f43WGxF for ; Fri, 1 Nov 2013 07:03:12 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 2031611E8390 for ; Fri, 1 Nov 2013 07:03:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3048; q=dns/txt; s=iport; t=1383314590; x=1384524190; h=from:to:subject:date:message-id:mime-version; bh=+jLCPtDjUkuh67N9Gy4010dQdrlTyc6Y1wzNOGY6GPA=; b=Eh/YB/nFYcLfRcuA4UbwHRSc8tovbKzWE4c8H++TOGrpE7FihdIo18/3 G8ywivYphcKQwsABJIePdSkTeX9rSPjr9s8d+6UI4CvwdebYAn00CtV0p NCfQhtQmYBELsuH63SAt8HEoAojckB5KwJiGvqk0cO5O6WVOQ1b1gf4Rx A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag8GALazc1KtJXG9/2dsb2JhbABZgkNEOFO/YoEeFm0HgicBBC1eAQweViYBBBuHf5t6oUGPJ4NYgQ4DqhODJoIq X-IronPort-AV: E=Sophos;i="4.93,617,1378857600"; d="scan'208,217";a="279481735" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-3.cisco.com with ESMTP; 01 Nov 2013 14:03:07 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id rA1E37mT006455 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Fri, 1 Nov 2013 14:03:07 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.14]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.02.0318.004; Fri, 1 Nov 2013 09:03:06 -0500 From: "Satyanarayana Danda (sdanda)" To: "dime@ietf.org" Thread-Topic: [Dime] Equivalent to Radius COA in Diameter Thread-Index: Ac7XCxYu4DB9XfiBTcePRBKIpnAlTw== Date: Fri, 1 Nov 2013 14:03:06 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.106.2] Content-Type: multipart/alternative; boundary="_000_E06F3B652F60A4409C49D8E840BEEC921E42E692xmbrcdx14ciscoc_" MIME-Version: 1.0 Subject: [Dime] Equivalent to Radius COA in Diameter X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 14:03:18 -0000 --_000_E06F3B652F60A4409C49D8E840BEEC921E42E692xmbrcdx14ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Not sure I am missing something obvious, looking for a method to achieve R= adius COA functionality with all possible command codes Using Diameter. I see, it would be possible with server initiated messages,= looking for more details in case any draft talks more about the respected = messages. Thanks Satya --_000_E06F3B652F60A4409C49D8E840BEEC921E42E692xmbrcdx14ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

Not sure I am missing something obvious,  looki= ng for a method to achieve Radius COA functionality with all possible comma= nd codes

Using Diameter. I see, it would be possible with ser= ver initiated messages, looking for more details in case any draft talks mo= re about the respected messages.

 

Thanks

Satya

--_000_E06F3B652F60A4409C49D8E840BEEC921E42E692xmbrcdx14ciscoc_-- From isj-dime@i1.dk Fri Nov 1 11:20:46 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF51911E8169 for ; Fri, 1 Nov 2013 11:20:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.299 X-Spam-Level: X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3+6xmT66U7gn for ; Fri, 1 Nov 2013 11:20:46 -0700 (PDT) Received: from i1.dk (isjsys5-i0.int.i1.dk [IPv6:2001:16d8:dd31:1:20d:93ff:fe73:ac12]) by ietfa.amsl.com (Postfix) with ESMTP id 3E11611E811D for ; Fri, 1 Nov 2013 11:20:45 -0700 (PDT) Received: from i1.dk (isjsys5 [127.0.0.1]) by i1.dk (Postfix) with ESMTP id E32245C008D for ; Fri, 1 Nov 2013 19:20:39 +0100 (CET) Received: from isjsys.int.i1.dk (isjsys-i0.int.i1.dk [IPv6:2001:16d8:dd31:1:219:d1ff:fe90:2bfa]) by i1.dk (Postfix) with ESMTP for ; Fri, 1 Nov 2013 19:20:39 +0100 (CET) Received: from isjsys.int.i1.dk (localhost [IPv6:::1]) by isjsys.int.i1.dk (Postfix) with ESMTP id B44C426F2E for ; Fri, 1 Nov 2013 19:20:39 +0100 (CET) From: Ivan Skytte =?ISO-8859-1?Q?J=F8rgensen?= To: dime@ietf.org Date: Fri, 01 Nov 2013 19:20:39 +0100 Message-ID: <2405851.kPegUBjbHl@isjsys.int.i1.dk> User-Agent: KMail/4.10.5 (Linux/3.7.10-1.16-desktop; KDE/4.10.5; x86_64; ; ) In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="ISO-8859-1" Subject: Re: [Dime] Equivalent to Radius COA in Diameter X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Nov 2013 18:20:46 -0000 On Friday 01 November 2013 14:03:06 Satyanarayana Danda wrote: > Hi, > > Not sure I am missing something obvious, looking for a method to achieve Radius COA functionality with all possible command codes > Using Diameter. I see, it would be possible with server initiated messages, looking for more details in case any draft talks more about the respected messages. The command you are looking for is Re-Auth-Request. Diameter Network Access Server Application rfc4005, page 12, section 3.3 Re-Auth-Request (RAR) Command. /isj From sdanda@cisco.com Sat Nov 2 00:12:51 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A5C211E81C7 for ; Sat, 2 Nov 2013 00:12:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b1vHCijOMFLB for ; Sat, 2 Nov 2013 00:12:46 -0700 (PDT) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id B3CBD11E80F2 for ; Sat, 2 Nov 2013 00:12:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1120; q=dns/txt; s=iport; t=1383376366; x=1384585966; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=z15HqE5hCFakWsqJwScafOWdMuBiqd12hsZ0DGPJsa4=; b=Mypqh9HXlqqrHthgSUfNHG20ti7UDVunQ0N8iFMROIWq953BPVJIUyZl G6dREbi0lo9UOt0G9NhveJLapUr2/OUuHCEj1+jUpALuB7Ui21U7Ll6pc j2js4CIohjSxYHBOLkHZrgfd1u1plyaBqPRmvLEft+n85T+77dAt2Q2Hd Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AhUFAJWldFKtJV2c/2dsb2JhbABZgwc4U798gR8WdIIlAQEBBAEBAWsXBAIBCBEEAQEBCh0HJwsUCQgBAQQBEgiHfw29HgSPJzgGgxqBDgOJCKELgyaCKg X-IronPort-AV: E=Sophos;i="4.93,621,1378857600"; d="scan'208";a="279787405" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-6.cisco.com with ESMTP; 02 Nov 2013 07:12:27 +0000 Received: from xhc-aln-x14.cisco.com (xhc-aln-x14.cisco.com [173.36.12.88]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id rA27CQqW012807 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 2 Nov 2013 07:12:26 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.14]) by xhc-aln-x14.cisco.com ([173.36.12.88]) with mapi id 14.02.0318.004; Sat, 2 Nov 2013 02:12:26 -0500 From: "Satyanarayana Danda (sdanda)" To: =?iso-8859-1?Q?Ivan_Skytte_J=F8rgensen?= , "dime@ietf.org" Thread-Topic: [Dime] Equivalent to Radius COA in Diameter Thread-Index: Ac7XCxYu4DB9XfiBTcePRBKIpnAlTwATeO2AABBpNOA= Date: Sat, 2 Nov 2013 07:12:25 +0000 Message-ID: References: <2405851.kPegUBjbHl@isjsys.int.i1.dk> In-Reply-To: <2405851.kPegUBjbHl@isjsys.int.i1.dk> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.33.98] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Dime] Equivalent to Radius COA in Diameter X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 02 Nov 2013 07:12:51 -0000 Thanks Ivan for your response, appreciate it. So, NAS can have RAR as a first request that it can receive after the peer = connection establishment is done. Thanks Satya -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Iva= n Skytte J=F8rgensen Sent: Friday, November 01, 2013 11:51 PM To: dime@ietf.org Subject: Re: [Dime] Equivalent to Radius COA in Diameter On Friday 01 November 2013 14:03:06 Satyanarayana Danda wrote: > Hi, >=20 > Not sure I am missing something obvious, looking for a method to=20 > achieve Radius COA functionality with all possible command codes Using Di= ameter. I see, it would be possible with server initiated messages, looking= for more details in case any draft talks more about the respected messages= . The command you are looking for is Re-Auth-Request. Diameter Network Access Server Application rfc4005, page 12, section 3.3 Re= -Auth-Request (RAR) Command. /isj _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From srdonovan@usdonovans.com Mon Nov 4 15:54:42 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF9E011E82DC; Mon, 4 Nov 2013 15:54:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUGfTLzfcq+h; Mon, 4 Nov 2013 15:54:35 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [192.249.113.76]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1EB11E81F7; Mon, 4 Nov 2013 15:54:30 -0800 (PST) Received: from dhcp-a58c.meeting.ietf.org ([31.133.165.140]:58146) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1VdTyU-0006IM-99; Mon, 04 Nov 2013 15:54:27 -0800 Message-ID: <527833AD.4030508@usdonovans.com> Date: Mon, 04 Nov 2013 15:54:21 -0800 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: doc-dt@ietf.org, dime@ietf.org Content-Type: multipart/alternative; boundary="------------030407090002080402010404" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Subject: [Dime] Comments on open issues in draft-docdt-dime-ovli-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Nov 2013 23:54:42 -0000 This is a multi-part message in MIME format. --------------030407090002080402010404 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All, I've included the DIME list on this email as the plan is to start migrating the Diameter Overload work from the design team to the DIME list now that the -01 version of the draft is out. There are a number of open issues listed in the draft. I have listed them here is some preliminary comments (preceded by srd>) on each. Note that this is just addressing issues that are explicitly called out in the draft. There are likely other issues that will be raised as the draft gets more review. Regards, Steve ---- Section 2 Server Farm A set of Diameter servers that can handle any request for a given set of Diameter applications. While these servers support the same set of applications, they do not necessarily all have the same capacity. An individual server farm might also support a subset of the users for a Diameter Realm. [OpenIssue: Is a server farm assumed to support a single realm? That is, does it support a set of applications in a single realm?] srd> Server farms are just groups of servers. There is nothing to prevent a server from supporting multiple applications in multiple realms so the same should be the case for server farms. Server Front End A Server Front End (SFE) is a role that can be performed by a Diameter agent -- either a relay or a proxy -- that sits between Diameter clients and a Server Farm. An SFE can perform various functions for the server farm it sits in front of. This includes some or all of the following functions: * Diameter Routing * Diameter layer load balancing * Load Management * Overload Management * Topology Hiding * Server Farm Identity Management [OpenIssue: We used the concept of a server farm and SFE for internal discussions. Do we still need those concepts to explain the mechanism? It doesn't seem like we use them much.] srd> We don't yet have the mechanism section written (section 5.5). This is where I would expect any wording dealing with server front ends that are doing overload management to end up. The rest of the server front end language is context for that discussion. Section 3.1.1 Pseudo-session applications: While this class of application does not use the Diameter Session-ID AVP to correlate requests, there is an implied ordering of transactions defined by the application. The 3GPP defined Cx application [reference] is an example of a pseudo-session application. [OpenIssue: Do we assume that all requests in a pseudo-session typically need to go to the same server?] srd> The assumption is that the first request in a pseudo session is Destination-Realm routed and the answer message contains an Origin-Host. The diameter id in received in the answer origin-host avp is then used as the destinition-host avp of subsequent requests. That's a long way of saying yes. Section 3.1.3 Correlated Session-Initiating Request: There are cases, most notably in the 3GPP PCC architecture, where multiple Diameter sessions are correlated and must be handled by the same Diameter server. This is a special case of a Session-Initiating Request. Gx CCR-I requests and Rx AAR messages are examples of correlated session- initiating requests. [OpenIssue: The previous paragraph needs references.] srd> We should add a reverence to the PCC architecture spec. Section 3.1.5 o Client --- Session Correlating Agent --- Multiple Equivalent Servers [OpenIssue: Do the "multiple equivalent servers" cases change for session-stateful applications? Do we need to distinguish equivalence for session-initiation requests vs intra-session requests?] srd> Given this is a PCC case, the only case where multiple equivalent servers could be used for routing a request is for the session that results in a binding. All other requests, both new session requests routed based on the binding and intra-session requests are routed to a specific server. A long was of saying no. o DOC client --- agent --- Partitioned/Segmented DOC server o DOC client --- agent --- agent --- Partitioned/Segmented DOC server o DOC client --- edge agent --- edge agent --- DOC server [OpenIssue: In the last 3 list entries, are the agents DOC or non- DOC?] srd> A change to this has been suggested in the past and just hasn't made it into the document yet. We clearly need to include both DOC supporting agents and non DOC supporting agents. Section 3.1.6 o This requirement also implies that if the Diameter agent does not impersonate the servers behind it, the Diameter dialogue is established between clients and servers and any overload information received by a client would be from a given server identified by the Origin-Host identity. [OpenIssue: We've discussed multiple situations where an agent might insert an OLR. I don't think we mean to force them to always perform topology hiding or SFIM in order to do so. We cannot assume that an OLR is always "from" or "about" the Origin-Host. Also, the section seems to assume that topology hiding agents act as b2b overload agents, but non-topology hiding agents never do. It don't think that's the right abstraction. It's possible that topology-hiding agents must do this, but I don't think we can preclude non-topology hiding agents from also doing it, at least some of the time.] srd> This is still an open issue on handling of "host" overload reports and "realm" overload reports. OC-OLR ::= < AVP Header: TBD2 > < TimeStamp > [ Reduction-Percentage ] [ ValidityDuration ] [ ReportType ] * [ AVP ] The TimeStamp AVP indicates when the original OC-OLR AVP with the current content was created. It is possible to replay the same OC- OLR AVP multiple times between the overload endpoints, however, when the OC-OLR AVP content changes or the other information sending endpoint wants the receiving endpoint to update its overload control information, then the TimeStamp AVP MUST contain a new value. [OpenIssue: Is this necessarily a timestamp, or is it just a sequence number that can be implemented as a timestamp? Is this timestamp used to calculate expiration time? (propose no.). We should also consider whether either a timestamp or sequence number is needed for protection against replay attacks.] srd> The primary reason for the timestamp is to distinguish when an overload report is new. A sequence number would word just as well, as long as it is unique across space and time. I agree that this should not be used by the reacting node to calculate expiration time. The reacting node should use its own local time plus the duration value in the overload report. We should choose either timestamp or sequence number and go forward with our choice. Section 4.5 The ReportType AVP is envisioned to be useful for situations where a reacting node needs to apply different overload treatments for different "types" of overload. For example, the reacting node(s) might need to throttle requests that are targeted to a specific server by the presence of a Destination-Host AVP than for requests that can be handled by any server in a realm. The example in Appendix C.3 illustrates this usage. [OpenIssue: There is an ongoing discussion about whether the ReportType AVP is the right way to solve that issue, and whether it's needed at all.] srd> This is part of the earlier issue from section 3.1.6. I propose we include the reporttype AVP and the report type explicit. Section 4.6 The value of the Reduction-Percentage AVP is between zero (0) and one hundred (100). Values greater than 100 are interpreted as 100. The value of 100 means that no traffic is expected, i.e. the sender of the information is under a severe load and ceases to process any new messages. The value of 0 means that the sender of the information is in a stable state and has no requests to the other endpoint to apply any traffic abatement. [Open Issue: We should consider an algorithm independent way to end an overload condition. Perhaps setting the validitytime to zero? Counter comment; since the abatement is based on a specific algorithm, it is natural to indicate that from the abatement algorithm point of view status quo has been reached.] srd> I thought that we agreed to setting the validity duration to zero was the mechanism to indicate that the overload condition had ended in the reporting node. If an overload control endpoint comes out of the 100 percent traffic reduction as a result of the overload report timing out, the following concerns are RECOMMENDED to be applied. The endpoint sending the traffic should be conservative and, for example, first send few "probe" messages to learn the overload condition of the other endpoint before converging to any traffic amount/rate decided by the sender. Similar concerns actually apply in all cases when the overload report times out unless the previous overload report stated 0 percent reduction. [Open Issue: It is still open whether we need an AVP to indicate the exact used traffic abatement algorithm. Currently it assumed that the reacting node is able to figure out what to do based on the Reducttion-Percentage AVP and possible other embedded information inside the OC-OLR AVP.] srd> There has been a lot of discussion on this. The current proposal is for each defined algorithm to define its own set of AVPs to carry information needed by the reacting node. This could be used to implicitly determine the algorithm to be used. It is still an open issue whether the abatement algorithm that the server will request is communicated in the capabilities exchange. My proposal is that the server does indicated the preferred algorithm as part of capabilities negotiation. Section 5.3.1 The basic principle is that the request message initiating endpoint (i.e. the "reacting node") announces its support for the overload control mechanism by including in the request message the OC-Feature- Vector AVP with those capability flag bits set that it supports and is willing to use for this Diameter session (or transaction in a case of a non-session state maintaining applications). In a case of session maintaining applications the request message initiating endpoint does not need to do the capability announcement more than once for the lifetime of the Diameter session. In a case of non- session maintaining applications, it is RECOMMENDED that the request message initiating endpoint includes the capability announcement into every request regardless it has had prior message exchanges with the give remote endpoint. [OpenIssue: We need to think about the lifetime of a capabilities declaration. It's probably not the same as for a session. We have had proposals that the feature vector needs to go into every request sent by an OC node. For peer to peer cases, this can be associated with connection lifetime, but it's more complex for non-adjacent OC support.] srd> I think the proposal is that capabilities advertised last either forever or until the a changed OC-Feature-Vector AVP is sent, which ever comes first. Section 5.5.2 [OpenIssue: did we now agree that e.g. a server can refrain sending OLR in answers based on some magical algorithm? (Note: We seem to have consensus that a server MAY repeat OLRs in subsequent messages, but is not required to do so, based on local policy.)] srd> We need to have wording to capture the behavior. I think wording something like "the reporting node should send overload reports in all answer messages. The reporting node can choose to not include the overload report in answers if it has the ability to determine that the reacting node that will receive the answer message has already received the overload report. Note that determining which reacting nodes have received the overload report is difficult in deployments that include agents." Section 8 The lack of end-to-end security features makes it far more difficult to establish trust in overload reports that originate from non- adjacent nodes. Any agents in the message path may insert or modify overload reports. Nodes must trust that their adjacent peers perform proper checks on overload reports from their peers, and so on, creating a transitive-trust requirement extending for potentially long chains of nodes. Network operators must determine if this transitive trust requirement is acceptable for their deployments. Nodes supporting Diameter overload control MUST give operators the ability to select which peers are trusted to deliver overload reports, and whether they are trusted to forward overload reports from non-adjacent nodes. [OpenIssue: This requires that a responding node be able to tell a peer-generated OLR from one generated by a non-adjacent node. One way of doing this would be to include the identity of the node that generated the report as part of the OLR] srd> We currently do not include the identity of the responding node in the overload report. It is highly likely that it will be required as part of the end-to-end security solution that is currently being worked. I propose that we include the identity in the overload report based on this expectation. [OpenIssue: Do we need further language about what rules an agent should apply before forwarding an OLR?] srd> I think we should but we don't yet have section 5.5 written and this is likely where this will go. The lack of end-to-end protection creates a tension between two requirements from the overload control requirements document. [I-D.ietf-dime-overload-reqs] Requirement 34 requires the ability to send overload reports across intermediaries (i.e. agents) that do not support overload control mechanism. Requirement 27 forbids the mechanism from adding new vulnerabilities or increasing the severity of existing ones. A non-supporting agent will most likely forward overload reports without inspecting them or applying any sort of validation or authorization. This makes the transitive trust issue considerably more of a problem. Without the ability to authenticate and integrity protect overload reports across a non-supporting agent, the mechanism cannot comply with both requirements. [OpenIssue: What do we want to do about this? Req27 is a normative MUST, while Req34 is "merely" a SHOULD. This would seem to imply that 27 has to take precedent. Can we say that overload reports MUST NOT be sent to and/or accepted from non-supporting agents until such time we can use end-to-end security?] srd> This needs to be discussed. --------------030407090002080402010404 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit All,

I've included the DIME list on this email as the plan is to start migrating the Diameter Overload work from the design team to the DIME list now that the -01 version of the draft is out.

There are a number of open issues listed in the draft.  I have listed them here is some preliminary comments (preceded by srd>) on each.

Note that this is just addressing issues that are explicitly called out in the draft.  There are likely other issues that will be raised as the draft gets more review.

Regards,

Steve

----

Section 2

   Server Farm

      A set of Diameter servers that can handle any request for a given
      set of Diameter applications.  While these servers support the
      same set of applications, they do not necessarily all have the
      same capacity.  An individual server farm might also support a
      subset of the users for a Diameter Realm.

      [OpenIssue: Is a server farm assumed to support a single realm?
      That is, does it support a set of applications in a single realm?]
srd> Server farms are just groups of servers.  There is nothing to prevent a server from supporting multiple applications in multiple realms so the same should be the case for server farms.

   Server Front End

      A Server Front End (SFE) is a role that can be performed by a
      Diameter agent -- either a relay or a proxy -- that sits between
      Diameter clients and a Server Farm.  An SFE can perform various
      functions for the server farm it sits in front of.  This includes
      some or all of the following functions:

      *  Diameter Routing

      *  Diameter layer load balancing

      *  Load Management

      *  Overload Management

      *  Topology Hiding

      *  Server Farm Identity Management

      [OpenIssue: We used the concept of a server farm and SFE for
      internal discussions.  Do we still need those concepts to explain
      the mechanism?  It doesn't seem like we use them much.]
srd> We don't yet have the mechanism section written (section 5.5).  This is where I would expect any wording dealing with server front ends that are doing overload management to end up.  The rest of the server front end language is context for that discussion.

Section 3.1.1

   Pseudo-session applications:  While this class of application does
      not use the Diameter Session-ID AVP to correlate requests, there
      is an implied ordering of transactions defined by the application.
      The 3GPP defined Cx application [reference] is an example of a
      pseudo-session application.

   [OpenIssue: Do we assume that all requests in a pseudo-session
   typically need to go to the same server?]
srd> The assumption is that the first request in a pseudo session is Destination-Realm routed and the answer message contains an Origin-Host.  The diameter id in received in the answer origin-host avp is then used as the destinition-host avp of subsequent requests.  That's a long way of saying yes.

Section 3.1.3

   Correlated Session-Initiating Request:  There are cases, most notably
      in the 3GPP PCC architecture, where multiple Diameter sessions are
      correlated and must be handled by the same Diameter server.  This
      is a special case of a Session-Initiating Request.  Gx CCR-I
      requests and Rx AAR messages are examples of correlated session-
      initiating requests.

      [OpenIssue: The previous paragraph needs references.]
srd> We should add a reverence to the PCC architecture spec.

Section 3.1.5

   o  Client --- Session Correlating Agent --- Multiple Equivalent
      Servers

   [OpenIssue: Do the "multiple equivalent servers" cases change for
   session-stateful applications?  Do we need to distinguish equivalence
   for session-initiation requests vs intra-session requests?]
srd> Given this is a PCC case, the only case where multiple equivalent servers could be used for routing a request is for the session that results in a binding.  All other requests, both new session requests routed based on the binding and intra-session requests are routed to a specific server.  A long was of saying no.

   o  DOC client --- agent --- Partitioned/Segmented DOC server

   o  DOC client --- agent --- agent --- Partitioned/Segmented DOC
      server
   o  DOC client --- edge agent --- edge agent --- DOC server

   [OpenIssue: In the last 3 list entries, are the agents DOC or non-
   DOC?]
srd> A change to this has been suggested in the past and just hasn't made it into the document yet.  We clearly need to include both DOC supporting agents and non DOC supporting agents.

Section 3.1.6

   o  This requirement also implies that if the Diameter agent does not
      impersonate the servers behind it, the Diameter dialogue is
      established between clients and servers and any overload
      information received by a client would be from a given server
      identified by the Origin-Host identity.

   [OpenIssue: We've discussed multiple situations where an agent might
   insert an OLR.  I don't think we mean to force them to always perform
   topology hiding or SFIM in order to do so.  We cannot assume that an
   OLR is always "from" or "about" the Origin-Host.  Also, the section
   seems to assume that topology hiding agents act as b2b overload
   agents, but non-topology hiding agents never do.  It don't think
   that's the right abstraction.  It's possible that topology-hiding
   agents must do this, but I don't think we can preclude non-topology
   hiding agents from also doing it, at least some of the time.]
srd> This is still an open issue on handling of "host" overload reports and "realm" overload reports. 

   OC-OLR ::= < AVP Header: TBD2 >
              < TimeStamp >
              [ Reduction-Percentage ]
              [ ValidityDuration ]
              [ ReportType ]
            * [ AVP ]


   The TimeStamp AVP indicates when the original OC-OLR AVP with the
   current content was created.  It is possible to replay the same OC-
   OLR AVP multiple times between the overload endpoints, however, when
   the OC-OLR AVP content changes or the other information sending
   endpoint wants the receiving endpoint to update its overload control
   information, then the TimeStamp AVP MUST contain a new value.

   [OpenIssue: Is this necessarily a timestamp, or is it just a sequence
   number that can be implemented as a timestamp?  Is this timestamp
   used to calculate expiration time? (propose no.).  We should also
   consider whether either a timestamp or sequence number is needed for
   protection against replay attacks.]
srd> The primary reason for the timestamp is to distinguish when an overload report is new.   A sequence number would word just as well, as long as it is unique across space and time.  I agree that this should not be used by the reacting node to calculate expiration time.  The reacting node should use its own local time plus the duration value in the overload report.  We should choose either timestamp or sequence number and go forward with our choice.

Section 4.5
   The ReportType AVP is envisioned to be useful for situations where a
   reacting node needs to apply different overload treatments for
   different "types" of overload.  For example, the reacting node(s)
   might need to throttle requests that are targeted to a specific
   server by the presence of a Destination-Host AVP than for requests
   that can be handled by any server in a realm.  The example in
   Appendix C.3 illustrates this usage.

   [OpenIssue: There is an ongoing discussion about whether the
   ReportType AVP is the right way to solve that issue, and whether it's
   needed at all.]
srd> This is part of the earlier issue from section 3.1.6.  I propose we include the reporttype AVP and the report type explicit.

Section 4.6

   The value of the Reduction-Percentage AVP is between zero (0) and one
   hundred (100).  Values greater than 100 are interpreted as 100.  The
   value of 100 means that no traffic is expected, i.e. the sender of
   the information is under a severe load and ceases to process any new
   messages.  The value of 0 means that the sender of the information is
   in a stable state and has no requests to the other endpoint to apply
   any traffic abatement.

   [Open Issue: We should consider an algorithm independent way to end
   an overload condition.  Perhaps setting the validitytime to zero?
   Counter comment; since the abatement is based on a specific
   algorithm, it is natural to indicate that from the abatement
   algorithm point of view status quo has been reached.]
srd> I thought that we agreed to setting the validity duration to zero was the mechanism to indicate that the overload condition had ended in the reporting node.

   If an overload control endpoint comes out of the 100 percent traffic
   reduction as a result of the overload report timing out, the
   following concerns are RECOMMENDED to be applied.  The endpoint
   sending the traffic should be conservative and, for example, first
   send few "probe" messages to learn the overload condition of the
   other endpoint before converging to any traffic amount/rate decided
   by the sender.  Similar concerns actually apply in all cases when the
   overload report times out unless the previous overload report stated
   0 percent reduction.

   [Open Issue: It is still open whether we need an AVP to indicate the
   exact used traffic abatement algorithm.  Currently it assumed that
   the reacting node is able to figure out what to do based on the
   Reducttion-Percentage AVP and possible other embedded information
   inside the OC-OLR AVP.]
srd> There has been a lot of discussion on this.  The current proposal is for each defined algorithm to define its own set of AVPs to carry information needed by the reacting node.  This could be used to implicitly determine the algorithm to be used.  It is still an open issue whether the abatement algorithm that the server will request is communicated in the capabilities exchange.  My proposal is that the server does indicated the preferred algorithm as part of capabilities negotiation.

Section 5.3.1

   The basic principle is that the request message initiating endpoint
   (i.e. the "reacting node") announces its support for the overload
   control mechanism by including in the request message the OC-Feature-
   Vector AVP with those capability flag bits set that it supports and
   is willing to use for this Diameter session (or transaction in a case
   of a non-session state maintaining applications).  In a case of
   session maintaining applications the request message initiating
   endpoint does not need to do the capability announcement more than
   once for the lifetime of the Diameter session.  In a case of non-
   session maintaining applications, it is RECOMMENDED that the request
   message initiating endpoint includes the capability announcement into
   every request regardless it has had prior message exchanges with the
   give remote endpoint.

   [OpenIssue: We need to think about the lifetime of a capabilities
   declaration.  It's probably not the same as for a session.  We have
   had proposals that the feature vector needs to go into every request
   sent by an OC node.  For peer to peer cases, this can be associated
   with connection lifetime, but it's more complex for non-adjacent OC
   support.]
srd> I think the proposal is that capabilities advertised last either forever or until the a changed OC-Feature-Vector AVP is sent, which ever comes first.

Section 5.5.2
   [OpenIssue: did we now agree that e.g. a server can refrain sending
   OLR in answers based on some magical algorithm?  (Note: We seem to
   have consensus that a server MAY repeat OLRs in subsequent messages,
   but is not required to do so, based on local policy.)]
srd> We need to have wording to capture the behavior.  I think wording something like "the reporting node should send overload reports in all answer messages.  The reporting node can choose to not include the overload report in answers if it has the ability to determine that the reacting node that will receive the answer message has already received the overload report.  Note that determining which reacting nodes have received the overload report is difficult in deployments that include agents."

Section 8

   The lack of end-to-end security features makes it far more difficult
   to establish trust in overload reports that originate from non-
   adjacent nodes.  Any agents in the message path may insert or modify
   overload reports.  Nodes must trust that their adjacent peers perform
   proper checks on overload reports from their peers, and so on,
   creating a transitive-trust requirement extending for potentially
   long chains of nodes.  Network operators must determine if this
   transitive trust requirement is acceptable for their deployments.
   Nodes supporting Diameter overload control MUST give operators the
   ability to select which peers are trusted to deliver overload
   reports, and whether they are trusted to forward overload reports
   from non-adjacent nodes.

   [OpenIssue: This requires that a responding node be able to tell a
   peer-generated OLR from one generated by a non-adjacent node.  One
   way of doing this would be to include the identity of the node that
   generated the report as part of the OLR]
srd> We currently do not include the identity of the responding node in the overload report.  It is highly likely that it will be required as part of the end-to-end security solution that is currently being worked.  I propose that we include the identity in the overload report based on this expectation.
   [OpenIssue: Do we need further language about what rules an agent
   should apply before forwarding an OLR?]
srd> I think we should but we don't yet have section 5.5 written and this is likely where this will go. 

      The lack of end-to-end protection creates a tension between two
      requirements from the overload control requirements document.
      [I-D.ietf-dime-overload-reqs] Requirement 34 requires the ability
      to send overload reports across intermediaries (i.e. agents) that
      do not support overload control mechanism.  Requirement 27 forbids
      the mechanism from adding new vulnerabilities or increasing the
      severity of existing ones.  A non-supporting agent will most
      likely forward overload reports without inspecting them or
      applying any sort of validation or authorization.  This makes the
      transitive trust issue considerably more of a problem.  Without
      the ability to authenticate and integrity protect overload reports
      across a non-supporting agent, the mechanism cannot comply with
      both requirements.

      [OpenIssue: What do we want to do about this?  Req27 is a
      normative MUST, while Req34 is "merely" a SHOULD.  This would seem
      to imply that 27 has to take precedent.  Can we say that overload
      reports MUST NOT be sent to and/or accepted from non-supporting
      agents until such time we can use end-to-end security?]
srd> This needs to be discussed.







--------------030407090002080402010404-- From srdonovan@usdonovans.com Mon Nov 4 16:01:33 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CBE321E8253; Mon, 4 Nov 2013 16:01:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LcNP2J8AHEps; Mon, 4 Nov 2013 16:01:27 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [192.249.113.76]) by ietfa.amsl.com (Postfix) with ESMTP id 1599121E8307; Mon, 4 Nov 2013 16:01:02 -0800 (PST) Received: from dhcp-a58c.meeting.ietf.org ([31.133.165.140]:58171) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1VdU4p-0006eA-Mm; Mon, 04 Nov 2013 16:01:00 -0800 Message-ID: <5278353C.4040506@usdonovans.com> Date: Mon, 04 Nov 2013 16:01:00 -0800 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: dime@ietf.org, doc-dt@ietf.org Content-Type: multipart/alternative; boundary="------------000801060506060005070102" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Subject: [Dime] Comment on definition of throttling DOC draft X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 00:01:34 -0000 This is a multi-part message in MIME format. --------------000801060506060005070102 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit All, The following definition of throttling is in the current draft: Throttling: Throttling is the reduction of the number of requests sent to an entity. Throttling can include a client dropping requests, or an agent rejecting requests with appropriate error responses. Clients and agents can also choose to redirect throttled requests to some other entity or entities capable of handling them. I suggest a couple of changes. First, an agent that is throttling a message should not "drop" the message but should rather send an error response indicating that the message was throttled. I think this was the intent of the definition but it would be good to be explicit. Second, the comment on redirecting doesn't belong as part of throttling. Once a request is throttled it doesn't exist anymore. Redirecting and throttling are two actions that can be taken as part of overload abatement. We should add a definition of overload abatement that includes both. We should also add a definition of redirecting. Regards, Steve --------------000801060506060005070102 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit All,

The following definition of throttling is in the current draft:
   Throttling:

      Throttling is the reduction of the number of requests sent to an
      entity.  Throttling can include a client dropping requests, or an
      agent rejecting requests with appropriate error responses.
      Clients and agents can also choose to redirect throttled requests
      to some other entity or entities capable of handling them.
I suggest a couple of changes. 

First, an agent that is throttling a message should not "drop" the message but should rather send an error response indicating that the message was throttled.  I think this was the intent of the definition but it would be good to be explicit.

Second, the comment on redirecting doesn't belong as part of throttling.  Once a request is throttled it doesn't exist anymore.  Redirecting and throttling are two actions that can be taken as part of overload abatement.  We should add a definition of overload abatement that includes both.  We should also add a definition of redirecting.

Regards,

Steve


--------------000801060506060005070102-- From ben@nostrum.com Mon Nov 4 16:28:17 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 746F721E811A; Mon, 4 Nov 2013 16:28:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.5 X-Spam-Level: X-Spam-Status: No, score=-102.5 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BBqiQPY-Pqt5; Mon, 4 Nov 2013 16:28:17 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id CBE9D21E82EB; Mon, 4 Nov 2013 16:28:16 -0800 (PST) Received: from dhcp-bc5b.meeting.ietf.org (dhcp-bc5b.meeting.ietf.org [31.133.188.91]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rA50SDCO090397 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 4 Nov 2013 18:28:15 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) From: Ben Campbell In-Reply-To: <5278353C.4040506@usdonovans.com> Date: Mon, 4 Nov 2013 16:28:12 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <077A1B7B-C97C-4B89-8699-63A47DA4DAFE@nostrum.com> References: <5278353C.4040506@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.1816) Received-SPF: pass (shaman.nostrum.com: 31.133.188.91 is authenticated by a trusted mechanism) Cc: "dime@ietf.org list" , doc-dt@ietf.org Subject: Re: [Dime] Comment on definition of throttling DOC draft X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 00:28:17 -0000 On Nov 4, 2013, at 4:01 PM, Steve Donovan = wrote: > All, >=20 > The following definition of throttling is in the current draft: > Throttling: >=20 > Throttling is the reduction of the number of requests sent to an > entity. Throttling can include a client dropping requests, or = an > agent rejecting requests with appropriate error responses. > Clients and agents can also choose to redirect throttled = requests > to some other entity or entities capable of handling them. >=20 > I suggest a couple of changes. =20 >=20 > First, an agent that is throttling a message should not "drop" the = message but should rather send an error response indicating that the = message was throttled. I think this was the intent of the definition = but it would be good to be explicit. Agreed. But we should probably say the same about clients. That is, if = they throttle a request, they need to do whatever application layer = thing they would need to do if they had received some certain error = (probably from the set of errors that an agent might send if it needed = to throttle.) >=20 > Second, the comment on redirecting doesn't belong as part of = throttling. Once a request is throttled it doesn't exist anymore. = Redirecting and throttling are two actions that can be taken as part of = overload abatement. We should add a definition of overload abatement = that includes both. We should also add a definition of redirecting. I don't have strong feelings on this, but my instinct is that throttling = means that a certain node doesn't have to process the request. That says = nothing about whether a different node had to process it. Or more = explicitly, a reporting node cannot (or should not) tell the difference = between whether messages go away entirely vs go somewhere else. >=20 > Regards, >=20 > Steve >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From ben@nostrum.com Mon Nov 4 16:36:46 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A6AB21E8396 for ; Mon, 4 Nov 2013 16:36:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[AWL=-0.513, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_25=0.6, J_CHICKENPOX_36=0.6, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fd2cyWBpMw5e for ; Mon, 4 Nov 2013 16:36:44 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 28FD821E818C for ; Mon, 4 Nov 2013 16:36:44 -0800 (PST) Received: from dhcp-bc5b.meeting.ietf.org (dhcp-bc5b.meeting.ietf.org [31.133.188.91]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rA50af13090748 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Mon, 4 Nov 2013 18:36:43 -0600 (CST) (envelope-from ben@nostrum.com) From: Ben Campbell Content-Type: multipart/alternative; boundary="Apple-Mail=_ABC222C8-466D-4672-9504-F881FED7CBEA" Message-Id: <66DEB166-8DEB-42CA-A46E-8128F0D0900B@nostrum.com> Date: Mon, 4 Nov 2013 16:36:41 -0800 To: "dime@ietf.org list" Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1816\)) X-Mailer: Apple Mail (2.1816) Received-SPF: pass (shaman.nostrum.com: 31.133.188.91 is authenticated by a trusted mechanism) Subject: [Dime] Proposed Example Text for draft-docdt-dime-ovli-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 00:36:46 -0000 --Apple-Mail=_ABC222C8-466D-4672-9504-F881FED7CBEA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, draft-docdt-dime-ovli-01 has a TBD item in appendix C, section 3. = Namely, an example showing a mix of Destination-Realm and = Destination-Host routed requests. Here's a straw man proposal for that = example. I don't expect this to be the "one true way" to approach the = scenario; rather, it's a possible way to do it, and there are likely = other ways as well. Comments solicited. Thanks! Ben. ---------------------------- C.3. Mix of Destination-Realm routed requests and Destination-Host reouted requests Diameter allows a client to optionally select the destination server of a request, even if there are agents between the client and the server. The client does this using the Destination-Host AVP. In cases where the client does not care if a specific server receives the request, it can omit Destination-Host and route the request using the Destination-Realm and ApplicationId AVPs, effectively letting an agent select the server. Clients commonly send mixtures of Destination-Host and Destination- Realm routed requests. For example, in an application that uses user sessions, a client typically won't care which server handles a session-initiating requests. But once the session is initiated, the client will send all subsequent requests in that session to the same server. Therefore it would send the initial request with no Destination-Host AVP. If it receives a successful answer, the client would copy the Origin-Host value from the answer message into a Destination-Host AVP in each subsequent request in the session. An agent has very limited options in applying overload abatement to requests that contain Destination-Host AVPs. It typically cannot route the request to a different server than the one identified in Destination-Host. It's only remaining options are to throttle such requests locally, or to send an overload report back towards the client so the client can throttle the requests. The second choice is usually more efficient, since it prevents any throttled requests from being sent in the first place, and removes the agent's need to send errors back to the client for each dropped request. On the other hand, an agent has much more leeway to apply overload abatement for requests that do not contain Destination-Host AVPs. If the agent has multiple servers in its peer table for the given realm and application, it can route such requests to other, less overloaded servers. If the overload severity increases, the agent may reach a point where there is not sufficient capacity across all servers to handle even Korhonen, et al. Expires May 03, 2014 [Page 35] Internet-Draft DOIC October 2013 realm-routed requests. In this case, the realm itself can be considered overloaded. The agent may need the client to throttle realm-routed requests in addition to Destination-Host routed requests. The overload severity may be different for each server, and the severity for the realm at is likely to be different than for any specific server. Therefore, an agent may need to forward, or originate, multiple overload reports with differing ReportType and Reduction-Percentage values. Figure 8 illustrates such a mixed-routing scenario. In this example, the servers S1, S2, and S3 handle requests for the realm "realm". Any of the three can handle requests that are not part of a user session (i.e. routed by Destination-Realm). But once a session is established, all requests in that session must go to the same server. Client Agent S1 S2 S3 | | | | | | | | | | | | | | | |(1) Request (DR:realm) | | |-------->| | | | | | | | | | | | | | | |Agent selects S1 | | | | | | | | | | | | | | | | | | |(2) Request (DR:realm) | | |-------->| | | | | | | | | | | | | | | |S1 overloaded, returns OLR | | | | | | | | | | | | | | | | |(3) Answer (OR:realm,OH:S1,OLR:RT=3DDH) | |<--------| | | | | | | | | | | | | | |sees OLR,routes DR traffic to S2&S3 | | | | | | | | | | | | | | | |(4) Answer (OR:realm,OH:S1, OLR:RT=3DDH) | |<--------| | | | | | | | | | | | | | |Client throttles requests with DH:S1 | | | | | | | | | | | | | | | | |(5) Request (DR:realm) | | |-------->| | | | | | | | | | | | | | | |Agent selects S2 | | | | | | | | | | | | | | | | | | |(6) Request (DR:realm) | | |------------------>| | | | | | | | | | | | | | | |S2 is overloaded... | | | | | | | | | | | | | | | | |(7) Answer (OH:S2, OLR:RT=3DDH)| | |<------------------| | | | | | | | | | | | | |Agent sees OLR, realm now overloaded | | | | | | | | | | | | | | | |(8) Answer (OR:realm,OH:S2, OLR:RT=3DDH, OLR: = RT=3DR) |<--------| | | | | | | | | | | | | | |Client throttles DH:S1, DH:S2, and DR:realm | | | | | | | | | | | | | | | | | | | | | | | | | Figure 8: Mix of Destination-Host and Destination-Realm Routed Requests 1: The client sends a request with no Destination-Host AVP (that is, a Destination-Realm routed request.) 2: The agent follows local policy to select a server from its peer table. In this case, the agent selects S2 and forwards the request. 3: S1 is overloaded. It sends a answer indicating success, but also includes an overload report. Since the overload report only applies to S1, the ReportType is "Destination-Host". 4: The agent sees the overload report, and records that S1 is overloaded by the value in the Reduction-Percentage AVP. It begins diverting the indicated percentage of realm-routed traffic from S1 to S2 and S3. Since it can't divert Destination-Host routed traffic, it forwards the overload report to the client. This effectively delegates the throttling of traffic with Destination-Host:S1 to the client. 5: The client sends another Destination-Realm routed request. 6: The agent selects S2, and forwards the request. 7: It turns out that S2 is also overloaded, perhaps due to all that traffic it took over for S1. S2 returns an successful answer containing an overload report. Since this report only applies to S2, the ReportType is "Destination-Host". 8: The agent sees that S2 is also overloaded by the value in Reduction-Percentage. This value is probably different than the value from S1's report. The agent diverts the remaining traffic to S3 as best as it can, but it calculates that the remaining capacity across all three servers is no longer sufficient to handle all of the realm-routed traffic. This means the realm itself is overloaded. The realm's overload percentage is most likely different than that for either S1 or S2. The agent forward's S2's report back to the client in the Diameter answer. Additionally, the agent generates a new report for the realm of "realm", and inserts that report into the answer. The client throttles requests with Destination-Host:S1 at one rate, requests with Destination-Host:S2 at another rate, and requests with no Destination-Host AVP at yet a third rate. (Since S3 has not indicated overload, the client does not throttle requests with Destination-Host:S3.) --Apple-Mail=_ABC222C8-466D-4672-9504-F881FED7CBEA Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii Hi,

draft-docdt-dime-ovli-01 has = a TBD item in appendix C, section 3. Namely,  an example showing a = mix of Destination-Realm and Destination-Host routed requests. Here's a = straw man proposal for that example. I don't expect this to be the "one = true way" to approach the scenario; rather, it's a possible way to do = it, and there are likely other ways as = well.

Comments = solicited.

Thanks!

Ben.<= /div>

----------------------------

=
C.3.  Mix of Destination-Realm = routed requests and Destination-Host
      reouted = requests

  =  Diameter allows a client to optionally select the destination = server
   of a request, = even if there are agents between the client and = the
   server. =  The client does this using the Destination-Host AVP. =  In
   cases where = the client does not care if a specific server = receives
   the = request, it can omit Destination-Host and route the request = using
   the = Destination-Realm and ApplicationId AVPs, effectively letting = an
   agent select the = server.

   Clients commonly send mixtures of = Destination-Host and Destination-
   Realm routed requests.  For example, = in an application that uses user
   sessions, a client typically won't care = which server handles a
  =  session-initiating requests.  But once the session is = initiated, the
  =  client will send all subsequent requests in that session to the = same
   server. =  Therefore it would send the initial request with = no
   Destination-Host = AVP.  If it receives a successful answer, the = client
   would copy = the Origin-Host value from the answer message into = a
   Destination-Host = AVP in each subsequent request in the session.

  =  An agent has very limited options in applying overload abatement = to
   requests that = contain Destination-Host AVPs.  It typically = cannot
   route the = request to a different server than the one identified = in
   Destination-Host. =  It's only remaining options are to throttle = such
   requests = locally, or to send an overload report back towards = the
   client so the = client can throttle the requests.  The second choice = is
   usually more = efficient, since it prevents any throttled requests = from
   being sent in = the first place, and removes the agent's need to = send
   errors back to = the client for each dropped request.

  =  On the other hand, an agent has much more leeway to apply = overload
   abatement = for requests that do not contain Destination-Host AVPs. =  If
   the agent = has multiple servers in its peer table for the given = realm
   and = application, it can route such requests to other, less = overloaded
  =  servers.

  =  If the overload severity increases, the agent may reach a point = where
   there is not = sufficient capacity across all servers to handle = even



Korhonen, et = al.          Expires May 03, 2014     =             [Page 35]
=0C=
Internet-Draft       =              DOIC     =                  October = 2013


  =  realm-routed requests.  In this case, the realm itself can = be
   considered = overloaded.  The agent may need the client to = throttle
  =  realm-routed requests in addition to Destination-Host = routed
   requests. =  The overload severity may be different for each = server,
   and the = severity for the realm at is likely to be different than = for
   any specific = server.  Therefore, an agent may need to forward, = or
   originate, = multiple overload reports with differing ReportType = and
  =  Reduction-Percentage values.

  =  Figure 8 illustrates such a mixed-routing scenario.  In this = example,
   the servers = S1, S2, and S3 handle requests for the realm = "realm".
   Any of the = three can handle requests that are not part of a = user
   session (i.e. = routed by Destination-Realm).  But once a session = is
   established, all = requests in that session must go to the same = server.

                =   Client     Agent      S1     =    S2        S3
                =      |         |       =   |         |         = |
        =              |       =   |         |         | =         |
                =      |         |       =   |         |         = |
        =              |(1) Request (DR:realm) =       |         = |
        =              |-------->|   =       |         |     =     |
    =                  |   =       |         |     =     |         |
                =      |         |       =   |         |         = |
        =              |       =   |Agent selects S1   |         = |
        =              |       =   |         |         | =         |
                =      |         |       =   |         |         = |
        =              |       =   |         |         | =         |
                =      |         |(2) Request = (DR:realm)       |
                =      |         |-------->|   =       |         = |
        =              |       =   |         |         | =         |
                =      |         |       =   |         |         = |
        =              |       =   |         |S1 overloaded, returns = OLR
        =              |       =   |         |         | =         |
                =      |         |       =   |         |         = |
        =              |       =   |         |         | =         |
                =      |         |(3) Answer = (OR:realm,OH:S1,OLR:RT=3DDH)
 =                    | =         |<--------|         | =         |
                =      |         |       =   |         |         = |
        =              |       =   |         |         | =         |
                =      |         |sees OLR,routes DR = traffic to S2&S3
  =                    | =         |         |   =       |         = |
        =              |       =   |         |         | =         |
                =      |         |       =   |         |         = |
        =              |(4) Answer = (OR:realm,OH:S1, OLR:RT=3DDH) |
                =      |<--------|         |   =       |         = |
        =              |       =   |         |         | =         |
                =      |         |       =   |         |         = |
        =              |Client throttles = requests with DH:S1   |
                  =    |         |         = |         |         = |
        =              |       =   |         |         | =         |
                =      |         |       =   |         |         = |
        =              |(5) Request (DR:realm) =       |         = |
        =              |-------->|   =       |         |     =     |
    =                  |   =       |         |     =     |         |
                =      |         |       =   |         |         = |
        =              |       =   |Agent selects S2   |         = |
        =              |       =   |         |         | =         |
                =      |         |       =   |         |         = |
        =              |       =   |         |         | =         |
                =      |         |(6) Request = (DR:realm)       |
                =      |         = |------------------>|         = |
        =              |       =   |         |         | =         |
                =      |         |       =   |         |         = |
        =              |       =   |         |         |S2 = is overloaded...
    =                  |   =       |         |     =     |         |
                =      |         |       =   |         |         = |
        =              |       =   |         |         | =         |
                =      |         |(7) Answer (OH:S2, = OLR:RT=3DDH)|
    =                  |   =       |<------------------|       =   |
      =                |     =     |         |       =   |         |
                =      |         |       =   |         |         = |
        =              |       =   |Agent sees OLR, realm now overloaded
                =      |         |       =   |         |         = |
        =              |       =   |         |         | =         |
                =      |         |       =   |         |         = |
        =              |(8) Answer = (OR:realm,OH:S2, OLR:RT=3DDH, OLR: RT=3DR)
                =      |<--------|         |   =       |         = |
        =              |       =   |         |         | =         |
                =      |         |       =   |         |         = |
        =              |Client throttles DH:S1, = DH:S2, and DR:realm
    =                  |   =       |         |     =     |         |
                =      |         |       =   |         |         = |
        =              |       =   |         |         | =         |
                =      |         |       =   |         |         = |
        =              |       =   |         |         | =         |


  =     Figure 8: Mix of Destination-Host and Destination-Realm = Routed
      =                     =        Requests

  =  1: The client sends a request with no Destination-Host AVP (that = is,
      a = Destination-Realm routed request.)

  =  2: The agent follows local policy to select a server from its = peer
      table. =  In this case, the agent selects S2 and forwards = the
      = request.

   3: S1 is overloaded.  It sends a answer = indicating success, but also
 =     includes an overload report.  Since the overload = report only
      = applies to S1, the ReportType is = "Destination-Host".

  =  4: The agent sees the overload report, and records that S1 = is
      = overloaded by the value in the Reduction-Percentage AVP. =  It
      = begins diverting the indicated percentage of realm-routed = traffic
      from = S1 to S2 and S3.  Since it can't divert = Destination-Host
    =   routed traffic, it forwards the overload report to the = client.
      This = effectively delegates the throttling of traffic = with
      = Destination-Host:S1 to the client.

  =  5: The client sends another Destination-Realm routed = request.

  =  6: The agent selects S2, and forwards the = request.

  =  7: It turns out that S2 is also overloaded, perhaps due to all = that
      traffic = it took over for S1.  S2 returns an successful = answer
      = containing an overload report.  Since this report only applies = to
      S2, the = ReportType is "Destination-Host".

  =  8: The agent sees that S2 is also overloaded by the value = in
      = Reduction-Percentage.  This value is probably different than = the
      value = from S1's report.  The agent diverts the remaining = traffic
      to = S3 as best as it can, but it calculates that the = remaining
      = capacity across all three servers is no longer sufficient = to
      handle = all of the realm-routed traffic.  This means the = realm
      itself = is overloaded.  The realm's overload percentage is = most
      likely = different than that for either S1 or S2.  The = agent
      = forward's S2's report back to the client in the Diameter = answer.
      = Additionally, the agent generates a new report for the realm = of
      "realm", = and inserts that report into the answer.  The = client
      = throttles requests with Destination-Host:S1 at one rate, = requests
      = with Destination-Host:S2 at another rate, and requests with = no
      = Destination-Host AVP at yet a third rate.  (Since S3 has = not
      = indicated overload, the client does not throttle requests = with
      = Destination-Host:S3.)

= --Apple-Mail=_ABC222C8-466D-4672-9504-F881FED7CBEA-- From lionel.morand@orange.com Mon Nov 4 17:29:31 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84CDA11E8261; Mon, 4 Nov 2013 17:29:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.597 X-Spam-Level: X-Spam-Status: No, score=-2.597 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TwImr57TQO5M; Mon, 4 Nov 2013 17:29:26 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) by ietfa.amsl.com (Postfix) with ESMTP id 43D2211E80F5; Mon, 4 Nov 2013 17:29:25 -0800 (PST) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm11.si.francetelecom.fr (ESMTP service) with ESMTP id DF45A3B427D; Tue, 5 Nov 2013 02:29:23 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id C6168238048; Tue, 5 Nov 2013 02:29:23 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Tue, 5 Nov 2013 02:29:23 +0100 From: To: Steve Donovan , "doc-dt@ietf.org" , "dime@ietf.org" Thread-Topic: [Dime] Comments on open issues in draft-docdt-dime-ovli-01.txt Thread-Index: AQHO2bk+RzShDn1PbkOBdw5Pt6IlCJoV1dJw Date: Tue, 5 Nov 2013 01:29:23 +0000 Message-ID: <30128_1383614963_527849F3_30128_10279_1_6B7134B31289DC4FAF731D844122B36E2E7C9D@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <527833AD.4030508@usdonovans.com> In-Reply-To: <527833AD.4030508@usdonovans.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E2E7C9DPEXCVZYM13corpora_" MIME-Version: 1.0 X-PMX-Version: 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2013.11.4.220614 Subject: Re: [Dime] Comments on open issues in draft-docdt-dime-ovli-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 01:29:31 -0000 --_000_6B7134B31289DC4FAF731D844122B36E2E7C9DPEXCVZYM13corpora_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Steve, Thank you for initiating the discussion on the open issues. >From a practical point of view, I recommend to have one thread per comment = and to numerate the open issues. Otherwise it will become difficult manage = all the answers and to follow the discussion if there are comments on diffe= rent parts of this long mail. It would even be an excellent opportunity to use the issue tracker tool :) Regards, Lionel De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de Ste= ve Donovan Envoy=E9 : mardi 5 novembre 2013 00:54 =C0 : doc-dt@ietf.org; dime@ietf.org Objet : [Dime] Comments on open issues in draft-docdt-dime-ovli-01.txt All, I've included the DIME list on this email as the plan is to start migrating= the Diameter Overload work from the design team to the DIME list now that = the -01 version of the draft is out. There are a number of open issues listed in the draft. I have listed them = here is some preliminary comments (preceded by srd>) on each. Note that this is just addressing issues that are explicitly called out in = the draft. There are likely other issues that will be raised as the draft = gets more review. Regards, Steve ---- Section 2 Server Farm A set of Diameter servers that can handle any request for a given set of Diameter applications. While these servers support the same set of applications, they do not necessarily all have the same capacity. An individual server farm might also support a subset of the users for a Diameter Realm. [OpenIssue: Is a server farm assumed to support a single realm? That is, does it support a set of applications in a single realm?] srd> Server farms are just groups of servers. There is nothing to prevent = a server from supporting multiple applications in multiple realms so the sa= me should be the case for server farms. Server Front End A Server Front End (SFE) is a role that can be performed by a Diameter agent -- either a relay or a proxy -- that sits between Diameter clients and a Server Farm. An SFE can perform various functions for the server farm it sits in front of. This includes some or all of the following functions: * Diameter Routing * Diameter layer load balancing * Load Management * Overload Management * Topology Hiding * Server Farm Identity Management [OpenIssue: We used the concept of a server farm and SFE for internal discussions. Do we still need those concepts to explain the mechanism? It doesn't seem like we use them much.] srd> We don't yet have the mechanism section written (section 5.5). This i= s where I would expect any wording dealing with server front ends that are = doing overload management to end up. The rest of the server front end lang= uage is context for that discussion. Section 3.1.1 Pseudo-session applications: While this class of application does not use the Diameter Session-ID AVP to correlate requests, there is an implied ordering of transactions defined by the application. The 3GPP defined Cx application [reference] is an example of a pseudo-session application. [OpenIssue: Do we assume that all requests in a pseudo-session typically need to go to the same server?] srd> The assumption is that the first request in a pseudo session is Destin= ation-Realm routed and the answer message contains an Origin-Host. The dia= meter id in received in the answer origin-host avp is then used as the dest= inition-host avp of subsequent requests. That's a long way of saying yes. Section 3.1.3 Correlated Session-Initiating Request: There are cases, most notably in the 3GPP PCC architecture, where multiple Diameter sessions are correlated and must be handled by the same Diameter server. This is a special case of a Session-Initiating Request. Gx CCR-I requests and Rx AAR messages are examples of correlated session- initiating requests. [OpenIssue: The previous paragraph needs references.] srd> We should add a reverence to the PCC architecture spec. Section 3.1.5 o Client --- Session Correlating Agent --- Multiple Equivalent Servers [OpenIssue: Do the "multiple equivalent servers" cases change for session-stateful applications? Do we need to distinguish equivalence for session-initiation requests vs intra-session requests?] srd> Given this is a PCC case, the only case where multiple equivalent serv= ers could be used for routing a request is for the session that results in = a binding. All other requests, both new session requests routed based on t= he binding and intra-session requests are routed to a specific server. A l= ong was of saying no. o DOC client --- agent --- Partitioned/Segmented DOC server o DOC client --- agent --- agent --- Partitioned/Segmented DOC server o DOC client --- edge agent --- edge agent --- DOC server [OpenIssue: In the last 3 list entries, are the agents DOC or non- DOC?] srd> A change to this has been suggested in the past and just hasn't made i= t into the document yet. We clearly need to include both DOC supporting ag= ents and non DOC supporting agents. Section 3.1.6 o This requirement also implies that if the Diameter agent does not impersonate the servers behind it, the Diameter dialogue is established between clients and servers and any overload information received by a client would be from a given server identified by the Origin-Host identity. [OpenIssue: We've discussed multiple situations where an agent might insert an OLR. I don't think we mean to force them to always perform topology hiding or SFIM in order to do so. We cannot assume that an OLR is always "from" or "about" the Origin-Host. Also, the section seems to assume that topology hiding agents act as b2b overload agents, but non-topology hiding agents never do. It don't think that's the right abstraction. It's possible that topology-hiding agents must do this, but I don't think we can preclude non-topology hiding agents from also doing it, at least some of the time.] srd> This is still an open issue on handling of "host" overload reports and= "realm" overload reports. OC-OLR ::=3D < AVP Header: TBD2 > < TimeStamp > [ Reduction-Percentage ] [ ValidityDuration ] [ ReportType ] * [ AVP ] The TimeStamp AVP indicates when the original OC-OLR AVP with the current content was created. It is possible to replay the same OC- OLR AVP multiple times between the overload endpoints, however, when the OC-OLR AVP content changes or the other information sending endpoint wants the receiving endpoint to update its overload control information, then the TimeStamp AVP MUST contain a new value. [OpenIssue: Is this necessarily a timestamp, or is it just a sequence number that can be implemented as a timestamp? Is this timestamp used to calculate expiration time? (propose no.). We should also consider whether either a timestamp or sequence number is needed for protection against replay attacks.] srd> The primary reason for the timestamp is to distinguish when an overloa= d report is new. A sequence number would word just as well, as long as it= is unique across space and time. I agree that this should not be used by = the reacting node to calculate expiration time. The reacting node should u= se its own local time plus the duration value in the overload report. We s= hould choose either timestamp or sequence number and go forward with our ch= oice. Section 4.5 The ReportType AVP is envisioned to be useful for situations where a reacting node needs to apply different overload treatments for different "types" of overload. For example, the reacting node(s) might need to throttle requests that are targeted to a specific server by the presence of a Destination-Host AVP than for requests that can be handled by any server in a realm. The example in Appendix C.3 illustrates this usage. [OpenIssue: There is an ongoing discussion about whether the ReportType AVP is the right way to solve that issue, and whether it's needed at all.] srd> This is part of the earlier issue from section 3.1.6. I propose we in= clude the reporttype AVP and the report type explicit. Section 4.6 The value of the Reduction-Percentage AVP is between zero (0) and one hundred (100). Values greater than 100 are interpreted as 100. The value of 100 means that no traffic is expected, i.e. the sender of the information is under a severe load and ceases to process any new messages. The value of 0 means that the sender of the information is in a stable state and has no requests to the other endpoint to apply any traffic abatement. [Open Issue: We should consider an algorithm independent way to end an overload condition. Perhaps setting the validitytime to zero? Counter comment; since the abatement is based on a specific algorithm, it is natural to indicate that from the abatement algorithm point of view status quo has been reached.] srd> I thought that we agreed to setting the validity duration to zero was = the mechanism to indicate that the overload condition had ended in the repo= rting node. If an overload control endpoint comes out of the 100 percent traffic reduction as a result of the overload report timing out, the following concerns are RECOMMENDED to be applied. The endpoint sending the traffic should be conservative and, for example, first send few "probe" messages to learn the overload condition of the other endpoint before converging to any traffic amount/rate decided by the sender. Similar concerns actually apply in all cases when the overload report times out unless the previous overload report stated 0 percent reduction. [Open Issue: It is still open whether we need an AVP to indicate the exact used traffic abatement algorithm. Currently it assumed that the reacting node is able to figure out what to do based on the Reducttion-Percentage AVP and possible other embedded information inside the OC-OLR AVP.] srd> There has been a lot of discussion on this. The current proposal is f= or each defined algorithm to define its own set of AVPs to carry informatio= n needed by the reacting node. This could be used to implicitly determine = the algorithm to be used. It is still an open issue whether the abatement = algorithm that the server will request is communicated in the capabilities = exchange. My proposal is that the server does indicated the preferred algo= rithm as part of capabilities negotiation. Section 5.3.1 The basic principle is that the request message initiating endpoint (i.e. the "reacting node") announces its support for the overload control mechanism by including in the request message the OC-Feature- Vector AVP with those capability flag bits set that it supports and is willing to use for this Diameter session (or transaction in a case of a non-session state maintaining applications). In a case of session maintaining applications the request message initiating endpoint does not need to do the capability announcement more than once for the lifetime of the Diameter session. In a case of non- session maintaining applications, it is RECOMMENDED that the request message initiating endpoint includes the capability announcement into every request regardless it has had prior message exchanges with the give remote endpoint. [OpenIssue: We need to think about the lifetime of a capabilities declaration. It's probably not the same as for a session. We have had proposals that the feature vector needs to go into every request sent by an OC node. For peer to peer cases, this can be associated with connection lifetime, but it's more complex for non-adjacent OC support.] srd> I think the proposal is that capabilities advertised last either forev= er or until the a changed OC-Feature-Vector AVP is sent, which ever comes f= irst. Section 5.5.2 [OpenIssue: did we now agree that e.g. a server can refrain sending OLR in answers based on some magical algorithm? (Note: We seem to have consensus that a server MAY repeat OLRs in subsequent messages, but is not required to do so, based on local policy.)] srd> We need to have wording to capture the behavior. I think wording some= thing like "the reporting node should send overload reports in all answer m= essages. The reporting node can choose to not include the overload report = in answers if it has the ability to determine that the reacting node that w= ill receive the answer message has already received the overload report. N= ote that determining which reacting nodes have received the overload report= is difficult in deployments that include agents." Section 8 The lack of end-to-end security features makes it far more difficult to establish trust in overload reports that originate from non- adjacent nodes. Any agents in the message path may insert or modify overload reports. Nodes must trust that their adjacent peers perform proper checks on overload reports from their peers, and so on, creating a transitive-trust requirement extending for potentially long chains of nodes. Network operators must determine if this transitive trust requirement is acceptable for their deployments. Nodes supporting Diameter overload control MUST give operators the ability to select which peers are trusted to deliver overload reports, and whether they are trusted to forward overload reports from non-adjacent nodes. [OpenIssue: This requires that a responding node be able to tell a peer-generated OLR from one generated by a non-adjacent node. One way of doing this would be to include the identity of the node that generated the report as part of the OLR] srd> We currently do not include the identity of the responding node in the= overload report. It is highly likely that it will be required as part of = the end-to-end security solution that is currently being worked. I propose= that we include the identity in the overload report based on this expectat= ion. [OpenIssue: Do we need further language about what rules an agent should apply before forwarding an OLR?] srd> I think we should but we don't yet have section 5.5 written and this i= s likely where this will go. The lack of end-to-end protection creates a tension between two requirements from the overload control requirements document. [I-D.ietf-dime-overload-reqs] Requirement 34 requires the ability to send overload reports across intermediaries (i.e. agents) that do not support overload control mechanism. Requirement 27 forbids the mechanism from adding new vulnerabilities or increasing the severity of existing ones. A non-supporting agent will most likely forward overload reports without inspecting them or applying any sort of validation or authorization. This makes the transitive trust issue considerably more of a problem. Without the ability to authenticate and integrity protect overload reports across a non-supporting agent, the mechanism cannot comply with both requirements. [OpenIssue: What do we want to do about this? Req27 is a normative MUST, while Req34 is "merely" a SHOULD. This would seem to imply that 27 has to take precedent. Can we say that overload reports MUST NOT be sent to and/or accepted from non-supporting agents until such time we can use end-to-end security?] srd> This needs to be discussed. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_6B7134B31289DC4FAF731D844122B36E2E7C9DPEXCVZYM13corpora_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Steve,

 <= /p>

Thank you = for initiating the discussion on the open issues.

 = ;

From a pra= ctical point of view, I recommend to have one thread per comment and to num= erate the open issues. Otherwise it will become difficult manage all the answers and to follow the discussion if there are comments = on different parts of this long mail.

 = ;

It would e= ven be an excellent opportunity to use the issue tracker tool J

 = ;

Regards,

 = ;

Lionel

 = ;

De := dime-bounces@ietf.org [mailto:dime-bounces@ie= tf.org] De la part de Steve Donovan
Envoy=E9 : mardi 5 novembre 2013 00:54
=C0 : doc-dt@ietf.org; dime@ietf.org
Objet : [Dime] Comments on open issues in draft-docdt-dime-ovli= -01.txt

 

All,

I've included the DIME list on this email as the plan is to start migrating= the Diameter Overload work from the design team to the DIME list now that = the -01 version of the draft is out.

There are a number of open issues listed in the draft.  I have listed = them here is some preliminary comments (preceded by srd>) on each.

Note that this is just addressing issues that are explicitly called out in = the draft.  There are likely other issues that will be raised as the d= raft gets more review.

Regards,

Steve

----

Section 2

   Server Farm
 
      A set of Diameter servers that can hand=
le any request for a given
      set of Diameter applications.  Whi=
le these servers support the
      same set of applications, they do not n=
ecessarily all have the
      same capacity.  An individual serv=
er farm might also support a
      subset of the users for a Diameter Real=
m.
 
      [OpenIssue: Is a server farm assumed to=
 support a single realm?
      That is, does it support a set of appli=
cations in a single realm?]

srd> Server farms = are just groups of servers.  There is nothing to prevent a server from= supporting multiple applications in multiple realms so the same should be = the case for server farms.

   Server Front End
 
      A Server Front End (SFE) is a role that=
 can be performed by a
      Diameter agent -- either a relay or a p=
roxy -- that sits between
      Diameter clients and a Server Farm.&nbs=
p; An SFE can perform various
      functions for the server farm it sits i=
n front of.  This includes
      some or all of the following functions:=
 
      *  Diameter Routing
 
      *  Diameter layer load balancing
 
      *  Load Management
 
      *  Overload Management<=
/pre>
 
      *  Topology Hiding
 
      *  Server Farm Identity Management=
 
      [OpenIssue: We used the concept of a se=
rver farm and SFE for
      internal discussions.  Do we still=
 need those concepts to explain
      the mechanism?  It doesn't seem li=
ke we use them much.]

srd> We don't yet = have the mechanism section written (section 5.5).  This is where I wou= ld expect any wording dealing with server front ends that are doing overloa= d management to end up.  The rest of the server front end language is context for that discussion.

Section 3.1.1

   Pseudo-session applications:  While this class of ap=
plication does
      not use the Diameter Session-ID AVP to =
correlate requests, there
      is an implied ordering of transactions =
defined by the application.
      The 3GPP defined Cx application [refere=
nce] is an example of a
      pseudo-session application.<=
/pre>
 
   [OpenIssue: Do we assume that all requests in a pseudo-se=
ssion
   typically need to go to the same server?]

srd> The assumptio= n is that the first request in a pseudo session is Destination-Realm routed= and the answer message contains an Origin-Host.  The diameter id in r= eceived in the answer origin-host avp is then used as the destinition-host avp of subsequent requests.  That's a lo= ng way of saying yes.

Section 3.1.3

   Correlated Session-Initiating Request:  There are ca=
ses, most notably
      in the 3GPP PCC architecture, where mul=
tiple Diameter sessions are
      correlated and must be handled by the s=
ame Diameter server.  This
      is a special case of a Session-Initiati=
ng Request.  Gx CCR-I
      requests and Rx AAR messages are exampl=
es of correlated session-
      initiating requests.
 
      [OpenIssue: The previous paragraph need=
s references.]

srd> We should add= a reverence to the PCC architecture spec.

Section 3.1.5

   o  Client --- Session Correlating Agent --- Multiple=
 Equivalent
      Servers
 
   [OpenIssue: Do the "multiple equivalent servers"=
; cases change for
   session-stateful applications?  Do we need to distin=
guish equivalence
   for session-initiation requests vs intra-session requests=
?]

srd> Given this is= a PCC case, the only case where multiple equivalent servers could be used = for routing a request is for the session that results in a binding.  A= ll other requests, both new session requests routed based on the binding and intra-session requests are routed to a spe= cific server.  A long was of saying no.

   o  DOC client --- agent --- Partitioned/Segmented DO=
C server
 
   o  DOC client --- agent --- agent --- Partitioned/Se=
gmented DOC
      server
   o  DOC client --- edge agent --- edge agent --- DOC =
server
 
   [OpenIssue: In the last 3 list entries, are the agents DO=
C or non-
   DOC?]

srd> A change to t= his has been suggested in the past and just hasn't made it into the documen= t yet.  We clearly need to include both DOC supporting agents and non = DOC supporting agents.

Section 3.1.6

   o  This requirement also implies that if the Diamete=
r agent does not
      impersonate the servers behind it, the =
Diameter dialogue is
      established between clients and servers=
 and any overload
      information received by a client would =
be from a given server
      identified by the Origin-Host identity.=
 
   [OpenIssue: We've discussed multiple situations where an =
agent might
   insert an OLR.  I don't think we mean to force them =
to always perform
   topology hiding or SFIM in order to do so.  We canno=
t assume that an
   OLR is always "from" or "about" the O=
rigin-Host.  Also, the section
   seems to assume that topology hiding agents act as b2b ov=
erload
   agents, but non-topology hiding agents never do.  It=
 don't think
   that's the right abstraction.  It's possible that to=
pology-hiding
   agents must do this, but I don't think we can preclude no=
n-topology
   hiding agents from also doing it, at least some of the ti=
me.]

srd> This is still= an open issue on handling of "host" overload reports and "r= ealm" overload reports. 

   OC-OLR ::=3D < AVP Header: TBD2 >
           &nbs=
p;  < TimeStamp >
           &nbs=
p;  [ Reduction-Percentage ]
           &nbs=
p;  [ ValidityDuration ]
           &nbs=
p;  [ ReportType ]
            * [=
 AVP ]
 
 
   The TimeStamp AVP indicates when the original OC-OLR AVP =
with the
   current content was created.  It is possible to repl=
ay the same OC-
   OLR AVP multiple times between the overload endpoints, ho=
wever, when
   the OC-OLR AVP content changes or the other information s=
ending
   endpoint wants the receiving endpoint to update its overl=
oad control
   information, then the TimeStamp AVP MUST contain a new va=
lue.
 
   [OpenIssue: Is this necessarily a timestamp, or is it jus=
t a sequence
   number that can be implemented as a timestamp?  Is t=
his timestamp
   used to calculate expiration time? (propose no.).  W=
e should also
   consider whether either a timestamp or sequence number is=
 needed for
   protection against replay attacks.]

srd> The primary reason for the timestamp is to d= istinguish when an overload report is new.   A sequence number wo= uld word just as well, as long as it is unique across space and time. = I agree that this should not be used by the reacting node to calculate expiration time.  The reacting node should use its = own local time plus the duration value in the overload report.  We sho= uld choose either timestamp or sequence number and go forward with our choi= ce.

Section 4.5

   The ReportType AVP is envisioned to be useful for situati=
ons where a
   reacting node needs to apply different overload treatment=
s for
   different "types" of overload.  For exampl=
e, the reacting node(s)
   might need to throttle requests that are targeted to a sp=
ecific
   server by the presence of a Destination-Host AVP than for=
 requests
   that can be handled by any server in a realm.  The e=
xample in
   Appendix C.3 illustrates this usage.
 
   [OpenIssue: There is an ongoing discussion about whether =
the
   ReportType AVP is the right way to solve that issue, and =
whether it's
   needed at all.]

srd> This is part = of the earlier issue from section 3.1.6.  I propose we include the rep= orttype AVP and the report type explicit.

Section 4.6

   The value of the Reduction-Percentage AVP is between zero=
 (0) and one
   hundred (100).  Values greater than 100 are interpre=
ted as 100.  The
   value of 100 means that no traffic is expected, i.e. the =
sender of
   the information is under a severe load and ceases to proc=
ess any new
   messages.  The value of 0 means that the sender of t=
he information is
   in a stable state and has no requests to the other endpoi=
nt to apply
   any traffic abatement.
 
   [Open Issue: We should consider an algorithm independent =
way to end
   an overload condition.  Perhaps setting the validity=
time to zero?
   Counter comment; since the abatement is based on a specif=
ic
   algorithm, it is natural to indicate that from the abatem=
ent
   algorithm point of view status quo has been reached.]

srd> I thought tha= t we agreed to setting the validity duration to zero was the mechanism to i= ndicate that the overload condition had ended in the reporting node.

   If an overload control endpoint comes out of the 100 perc=
ent traffic
   reduction as a result of the overload report timing out, =
the
   following concerns are RECOMMENDED to be applied.  T=
he endpoint
   sending the traffic should be conservative and, for examp=
le, first
   send few "probe" messages to learn the overload=
 condition of the
   other endpoint before converging to any traffic amount/ra=
te decided
   by the sender.  Similar concerns actually apply in a=
ll cases when the
   overload report times out unless the previous overload re=
port stated
   0 percent reduction.
 
   [Open Issue: It is still open whether we need an AVP to i=
ndicate the
   exact used traffic abatement algorithm.  Currently i=
t assumed that
   the reacting node is able to figure out what to do based =
on the
   Reducttion-Percentage AVP and possible other embedded inf=
ormation
   inside the OC-OLR AVP.]

srd> There has bee= n a lot of discussion on this.  The current proposal is for each defin= ed algorithm to define its own set of AVPs to carry information needed by t= he reacting node.  This could be used to implicitly determine the algorithm to be used.  It is still an open issue whethe= r the abatement algorithm that the server will request is communicated in t= he capabilities exchange.  My proposal is that the server does indicat= ed the preferred algorithm as part of capabilities negotiation.

Section 5.3.1

   The basic principle is that the request message initiatin=
g endpoint
   (i.e. the "reacting node") announces its suppor=
t for the overload
   control mechanism by including in the request message the=
 OC-Feature-
   Vector AVP with those capability flag bits set that it su=
pports and
   is willing to use for this Diameter session (or transacti=
on in a case
   of a non-session state maintaining applications).  I=
n a case of
   session maintaining applications the request message init=
iating
   endpoint does not need to do the capability announcement =
more than
   once for the lifetime of the Diameter session.  In a=
 case of non-
   session maintaining applications, it is RECOMMENDED that =
the request
   message initiating endpoint includes the capability annou=
ncement into
   every request regardless it has had prior message exchang=
es with the
   give remote endpoint.
 
   [OpenIssue: We need to think about the lifetime of a capa=
bilities
   declaration.  It's probably not the same as for a se=
ssion.  We have
   had proposals that the feature vector needs to go into ev=
ery request
   sent by an OC node.  For peer to peer cases, this ca=
n be associated
   with connection lifetime, but it's more complex for non-a=
djacent OC
   support.]

srd> I think the proposal is that capabilities ad= vertised last either forever or until the a changed OC-Feature-Vector AVP i= s sent, which ever comes first.

Section 5.5.2

   [OpenIssue: did we now agree that e.g. a server can refra=
in sending
   OLR in answers based on some magical algorithm?  (No=
te: We seem to
   have consensus that a server MAY repeat OLRs in subsequen=
t messages,
   but is not required to do so, based on local policy.)]

srd> We need to ha= ve wording to capture the behavior.  I think wording something like &q= uot;the reporting node should send overload reports in all answer messages.=   The reporting node can choose to not include the overload report in answers if it has the ability to determine that the rea= cting node that will receive the answer message has already received the ov= erload report.  Note that determining which reacting nodes have receiv= ed the overload report is difficult in deployments that include agents."

Section 8

   The lack of end-to-end security features makes it far mor=
e difficult
   to establish trust in overload reports that originate fro=
m non-
   adjacent nodes.  Any agents in the message path may =
insert or modify
   overload reports.  Nodes must trust that their adjac=
ent peers perform
   proper checks on overload reports from their peers, and s=
o on,
   creating a transitive-trust requirement extending for pot=
entially
   long chains of nodes.  Network operators must determ=
ine if this
   transitive trust requirement is acceptable for their depl=
oyments.
   Nodes supporting Diameter overload control MUST give oper=
ators the
   ability to select which peers are trusted to deliver over=
load
   reports, and whether they are trusted to forward overload=
 reports
   from non-adjacent nodes.
 
   [OpenIssue: This requires that a responding node be able =
to tell a
   peer-generated OLR from one generated by a non-adjacent n=
ode.  One
   way of doing this would be to include the identity of the=
 node that
   generated the report as part of the OLR]

srd> We currently do not include the identity of = the responding node in the overload report.  It is highly likely that = it will be required as part of the end-to-end security solution that is cur= rently being worked.  I propose that we include the identity in the overload report based on this expectation.<= /p>

   [OpenIssue: Do we need further language about what rules =
an agent
   should apply before forwarding an OLR?]

srd> I think we sh= ould but we don't yet have section 5.5 written and this is likely where thi= s will go. 

      The lack of end-to-end protection =
creates a tension between two
      requirements from the overload control =
requirements document.
      [I-D.ietf-dime-overload-reqs] Requireme=
nt 34 requires the ability
      to send overload reports across interme=
diaries (i.e. agents) that
      do not support overload control mechani=
sm.  Requirement 27 forbids
      the mechanism from adding new vulnerabi=
lities or increasing the
      severity of existing ones.  A non-=
supporting agent will most
      likely forward overload reports without=
 inspecting them or
      applying any sort of validation or auth=
orization.  This makes the
      transitive trust issue considerably mor=
e of a problem.  Without
      the ability to authenticate and integri=
ty protect overload reports
      across a non-supporting agent, the mech=
anism cannot comply with
      both requirements.
 
      [OpenIssue: What do we want to do about=
 this?  Req27 is a
      normative MUST, while Req34 is "me=
rely" a SHOULD.  This would seem
      to imply that 27 has to take precedent.=
  Can we say that overload
      reports MUST NOT be sent to and/or acce=
pted from non-supporting
      agents until such time we can use end-t=
o-end security?]

srd> This needs to= be discussed.






______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_6B7134B31289DC4FAF731D844122B36E2E7C9DPEXCVZYM13corpora_-- From lionel.morand@orange.com Mon Nov 4 17:34:26 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 26DB721E82E6; Mon, 4 Nov 2013 17:34:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.474 X-Spam-Level: X-Spam-Status: No, score=-2.474 tagged_above=-999 required=5 tests=[AWL=0.123, BAYES_00=-2.599, HTML_MESSAGE=0.001, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCuIif7GsiS2; Mon, 4 Nov 2013 17:34:21 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6BE21E80EE; Mon, 4 Nov 2013 17:34:15 -0800 (PST) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id C7A402AC387; Tue, 5 Nov 2013 02:34:14 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id B0EF438403C; Tue, 5 Nov 2013 02:34:11 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Tue, 5 Nov 2013 02:34:08 +0100 From: To: MORAND Lionel IMT/OLN , Steve Donovan , "doc-dt@ietf.org" , "dime@ietf.org" Thread-Topic: [doc-dt] [Dime] Comments on open issues in draft-docdt-dime-ovli-01.txt Thread-Index: AQHO2cZ8Xw9vnH3h/Ey9uRlalVaGQJoV2pIw Date: Tue, 5 Nov 2013 01:34:07 +0000 Message-ID: <9174_1383615251_52784B13_9174_3058_1_6168d504-7fca-4cb9-b705-f7dd0f954fbd@PEXCVZYH01.corporate.adroot.infra.ftgroup> References: <527833AD.4030508@usdonovans.com> <30128_1383614963_527849F3_30128_10279_1_6B7134B31289DC4FAF731D844122B36E2E7C9D@PEXCVZYM13.corporate.adroot.infra.ftgroup> In-Reply-To: <30128_1383614963_527849F3_30128_10279_1_6B7134B31289DC4FAF731D844122B36E2E7C9D@PEXCVZYM13.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.1] Content-Type: multipart/alternative; boundary="_000_6168d5047fca4cb9b705f7dd0f954fbdPEXCVZYH01corporateadro_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.5.2115 X-Mailman-Approved-At: Mon, 04 Nov 2013 17:53:21 -0800 Subject: Re: [Dime] [doc-dt] Comments on open issues in draft-docdt-dime-ovli-01.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 01:34:26 -0000 --_000_6168d5047fca4cb9b705f7dd0f954fbdPEXCVZYH01corporateadro_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Useful link for new tickets: http://tools.ietf.org/wg/dime/trac/newticket Lionel De : doc-dt-bounces@ietf.org [mailto:doc-dt-bounces@ietf.org] De la part de= lionel.morand@orange.com Envoy=E9 : mardi 5 novembre 2013 02:29 =C0 : Steve Donovan; doc-dt@ietf.org; dime@ietf.org Objet : Re: [doc-dt] [Dime] Comments on open issues in draft-docdt-dime-ovl= i-01.txt Hi Steve, Thank you for initiating the discussion on the open issues. >From a practical point of view, I recommend to have one thread per comment = and to numerate the open issues. Otherwise it will become difficult manage = all the answers and to follow the discussion if there are comments on diffe= rent parts of this long mail. It would even be an excellent opportunity to use the issue tracker tool :) Regards, Lionel De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de Ste= ve Donovan Envoy=E9 : mardi 5 novembre 2013 00:54 =C0 : doc-dt@ietf.org; dime@ietf.org Objet : [Dime] Comments on open issues in draft-docdt-dime-ovli-01.txt All, I've included the DIME list on this email as the plan is to start migrating= the Diameter Overload work from the design team to the DIME list now that = the -01 version of the draft is out. There are a number of open issues listed in the draft. I have listed them = here is some preliminary comments (preceded by srd>) on each. Note that this is just addressing issues that are explicitly called out in = the draft. There are likely other issues that will be raised as the draft = gets more review. Regards, Steve ---- Section 2 Server Farm A set of Diameter servers that can handle any request for a given set of Diameter applications. While these servers support the same set of applications, they do not necessarily all have the same capacity. An individual server farm might also support a subset of the users for a Diameter Realm. [OpenIssue: Is a server farm assumed to support a single realm? That is, does it support a set of applications in a single realm?] srd> Server farms are just groups of servers. There is nothing to prevent = a server from supporting multiple applications in multiple realms so the sa= me should be the case for server farms. Server Front End A Server Front End (SFE) is a role that can be performed by a Diameter agent -- either a relay or a proxy -- that sits between Diameter clients and a Server Farm. An SFE can perform various functions for the server farm it sits in front of. This includes some or all of the following functions: * Diameter Routing * Diameter layer load balancing * Load Management * Overload Management * Topology Hiding * Server Farm Identity Management [OpenIssue: We used the concept of a server farm and SFE for internal discussions. Do we still need those concepts to explain the mechanism? It doesn't seem like we use them much.] srd> We don't yet have the mechanism section written (section 5.5). This i= s where I would expect any wording dealing with server front ends that are = doing overload management to end up. The rest of the server front end lang= uage is context for that discussion. Section 3.1.1 Pseudo-session applications: While this class of application does not use the Diameter Session-ID AVP to correlate requests, there is an implied ordering of transactions defined by the application. The 3GPP defined Cx application [reference] is an example of a pseudo-session application. [OpenIssue: Do we assume that all requests in a pseudo-session typically need to go to the same server?] srd> The assumption is that the first request in a pseudo session is Destin= ation-Realm routed and the answer message contains an Origin-Host. The dia= meter id in received in the answer origin-host avp is then used as the dest= inition-host avp of subsequent requests. That's a long way of saying yes. Section 3.1.3 Correlated Session-Initiating Request: There are cases, most notably in the 3GPP PCC architecture, where multiple Diameter sessions are correlated and must be handled by the same Diameter server. This is a special case of a Session-Initiating Request. Gx CCR-I requests and Rx AAR messages are examples of correlated session- initiating requests. [OpenIssue: The previous paragraph needs references.] srd> We should add a reverence to the PCC architecture spec. Section 3.1.5 o Client --- Session Correlating Agent --- Multiple Equivalent Servers [OpenIssue: Do the "multiple equivalent servers" cases change for session-stateful applications? Do we need to distinguish equivalence for session-initiation requests vs intra-session requests?] srd> Given this is a PCC case, the only case where multiple equivalent serv= ers could be used for routing a request is for the session that results in = a binding. All other requests, both new session requests routed based on t= he binding and intra-session requests are routed to a specific server. A l= ong was of saying no. o DOC client --- agent --- Partitioned/Segmented DOC server o DOC client --- agent --- agent --- Partitioned/Segmented DOC server o DOC client --- edge agent --- edge agent --- DOC server [OpenIssue: In the last 3 list entries, are the agents DOC or non- DOC?] srd> A change to this has been suggested in the past and just hasn't made i= t into the document yet. We clearly need to include both DOC supporting ag= ents and non DOC supporting agents. Section 3.1.6 o This requirement also implies that if the Diameter agent does not impersonate the servers behind it, the Diameter dialogue is established between clients and servers and any overload information received by a client would be from a given server identified by the Origin-Host identity. [OpenIssue: We've discussed multiple situations where an agent might insert an OLR. I don't think we mean to force them to always perform topology hiding or SFIM in order to do so. We cannot assume that an OLR is always "from" or "about" the Origin-Host. Also, the section seems to assume that topology hiding agents act as b2b overload agents, but non-topology hiding agents never do. It don't think that's the right abstraction. It's possible that topology-hiding agents must do this, but I don't think we can preclude non-topology hiding agents from also doing it, at least some of the time.] srd> This is still an open issue on handling of "host" overload reports and= "realm" overload reports. OC-OLR ::=3D < AVP Header: TBD2 > < TimeStamp > [ Reduction-Percentage ] [ ValidityDuration ] [ ReportType ] * [ AVP ] The TimeStamp AVP indicates when the original OC-OLR AVP with the current content was created. It is possible to replay the same OC- OLR AVP multiple times between the overload endpoints, however, when the OC-OLR AVP content changes or the other information sending endpoint wants the receiving endpoint to update its overload control information, then the TimeStamp AVP MUST contain a new value. [OpenIssue: Is this necessarily a timestamp, or is it just a sequence number that can be implemented as a timestamp? Is this timestamp used to calculate expiration time? (propose no.). We should also consider whether either a timestamp or sequence number is needed for protection against replay attacks.] srd> The primary reason for the timestamp is to distinguish when an overloa= d report is new. A sequence number would word just as well, as long as it= is unique across space and time. I agree that this should not be used by = the reacting node to calculate expiration time. The reacting node should u= se its own local time plus the duration value in the overload report. We s= hould choose either timestamp or sequence number and go forward with our ch= oice. Section 4.5 The ReportType AVP is envisioned to be useful for situations where a reacting node needs to apply different overload treatments for different "types" of overload. For example, the reacting node(s) might need to throttle requests that are targeted to a specific server by the presence of a Destination-Host AVP than for requests that can be handled by any server in a realm. The example in Appendix C.3 illustrates this usage. [OpenIssue: There is an ongoing discussion about whether the ReportType AVP is the right way to solve that issue, and whether it's needed at all.] srd> This is part of the earlier issue from section 3.1.6. I propose we in= clude the reporttype AVP and the report type explicit. Section 4.6 The value of the Reduction-Percentage AVP is between zero (0) and one hundred (100). Values greater than 100 are interpreted as 100. The value of 100 means that no traffic is expected, i.e. the sender of the information is under a severe load and ceases to process any new messages. The value of 0 means that the sender of the information is in a stable state and has no requests to the other endpoint to apply any traffic abatement. [Open Issue: We should consider an algorithm independent way to end an overload condition. Perhaps setting the validitytime to zero? Counter comment; since the abatement is based on a specific algorithm, it is natural to indicate that from the abatement algorithm point of view status quo has been reached.] srd> I thought that we agreed to setting the validity duration to zero was = the mechanism to indicate that the overload condition had ended in the repo= rting node. If an overload control endpoint comes out of the 100 percent traffic reduction as a result of the overload report timing out, the following concerns are RECOMMENDED to be applied. The endpoint sending the traffic should be conservative and, for example, first send few "probe" messages to learn the overload condition of the other endpoint before converging to any traffic amount/rate decided by the sender. Similar concerns actually apply in all cases when the overload report times out unless the previous overload report stated 0 percent reduction. [Open Issue: It is still open whether we need an AVP to indicate the exact used traffic abatement algorithm. Currently it assumed that the reacting node is able to figure out what to do based on the Reducttion-Percentage AVP and possible other embedded information inside the OC-OLR AVP.] srd> There has been a lot of discussion on this. The current proposal is f= or each defined algorithm to define its own set of AVPs to carry informatio= n needed by the reacting node. This could be used to implicitly determine = the algorithm to be used. It is still an open issue whether the abatement = algorithm that the server will request is communicated in the capabilities = exchange. My proposal is that the server does indicated the preferred algo= rithm as part of capabilities negotiation. Section 5.3.1 The basic principle is that the request message initiating endpoint (i.e. the "reacting node") announces its support for the overload control mechanism by including in the request message the OC-Feature- Vector AVP with those capability flag bits set that it supports and is willing to use for this Diameter session (or transaction in a case of a non-session state maintaining applications). In a case of session maintaining applications the request message initiating endpoint does not need to do the capability announcement more than once for the lifetime of the Diameter session. In a case of non- session maintaining applications, it is RECOMMENDED that the request message initiating endpoint includes the capability announcement into every request regardless it has had prior message exchanges with the give remote endpoint. [OpenIssue: We need to think about the lifetime of a capabilities declaration. It's probably not the same as for a session. We have had proposals that the feature vector needs to go into every request sent by an OC node. For peer to peer cases, this can be associated with connection lifetime, but it's more complex for non-adjacent OC support.] srd> I think the proposal is that capabilities advertised last either forev= er or until the a changed OC-Feature-Vector AVP is sent, which ever comes f= irst. Section 5.5.2 [OpenIssue: did we now agree that e.g. a server can refrain sending OLR in answers based on some magical algorithm? (Note: We seem to have consensus that a server MAY repeat OLRs in subsequent messages, but is not required to do so, based on local policy.)] srd> We need to have wording to capture the behavior. I think wording some= thing like "the reporting node should send overload reports in all answer m= essages. The reporting node can choose to not include the overload report = in answers if it has the ability to determine that the reacting node that w= ill receive the answer message has already received the overload report. N= ote that determining which reacting nodes have received the overload report= is difficult in deployments that include agents." Section 8 The lack of end-to-end security features makes it far more difficult to establish trust in overload reports that originate from non- adjacent nodes. Any agents in the message path may insert or modify overload reports. Nodes must trust that their adjacent peers perform proper checks on overload reports from their peers, and so on, creating a transitive-trust requirement extending for potentially long chains of nodes. Network operators must determine if this transitive trust requirement is acceptable for their deployments. Nodes supporting Diameter overload control MUST give operators the ability to select which peers are trusted to deliver overload reports, and whether they are trusted to forward overload reports from non-adjacent nodes. [OpenIssue: This requires that a responding node be able to tell a peer-generated OLR from one generated by a non-adjacent node. One way of doing this would be to include the identity of the node that generated the report as part of the OLR] srd> We currently do not include the identity of the responding node in the= overload report. It is highly likely that it will be required as part of = the end-to-end security solution that is currently being worked. I propose= that we include the identity in the overload report based on this expectat= ion. [OpenIssue: Do we need further language about what rules an agent should apply before forwarding an OLR?] srd> I think we should but we don't yet have section 5.5 written and this i= s likely where this will go. The lack of end-to-end protection creates a tension between two requirements from the overload control requirements document. [I-D.ietf-dime-overload-reqs] Requirement 34 requires the ability to send overload reports across intermediaries (i.e. agents) that do not support overload control mechanism. Requirement 27 forbids the mechanism from adding new vulnerabilities or increasing the severity of existing ones. A non-supporting agent will most likely forward overload reports without inspecting them or applying any sort of validation or authorization. This makes the transitive trust issue considerably more of a problem. Without the ability to authenticate and integrity protect overload reports across a non-supporting agent, the mechanism cannot comply with both requirements. [OpenIssue: What do we want to do about this? Req27 is a normative MUST, while Req34 is "merely" a SHOULD. This would seem to imply that 27 has to take precedent. Can we say that overload reports MUST NOT be sent to and/or accepted from non-supporting agents until such time we can use end-to-end security?] srd> This needs to be discussed. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_6168d5047fca4cb9b705f7dd0f954fbdPEXCVZYH01corporateadro_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Useful lin= k for new tickets: http://tools.ietf.= org/wg/dime/trac/newticket

 = ;

Lionel

 = ;

De := doc-dt-bounces@ietf.org [mailto:doc-dt-bounce= s@ietf.org] De la part de lionel.morand@orange.com
Envoy=E9 : mardi 5 novembre 2013 02:29
=C0 : Steve Donovan; doc-dt@ietf.org; dime@ietf.org
Objet : Re: [doc-dt] [Dime] Comments on open issues in draft-do= cdt-dime-ovli-01.txt

 

Hi Steve,

 <= /p>

Thank you = for initiating the discussion on the open issues.

 = ;

From a pra= ctical point of view, I recommend to have one thread per comment and to num= erate the open issues. Otherwise it will become difficult manage all the answers and to follow the discussion if there are comments = on different parts of this long mail.

 = ;

It would e= ven be an excellent opportunity to use the issue tracker tool J

 = ;

Regards,

 = ;

Lionel

 = ;

De := dime-bounces@ietf.org [mailto:dime-bounces@ie= tf.org] De la part de Steve Donovan
Envoy=E9 : mardi 5 novembre 2013 00:54
=C0 : doc-dt@ietf.org; dime@ietf.org
Objet : [Dime] Comments on open issues in draft-docdt-dime-ovli= -01.txt

 

All,

I've included the DIME list on this email as the plan is to start migrating= the Diameter Overload work from the design team to the DIME list now that = the -01 version of the draft is out.

There are a number of open issues listed in the draft.  I have listed = them here is some preliminary comments (preceded by srd>) on each.

Note that this is just addressing issues that are explicitly called out in = the draft.  There are likely other issues that will be raised as the d= raft gets more review.

Regards,

Steve

----

Section 2

   Server Farm
 
      A set of Diameter servers that can hand=
le any request for a given
      set of Diameter applications.  Whi=
le these servers support the
      same set of applications, they do not n=
ecessarily all have the
      same capacity.  An individual serv=
er farm might also support a
      subset of the users for a Diameter Real=
m.
 
      [OpenIssue: Is a server farm assumed to=
 support a single realm?
      That is, does it support a set of appli=
cations in a single realm?]

srd> Server farms = are just groups of servers.  There is nothing to prevent a server from= supporting multiple applications in multiple realms so the same should be = the case for server farms.

   Server Front End
 
      A Server Front End (SFE) is a role that=
 can be performed by a
      Diameter agent -- either a relay or a p=
roxy -- that sits between
      Diameter clients and a Server Farm.&nbs=
p; An SFE can perform various
      functions for the server farm it sits i=
n front of.  This includes
      some or all of the following functions:=
 
      *  Diameter Routing
 
      *  Diameter layer load balancing
 
      *  Load Management
 
      *  Overload Management<=
/pre>
 
      *  Topology Hiding
 
      *  Server Farm Identity Management=
 
      [OpenIssue: We used the concept of a se=
rver farm and SFE for
      internal discussions.  Do we still=
 need those concepts to explain
      the mechanism?  It doesn't seem li=
ke we use them much.]

srd> We don't yet = have the mechanism section written (section 5.5).  This is where I wou= ld expect any wording dealing with server front ends that are doing overloa= d management to end up.  The rest of the server front end language is context for that discussion.

Section 3.1.1

   Pseudo-session applications:  While this class of ap=
plication does
      not use the Diameter Session-ID AVP to =
correlate requests, there
      is an implied ordering of transactions =
defined by the application.
      The 3GPP defined Cx application [refere=
nce] is an example of a
      pseudo-session application.<=
/pre>
 
   [OpenIssue: Do we assume that all requests in a pseudo-se=
ssion
   typically need to go to the same server?]

srd> The assumptio= n is that the first request in a pseudo session is Destination-Realm routed= and the answer message contains an Origin-Host.  The diameter id in r= eceived in the answer origin-host avp is then used as the destinition-host avp of subsequent requests.  That's a lo= ng way of saying yes.

Section 3.1.3

   Correlated Session-Initiating Request:  There are ca=
ses, most notably
      in the 3GPP PCC architecture, where mul=
tiple Diameter sessions are
      correlated and must be handled by the s=
ame Diameter server.  This
      is a special case of a Session-Initiati=
ng Request.  Gx CCR-I
      requests and Rx AAR messages are exampl=
es of correlated session-
      initiating requests.
 
      [OpenIssue: The previous paragraph need=
s references.]

srd> We should add= a reverence to the PCC architecture spec.

Section 3.1.5

   o  Client --- Session Correlating Agent --- Multiple=
 Equivalent
      Servers
 
   [OpenIssue: Do the "multiple equivalent servers"=
; cases change for
   session-stateful applications?  Do we need to distin=
guish equivalence
   for session-initiation requests vs intra-session requests=
?]

srd> Given this is= a PCC case, the only case where multiple equivalent servers could be used = for routing a request is for the session that results in a binding.  A= ll other requests, both new session requests routed based on the binding and intra-session requests are routed to a spe= cific server.  A long was of saying no.

   o  DOC client --- agent --- Partitioned/Segmented DO=
C server
 
   o  DOC client --- agent --- agent --- Partitioned/Se=
gmented DOC
      server
   o  DOC client --- edge agent --- edge agent --- DOC =
server
 
   [OpenIssue: In the last 3 list entries, are the agents DO=
C or non-
   DOC?]

srd> A change to t= his has been suggested in the past and just hasn't made it into the documen= t yet.  We clearly need to include both DOC supporting agents and non = DOC supporting agents.

Section 3.1.6

   o  This requirement also implies that if the Diamete=
r agent does not
      impersonate the servers behind it, the =
Diameter dialogue is
      established between clients and servers=
 and any overload
      information received by a client would =
be from a given server
      identified by the Origin-Host identity.=
 
   [OpenIssue: We've discussed multiple situations where an =
agent might
   insert an OLR.  I don't think we mean to force them =
to always perform
   topology hiding or SFIM in order to do so.  We canno=
t assume that an
   OLR is always "from" or "about" the O=
rigin-Host.  Also, the section
   seems to assume that topology hiding agents act as b2b ov=
erload
   agents, but non-topology hiding agents never do.  It=
 don't think
   that's the right abstraction.  It's possible that to=
pology-hiding
   agents must do this, but I don't think we can preclude no=
n-topology
   hiding agents from also doing it, at least some of the ti=
me.]

srd> This is still= an open issue on handling of "host" overload reports and "r= ealm" overload reports. 

   OC-OLR ::=3D < AVP Header: TBD2 >
           &nbs=
p;  < TimeStamp >
           &nbs=
p;  [ Reduction-Percentage ]
           &nbs=
p;  [ ValidityDuration ]
           &nbs=
p;  [ ReportType ]
            * [=
 AVP ]
 
 
   The TimeStamp AVP indicates when the original OC-OLR AVP =
with the
   current content was created.  It is possible to repl=
ay the same OC-
   OLR AVP multiple times between the overload endpoints, ho=
wever, when
   the OC-OLR AVP content changes or the other information s=
ending
   endpoint wants the receiving endpoint to update its overl=
oad control
   information, then the TimeStamp AVP MUST contain a new va=
lue.
 
   [OpenIssue: Is this necessarily a timestamp, or is it jus=
t a sequence
   number that can be implemented as a timestamp?  Is t=
his timestamp
   used to calculate expiration time? (propose no.).  W=
e should also
   consider whether either a timestamp or sequence number is=
 needed for
   protection against replay attacks.]

srd> The primary reason for the timestamp is to d= istinguish when an overload report is new.   A sequence number wo= uld word just as well, as long as it is unique across space and time. = I agree that this should not be used by the reacting node to calculate expiration time.  The reacting node should use its = own local time plus the duration value in the overload report.  We sho= uld choose either timestamp or sequence number and go forward with our choi= ce.

Section 4.5

   The ReportType AVP is envisioned to be useful for situati=
ons where a
   reacting node needs to apply different overload treatment=
s for
   different "types" of overload.  For exampl=
e, the reacting node(s)
   might need to throttle requests that are targeted to a sp=
ecific
   server by the presence of a Destination-Host AVP than for=
 requests
   that can be handled by any server in a realm.  The e=
xample in
   Appendix C.3 illustrates this usage.
 
   [OpenIssue: There is an ongoing discussion about whether =
the
   ReportType AVP is the right way to solve that issue, and =
whether it's
   needed at all.]

srd> This is part = of the earlier issue from section 3.1.6.  I propose we include the rep= orttype AVP and the report type explicit.

Section 4.6

   The value of the Reduction-Percentage AVP is between zero=
 (0) and one
   hundred (100).  Values greater than 100 are interpre=
ted as 100.  The
   value of 100 means that no traffic is expected, i.e. the =
sender of
   the information is under a severe load and ceases to proc=
ess any new
   messages.  The value of 0 means that the sender of t=
he information is
   in a stable state and has no requests to the other endpoi=
nt to apply
   any traffic abatement.
 
   [Open Issue: We should consider an algorithm independent =
way to end
   an overload condition.  Perhaps setting the validity=
time to zero?
   Counter comment; since the abatement is based on a specif=
ic
   algorithm, it is natural to indicate that from the abatem=
ent
   algorithm point of view status quo has been reached.]

srd> I thought tha= t we agreed to setting the validity duration to zero was the mechanism to i= ndicate that the overload condition had ended in the reporting node.

   If an overload control endpoint comes out of the 100 perc=
ent traffic
   reduction as a result of the overload report timing out, =
the
   following concerns are RECOMMENDED to be applied.  T=
he endpoint
   sending the traffic should be conservative and, for examp=
le, first
   send few "probe" messages to learn the overload=
 condition of the
   other endpoint before converging to any traffic amount/ra=
te decided
   by the sender.  Similar concerns actually apply in a=
ll cases when the
   overload report times out unless the previous overload re=
port stated
   0 percent reduction.
 
   [Open Issue: It is still open whether we need an AVP to i=
ndicate the
   exact used traffic abatement algorithm.  Currently i=
t assumed that
   the reacting node is able to figure out what to do based =
on the
   Reducttion-Percentage AVP and possible other embedded inf=
ormation
   inside the OC-OLR AVP.]

srd> There has bee= n a lot of discussion on this.  The current proposal is for each defin= ed algorithm to define its own set of AVPs to carry information needed by t= he reacting node.  This could be used to implicitly determine the algorithm to be used.  It is still an open issue whethe= r the abatement algorithm that the server will request is communicated in t= he capabilities exchange.  My proposal is that the server does indicat= ed the preferred algorithm as part of capabilities negotiation.

Section 5.3.1

   The basic principle is that the request message initiatin=
g endpoint
   (i.e. the "reacting node") announces its suppor=
t for the overload
   control mechanism by including in the request message the=
 OC-Feature-
   Vector AVP with those capability flag bits set that it su=
pports and
   is willing to use for this Diameter session (or transacti=
on in a case
   of a non-session state maintaining applications).  I=
n a case of
   session maintaining applications the request message init=
iating
   endpoint does not need to do the capability announcement =
more than
   once for the lifetime of the Diameter session.  In a=
 case of non-
   session maintaining applications, it is RECOMMENDED that =
the request
   message initiating endpoint includes the capability annou=
ncement into
   every request regardless it has had prior message exchang=
es with the
   give remote endpoint.
 
   [OpenIssue: We need to think about the lifetime of a capa=
bilities
   declaration.  It's probably not the same as for a se=
ssion.  We have
   had proposals that the feature vector needs to go into ev=
ery request
   sent by an OC node.  For peer to peer cases, this ca=
n be associated
   with connection lifetime, but it's more complex for non-a=
djacent OC
   support.]

srd> I think the proposal is that capabilities ad= vertised last either forever or until the a changed OC-Feature-Vector AVP i= s sent, which ever comes first.

Section 5.5.2

   [OpenIssue: did we now agree that e.g. a server can refra=
in sending
   OLR in answers based on some magical algorithm?  (No=
te: We seem to
   have consensus that a server MAY repeat OLRs in subsequen=
t messages,
   but is not required to do so, based on local policy.)]

srd> We need to ha= ve wording to capture the behavior.  I think wording something like &q= uot;the reporting node should send overload reports in all answer messages.=   The reporting node can choose to not include the overload report in answers if it has the ability to determine that the rea= cting node that will receive the answer message has already received the ov= erload report.  Note that determining which reacting nodes have receiv= ed the overload report is difficult in deployments that include agents."

Section 8

   The lack of end-to-end security features makes it far mor=
e difficult
   to establish trust in overload reports that originate fro=
m non-
   adjacent nodes.  Any agents in the message path may =
insert or modify
   overload reports.  Nodes must trust that their adjac=
ent peers perform
   proper checks on overload reports from their peers, and s=
o on,
   creating a transitive-trust requirement extending for pot=
entially
   long chains of nodes.  Network operators must determ=
ine if this
   transitive trust requirement is acceptable for their depl=
oyments.
   Nodes supporting Diameter overload control MUST give oper=
ators the
   ability to select which peers are trusted to deliver over=
load
   reports, and whether they are trusted to forward overload=
 reports
   from non-adjacent nodes.
 
   [OpenIssue: This requires that a responding node be able =
to tell a
   peer-generated OLR from one generated by a non-adjacent n=
ode.  One
   way of doing this would be to include the identity of the=
 node that
   generated the report as part of the OLR]

srd> We currently do not include the identity of = the responding node in the overload report.  It is highly likely that = it will be required as part of the end-to-end security solution that is cur= rently being worked.  I propose that we include the identity in the overload report based on this expectation.<= /p>

   [OpenIssue: Do we need further language about what rules =
an agent
   should apply before forwarding an OLR?]

srd> I think we sh= ould but we don't yet have section 5.5 written and this is likely where thi= s will go. 

      The lack of end-to-end protection =
creates a tension between two
      requirements from the overload control =
requirements document.
      [I-D.ietf-dime-overload-reqs] Requireme=
nt 34 requires the ability
      to send overload reports across interme=
diaries (i.e. agents) that
      do not support overload control mechani=
sm.  Requirement 27 forbids
      the mechanism from adding new vulnerabi=
lities or increasing the
      severity of existing ones.  A non-=
supporting agent will most
      likely forward overload reports without=
 inspecting them or
      applying any sort of validation or auth=
orization.  This makes the
      transitive trust issue considerably mor=
e of a problem.  Without
      the ability to authenticate and integri=
ty protect overload reports
      across a non-supporting agent, the mech=
anism cannot comply with
      both requirements.
 
      [OpenIssue: What do we want to do about=
 this?  Req27 is a
      normative MUST, while Req34 is "me=
rely" a SHOULD.  This would seem
      to imply that 27 has to take precedent.=
  Can we say that overload
      reports MUST NOT be sent to and/or acce=
pted from non-supporting
      agents until such time we can use end-t=
o-end security?]

srd> This needs to= be discussed.





______________________________________________________________________=
___________________________________________________
 
Ce message et ses pieces jointes peuvent contenir des informations con=
fidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez=
 recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messag=
es electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deform=
e ou falsifie. Merci.
 
This message and its attachments may contain confidential or privilege=
d information that may be protected by law;
they should not be distributed, used or copied without authorisation.<=
o:p>
If you have received this email in error, please notify the sender and=
 delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have =
been modified, changed or falsified.
Thank you.
______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_6168d5047fca4cb9b705f7dd0f954fbdPEXCVZYH01corporateadro_-- From srdonovan@usdonovans.com Tue Nov 5 03:52:51 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56C1811E8280; Tue, 5 Nov 2013 03:52:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[AWL=0.001, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hq3ii7vFtmft; Tue, 5 Nov 2013 03:52:46 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [192.249.113.76]) by ietfa.amsl.com (Postfix) with ESMTP id D208A11E827D; Tue, 5 Nov 2013 03:52:44 -0800 (PST) Received: from dhcp-91b2.meeting.ietf.org ([31.133.145.178]:56454) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1VdfBb-00069L-De; Tue, 05 Nov 2013 03:52:44 -0800 Message-ID: <5278DC09.5000100@usdonovans.com> Date: Tue, 05 Nov 2013 03:52:41 -0800 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: doc-dt@ietf.org, dime@ietf.org References: <56B66C39-C093-45D2-B10F-B115AD1C7C75@att.com> <527259C2.8080100@usdonovans.com> <26C84DFD55BC3040A45BF70926E55F25867D2DE3@szxeml512-mbx.china.huawei.com> <1732_1383579176_5277BE28_1732_124_1_6B7134B31289DC4FAF731D844122B36E2E61ED@PEXCVZYM13.corporate.adroot.infra.ftgroup> <26C84DFD55BC3040A45BF70926E55F25867D53B3@szxeml512-mbx.china.huawei.com> In-Reply-To: <26C84DFD55BC3040A45BF70926E55F25867D53B3@szxeml512-mbx.china.huawei.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Subject: Re: [Dime] [doc-dt] Capability "Advertisement" X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 11:52:51 -0000 Added DIME list. Susan, Once we have more than one algorithm we have to have the ability to for the server to send overload parameters for the algorithm type being used. We have had a lot of conversation about the role of a server in selecting the algorithm to be used. There was never agreement on the assertion that it is a burden for a server to deal with clients supporting different algorithms. This is an inherent requirement that comes along with extensibility. Steve On 11/5/13, 3:14 AM, Shishufeng (Susan) wrote: > Hi Lionel, > > I missed the discussion regarding the proposal to define an Overload Report (AVP) per algo and was actually surprised at it. I ever thought we had enough discussion regarding if the server cares about the algorithm implemented by the client. I didn't see the value to have overload report per algorithm. This just adds much more burden on the server to do the conversion per client/algorithm which actually can be done by the client itself. > > Best Regards, > Susan > > -----Original Message----- > From: lionel.morand@orange.com [mailto:lionel.morand@orange.com] > Sent: Monday, November 04, 2013 11:33 PM > To: Shishufeng (Susan); Steve Donovan; doc-dt@ietf.org > Subject: RE: [doc-dt] Capability "Advertisement" > > Hi, > > As I have not received any answer, I try again: > > As said during the call, OK for OC-Feature AVP in answer, especially for enabling client to discover that a server DO NOT support any overload control mechanism. > The existing text is clear on this point: > > Once the endpoint that initiated the request message receives an > answer message from the remote endpoint, it can detect from the > received answer message whether the remote endpoint supports the > overload control solution and in a case it does, what features are > supported. > > About the proposal to define an Overload Report (AVP) per algo, is it something that you would agree on? > Of course, extensibility of each grouped AVP would have to be ensured if any "missing/new" info needs to be added for an existing mechanism (e.g. add specific AVPs to support agent overload in the Loss algo). > But, for any specific algo, it would maybe simpler to rely on its own grouped AVP to ease the answer processing. The AVP code can be directly associated to a unique algo instead of digging into an additional AVP (e.g. OC-Feature or single AVP inside a grouped AVP) to discover for which algo the Overload-Report is sent. > Therefore, the aim of the current work in the DT draft would be to define the grouped AVP for reduction/loss and explain how new algo can be discovered. Does it make sense? > > Another point would be on the negotiation as soon as several algos are supported: > > During the message exchange the overload control endpoints express > their common set of supported capabilities. The endpoint sending a > request (the reacting node) includes the OC-Feature-Vector AVP with > those flags set that correspond what it supports. The endpoint that > sends the answer (the reporting node) also includes the OC-Feature- > Vector AVP with flags set to describe ^^the capabilities it both > supports and agrees with the request sender^^ (e.g., based on the local > policy and/or configuration). The answer sending endpoint (the > reporting node) does not need to advertise those capabilities it is > not going to use with the request sending endpoint (the reacting > node). > > I think it is not so true and/or incomplete. Both endpoints will support the default algo (0) and a server cannot say "I will not use the default algo with you" because it could mean the same as "I'm not supporting the default", that is a non-sense by definition of a default. > > In any case, what is the harm for a server to advertize in the response all the algos that it supports if when sending an overload report the use of a specific grouped AVP will let the client know the algo to use according to this report? > If both endpoints advertize all the supported capabilities each time, I think it would ease the use of the OC-Feature. > What do you think? > > Lionel > > -----Message d'origine----- > De : doc-dt-bounces@ietf.org [mailto:doc-dt-bounces@ietf.org] De la part de Shishufeng (Susan) > Envoyé : lundi 4 novembre 2013 12:19 > À : Steve Donovan; doc-dt@ietf.org > Objet : Re: [doc-dt] Capability "Advertisement" > > Hi Steve and all, > > I agree to have the capability advertisement mechanism. For the base version, it should be a way for the client and server, especially the server knows if the another node supports DOC or not, e.g. the server can decide if it can send overload reporting information to the client to request traffic reduction. To the client, what I can imagine is, if the client knows the server does not support DOC and is unable to provide overload information of the server to the client, the client has to apply its own mechanism as currently to drop messages e.g. when the messages which are not responded by the server reaches the configured window. While all of these capabilities so far are not related the algorithms implemented at the client. > > Best Regards, > Susan > > -----Original Message----- > From: doc-dt-bounces@ietf.org [mailto:doc-dt-bounces@ietf.org] On Behalf Of Steve Donovan > Sent: Thursday, October 31, 2013 9:23 PM > To: doc-dt@ietf.org > Subject: [doc-dt] Capability "Advertisement" > > All, > > Breaking the question of negotiation down in to its parts, I believe we > have consensus on the need to support extensibility. Does anyone > disagree with this? > > The next question is then whether we agree that DOIC End-Points (to use > the term in the draft) must advertise that DOIC capabilities it > supports. There is only one capability in the base draft, but the > expectation is that more capabilities will be defined. > > Do we have agreement on the need to support capabilities advertisement? > > The next question will be what the receiving DOIC end-point does with > the advertisement but I think there is value in making sure we agree > that advertisement is needed before continuing that discussion. > > Regards, > > Steve > _______________________________________________ > doc-dt mailing list > doc-dt@ietf.org > https://www.ietf.org/mailman/listinfo/doc-dt > _______________________________________________ > doc-dt mailing list > doc-dt@ietf.org > https://www.ietf.org/mailman/listinfo/doc-dt > > _________________________________________________________________________________________________________________________ > > Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. > > This message and its attachments may contain confidential or privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. > Thank you. > > _______________________________________________ > doc-dt mailing list > doc-dt@ietf.org > https://www.ietf.org/mailman/listinfo/doc-dt > From ulrich.wiehe@nsn.com Tue Nov 5 08:06:38 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 557CC11E82EC; Tue, 5 Nov 2013 08:06:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.658 X-Spam-Level: X-Spam-Status: No, score=-5.658 tagged_above=-999 required=5 tests=[AWL=0.340, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qGp5nEXOG2IZ; Tue, 5 Nov 2013 08:06:33 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 559F011E80F9; Tue, 5 Nov 2013 08:06:29 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rA5G6QCQ027022 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 5 Nov 2013 17:06:26 +0100 Received: from DEMUHTC003.nsn-intra.net ([10.159.42.34]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rA5G6QVR021319 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 5 Nov 2013 17:06:26 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.198]) by DEMUHTC003.nsn-intra.net ([10.159.42.34]) with mapi id 14.03.0123.003; Tue, 5 Nov 2013 17:06:26 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "doc-dt@ietf.org" , "dime@ietf.org" Thread-Topic: Ongoing Throttling Information in request messages Thread-Index: Ac7aQPqQ1tyE3SNOTC+vVrUogwBrJQ== Date: Tue, 5 Nov 2013 16:06:26 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D9000668151918EC@DEMUMBX014.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.113] Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D9000668151918ECDEMUMBX014nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 21006 X-purgate-ID: 151667::1383667587-00005753-A2654CA5/0-0/0-0 Subject: [Dime] Ongoing Throttling Information in request messages X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Nov 2013 16:06:38 -0000 --_000_5BCBA1FC2B7F0B4C9D935572D9000668151918ECDEMUMBX014nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, draft-docdt-dime-ovli-01 in Appendix B, Table 1, REQ 13 says: .... Another way is to let the request sender (reacting node) insert information in the request to say whether a throttling is actually performed. The reporting node then can base its decision on information received in the request; no need for keeping state to record who has received overload reports. And in Appendix B, Table 1, REQ 18: There has been a proposal to mark messages that survived overload throttling as one method for an overloaded node to address fairness but this proposal is not yet part of the solution. I would like to come back to this proposal. A new AVP OC-Ongoing-Throttling-Information inserted in request messages wo= uld indicate that the request message survived a throttling. Furthermore, i= nformation within the AVP indicates the TimeStamp as received in the previo= us OC-OLR AVP, according to which the ongoing throttling (which was survive= d) is performed. OC-Ongoing-Throttling-Information ::=3D < AVP Header: TBD9 > < TimeStamp > * [ AVP ] Supporting Clients would insert the OC-Ongoing-Throttling-Information AVP = into request messages that survived a throttling performed at that client. Supporting Agents when receiving a request message that contains an OC-Ongo= ing-Throttling-Information AVP would not perform an additional throttling (= since the client or a downstream agent already performed the throttling) , = while, when receiving a request that does not contain OC-Ongoing-Throttling= -Information AVP would perform throttling (on behalf of the client) accordi= ng to a previously received and stored OC-OLR, and if that throttling is su= rvived the agent would insert the OC-Ongoing-Throttling-Information AVP in = the request before sending it further upstream. Servers (or in general reporting nodes) would check presence and content of= the OC-Ongoing-Throttling-Information AVP in received request messages and= could detect (together with a check of presence of OC-Feature-Vector AVP) = whether inserting an OC-OLR AVP in the corresponding answer message is need= ed in order to update the reacting node with a new OC-OLR). This proposal especially addresses use cases like the following: Architecture: +----------------+ | supporting | /| agent A1 |\ +----------------+ / +----------------+ \ | non supporting |/ \ | client C |\ \ +----------------+ \ +----------------+ \ +------------+ +---------= + \| non supporting | \| supporting | | Server = | | agent A2 |------| agent A3 |----| S = | +----------------+ +------------+ +---------= + 1. A request is sent from C via A2 and A3 to S. A3 recognizes that the= re is no reacting node downstream (no OC-Feature-Vector received) and there= fore takes the role of the reacting node and inserts an OC-Feature-Vector A= VP. A3 has no valid OLR from S stored and therefore does not perform thrott= ling and does not insert an OC-Throttling-Information AVP. 2. S recognizes that there is a reacting node downstream which is actu= ally not performing a throttling. S returns a 10% throttling request (TimeS= tamp=3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A3= and A2 to C. 3. A3 stores the 10% throttling request. 4. A new request is sent from C via A2 and A3 to S. A3 recognizes that= there is no reacting node downstream (no OC-Feature-Vector received) and t= herefore takes the role of the reacting node and inserts an OC-Feature-Vect= or AVP. A3 has valid OLR from S stored and performs a 10% throttling. The = request survives and A3 inserts an OC-Throttling-Information AVP with timeS= tamp=3Dt1. 5. S recognizes that correct throttling (correct time stamp) is in pla= ce and therefore does not return OC-OLR in the answer. 6. A new request is sent from C via A1 and A3 to S. A1 recognizes that= there is no reacting node downstream (no OC-Feature-Vector received) and t= herefore takes the role of the reacting node and inserts an OC-Feature-AVP.= A1 has no valid OLR from S stored and therefore does not perform throttlin= g and does not insert an OC-Throttling-Information AVP. A3 recognizes that = there is a reacting node downstream (OC-Feature-Vector received) and theref= ore does not take the role of the reacting node. 7. S recognizes that there is a reacting node downstream which is actu= ally not performing a throttling. S returns a 10% throttling request (TimeS= tamp=3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A3= and A1 to C. 8. A1 stores the 10% throttling request. 9. A new request is sent from C via A1 and A3 to S. A1 recognizes that= there is no reacting node downstream (no OC-Feature-Vector received) and t= herefore takes the role of the reacting node and inserts an OC-Feature-AVP.= A1 has valid OLR from S stored and therefore performs a 10% throttling. T= he request survives and A1 inserts an OC-Throttling-Information AVP with ti= meStamp=3Dt1. A3 recognizes that there is a reacting node downstream (OC-Fe= ature-Vector received) and therefore does not take the role of the reacting= node. 10. S recognizes that correct throttling (correct time stamp) is in pla= ce and therefore does not return OC-OLR in the answer. 11. Requests sent from C via A1 and A3 to S undergo a 10% throttling at= A1, requests sent from C via A2 and A3 to S undergo a 10% throttling at A3= . 12. Overload situation in S for some reason gets worse, S decides to re= quest 20 % reduction. 13. A new request is sent from C via A1 and A3 to S. A1 recognizes that= there is no reacting node downstream (no OC-Feature-Vector received) and t= herefore takes the role of the reacting node and inserts an OC-Feature-AVP.= A1 has valid OLR from S stored and therefore performs a 10% throttling. T= he request survives and A1 inserts an OC-Throttling-Information AVP with ti= meStamp=3Dt1. A3 recognizes that there is a reacting node downstream (OC-Fe= ature-Vector received) and therefore does not take the role of the reacting= node. 14. S recognizes that incorrect throttling (wrong time stamp) is in pla= ce and therefore S returns a 20% throttling request (TimeStamp=3Dt2, durati= on=3Dx) within OC-OLR in the answer which goes back via A3 and A1 to C. 15. A3 (not taking the role of the reactingt node)may, A1 must store th= e 20% throttling request (replacing the 10% request). 16. A new request is sent from C via A2 and A3 to S. A3 recognizes that= there is no reacting node downstream (no OC-Feature-Vector received) and t= herefore takes the role of the reacting node and inserts an OC-Feature-Vect= or AVP. A3 has valid OLR from S stored and performs a 10% throttling. The = request survives and A3 inserts an OC-Throttling-Information AVP with timeS= tamp=3Dt1. (assuming A3 did not store the 20% request at step 14) 17. S recognizes that incorrect throttling (wrong time stamp) is in pla= ce and therefore S returns a 20% throttling request (TimeStamp=3Dt2, durati= on=3Dx) within OC-OLR in the answer which goes back via A3 and A2 to C. 18. A3 stores the 20% throttling request (replacing the 10% request). 19. Requests sent from C via A1 and A3 to S undergo a 20% throttling at= A1, requests sent from C via A2 and A3 to S undergo a 20% throttling at A3= . Comments are welcome. Best regards Ulrich --_000_5BCBA1FC2B7F0B4C9D935572D9000668151918ECDEMUMBX014nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable
Hi,
draft-docdt-dime-ovli-01=
in Appendix B, Table 1, REQ 13 says:
        …. Another way
        is to let the request sender (re= acting node) insert
        information in the request to sa= y whether a
        throttling is actually = performed.  The reporting node
        then can base its decision on in= formation received in
        the request; no need for keeping= state to record who
  has received overload reports.  <= /span>
 
And in Appendix B, Table 1, REQ 18:
        There has been a proposal to mar= k
        messages that survived overload = throttling as one
        method for an overloaded node to= address fairness but
        this proposal is not yet part of= the solution. 
 
I would like to come back to this proposal.
A new AVP OC-Ongoing-Throttling-Information inserted in request messag= es would indicate that the request message survived a throttling. Furthermo= re, information within the AVP indicates the TimeStamp as received in the p= revious OC-OLR AVP, according to which the ongoing throttling (which was survived) is performed.
 
= OC-Ongoing-Throttling-Information ::=3D < AVP Header: TBD9 >
=             &nb= sp; < TimeStamp >
=             * [ AVP = ]
 
Supporting Clients would insert the OC-Ongoing-Throttling-Information = AVP  into request messages that survived a throttling performed at tha= t client.
Supporting Agents when receiving a request message that contains an OC= -Ongoing-Throttling-Information AVP would not perform an additional throttl= ing (since the client or a downstream agent already performed the throttlin= g) , while, when receiving a request that does not contain OC-Ongoing-Throttling-Information AVP would perform t= hrottling (on behalf of the client) according to a previously received and = stored OC-OLR, and if that throttling is survived the agent would insert th= e OC-Ongoing-Throttling-Information AVP in the request before sending it further upstream.
Servers (or in general reporting nodes) would check presence and conte= nt of the OC-Ongoing-Throttling-Information AVP in received request message= s and could detect (together with a check of presence of OC-Feature-Vector = AVP) whether inserting an OC-OLR AVP in the corresponding answer message is needed in order to update the re= acting node with a new OC-OLR).
 
This proposal especially addresses use cases like the following:
 
Architecture:
 
       &= nbsp;           &nbs= p;   +----------------+
       &= nbsp;           &nbs= p;   | supporting     |
        =             &nb= sp; /| agent A1       |\   
  +----------------+ / +--= --------------+ \
  | non supporting |/   = ;            &n= bsp;      \
  | client C    &n= bsp;  |\          &n= bsp;            \
  +----------------+ \ +--= --------------+    \ +------------+  &= nbsp; +---------+
       &= nbsp;           &nbs= p;  \| non supporting |     \| supporting |  =   | Server  |
       &= nbsp;           &nbs= p;   |  agent A2      |------| agen= t A3   |----|  S      |
       &= nbsp;            &n= bsp; +----------------+      +--------= ----+    +---------+
 
  1. A request is sent from C via A2 and A3 to S. A3 recognizes that there i= s no reacting node downstream (no OC-Feature-Vector received) and therefore= takes the role of the reacting node and inserts an OC-Feature-Vector AVP. = A3 has no valid OLR from S stored and therefore does not perform throttling and does not insert an OC-Throttl= ing-Information AVP.
  2. S recognizes that there is a reacting node dow= nstream which is actually not performing a throttling. S returns a 10% thro= ttling request (TimeStamp=3Dt1, duration=3Dd) within OC-OLR in the answer w= hich goes back via A3 and A2 to C.
  3. A3 stores the 10% throttling req= uest.
  4. A new request is sent from C via A2 and A3 to S. A3 recognize= s that there is no reacting node downstream (no OC-Feature-Vector received)= and therefore takes the role of the reacting node and inserts an OC-Featur= e-Vector AVP. A3 has  valid OLR from S stored and performs a 10% throttling. The request survives and A3 inserts an OC-Th= rottling-Information AVP with timeStamp=3Dt1.
  5. S recognizes that cor= rect throttling (correct time stamp) is in place and therefore does not ret= urn OC-OLR in the answer.
  6. A new request is sent from C via A1 and A= 3 to S. A1 recognizes that there is no reacting node downstream (no OC-Feat= ure-Vector received) and therefore takes the role of the reacting node and = inserts an OC-Feature-AVP. A1 has no valid OLR from S stored and therefore does not perform throttling and does not insert an OC-Throttling-= Information AVP. A3 recognizes that there is a reacting node downstream (OC= -Feature-Vector received) and therefore does not take the role of the react= ing node.
  7. S recognizes that there is a reacting node downstream whi= ch is actually not performing a throttling. S returns a 10% throttling requ= est (TimeStamp=3Dt1, duration=3Dd) within OC-OLR in the answer which goes b= ack via A3 and A1 to C.
  8. A1 stores the 10% throttling request.
  9. <= li>A new request is sent from C via A1 and A3 to S. A1 recognizes that ther= e is no reacting node downstream (no OC-Feature-Vector received) and theref= ore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 h= as  valid OLR from S stored and therefore performs a 10% throttling. The request survives and A1 inserts an= OC-Throttling-Information AVP with timeStamp=3Dt1. A3 recognizes that ther= e is a reacting node downstream (OC-Feature-Vector received) and therefore = does not take the role of the reacting node.
  10. S recognizes that correct throttling (correct time stamp) is = in place and therefore does not return OC-OLR in the answer.
  11. Reques= ts sent from C via A1 and A3 to S undergo a 10% throttling at A1, requests = sent from C via A2 and A3 to S undergo a 10% throttling at A3.
  12. Over= load situation in S for some reason gets worse, S decides to request 20 % r= eduction.
  13. A new request is sent from C via A1 and A3 to S. A1 recog= nizes that there is no reacting node downstream (no OC-Feature-Vector recei= ved) and therefore takes the role of the reacting node and inserts an OC-Fe= ature-AVP. A1 has  valid OLR from S stored and therefore performs a 10% throttling. The request survives and A1 inserts an= OC-Throttling-Information AVP with timeStamp=3Dt1. A3 recognizes that ther= e is a reacting node downstream (OC-Feature-Vector received) and therefore = does not take the role of the reacting node.
  14. S recognizes that incorrect throttling (wrong time stamp) is = in place and therefore S returns a 20% throttling request (TimeStamp=3Dt2, = duration=3Dx) within OC-OLR in the answer which goes back via A3 and A1 to = C.
  15. A3 (not taking the role of the reactingt node)may, A1 must store= the 20% throttling request (replacing the 10% request).
  16. A new requ= est is sent from C via A2 and A3 to S. A3 recognizes that there is no react= ing node downstream (no OC-Feature-Vector received) and therefore takes the= role of the reacting node and inserts an OC-Feature-Vector AVP. A3 has&nbs= p; valid OLR from S stored and performs a 10% throttling. The request survives and A3 inserts an OC-Th= rottling-Information AVP with timeStamp=3Dt1. (assuming A3 did not store th= e 20% request at step 14)
  17. S recognizes that incorrect throttling (w= rong time stamp) is in place and therefore S returns a 20% throttling reque= st (TimeStamp=3Dt2, duration=3Dx) within OC-OLR in the answer which goes ba= ck via A3 and A2 to C.
  18. A3 stores the 20% throttling request (replac= ing the 10% request).
  19. Requests sent from C via A1 and A3 to S under= go a 20% throttling at A1, requests sent from C via A2 and A3 to S undergo = a 20% throttling at A3.
 
 
Comments are welcome.
 
Best regards
Ulrich
 
 
--_000_5BCBA1FC2B7F0B4C9D935572D9000668151918ECDEMUMBX014nsnin_-- From ulrich.wiehe@nsn.com Wed Nov 6 05:38:04 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5619D11E81B5; Wed, 6 Nov 2013 05:38:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.677 X-Spam-Level: X-Spam-Status: No, score=-5.677 tagged_above=-999 required=5 tests=[AWL=0.321, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V6tZQU-EoGWW; Wed, 6 Nov 2013 05:37:56 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 5B91811E81A9; Wed, 6 Nov 2013 05:37:55 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rA6Dbobc027614 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 6 Nov 2013 14:37:50 +0100 Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rA6Dbo0m010287 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Nov 2013 14:37:50 +0100 Received: from DEMUHTC009.nsn-intra.net (10.159.42.40) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 6 Nov 2013 14:37:50 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.198]) by DEMUHTC009.nsn-intra.net ([10.159.42.40]) with mapi id 14.03.0123.003; Wed, 6 Nov 2013 14:37:50 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "ext Nirav Salot (nsalot)" , "doc-dt@ietf.org" , "dime@ietf.org" Thread-Topic: Ongoing Throttling Information in request messages Thread-Index: Ac7aQPqQ1tyE3SNOTC+vVrUogwBrJQAnWH+wAADoRNA= Date: Wed, 6 Nov 2013 13:37:49 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D900066815192B2B@DEMUMBX014.nsn-intra.net> References: <5BCBA1FC2B7F0B4C9D935572D9000668151918EC@DEMUMBX014.nsn-intra.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.113] Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D900066815192B2BDEMUMBX014nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 56546 X-purgate-ID: 151667::1383745071-00005753-966E370D/0-0/0-0 X-Mailman-Approved-At: Wed, 06 Nov 2013 06:39:49 -0800 Subject: Re: [Dime] Ongoing Throttling Information in request messages X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 13:38:04 -0000 --_000_5BCBA1FC2B7F0B4C9D935572D900066815192B2BDEMUMBX014nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Nirav, thank you for your comments. The comparism is between: Current way: "send OC specific information (Feature-Vector) in every reques= t message and in every corresponding answer message" My proposal: "send OC specific information (Feature-Vector and in some case= s Ongoing-Throttling-Info) in every request message and in corresponding an= swer messages only when required". Sending OC specific information is regarded a resource consuming action an= d we should not put this action to the (overloaded) server where avoidable.= See REQ 13. Best regards Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 12:04 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, Thanks for the detail explanation of your proposal. Just to verify my understanding, Your proposal would allow the reporting node to avoid inclusion of the "sam= e" overload-report in the answer message since the request message indicate= s that the path contains at least one reacting node which already has the l= atest overload-report. In other words, the reporting node need not include overload-report in ever= y message, blindly. To achieve the above objective, the solution below suggest the reacting nod= e to include new AVP OC-Ongoing-Throttling-Information in every request mes= sage, which survives throttling. So the net result is that, the inclusion of the overload-report is prevente= d in every answer message since the OC-Ongoing-Throttling-Information is in= cluded in every request message. [Wiehe, Ulrich (NSN - DE/Munich)] no. ...in every request message that sur= vived a throttling. And hence I am not sure if the solution has sound benefit from the inclusio= n of redundant information point of view. In summary, I think the solution suggested below works as explained. But I fail to see the benefit of using this solution compare to a solution = in which the reporting node includes overload-report in every answer messag= e. Regards, Nirav. From: doc-dt-bounces@ietf.org [mailto:doc-d= t-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich) Sent: Tuesday, November 05, 2013 9:36 PM To: doc-dt@ietf.org; dime@ietf.org Subject: [doc-dt] Ongoing Throttling Information in request messages Hi, draft-docdt-dime-ovli-01 in Appendix B, Table 1, REQ 13 says: .... Another way is to let the request sender (reacting node) insert information in the request to say whether a throttling is actually performed. The reporting node then can base its decision on information received in the request; no need for keeping state to record who has received overload reports. And in Appendix B, Table 1, REQ 18: There has been a proposal to mark messages that survived overload throttling as one method for an overloaded node to address fairness but this proposal is not yet part of the solution. I would like to come back to this proposal. A new AVP OC-Ongoing-Throttling-Information inserted in request messages wo= uld indicate that the request message survived a throttling. Furthermore, i= nformation within the AVP indicates the TimeStamp as received in the previo= us OC-OLR AVP, according to which the ongoing throttling (which was survive= d) is performed. OC-Ongoing-Throttling-Information ::=3D < AVP Header: TBD9 > < TimeStamp > * [ AVP ] Supporting Clients would insert the OC-Ongoing-Throttling-Information AVP = into request messages that survived a throttling performed at that client. Supporting Agents when receiving a request message that contains an OC-Ongo= ing-Throttling-Information AVP would not perform an additional throttling (= since the client or a downstream agent already performed the throttling) , = while, when receiving a request that does not contain OC-Ongoing-Throttling= -Information AVP would perform throttling (on behalf of the client) accordi= ng to a previously received and stored OC-OLR, and if that throttling is su= rvived the agent would insert the OC-Ongoing-Throttling-Information AVP in = the request before sending it further upstream. Servers (or in general reporting nodes) would check presence and content of= the OC-Ongoing-Throttling-Information AVP in received request messages and= could detect (together with a check of presence of OC-Feature-Vector AVP) = whether inserting an OC-OLR AVP in the corresponding answer message is need= ed in order to update the reacting node with a new OC-OLR). This proposal especially addresses use cases like the following: Architecture: +----------------+ | supporting | /| agent A1 |\ +----------------+ / +----------------+ \ | non supporting |/ \ | client C |\ \ +----------------+ \ +----------------+ \ +------------+ +---------= + \| non supporting | \| supporting | | Server = | | agent A2 |------| agent A3 |----| S = | +----------------+ +------------+ +---------+ 1. A request is sent from C via A2 and A3 to S. A3 recognizes that th= ere is no reacting node downstream (no OC-Feature-Vector received) and ther= efore takes the role of the reacting node and inserts an OC-Feature-Vector = AVP. A3 has no valid OLR from S stored and therefore does not perform throt= tling and does not insert an OC-Throttling-Information AVP. 2. S recognizes that there is a reacting node downstream which is act= ually not performing a throttling. S returns a 10% throttling request (Time= Stamp=3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A= 3 and A2 to C. 3. A3 stores the 10% throttling request. 4. A new request is sent from C via A2 and A3 to S. A3 recognizes tha= t there is no reacting node downstream (no OC-Feature-Vector received) and = therefore takes the role of the reacting node and inserts an OC-Feature-Vec= tor AVP. A3 has valid OLR from S stored and performs a 10% throttling. The= request survives and A3 inserts an OC-Throttling-Information AVP with time= Stamp=3Dt1. 5. S recognizes that correct throttling (correct time stamp) is in pl= ace and therefore does not return OC-OLR in the answer. 6. A new request is sent from C via A1 and A3 to S. A1 recognizes tha= t there is no reacting node downstream (no OC-Feature-Vector received) and = therefore takes the role of the reacting node and inserts an OC-Feature-AVP= . A1 has no valid OLR from S stored and therefore does not perform throttli= ng and does not insert an OC-Throttling-Information AVP. A3 recognizes that= there is a reacting node downstream (OC-Feature-Vector received) and there= fore does not take the role of the reacting node. 7. S recognizes that there is a reacting node downstream which is act= ually not performing a throttling. S returns a 10% throttling request (Time= Stamp=3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A= 3 and A1 to C. 8. A1 stores the 10% throttling request. 9. A new request is sent from C via A1 and A3 to S. A1 recognizes tha= t there is no reacting node downstream (no OC-Feature-Vector received) and = therefore takes the role of the reacting node and inserts an OC-Feature-AVP= . A1 has valid OLR from S stored and therefore performs a 10% throttling. = The request survives and A1 inserts an OC-Throttling-Information AVP with t= imeStamp=3Dt1. A3 recognizes that there is a reacting node downstream (OC-F= eature-Vector received) and therefore does not take the role of the reactin= g node. 10. S recognizes that correct throttling (correct time stamp) is in place= and therefore does not return OC-OLR in the answer. 11. Requests sent from C via A1 and A3 to S undergo a 10% throttling at A= 1, requests sent from C via A2 and A3 to S undergo a 10% throttling at A3. 12. Overload situation in S for some reason gets worse, S decides to requ= est 20 % reduction. 13. A new request is sent from C via A1 and A3 to S. A1 recognizes that t= here is no reacting node downstream (no OC-Feature-Vector received) and the= refore takes the role of the reacting node and inserts an OC-Feature-AVP. A= 1 has valid OLR from S stored and therefore performs a 10% throttling. The= request survives and A1 inserts an OC-Throttling-Information AVP with time= Stamp=3Dt1. A3 recognizes that there is a reacting node downstream (OC-Feat= ure-Vector received) and therefore does not take the role of the reacting n= ode. 14. S recognizes that incorrect throttling (wrong time stamp) is in place= and therefore S returns a 20% throttling request (TimeStamp=3Dt2, duration= =3Dx) within OC-OLR in the answer which goes back via A3 and A1 to C. 15. A3 (not taking the role of the reactingt node)may, A1 must store the = 20% throttling request (replacing the 10% request). 16. A new request is sent from C via A2 and A3 to S. A3 recognizes that t= here is no reacting node downstream (no OC-Feature-Vector received) and the= refore takes the role of the reacting node and inserts an OC-Feature-Vector= AVP. A3 has valid OLR from S stored and performs a 10% throttling. The re= quest survives and A3 inserts an OC-Throttling-Information AVP with timeSta= mp=3Dt1. (assuming A3 did not store the 20% request at step 14) 17. S recognizes that incorrect throttling (wrong time stamp) is in place= and therefore S returns a 20% throttling request (TimeStamp=3Dt2, duration= =3Dx) within OC-OLR in the answer which goes back via A3 and A2 to C. 18. A3 stores the 20% throttling request (replacing the 10% request). 19. Requests sent from C via A1 and A3 to S undergo a 20% throttling at A= 1, requests sent from C via A2 and A3 to S undergo a 20% throttling at A3. Comments are welcome. Best regards Ulrich --_000_5BCBA1FC2B7F0B4C9D935572D900066815192B2BDEMUMBX014nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nirav,

thank you = for your comments.

 = ;

The compar= ism is between:

Current wa= y: “send OC specific information (Feature-Vector) in every request me= ssage and in every corresponding answer message”

My proposa= l: “send OC specific information (Feature-Vector and in some cases On= going-Throttling-Info) in every request message and in corresponding answer messages only when required”.

 = ;

Sending OC= specific information  is regarded a resource consuming action and we = should not put this action to the (overloaded) server where avoidable. See REQ 13.

 = ;

Best regar= ds

Ulrich

 = ;

 = ;

 = ;

 = ;

From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]
Sent: Wednesday, November 06, 2013 12:04 PM
To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org<= br> Subject: RE: Ongoing Throttling Information in request messages=

 

Ulrich,

 = ;

Thanks for= the detail explanation of your proposal.

 = ;

Just to ve= rify my understanding,

Your propo= sal would allow the reporting node to avoid inclusion of the “same= 221; overload-report in the answer message since the request message indica= tes that the path contains at least one reacting node which already has the la= test overload-report.

In other w= ords, the reporting node need not include overload-report in every message,= blindly.

 = ;

To achieve= the above objective, the solution below suggest the reacting node to inclu= de new AVP OC-Ongoing-Throttling-Information in every request message, which survives throttling.

So the net= result is that, the inclusion of the overload-report is prevented in every= answer message since the OC-Ongoing-Throttling-Information is included in every request message.

[Wie= he, Ulrich (NSN - DE/Munich)] no.  …in every request message tha= t survived a throttling.

And hence = I am not sure if the solution has sound benefit from the inclusion of redun= dant information point of view.

 = ;

In summary= , I think the solution suggested below works as explained.

But I fail= to see the benefit of using this solution compare to a solution in which t= he reporting node includes overload-report in every answer message.

 = ;

Regards,

Nirav.

 = ;

From: doc-dt-bounces@ietf.org [mailto:doc-dt-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: Tuesday, November 05, 2013 9:36 PM
To: doc-dt@ietf.org; dime@ietf.org
Subject: [doc-dt] Ongoing Throttling Information in request messages=

 

Hi,

draft-docdt-dime-ovli-01

in Appendix B, Table 1, = REQ 13 says:

    =     …. Another way

    =     is to let the request sender (reacting node) insert<= span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:"Calibri&quo= t;,"sans-serif"">

    =     information in the request to say whether a

    =     throttling is actually performed.  The reporting node<= /span>

    =     then can base its decision on information received in

    =     the request; no need for keeping state to record who=

  has rec= eived overload reports. 

 =

And in Appendix B, Table= 1, REQ 18:

    =     There has been a proposal to mark

    =     messages that survived overload throttling as one

    =     method for an overloaded node to address fairness but

    =     this proposal is not yet part of the solution. 

 =

I would like to come bac= k to this proposal.

A new AVP OC-Ongoing-Thr= ottling-Information inserted in request messages would indicate that the re= quest message survived a throttling. Furthermore, information within the AVP indicates the TimeStamp as received in the previous OC-OLR = AVP, according to which the ongoing throttling (which was survived) is perf= ormed.

 =

OC-Ongoing-Throttling-Information ::=3D <= ; AVP Header: TBD9 >

       &= nbsp;      < TimeStamp >

       &= nbsp;    * [ AVP ]

 =

Supporting Clients would= insert the OC-Ongoing-Throttling-Information AVP  into request messag= es that survived a throttling performed at that client.

Supporting Agents when r= eceiving a request message that contains an OC-Ongoing-Throttling-Informati= on AVP would not perform an additional throttling (since the client or a downstream agent already performed the throttling) , while, wh= en receiving a request that does not contain OC-Ongoing-Throttling-Informat= ion AVP would perform throttling (on behalf of the client) according to a p= reviously received and stored OC-OLR, and if that throttling is survived the agent would insert the OC-Ongoing-T= hrottling-Information AVP in the request before sending it further upstream= .

Servers (or in general r= eporting nodes) would check presence and content of the OC-Ongoing-Throttli= ng-Information AVP in received request messages and could detect (together with a check of presence of OC-Feature-Vector AVP) whethe= r inserting an OC-OLR AVP in the corresponding answer message is needed in = order to update the reacting node with a new OC-OLR).

 =

This proposal especially= addresses use cases like the following:

 =

Architecture:=

 =

       &= nbsp;           &nbs= p;   +----------------+

       &= nbsp;           &nbs= p;   | supporting     |

        =             &nb= sp; /| agent A1       |\   

  +----------------+ / +--= --------------+ \<= /p>

  | non supporting |/   = ;            &n= bsp;      \

  | client C    &n= bsp;  |\          &n= bsp;            \

  +----------------+ \ +--= --------------+    \ +------------+  &= nbsp; +---------+

       &= nbsp;           &nbs= p;  \| non supporting |     \| supporting |  =   | Server  |

       &= nbsp;           &nbs= p;   |  agent A2      |------| agen= t A3   |----|  S      |

       &= nbsp;            &nb= sp; +----------------+      +---------= ---+    +---------+

 =

1.  =      A request is sen= t from C via A2 and A3 to S. A3 recognizes that there is no reacting node d= ownstream (no OC-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-Vector AVP. = A3 has no valid OLR from S stored and therefore does not perform throttling= and does not insert an OC-Throttling-Information AVP.

2.  =      S recognizes tha= t there is a reacting node downstream which is actually not performing a th= rottling. S returns a 10% throttling request (TimeStamp=3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A3 and A2 to= C.

3.  =      A3 stores the 10= % throttling request.

4.  =      A new request is= sent from C via A2 and A3 to S. A3 recognizes that there is no reacting no= de downstream (no OC-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-Vector AVP. = A3 has  valid OLR from S stored and performs a 10% throttling. The req= uest survives and A3 inserts an OC-Throttling-Information AVP with timeStam= p=3Dt1.

5.  =      S recognizes tha= t correct throttling (correct time stamp) is in place and therefore does no= t return OC-OLR in the answer.

6.  =      A new request is= sent from C via A1 and A3 to S. A1 recognizes that there is no reacting no= de downstream (no OC-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 has = no valid OLR from S stored and therefore does not perform throttling and do= es not insert an OC-Throttling-Information AVP. A3 recognizes that there is= a reacting node downstream (OC-Feature-Vector received) and therefore does not take the role of the reacting node.<= /o:p>

7.  =      S recognizes tha= t there is a reacting node downstream which is actually not performing a th= rottling. S returns a 10% throttling request (TimeStamp=3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A3 and A1 to= C.

8.  =      A1 stores the 10= % throttling request.

9.  =      A new request is= sent from C via A1 and A3 to S. A1 recognizes that there is no reacting no= de downstream (no OC-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 has&= nbsp; valid OLR from S stored and therefore performs a 10% throttling. The = request survives and A1 inserts an OC-Throttling-Information AVP with timeS= tamp=3Dt1. A3 recognizes that there is a reacting node downstream (OC-Feature-Vector received) and therefore does= not take the role of the reacting node.

10.  = ; S recognizes tha= t correct throttling (correct time stamp) is in place and therefore does no= t return OC-OLR in the answer.

11.  = ; Requests sent fr= om C via A1 and A3 to S undergo a 10% throttling at A1, requests sent from = C via A2 and A3 to S undergo a 10% throttling at A3.

12.  = ; Overload situati= on in S for some reason gets worse, S decides to request 20 % reduction.

13.  = ; A new request is= sent from C via A1 and A3 to S. A1 recognizes that there is no reacting no= de downstream (no OC-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 has&= nbsp; valid OLR from S stored and therefore performs a 10% throttling. The = request survives and A1 inserts an OC-Throttling-Information AVP with timeS= tamp=3Dt1. A3 recognizes that there is a reacting node downstream (OC-Feature-Vector received) and therefore does= not take the role of the reacting node.

14.  = ; S recognizes tha= t incorrect throttling (wrong time stamp) is in place and therefore S retur= ns a 20% throttling request (TimeStamp=3Dt2, duration=3Dx) within OC-OLR in the answer which goes back via A3 and A1 to C.=

15.  = ; A3 (not taking t= he role of the reactingt node)may, A1 must store the 20% throttling request= (replacing the 10% request).

16.  = ; A new request is= sent from C via A2 and A3 to S. A3 recognizes that there is no reacting no= de downstream (no OC-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-Vector AVP. = A3 has  valid OLR from S stored and performs a 10% throttling. The req= uest survives and A3 inserts an OC-Throttling-Information AVP with timeStam= p=3Dt1. (assuming A3 did not store the 20% request at step 14)

17.  = ; S recognizes tha= t incorrect throttling (wrong time stamp) is in place and therefore S retur= ns a 20% throttling request (TimeStamp=3Dt2, duration=3Dx) within OC-OLR in the answer which goes back via A3 and A2 to C.=

18.  = ; A3 stores the 20= % throttling request (replacing the 10% request).

19.  = ; Requests sent fr= om C via A1 and A3 to S undergo a 20% throttling at A1, requests sent from = C via A2 and A3 to S undergo a 20% throttling at A3.

 =

 =

Comments are welcome.

 =

Best regards<= /span>

Ulrich=

 =

 =

--_000_5BCBA1FC2B7F0B4C9D935572D900066815192B2BDEMUMBX014nsnin_-- From nsalot@cisco.com Wed Nov 6 03:04:52 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BC3C21E80B4; Wed, 6 Nov 2013 03:04:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.276 X-Spam-Level: X-Spam-Status: No, score=-10.276 tagged_above=-999 required=5 tests=[AWL=-0.278, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2A-CgF2mwbu0; Wed, 6 Nov 2013 03:04:46 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 6771721E8088; Wed, 6 Nov 2013 03:04:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=46951; q=dns/txt; s=iport; t=1383735886; x=1384945486; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=CQ7fKriaD8ow3aJv1s0/kSPx+YlnKzojXRbiqKQYN1s=; b=i/BN9n+Zg7JA1GhJ2I4THbe+5yvVv+ufkUlBUEP9Q494PhgX2Z6Tbpcp 41TBqk9Vvff/+h2zx1WMakCq3Jo8umZbPmElanrzIQjNfn6Q8fhcv0EQ6 vGmAEUO65xtIrR9Np/tw93Jut7eQqJ25eY6WrsUso6NoHByD51luD0nhC I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkgFACYielKtJXHA/2dsb2JhbABagkNEOFO/PYEkFnSCJQEBAQQtXAIBCBEBAwEBCw8CBQEGBzIUAwYIAQEEARIIE4dmvwePKDcBBhoHgnmBEAOULI4zhzeDJoFMHkA X-IronPort-AV: E=Sophos;i="4.93,646,1378857600"; d="scan'208,217";a="281364930" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by rcdn-iport-3.cisco.com with ESMTP; 06 Nov 2013 11:04:22 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id rA6B4MFw006486 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Nov 2013 11:04:22 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.47]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Wed, 6 Nov 2013 05:04:21 -0600 From: "Nirav Salot (nsalot)" To: "Wiehe, Ulrich (NSN - DE/Munich)" , "doc-dt@ietf.org" , "dime@ietf.org" Thread-Topic: Ongoing Throttling Information in request messages Thread-Index: Ac7aQPqQ1tyE3SNOTC+vVrUogwBrJQAnWH+w Date: Wed, 6 Nov 2013 11:04:21 +0000 Message-ID: References: <5BCBA1FC2B7F0B4C9D935572D9000668151918EC@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151918EC@DEMUMBX014.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.39.185] Content-Type: multipart/alternative; boundary="_000_A9CA33BB78081F478946E4F34BF9AAA014CF3131xmbrcdx10ciscoc_" MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 06 Nov 2013 06:39:52 -0800 Subject: Re: [Dime] Ongoing Throttling Information in request messages X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 11:04:52 -0000 --_000_A9CA33BB78081F478946E4F34BF9AAA014CF3131xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ulrich, Thanks for the detail explanation of your proposal. Just to verify my understanding, Your proposal would allow the reporting node to avoid inclusion of the "sam= e" overload-report in the answer message since the request message indicate= s that the path contains at least one reacting node which already has the l= atest overload-report. In other words, the reporting node need not include overload-report in ever= y message, blindly. To achieve the above objective, the solution below suggest the reacting nod= e to include new AVP OC-Ongoing-Throttling-Information in every request mes= sage, which survives throttling. So the net result is that, the inclusion of the overload-report is prevente= d in every answer message since the OC-Ongoing-Throttling-Information is in= cluded in every request message. And hence I am not sure if the solution has sound benefit from the inclusio= n of redundant information point of view. In summary, I think the solution suggested below works as explained. But I fail to see the benefit of using this solution compare to a solution = in which the reporting node includes overload-report in every answer messag= e. Regards, Nirav. From: doc-dt-bounces@ietf.org [mailto:doc-dt-bounces@ietf.org] On Behalf Of= Wiehe, Ulrich (NSN - DE/Munich) Sent: Tuesday, November 05, 2013 9:36 PM To: doc-dt@ietf.org; dime@ietf.org Subject: [doc-dt] Ongoing Throttling Information in request messages Hi, draft-docdt-dime-ovli-01 in Appendix B, Table 1, REQ 13 says: .... Another way is to let the request sender (reacting node) insert information in the request to say whether a throttling is actually performed. The reporting node then can base its decision on information received in the request; no need for keeping state to record who has received overload reports. And in Appendix B, Table 1, REQ 18: There has been a proposal to mark messages that survived overload throttling as one method for an overloaded node to address fairness but this proposal is not yet part of the solution. I would like to come back to this proposal. A new AVP OC-Ongoing-Throttling-Information inserted in request messages wo= uld indicate that the request message survived a throttling. Furthermore, i= nformation within the AVP indicates the TimeStamp as received in the previo= us OC-OLR AVP, according to which the ongoing throttling (which was survive= d) is performed. OC-Ongoing-Throttling-Information ::=3D < AVP Header: TBD9 > < TimeStamp > * [ AVP ] Supporting Clients would insert the OC-Ongoing-Throttling-Information AVP = into request messages that survived a throttling performed at that client. Supporting Agents when receiving a request message that contains an OC-Ongo= ing-Throttling-Information AVP would not perform an additional throttling (= since the client or a downstream agent already performed the throttling) , = while, when receiving a request that does not contain OC-Ongoing-Throttling= -Information AVP would perform throttling (on behalf of the client) accordi= ng to a previously received and stored OC-OLR, and if that throttling is su= rvived the agent would insert the OC-Ongoing-Throttling-Information AVP in = the request before sending it further upstream. Servers (or in general reporting nodes) would check presence and content of= the OC-Ongoing-Throttling-Information AVP in received request messages and= could detect (together with a check of presence of OC-Feature-Vector AVP) = whether inserting an OC-OLR AVP in the corresponding answer message is need= ed in order to update the reacting node with a new OC-OLR). This proposal especially addresses use cases like the following: Architecture: +----------------+ | supporting | /| agent A1 |\ +----------------+ / +----------------+ \ | non supporting |/ \ | client C |\ \ +----------------+ \ +----------------+ \ +------------+ +---------= + \| non supporting | \| supporting | | Server = | | agent A2 |------| agent A3 |----| S = | +----------------+ +------------+ +---------+ 1. A request is sent from C via A2 and A3 to S. A3 recognizes that th= ere is no reacting node downstream (no OC-Feature-Vector received) and ther= efore takes the role of the reacting node and inserts an OC-Feature-Vector = AVP. A3 has no valid OLR from S stored and therefore does not perform throt= tling and does not insert an OC-Throttling-Information AVP. 2. S recognizes that there is a reacting node downstream which is act= ually not performing a throttling. S returns a 10% throttling request (Time= Stamp=3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A= 3 and A2 to C. 3. A3 stores the 10% throttling request. 4. A new request is sent from C via A2 and A3 to S. A3 recognizes tha= t there is no reacting node downstream (no OC-Feature-Vector received) and = therefore takes the role of the reacting node and inserts an OC-Feature-Vec= tor AVP. A3 has valid OLR from S stored and performs a 10% throttling. The= request survives and A3 inserts an OC-Throttling-Information AVP with time= Stamp=3Dt1. 5. S recognizes that correct throttling (correct time stamp) is in pl= ace and therefore does not return OC-OLR in the answer. 6. A new request is sent from C via A1 and A3 to S. A1 recognizes tha= t there is no reacting node downstream (no OC-Feature-Vector received) and = therefore takes the role of the reacting node and inserts an OC-Feature-AVP= . A1 has no valid OLR from S stored and therefore does not perform throttli= ng and does not insert an OC-Throttling-Information AVP. A3 recognizes that= there is a reacting node downstream (OC-Feature-Vector received) and there= fore does not take the role of the reacting node. 7. S recognizes that there is a reacting node downstream which is act= ually not performing a throttling. S returns a 10% throttling request (Time= Stamp=3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A= 3 and A1 to C. 8. A1 stores the 10% throttling request. 9. A new request is sent from C via A1 and A3 to S. A1 recognizes tha= t there is no reacting node downstream (no OC-Feature-Vector received) and = therefore takes the role of the reacting node and inserts an OC-Feature-AVP= . A1 has valid OLR from S stored and therefore performs a 10% throttling. = The request survives and A1 inserts an OC-Throttling-Information AVP with t= imeStamp=3Dt1. A3 recognizes that there is a reacting node downstream (OC-F= eature-Vector received) and therefore does not take the role of the reactin= g node. 10. S recognizes that correct throttling (correct time stamp) is in place= and therefore does not return OC-OLR in the answer. 11. Requests sent from C via A1 and A3 to S undergo a 10% throttling at A= 1, requests sent from C via A2 and A3 to S undergo a 10% throttling at A3. 12. Overload situation in S for some reason gets worse, S decides to requ= est 20 % reduction. 13. A new request is sent from C via A1 and A3 to S. A1 recognizes that t= here is no reacting node downstream (no OC-Feature-Vector received) and the= refore takes the role of the reacting node and inserts an OC-Feature-AVP. A= 1 has valid OLR from S stored and therefore performs a 10% throttling. The= request survives and A1 inserts an OC-Throttling-Information AVP with time= Stamp=3Dt1. A3 recognizes that there is a reacting node downstream (OC-Feat= ure-Vector received) and therefore does not take the role of the reacting n= ode. 14. S recognizes that incorrect throttling (wrong time stamp) is in place= and therefore S returns a 20% throttling request (TimeStamp=3Dt2, duration= =3Dx) within OC-OLR in the answer which goes back via A3 and A1 to C. 15. A3 (not taking the role of the reactingt node)may, A1 must store the = 20% throttling request (replacing the 10% request). 16. A new request is sent from C via A2 and A3 to S. A3 recognizes that t= here is no reacting node downstream (no OC-Feature-Vector received) and the= refore takes the role of the reacting node and inserts an OC-Feature-Vector= AVP. A3 has valid OLR from S stored and performs a 10% throttling. The re= quest survives and A3 inserts an OC-Throttling-Information AVP with timeSta= mp=3Dt1. (assuming A3 did not store the 20% request at step 14) 17. S recognizes that incorrect throttling (wrong time stamp) is in place= and therefore S returns a 20% throttling request (TimeStamp=3Dt2, duration= =3Dx) within OC-OLR in the answer which goes back via A3 and A2 to C. 18. A3 stores the 20% throttling request (replacing the 10% request). 19. Requests sent from C via A1 and A3 to S undergo a 20% throttling at A= 1, requests sent from C via A2 and A3 to S undergo a 20% throttling at A3. Comments are welcome. Best regards Ulrich --_000_A9CA33BB78081F478946E4F34BF9AAA014CF3131xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ulrich,=

 <= /p>

Thanks for the detail exp= lanation of your proposal.

 <= /p>

Just to verify my underst= anding,

Your proposal would allow= the reporting node to avoid inclusion of the “same” overload-r= eport in the answer message since the request message indicates that the path contains at least one reacting node which already has the latest = overload-report.

In other words, the repor= ting node need not include overload-report in every message, blindly.<= /o:p>

 <= /p>

To achieve the above obje= ctive, the solution below suggest the reacting node to include new AVP OC-O= ngoing-Throttling-Information in every request message, which survives throttling.

So the net result is that= , the inclusion of the overload-report is prevented in every answer message= since the OC-Ongoing-Throttling-Information is included in every request message.

And hence I am not sure i= f the solution has sound benefit from the inclusion of redundant informatio= n point of view.

 <= /p>

In summary, I think the s= olution suggested below works as explained.

But I fail to see the ben= efit of using this solution compare to a solution in which the reporting no= de includes overload-report in every answer message.

 <= /p>

Regards,

Nirav.<= /p>

 <= /p>

From: doc-dt-b= ounces@ietf.org [mailto:doc-dt-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: Tuesday, November 05, 2013 9:36 PM
To: doc-dt@ietf.org; dime@ietf.org
Subject: [doc-dt] Ongoing Throttling Information in request messages=

 

Hi,

draft-docdt-dime-ovli-01

in Appendix B, Table 1, REQ 13 says:

      &nb= sp; …. Another way

      &nb= sp; is to let the request sender (reacting node) insert

      &nb= sp; information in the request to say whether a=

      &nb= sp; throttling is actually performed.  The reporting node

      &nb= sp; then can base its decision on information received in

      &nb= sp; the request; no need for keeping state to record who

  has received overload = reports. 

 

And in Appendix B, Table 1, REQ 18:

      &nb= sp; There has been a proposal to mark

      &nb= sp; messages that survived overload throttling as one=

      &nb= sp; method for an overloaded node to address fairness but<= o:p>

      &nb= sp; this proposal is not yet part of the solution. 

 

I would like to come back to this propo= sal.

A new AVP OC-Ongoing-Throttling-Informa= tion inserted in request messages would indicate that the request message s= urvived a throttling. Furthermore, information within the AVP indicates the TimeStamp as received in the previous OC-OLR AVP, accord= ing to which the ongoing throttling (which was survived) is performed.=

 

OC-Ongoing-Throttling-Information ::=3D < AVP Header: T= BD9 >

         &nbs= p;    < TimeStamp >

         &nbs= p;  * [ AVP ]

 

Supporting Clients would insert the OC-= Ongoing-Throttling-Information AVP  into request messages that survive= d a throttling performed at that client.

Supporting Agents when receiving a requ= est message that contains an OC-Ongoing-Throttling-Information AVP would no= t perform an additional throttling (since the client or a downstream agent already performed the throttling) , while, when receivi= ng a request that does not contain OC-Ongoing-Throttling-Information AVP wo= uld perform throttling (on behalf of the client) according to a previously = received and stored OC-OLR, and if that throttling is survived the agent would insert the OC-Ongoing-Throt= tling-Information AVP in the request before sending it further upstream.

Servers (or in general reporting nodes)= would check presence and content of the OC-Ongoing-Throttling-Information = AVP in received request messages and could detect (together with a check of presence of OC-Feature-Vector AVP) whether inserting an OC= -OLR AVP in the corresponding answer message is needed in order to update t= he reacting node with a new OC-OLR).

 

This proposal especially addresses use = cases like the following:

 

Architecture:

 

         &nbs= p;             = +----------------+

         &nbs= p;             = | supporting     |

          &nb= sp;           /| agent A1=        |\   

  +----------------+ / +----------------&= #43; \

  | non supporting |/     &n= bsp;            = ;    \

  | client C       |\&n= bsp;            = ;          \

  +----------------+ \ +----------------&= #43;    \ +------------+    +----= -----+

         &nbs= p;            \| non= supporting |     \| supporting |    | Server=   |

         &nbs= p;             = |  agent A2      |------| agent A3  = ; |----|  S      |

         &nbs= p;            +------= ----------+      +------------+ &= nbsp;  +---------+

 

1.    &nb= sp;  A request is sent from C via A2= and A3 to S. A3 recognizes that there is no reacting node downstream (no O= C-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-Vector AVP. A3 has no valid= OLR from S stored and therefore does not perform throttling and does not i= nsert an OC-Throttling-Information AVP.

2.    &nb= sp;  S recognizes that there is a re= acting node downstream which is actually not performing a throttling. S ret= urns a 10% throttling request (TimeStamp=3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A3 and A2 to C.=

3.    &nb= sp;  A3 stores the 10% throttling re= quest.

4.    &nb= sp;  A new request is sent from C vi= a A2 and A3 to S. A3 recognizes that there is no reacting node downstream (= no OC-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-Vector AVP. A3 has&nbs= p; valid OLR from S stored and performs a 10% throttling. The request survi= ves and A3 inserts an OC-Throttling-Information AVP with timeStamp=3Dt1.

5.    &nb= sp;  S recognizes that correct throt= tling (correct time stamp) is in place and therefore does not return OC-OLR= in the answer.

6.    &nb= sp;  A new request is sent from C vi= a A1 and A3 to S. A1 recognizes that there is no reacting node downstream (= no OC-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 has no valid O= LR from S stored and therefore does not perform throttling and does not ins= ert an OC-Throttling-Information AVP. A3 recognizes that there is a reactin= g node downstream (OC-Feature-Vector received) and therefore does not take the role of the reacting node.<= /o:p>

7.    &nb= sp;  S recognizes that there is a re= acting node downstream which is actually not performing a throttling. S ret= urns a 10% throttling request (TimeStamp=3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A3 and A1 to C.=

8.    &nb= sp;  A1 stores the 10% throttling re= quest.

9.    &nb= sp;  A new request is sent from C vi= a A1 and A3 to S. A1 recognizes that there is no reacting node downstream (= no OC-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 has  vali= d OLR from S stored and therefore performs a 10% throttling. The request su= rvives and A1 inserts an OC-Throttling-Information AVP with timeStamp=3Dt1.= A3 recognizes that there is a reacting node downstream (OC-Feature-Vector received) and therefore does not take t= he role of the reacting node.

10.   S recognizes that correct throt= tling (correct time stamp) is in place and therefore does not return OC-OLR= in the answer.

11.   Requests sent from C via A1 and= A3 to S undergo a 10% throttling at A1, requests sent from C via A2 and A3= to S undergo a 10% throttling at A3.

12.   Overload situation in S for som= e reason gets worse, S decides to request 20 % reduction.=

13.   A new request is sent from C vi= a A1 and A3 to S. A1 recognizes that there is no reacting node downstream (= no OC-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 has  vali= d OLR from S stored and therefore performs a 10% throttling. The request su= rvives and A1 inserts an OC-Throttling-Information AVP with timeStamp=3Dt1.= A3 recognizes that there is a reacting node downstream (OC-Feature-Vector received) and therefore does not take t= he role of the reacting node.

14.   S recognizes that incorrect thr= ottling (wrong time stamp) is in place and therefore S returns a 20% thrott= ling request (TimeStamp=3Dt2, duration=3Dx) within OC-OLR in the answer which goes back via A3 and A1 to C.

15.   A3 (not taking the role of the = reactingt node)may, A1 must store the 20% throttling request (replacing the= 10% request).

16.   A new request is sent from C vi= a A2 and A3 to S. A3 recognizes that there is no reacting node downstream (= no OC-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-Vector AVP. A3 has&nbs= p; valid OLR from S stored and performs a 10% throttling. The request survi= ves and A3 inserts an OC-Throttling-Information AVP with timeStamp=3Dt1. (a= ssuming A3 did not store the 20% request at step 14)

17.   S recognizes that incorrect thr= ottling (wrong time stamp) is in place and therefore S returns a 20% thrott= ling request (TimeStamp=3Dt2, duration=3Dx) within OC-OLR in the answer which goes back via A3 and A2 to C.

18.   A3 stores the 20% throttling re= quest (replacing the 10% request).

19.   Requests sent from C via A1 and= A3 to S undergo a 20% throttling at A1, requests sent from C via A2 and A3= to S undergo a 20% throttling at A3.

 

 

Comments are welcome.=

 

Best regards

Ulrich

 

 

--_000_A9CA33BB78081F478946E4F34BF9AAA014CF3131xmbrcdx10ciscoc_-- From nsalot@cisco.com Wed Nov 6 06:15:01 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D43511E8150; Wed, 6 Nov 2013 06:15:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.298 X-Spam-Level: X-Spam-Status: No, score=-10.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MmzZ5RyxKB3A; Wed, 6 Nov 2013 06:14:55 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id DDCDF11E81C8; Wed, 6 Nov 2013 06:14:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=57543; q=dns/txt; s=iport; t=1383747295; x=1384956895; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=qEio7IUQrxa4C/lgHLBbJpWJEMNipO8I293SFGhW2FI=; b=fgYwSF+9ip23ITheXGga6MjdlwmyqtPptQturh0QTGo/p/aSuvow0syT hxffc1zBHvIAnIq2SdloFRbJ4Rw/kFPgorCWri5RXF4iwW2tYm1MoGtgU MfKZx1CU3fDSmbDy3vxuvs83YaFNfyZIW2Rge0WLLfD6eLvIK6Bm8rioK k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkgFAHVOelKtJXHB/2dsb2JhbABagkNEOFO/PoEkFnSCJQEBAQQtXAIBCBEBAwEBCw8CBQEGBzIUAwYIAQEEARIIE4dmvw+PKDcBBhoHgnmBEAOULI4zhzeDJoFMHkA X-IronPort-AV: E=Sophos;i="4.93,647,1378857600"; d="scan'208,217";a="281365587" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-2.cisco.com with ESMTP; 06 Nov 2013 14:14:52 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id rA6EEo6I002148 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Nov 2013 14:14:51 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.47]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.03.0123.003; Wed, 6 Nov 2013 08:14:50 -0600 From: "Nirav Salot (nsalot)" To: "Wiehe, Ulrich (NSN - DE/Munich)" , "doc-dt@ietf.org" , "dime@ietf.org" Thread-Topic: Ongoing Throttling Information in request messages Thread-Index: Ac7aQPqQ1tyE3SNOTC+vVrUogwBrJQAnWH+wAADoRNAABgE0oA== Date: Wed, 6 Nov 2013 14:14:49 +0000 Message-ID: References: <5BCBA1FC2B7F0B4C9D935572D9000668151918EC@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192B2B@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D900066815192B2B@DEMUMBX014.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.39.185] Content-Type: multipart/alternative; boundary="_000_A9CA33BB78081F478946E4F34BF9AAA014CF31E9xmbrcdx10ciscoc_" MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 06 Nov 2013 06:39:53 -0800 Subject: Re: [Dime] Ongoing Throttling Information in request messages X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 14:15:01 -0000 --_000_A9CA33BB78081F478946E4F34BF9AAA014CF31E9xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ulrich, Thanks for clarification. Then the question would be "is sending overload-report in every answer message is more resource consum= ing than the solution below - i.e. receiving OC-Ongoing-Throttling-Informat= ion in all request message and analyzing the timestamp and then deciding if= the overload-report should be included or not." I am not sure. Regards, Nirav. From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Wednesday, November 06, 2013 7:08 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, thank you for your comments. The comparism is between: Current way: "send OC specific information (Feature-Vector) in every reques= t message and in every corresponding answer message" My proposal: "send OC specific information (Feature-Vector and in some case= s Ongoing-Throttling-Info) in every request message and in corresponding an= swer messages only when required". Sending OC specific information is regarded a resource consuming action an= d we should not put this action to the (overloaded) server where avoidable.= See REQ 13. Best regards Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 12:04 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, Thanks for the detail explanation of your proposal. Just to verify my understanding, Your proposal would allow the reporting node to avoid inclusion of the "sam= e" overload-report in the answer message since the request message indicate= s that the path contains at least one reacting node which already has the l= atest overload-report. In other words, the reporting node need not include overload-report in ever= y message, blindly. To achieve the above objective, the solution below suggest the reacting nod= e to include new AVP OC-Ongoing-Throttling-Information in every request mes= sage, which survives throttling. So the net result is that, the inclusion of the overload-report is prevente= d in every answer message since the OC-Ongoing-Throttling-Information is in= cluded in every request message. [Wiehe, Ulrich (NSN - DE/Munich)] no. ...in every request message that sur= vived a throttling. And hence I am not sure if the solution has sound benefit from the inclusio= n of redundant information point of view. In summary, I think the solution suggested below works as explained. But I fail to see the benefit of using this solution compare to a solution = in which the reporting node includes overload-report in every answer messag= e. Regards, Nirav. From: doc-dt-bounces@ietf.org [mailto:doc-d= t-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich) Sent: Tuesday, November 05, 2013 9:36 PM To: doc-dt@ietf.org; dime@ietf.org Subject: [doc-dt] Ongoing Throttling Information in request messages Hi, draft-docdt-dime-ovli-01 in Appendix B, Table 1, REQ 13 says: .... Another way is to let the request sender (reacting node) insert information in the request to say whether a throttling is actually performed. The reporting node then can base its decision on information received in the request; no need for keeping state to record who has received overload reports. And in Appendix B, Table 1, REQ 18: There has been a proposal to mark messages that survived overload throttling as one method for an overloaded node to address fairness but this proposal is not yet part of the solution. I would like to come back to this proposal. A new AVP OC-Ongoing-Throttling-Information inserted in request messages wo= uld indicate that the request message survived a throttling. Furthermore, i= nformation within the AVP indicates the TimeStamp as received in the previo= us OC-OLR AVP, according to which the ongoing throttling (which was survive= d) is performed. OC-Ongoing-Throttling-Information ::=3D < AVP Header: TBD9 > < TimeStamp > * [ AVP ] Supporting Clients would insert the OC-Ongoing-Throttling-Information AVP = into request messages that survived a throttling performed at that client. Supporting Agents when receiving a request message that contains an OC-Ongo= ing-Throttling-Information AVP would not perform an additional throttling (= since the client or a downstream agent already performed the throttling) , = while, when receiving a request that does not contain OC-Ongoing-Throttling= -Information AVP would perform throttling (on behalf of the client) accordi= ng to a previously received and stored OC-OLR, and if that throttling is su= rvived the agent would insert the OC-Ongoing-Throttling-Information AVP in = the request before sending it further upstream. Servers (or in general reporting nodes) would check presence and content of= the OC-Ongoing-Throttling-Information AVP in received request messages and= could detect (together with a check of presence of OC-Feature-Vector AVP) = whether inserting an OC-OLR AVP in the corresponding answer message is need= ed in order to update the reacting node with a new OC-OLR). This proposal especially addresses use cases like the following: Architecture: +----------------+ | supporting | /| agent A1 |\ +----------------+ / +----------------+ \ | non supporting |/ \ | client C |\ \ +----------------+ \ +----------------+ \ +------------+ +---------= + \| non supporting | \| supporting | | Server = | | agent A2 |------| agent A3 |----| S = | +----------------+ +------------+ +---------+ 1. A request is sent from C via A2 and A3 to S. A3 recognizes that th= ere is no reacting node downstream (no OC-Feature-Vector received) and ther= efore takes the role of the reacting node and inserts an OC-Feature-Vector = AVP. A3 has no valid OLR from S stored and therefore does not perform throt= tling and does not insert an OC-Throttling-Information AVP. 2. S recognizes that there is a reacting node downstream which is act= ually not performing a throttling. S returns a 10% throttling request (Time= Stamp=3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A= 3 and A2 to C. 3. A3 stores the 10% throttling request. 4. A new request is sent from C via A2 and A3 to S. A3 recognizes tha= t there is no reacting node downstream (no OC-Feature-Vector received) and = therefore takes the role of the reacting node and inserts an OC-Feature-Vec= tor AVP. A3 has valid OLR from S stored and performs a 10% throttling. The= request survives and A3 inserts an OC-Throttling-Information AVP with time= Stamp=3Dt1. 5. S recognizes that correct throttling (correct time stamp) is in pl= ace and therefore does not return OC-OLR in the answer. 6. A new request is sent from C via A1 and A3 to S. A1 recognizes tha= t there is no reacting node downstream (no OC-Feature-Vector received) and = therefore takes the role of the reacting node and inserts an OC-Feature-AVP= . A1 has no valid OLR from S stored and therefore does not perform throttli= ng and does not insert an OC-Throttling-Information AVP. A3 recognizes that= there is a reacting node downstream (OC-Feature-Vector received) and there= fore does not take the role of the reacting node. 7. S recognizes that there is a reacting node downstream which is act= ually not performing a throttling. S returns a 10% throttling request (Time= Stamp=3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A= 3 and A1 to C. 8. A1 stores the 10% throttling request. 9. A new request is sent from C via A1 and A3 to S. A1 recognizes tha= t there is no reacting node downstream (no OC-Feature-Vector received) and = therefore takes the role of the reacting node and inserts an OC-Feature-AVP= . A1 has valid OLR from S stored and therefore performs a 10% throttling. = The request survives and A1 inserts an OC-Throttling-Information AVP with t= imeStamp=3Dt1. A3 recognizes that there is a reacting node downstream (OC-F= eature-Vector received) and therefore does not take the role of the reactin= g node. 10. S recognizes that correct throttling (correct time stamp) is in place= and therefore does not return OC-OLR in the answer. 11. Requests sent from C via A1 and A3 to S undergo a 10% throttling at A= 1, requests sent from C via A2 and A3 to S undergo a 10% throttling at A3. 12. Overload situation in S for some reason gets worse, S decides to requ= est 20 % reduction. 13. A new request is sent from C via A1 and A3 to S. A1 recognizes that t= here is no reacting node downstream (no OC-Feature-Vector received) and the= refore takes the role of the reacting node and inserts an OC-Feature-AVP. A= 1 has valid OLR from S stored and therefore performs a 10% throttling. The= request survives and A1 inserts an OC-Throttling-Information AVP with time= Stamp=3Dt1. A3 recognizes that there is a reacting node downstream (OC-Feat= ure-Vector received) and therefore does not take the role of the reacting n= ode. 14. S recognizes that incorrect throttling (wrong time stamp) is in place= and therefore S returns a 20% throttling request (TimeStamp=3Dt2, duration= =3Dx) within OC-OLR in the answer which goes back via A3 and A1 to C. 15. A3 (not taking the role of the reactingt node)may, A1 must store the = 20% throttling request (replacing the 10% request). 16. A new request is sent from C via A2 and A3 to S. A3 recognizes that t= here is no reacting node downstream (no OC-Feature-Vector received) and the= refore takes the role of the reacting node and inserts an OC-Feature-Vector= AVP. A3 has valid OLR from S stored and performs a 10% throttling. The re= quest survives and A3 inserts an OC-Throttling-Information AVP with timeSta= mp=3Dt1. (assuming A3 did not store the 20% request at step 14) 17. S recognizes that incorrect throttling (wrong time stamp) is in place= and therefore S returns a 20% throttling request (TimeStamp=3Dt2, duration= =3Dx) within OC-OLR in the answer which goes back via A3 and A2 to C. 18. A3 stores the 20% throttling request (replacing the 10% request). 19. Requests sent from C via A1 and A3 to S undergo a 20% throttling at A= 1, requests sent from C via A2 and A3 to S undergo a 20% throttling at A3. Comments are welcome. Best regards Ulrich --_000_A9CA33BB78081F478946E4F34BF9AAA014CF31E9xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ulrich,=

 <= /p>

Thanks for clarification.=

 <= /p>

Then the question would b= e

“is sending overloa= d-report in every answer message is more resource consuming than the soluti= on below – i.e. receiving OC-Ongoing-Throttling-Information in all request message and analyzing the timestamp and then deciding if the o= verload-report should be included or not.”

I am not sure.=

 <= /p>

Regards,

Nirav.<= /p>

 <= /p>

From: Wiehe, U= lrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Sent: Wednesday, November 06, 2013 7:08 PM
To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org
Subject: RE: Ongoing Throttling Information in request messages=

 

Nirav,<= /p>

thank you for your commen= ts.

 <= /p>

The comparism is between:=

Current way: “send = OC specific information (Feature-Vector) in every request message and in ev= ery corresponding answer message”

My proposal: “send = OC specific information (Feature-Vector and in some cases Ongoing-Throttlin= g-Info) in every request message and in corresponding answer messages only when required”.

 <= /p>

Sending OC specific infor= mation  is regarded a resource consuming action and we should not put = this action to the (overloaded) server where avoidable. See REQ 13.

 <= /p>

Best regards

Ulrich<= /p>

 <= /p>

 <= /p>

 <= /p>

 <= /p>

From: ext Nira= v Salot (nsalot) [mailto:nsalot@cisco.c= om]
Sent: Wednesday, November 06, 2013 12:04 PM
To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org
Subject: RE: Ongoing Throttling Information in request messages=

 

Ulrich,=

 <= /p>

Thanks for the detail exp= lanation of your proposal.

 <= /p>

Just to verify my underst= anding,

Your proposal would allow= the reporting node to avoid inclusion of the “same” overload-r= eport in the answer message since the request message indicates that the path contains at least one reacting node which already has the latest = overload-report.

In other words, the repor= ting node need not include overload-report in every message, blindly.<= /o:p>

 <= /p>

To achieve the above obje= ctive, the solution below suggest the reacting node to include new AVP OC-O= ngoing-Throttling-Information in every request message, which survives throttling.

So the net result is that= , the inclusion of the overload-report is prevented in every answer message= since the OC-Ongoing-Throttling-Information is included in every request message.

[Wiehe, Ulrich (NSN= - DE/Munich)] no.  …in every request message that survived a th= rottling.

And hence I am not sure i= f the solution has sound benefit from the inclusion of redundant informatio= n point of view.

 <= /p>

In summary, I think the s= olution suggested below works as explained.

But I fail to see the ben= efit of using this solution compare to a solution in which the reporting no= de includes overload-report in every answer message.

 <= /p>

Regards,

Nirav.<= /p>

 <= /p>

From: doc-dt-bounces@ietf.org [mailto:doc-dt-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: Tuesday, November 05, 2013 9:36 PM
To: doc-dt@ietf.org; dime@ietf.org
Subject: [doc-dt] Ongoing Throttling Information in request messages=

 

Hi,

draft-docdt-dime-ovli-01

in Appendix B, Table 1, REQ 13 says:

      &nb= sp; …. Another way

      &nb= sp; is to let the request sender (reacting node) insert

      &nb= sp; information in the request to say whether a=

      &nb= sp; throttling is actually performed.  The reporting node

      &nb= sp; then can base its decision on information received in

      &nb= sp; the request; no need for keeping state to record who

  has received overload = reports. 

 

And in Appendix B, Table 1, REQ 18:

      &nb= sp; There has been a proposal to mark

      &nb= sp; messages that survived overload throttling as one=

      &nb= sp; method for an overloaded node to address fairness but<= o:p>

      &nb= sp; this proposal is not yet part of the solution. 

 

I would like to come back to this propo= sal.

A new AVP OC-Ongoing-Throttling-Informa= tion inserted in request messages would indicate that the request message s= urvived a throttling. Furthermore, information within the AVP indicates the TimeStamp as received in the previous OC-OLR AVP, accord= ing to which the ongoing throttling (which was survived) is performed.=

 

OC-Ongoing-Throttling-Information ::=3D < AVP Header: T= BD9 >

         &nbs= p;    < TimeStamp >

         &nbs= p;  * [ AVP ]

 

Supporting Clients would insert the OC-= Ongoing-Throttling-Information AVP  into request messages that survive= d a throttling performed at that client.

Supporting Agents when receiving a requ= est message that contains an OC-Ongoing-Throttling-Information AVP would no= t perform an additional throttling (since the client or a downstream agent already performed the throttling) , while, when receivi= ng a request that does not contain OC-Ongoing-Throttling-Information AVP wo= uld perform throttling (on behalf of the client) according to a previously = received and stored OC-OLR, and if that throttling is survived the agent would insert the OC-Ongoing-Throt= tling-Information AVP in the request before sending it further upstream.

Servers (or in general reporting nodes)= would check presence and content of the OC-Ongoing-Throttling-Information = AVP in received request messages and could detect (together with a check of presence of OC-Feature-Vector AVP) whether inserting an OC= -OLR AVP in the corresponding answer message is needed in order to update t= he reacting node with a new OC-OLR).

 

This proposal especially addresses use = cases like the following:

 

Architecture:

 

         &nbs= p;             = +----------------+

         &nbs= p;             = | supporting     |

          &nb= sp;           /| agent A1=        |\   

  +----------------+ / +----------------&= #43; \

  | non supporting |/     &n= bsp;            = ;    \

  | client C       |\&n= bsp;            = ;          \

  +----------------+ \ +----------------&= #43;    \ +------------+    +----= -----+

         &nbs= p;            \| non= supporting |     \| supporting |    | Server=   |

         &nbs= p;             = |  agent A2      |------| agent A3  = ; |----|  S      |

         &nbs= p;            +------= ----------+      +------------+ &= nbsp;  +---------+

 

1.    &nb= sp;  A request is sent from C via A2= and A3 to S. A3 recognizes that there is no reacting node downstream (no O= C-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-Vector AVP. A3 has no valid= OLR from S stored and therefore does not perform throttling and does not i= nsert an OC-Throttling-Information AVP.

2.    &nb= sp;  S recognizes that there is a re= acting node downstream which is actually not performing a throttling. S ret= urns a 10% throttling request (TimeStamp=3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A3 and A2 to C.=

3.    &nb= sp;  A3 stores the 10% throttling re= quest.

4.    &nb= sp;  A new request is sent from C vi= a A2 and A3 to S. A3 recognizes that there is no reacting node downstream (= no OC-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-Vector AVP. A3 has&nbs= p; valid OLR from S stored and performs a 10% throttling. The request survi= ves and A3 inserts an OC-Throttling-Information AVP with timeStamp=3Dt1.

5.    &nb= sp;  S recognizes that correct throt= tling (correct time stamp) is in place and therefore does not return OC-OLR= in the answer.

6.    &nb= sp;  A new request is sent from C vi= a A1 and A3 to S. A1 recognizes that there is no reacting node downstream (= no OC-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 has no valid O= LR from S stored and therefore does not perform throttling and does not ins= ert an OC-Throttling-Information AVP. A3 recognizes that there is a reactin= g node downstream (OC-Feature-Vector received) and therefore does not take the role of the reacting node.<= /o:p>

7.    &nb= sp;  S recognizes that there is a re= acting node downstream which is actually not performing a throttling. S ret= urns a 10% throttling request (TimeStamp=3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A3 and A1 to C.=

8.    &nb= sp;  A1 stores the 10% throttling re= quest.

9.    &nb= sp;  A new request is sent from C vi= a A1 and A3 to S. A1 recognizes that there is no reacting node downstream (= no OC-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 has  vali= d OLR from S stored and therefore performs a 10% throttling. The request su= rvives and A1 inserts an OC-Throttling-Information AVP with timeStamp=3Dt1.= A3 recognizes that there is a reacting node downstream (OC-Feature-Vector received) and therefore does not take t= he role of the reacting node.

10.   S recognizes that correct throt= tling (correct time stamp) is in place and therefore does not return OC-OLR= in the answer.

11.   Requests sent from C via A1 and= A3 to S undergo a 10% throttling at A1, requests sent from C via A2 and A3= to S undergo a 10% throttling at A3.

12.   Overload situation in S for som= e reason gets worse, S decides to request 20 % reduction.=

13.   A new request is sent from C vi= a A1 and A3 to S. A1 recognizes that there is no reacting node downstream (= no OC-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 has  vali= d OLR from S stored and therefore performs a 10% throttling. The request su= rvives and A1 inserts an OC-Throttling-Information AVP with timeStamp=3Dt1.= A3 recognizes that there is a reacting node downstream (OC-Feature-Vector received) and therefore does not take t= he role of the reacting node.

14.   S recognizes that incorrect thr= ottling (wrong time stamp) is in place and therefore S returns a 20% thrott= ling request (TimeStamp=3Dt2, duration=3Dx) within OC-OLR in the answer which goes back via A3 and A1 to C.

15.   A3 (not taking the role of the = reactingt node)may, A1 must store the 20% throttling request (replacing the= 10% request).

16.   A new request is sent from C vi= a A2 and A3 to S. A3 recognizes that there is no reacting node downstream (= no OC-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-Vector AVP. A3 has&nbs= p; valid OLR from S stored and performs a 10% throttling. The request survi= ves and A3 inserts an OC-Throttling-Information AVP with timeStamp=3Dt1. (a= ssuming A3 did not store the 20% request at step 14)

17.   S recognizes that incorrect thr= ottling (wrong time stamp) is in place and therefore S returns a 20% thrott= ling request (TimeStamp=3Dt2, duration=3Dx) within OC-OLR in the answer which goes back via A3 and A2 to C.

18.   A3 stores the 20% throttling re= quest (replacing the 10% request).

19.   Requests sent from C via A1 and= A3 to S undergo a 20% throttling at A1, requests sent from C via A2 and A3= to S undergo a 20% throttling at A3.

 

 

Comments are welcome.=

 

Best regards

Ulrich

 

 

--_000_A9CA33BB78081F478946E4F34BF9AAA014CF31E9xmbrcdx10ciscoc_-- From ulrich.wiehe@nsn.com Wed Nov 6 06:54:01 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E9E021E8117; Wed, 6 Nov 2013 06:54:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.694 X-Spam-Level: X-Spam-Status: No, score=-5.694 tagged_above=-999 required=5 tests=[AWL=0.304, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WGc2E8www8hA; Wed, 6 Nov 2013 06:53:44 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id CD5A411E81D4; Wed, 6 Nov 2013 06:53:43 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rA6EreOc030668 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 6 Nov 2013 15:53:40 +0100 Received: from DEMUHTC001.nsn-intra.net ([10.159.42.32]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rA6ErdAq013244 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Nov 2013 15:53:39 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.198]) by DEMUHTC001.nsn-intra.net ([10.159.42.32]) with mapi id 14.03.0123.003; Wed, 6 Nov 2013 15:53:38 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "ext Nirav Salot (nsalot)" , "doc-dt@ietf.org" , "dime@ietf.org" Thread-Topic: Ongoing Throttling Information in request messages Thread-Index: Ac7aQPqQ1tyE3SNOTC+vVrUogwBrJQAnWH+wAADoRNAABgE0oAAA57Dw Date: Wed, 6 Nov 2013 14:53:38 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D900066815192B90@DEMUMBX014.nsn-intra.net> References: <5BCBA1FC2B7F0B4C9D935572D9000668151918EC@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192B2B@DEMUMBX014.nsn-intra.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.113] Content-Type: multipart/alternative; boundary="_000_5BCBA1FC2B7F0B4C9D935572D900066815192B90DEMUMBX014nsnin_" MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 64474 X-purgate-ID: 151667::1383749620-00004A43-8708B9B6/0-0/0-0 X-Mailman-Approved-At: Wed, 06 Nov 2013 07:04:11 -0800 Subject: Re: [Dime] Ongoing Throttling Information in request messages X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 14:54:01 -0000 --_000_5BCBA1FC2B7F0B4C9D935572D900066815192B90DEMUMBX014nsnin_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Nirav, Not quite. The question is: "is sending an overload-report in every answer message that corresponds to = request with OC-Feature-Vector present more resource consuming than receivi= ng Ongoing-Throttling-Information in some request messages (only those that= survived a throttling)?" Best regards Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 3:15 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, Thanks for clarification. Then the question would be "is sending overload-report in every answer message is more resource consum= ing than the solution below - i.e. receiving OC-Ongoing-Throttling-Informat= ion in all request message and analyzing the timestamp and then deciding if= the overload-report should be included or not." I am not sure. Regards, Nirav. From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Wednesday, November 06, 2013 7:08 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@iet= f.org Subject: RE: Ongoing Throttling Information in request messages Nirav, thank you for your comments. The comparism is between: Current way: "send OC specific information (Feature-Vector) in every reques= t message and in every corresponding answer message" My proposal: "send OC specific information (Feature-Vector and in some case= s Ongoing-Throttling-Info) in every request message and in corresponding an= swer messages only when required". Sending OC specific information is regarded a resource consuming action an= d we should not put this action to the (overloaded) server where avoidable.= See REQ 13. Best regards Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 12:04 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, Thanks for the detail explanation of your proposal. Just to verify my understanding, Your proposal would allow the reporting node to avoid inclusion of the "sam= e" overload-report in the answer message since the request message indicate= s that the path contains at least one reacting node which already has the l= atest overload-report. In other words, the reporting node need not include overload-report in ever= y message, blindly. To achieve the above objective, the solution below suggest the reacting nod= e to include new AVP OC-Ongoing-Throttling-Information in every request mes= sage, which survives throttling. So the net result is that, the inclusion of the overload-report is prevente= d in every answer message since the OC-Ongoing-Throttling-Information is in= cluded in every request message. [Wiehe, Ulrich (NSN - DE/Munich)] no. ...in every request message that sur= vived a throttling. And hence I am not sure if the solution has sound benefit from the inclusio= n of redundant information point of view. In summary, I think the solution suggested below works as explained. But I fail to see the benefit of using this solution compare to a solution = in which the reporting node includes overload-report in every answer messag= e. Regards, Nirav. From: doc-dt-bounces@ietf.org [mailto:doc-d= t-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich) Sent: Tuesday, November 05, 2013 9:36 PM To: doc-dt@ietf.org; dime@ietf.org Subject: [doc-dt] Ongoing Throttling Information in request messages Hi, draft-docdt-dime-ovli-01 in Appendix B, Table 1, REQ 13 says: .... Another way is to let the request sender (reacting node) insert information in the request to say whether a throttling is actually performed. The reporting node then can base its decision on information received in the request; no need for keeping state to record who has received overload reports. And in Appendix B, Table 1, REQ 18: There has been a proposal to mark messages that survived overload throttling as one method for an overloaded node to address fairness but this proposal is not yet part of the solution. I would like to come back to this proposal. A new AVP OC-Ongoing-Throttling-Information inserted in request messages wo= uld indicate that the request message survived a throttling. Furthermore, i= nformation within the AVP indicates the TimeStamp as received in the previo= us OC-OLR AVP, according to which the ongoing throttling (which was survive= d) is performed. OC-Ongoing-Throttling-Information ::=3D < AVP Header: TBD9 > < TimeStamp > * [ AVP ] Supporting Clients would insert the OC-Ongoing-Throttling-Information AVP = into request messages that survived a throttling performed at that client. Supporting Agents when receiving a request message that contains an OC-Ongo= ing-Throttling-Information AVP would not perform an additional throttling (= since the client or a downstream agent already performed the throttling) , = while, when receiving a request that does not contain OC-Ongoing-Throttling= -Information AVP would perform throttling (on behalf of the client) accordi= ng to a previously received and stored OC-OLR, and if that throttling is su= rvived the agent would insert the OC-Ongoing-Throttling-Information AVP in = the request before sending it further upstream. Servers (or in general reporting nodes) would check presence and content of= the OC-Ongoing-Throttling-Information AVP in received request messages and= could detect (together with a check of presence of OC-Feature-Vector AVP) = whether inserting an OC-OLR AVP in the corresponding answer message is need= ed in order to update the reacting node with a new OC-OLR). This proposal especially addresses use cases like the following: Architecture: +----------------+ | supporting | /| agent A1 |\ +----------------+ / +----------------+ \ | non supporting |/ \ | client C |\ \ +----------------+ \ +----------------+ \ +------------+ +---------= + \| non supporting | \| supporting | | Server = | | agent A2 |------| agent A3 |----| S = | +----------------+ +------------+ +---------+ 1. A request is sent from C via A2 and A3 to S. A3 recognizes that th= ere is no reacting node downstream (no OC-Feature-Vector received) and ther= efore takes the role of the reacting node and inserts an OC-Feature-Vector = AVP. A3 has no valid OLR from S stored and therefore does not perform throt= tling and does not insert an OC-Throttling-Information AVP. 2. S recognizes that there is a reacting node downstream which is act= ually not performing a throttling. S returns a 10% throttling request (Time= Stamp=3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A= 3 and A2 to C. 3. A3 stores the 10% throttling request. 4. A new request is sent from C via A2 and A3 to S. A3 recognizes tha= t there is no reacting node downstream (no OC-Feature-Vector received) and = therefore takes the role of the reacting node and inserts an OC-Feature-Vec= tor AVP. A3 has valid OLR from S stored and performs a 10% throttling. The= request survives and A3 inserts an OC-Throttling-Information AVP with time= Stamp=3Dt1. 5. S recognizes that correct throttling (correct time stamp) is in pl= ace and therefore does not return OC-OLR in the answer. 6. A new request is sent from C via A1 and A3 to S. A1 recognizes tha= t there is no reacting node downstream (no OC-Feature-Vector received) and = therefore takes the role of the reacting node and inserts an OC-Feature-AVP= . A1 has no valid OLR from S stored and therefore does not perform throttli= ng and does not insert an OC-Throttling-Information AVP. A3 recognizes that= there is a reacting node downstream (OC-Feature-Vector received) and there= fore does not take the role of the reacting node. 7. S recognizes that there is a reacting node downstream which is act= ually not performing a throttling. S returns a 10% throttling request (Time= Stamp=3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A= 3 and A1 to C. 8. A1 stores the 10% throttling request. 9. A new request is sent from C via A1 and A3 to S. A1 recognizes tha= t there is no reacting node downstream (no OC-Feature-Vector received) and = therefore takes the role of the reacting node and inserts an OC-Feature-AVP= . A1 has valid OLR from S stored and therefore performs a 10% throttling. = The request survives and A1 inserts an OC-Throttling-Information AVP with t= imeStamp=3Dt1. A3 recognizes that there is a reacting node downstream (OC-F= eature-Vector received) and therefore does not take the role of the reactin= g node. 10. S recognizes that correct throttling (correct time stamp) is in place= and therefore does not return OC-OLR in the answer. 11. Requests sent from C via A1 and A3 to S undergo a 10% throttling at A= 1, requests sent from C via A2 and A3 to S undergo a 10% throttling at A3. 12. Overload situation in S for some reason gets worse, S decides to requ= est 20 % reduction. 13. A new request is sent from C via A1 and A3 to S. A1 recognizes that t= here is no reacting node downstream (no OC-Feature-Vector received) and the= refore takes the role of the reacting node and inserts an OC-Feature-AVP. A= 1 has valid OLR from S stored and therefore performs a 10% throttling. The= request survives and A1 inserts an OC-Throttling-Information AVP with time= Stamp=3Dt1. A3 recognizes that there is a reacting node downstream (OC-Feat= ure-Vector received) and therefore does not take the role of the reacting n= ode. 14. S recognizes that incorrect throttling (wrong time stamp) is in place= and therefore S returns a 20% throttling request (TimeStamp=3Dt2, duration= =3Dx) within OC-OLR in the answer which goes back via A3 and A1 to C. 15. A3 (not taking the role of the reactingt node)may, A1 must store the = 20% throttling request (replacing the 10% request). 16. A new request is sent from C via A2 and A3 to S. A3 recognizes that t= here is no reacting node downstream (no OC-Feature-Vector received) and the= refore takes the role of the reacting node and inserts an OC-Feature-Vector= AVP. A3 has valid OLR from S stored and performs a 10% throttling. The re= quest survives and A3 inserts an OC-Throttling-Information AVP with timeSta= mp=3Dt1. (assuming A3 did not store the 20% request at step 14) 17. S recognizes that incorrect throttling (wrong time stamp) is in place= and therefore S returns a 20% throttling request (TimeStamp=3Dt2, duration= =3Dx) within OC-OLR in the answer which goes back via A3 and A2 to C. 18. A3 stores the 20% throttling request (replacing the 10% request). 19. Requests sent from C via A1 and A3 to S undergo a 20% throttling at A= 1, requests sent from C via A2 and A3 to S undergo a 20% throttling at A3. Comments are welcome. Best regards Ulrich --_000_5BCBA1FC2B7F0B4C9D935572D900066815192B90DEMUMBX014nsnin_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Nirav,<= /p>

 <= /p>

Not quite.=

 = ;

The questi= on is:

“is = sending an overload-report in every answer message that corresponds to request with OC-Feature-Vec= tor present more resource consuming than receiving Ongoing-Throttling-Infor= mation in some request messages (only those that survived a throttling)?”= ;

 = ;

Best regar= ds

Ulrich

 = ;

 = ;

 = ;

From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]
Sent: Wednesday, November 06, 2013 3:15 PM
To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org<= br> Subject: RE: Ongoing Throttling Information in request messages=

 

Ulrich,

 = ;

Thanks for= clarification.

 = ;

Then the q= uestion would be

“is = sending overload-report in every answer message is more resource consuming = than the solution below – i.e. receiving OC-Ongoing-Throttling-Inform= ation in all request message and analyzing the timestamp and then deciding if th= e overload-report should be included or not.”

I am not s= ure.

 = ;

Regards,

Nirav.

 = ;

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Sent: Wednesday, November 06, 2013 7:08 PM
To: Nirav Salot (nsalot); doc-dt@= ietf.org; dime@ietf.org
Subject: RE: Ongoing Throttling Information in request messages=

 

Nirav,

thank you = for your comments.

 = ;

The compar= ism is between:

Current wa= y: “send OC specific information (Feature-Vector) in every request me= ssage and in every corresponding answer message”

My proposa= l: “send OC specific information (Feature-Vector and in some cases On= going-Throttling-Info) in every request message and in corresponding answer messages only when required”.

 = ;

Sending OC= specific information  is regarded a resource consuming action and we = should not put this action to the (overloaded) server where avoidable. See REQ 13.

 = ;

Best regar= ds

Ulrich

 = ;

 = ;

 = ;

 = ;

From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]
Sent: Wednesday, November 06, 2013 12:04 PM
To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org
Subject: RE: Ongoing Throttling Information in request messages=

 

Ulrich,

 = ;

Thanks for= the detail explanation of your proposal.

 = ;

Just to ve= rify my understanding,

Your propo= sal would allow the reporting node to avoid inclusion of the “same= 221; overload-report in the answer message since the request message indica= tes that the path contains at least one reacting node which already has the la= test overload-report.

In other w= ords, the reporting node need not include overload-report in every message,= blindly.

 = ;

To achieve= the above objective, the solution below suggest the reacting node to inclu= de new AVP OC-Ongoing-Throttling-Information in every request message, which survives throttling.

So the net= result is that, the inclusion of the overload-report is prevented in every= answer message since the OC-Ongoing-Throttling-Information is included in every request message.

[Wie= he, Ulrich (NSN - DE/Munich)] no.  …in every request message tha= t survived a throttling.

And hence = I am not sure if the solution has sound benefit from the inclusion of redun= dant information point of view.

 = ;

In summary= , I think the solution suggested below works as explained.

But I fail= to see the benefit of using this solution compare to a solution in which t= he reporting node includes overload-report in every answer message.

 = ;

Regards,

Nirav.

 = ;

From: doc-dt-bounces@ietf.org [mailto:doc-dt-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: Tuesday, November 05, 2013 9:36 PM
To: doc-dt@ietf.org; dime@ietf.org
Subject: [doc-dt] Ongoing Throttling Information in request messages=

 

Hi,

draft-docdt-dime-ovli-01

in Appendix B, Table 1, = REQ 13 says:

    =     …. Another way

    =     is to let the request sender (reacting node) insert<= span lang=3D"EN-US" style=3D"font-size:11.0pt;font-family:"Calibri&quo= t;,"sans-serif"">

    =     information in the request to say whether a

    =     throttling is actually performed.  The reporting node<= /span>

    =     then can base its decision on information received in

    =     the request; no need for keeping state to record who=

  has rec= eived overload reports. 

 =

And in Appendix B, Table= 1, REQ 18:

    =     There has been a proposal to mark

    =     messages that survived overload throttling as one

    =     method for an overloaded node to address fairness but

    =     this proposal is not yet part of the solution. 

 =

I would like to come bac= k to this proposal.

A new AVP OC-Ongoing-Thr= ottling-Information inserted in request messages would indicate that the re= quest message survived a throttling. Furthermore, information within the AVP indicates the TimeStamp as received in the previous OC-OLR = AVP, according to which the ongoing throttling (which was survived) is perf= ormed.

 =

OC-Ongoing-Throttling-Information ::=3D <= ; AVP Header: TBD9 >

       &= nbsp;      < TimeStamp >

       &= nbsp;    * [ AVP ]

 =

Supporting Clients would= insert the OC-Ongoing-Throttling-Information AVP  into request messag= es that survived a throttling performed at that client.

Supporting Agents when r= eceiving a request message that contains an OC-Ongoing-Throttling-Informati= on AVP would not perform an additional throttling (since the client or a downstream agent already performed the throttling) , while, wh= en receiving a request that does not contain OC-Ongoing-Throttling-Informat= ion AVP would perform throttling (on behalf of the client) according to a p= reviously received and stored OC-OLR, and if that throttling is survived the agent would insert the OC-Ongoing-T= hrottling-Information AVP in the request before sending it further upstream= .

Servers (or in general r= eporting nodes) would check presence and content of the OC-Ongoing-Throttli= ng-Information AVP in received request messages and could detect (together with a check of presence of OC-Feature-Vector AVP) whethe= r inserting an OC-OLR AVP in the corresponding answer message is needed in = order to update the reacting node with a new OC-OLR).

 =

This proposal especially= addresses use cases like the following:

 =

Architecture:=

 =

       &= nbsp;           &nbs= p;   +----------------+

       &= nbsp;           &nbs= p;   | supporting     |

        =             &nb= sp; /| agent A1       |\   

  +----------------+ / +--= --------------+ \<= /p>

  | non supporting |/   = ;            &n= bsp;      \

  | client C    &n= bsp;  |\          &n= bsp;            \

  +----------------+ \ +--= --------------+    \ +------------+  &= nbsp; +---------+

       &= nbsp;           &nbs= p;  \| non supporting |     \| supporting |  =   | Server  |

       &= nbsp;           &nbs= p;   |  agent A2      |------| agen= t A3   |----|  S      |

       &= nbsp;            &nb= sp; +----------------+      +---------= ---+    +---------+

 =

1.  =      A request is sen= t from C via A2 and A3 to S. A3 recognizes that there is no reacting node d= ownstream (no OC-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-Vector AVP. = A3 has no valid OLR from S stored and therefore does not perform throttling= and does not insert an OC-Throttling-Information AVP.

2.  =      S recognizes tha= t there is a reacting node downstream which is actually not performing a th= rottling. S returns a 10% throttling request (TimeStamp=3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A3 and A2 to= C.

3.  =      A3 stores the 10= % throttling request.

4.  =      A new request is= sent from C via A2 and A3 to S. A3 recognizes that there is no reacting no= de downstream (no OC-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-Vector AVP. = A3 has  valid OLR from S stored and performs a 10% throttling. The req= uest survives and A3 inserts an OC-Throttling-Information AVP with timeStam= p=3Dt1.

5.  =      S recognizes tha= t correct throttling (correct time stamp) is in place and therefore does no= t return OC-OLR in the answer.

6.  =      A new request is= sent from C via A1 and A3 to S. A1 recognizes that there is no reacting no= de downstream (no OC-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 has = no valid OLR from S stored and therefore does not perform throttling and do= es not insert an OC-Throttling-Information AVP. A3 recognizes that there is= a reacting node downstream (OC-Feature-Vector received) and therefore does not take the role of the reacting node.<= /o:p>

7.  =      S recognizes tha= t there is a reacting node downstream which is actually not performing a th= rottling. S returns a 10% throttling request (TimeStamp=3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A3 and A1 to= C.

8.  =      A1 stores the 10= % throttling request.

9.  =      A new request is= sent from C via A1 and A3 to S. A1 recognizes that there is no reacting no= de downstream (no OC-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 has&= nbsp; valid OLR from S stored and therefore performs a 10% throttling. The = request survives and A1 inserts an OC-Throttling-Information AVP with timeS= tamp=3Dt1. A3 recognizes that there is a reacting node downstream (OC-Feature-Vector received) and therefore does= not take the role of the reacting node.

10.  = ; S recognizes tha= t correct throttling (correct time stamp) is in place and therefore does no= t return OC-OLR in the answer.

11.  = ; Requests sent fr= om C via A1 and A3 to S undergo a 10% throttling at A1, requests sent from = C via A2 and A3 to S undergo a 10% throttling at A3.

12.  = ; Overload situati= on in S for some reason gets worse, S decides to request 20 % reduction.

13.  = ; A new request is= sent from C via A1 and A3 to S. A1 recognizes that there is no reacting no= de downstream (no OC-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 has&= nbsp; valid OLR from S stored and therefore performs a 10% throttling. The = request survives and A1 inserts an OC-Throttling-Information AVP with timeS= tamp=3Dt1. A3 recognizes that there is a reacting node downstream (OC-Feature-Vector received) and therefore does= not take the role of the reacting node.

14.  = ; S recognizes tha= t incorrect throttling (wrong time stamp) is in place and therefore S retur= ns a 20% throttling request (TimeStamp=3Dt2, duration=3Dx) within OC-OLR in the answer which goes back via A3 and A1 to C.=

15.  = ; A3 (not taking t= he role of the reactingt node)may, A1 must store the 20% throttling request= (replacing the 10% request).

16.  = ; A new request is= sent from C via A2 and A3 to S. A3 recognizes that there is no reacting no= de downstream (no OC-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-Vector AVP. = A3 has  valid OLR from S stored and performs a 10% throttling. The req= uest survives and A3 inserts an OC-Throttling-Information AVP with timeStam= p=3Dt1. (assuming A3 did not store the 20% request at step 14)

17.  = ; S recognizes tha= t incorrect throttling (wrong time stamp) is in place and therefore S retur= ns a 20% throttling request (TimeStamp=3Dt2, duration=3Dx) within OC-OLR in the answer which goes back via A3 and A2 to C.=

18.  = ; A3 stores the 20= % throttling request (replacing the 10% request).

19.  = ; Requests sent fr= om C via A1 and A3 to S undergo a 20% throttling at A1, requests sent from = C via A2 and A3 to S undergo a 20% throttling at A3.

 =

 =

Comments are welcome.

 =

Best regards<= /span>

Ulrich=

 =

 =

--_000_5BCBA1FC2B7F0B4C9D935572D900066815192B90DEMUMBX014nsnin_-- From nsalot@cisco.com Wed Nov 6 07:02:35 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B26C811E8141; Wed, 6 Nov 2013 07:02:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.241 X-Spam-Level: X-Spam-Status: No, score=-10.241 tagged_above=-999 required=5 tests=[AWL=-0.243, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WOFrJ9UbCD3G; Wed, 6 Nov 2013 07:02:30 -0800 (PST) Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) by ietfa.amsl.com (Postfix) with ESMTP id 39C7011E80DC; Wed, 6 Nov 2013 07:02:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=65378; q=dns/txt; s=iport; t=1383750149; x=1384959749; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=zcUPwFBoHpHi+42BOOAhhDhDjdcTJvfLMR7ibmVDOp4=; b=LqBCgPjMs4BVe0p8v4Z3NEHdO/OdTiLf/UMQhFtXWLWbaAN5swk+ZRG4 UWn7HpDvmI+h4aUFEh7b28z10KHr3VFgN4215fRypscSE8hvFsr3xACi1 4pE/6daFtQ91jD97NEdmErKIvl5zv0IvEqufSmSDOCMZa2TVCdLUBQPz+ 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AkgFAANZelKtJV2d/2dsb2JhbABagkNEOFO/PoEkFnSCJQEBAQQaE1wCAQgRAQMBAQsPAgUBBgcyFAMGCAEBBAESCBOHZr8Xjyg3AQYaB4J5gRADlCyOM4c3gyaBTB5A X-IronPort-AV: E=Sophos;i="4.93,647,1378857600"; d="scan'208,217";a="281384610" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-2.cisco.com with ESMTP; 06 Nov 2013 15:02:27 +0000 Received: from xhc-rcd-x08.cisco.com (xhc-rcd-x08.cisco.com [173.37.183.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id rA6F2RCM019877 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 6 Nov 2013 15:02:27 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.47]) by xhc-rcd-x08.cisco.com ([173.37.183.82]) with mapi id 14.03.0123.003; Wed, 6 Nov 2013 09:02:27 -0600 From: "Nirav Salot (nsalot)" To: "Wiehe, Ulrich (NSN - DE/Munich)" , "doc-dt@ietf.org" , "dime@ietf.org" Thread-Topic: Ongoing Throttling Information in request messages Thread-Index: Ac7aQPqQ1tyE3SNOTC+vVrUogwBrJQAnWH+wAADoRNAABgE0oAAA57DwAACoAlA= Date: Wed, 6 Nov 2013 15:02:26 +0000 Message-ID: References: <5BCBA1FC2B7F0B4C9D935572D9000668151918EC@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192B2B@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192B90@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D900066815192B90@DEMUMBX014.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.39.185] Content-Type: multipart/alternative; boundary="_000_A9CA33BB78081F478946E4F34BF9AAA014CF3237xmbrcdx10ciscoc_" MIME-Version: 1.0 X-Mailman-Approved-At: Wed, 06 Nov 2013 07:11:25 -0800 Subject: Re: [Dime] Ongoing Throttling Information in request messages X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 15:02:35 -0000 --_000_A9CA33BB78081F478946E4F34BF9AAA014CF3237xmbrcdx10ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ulrich, I might be missing something here so please bear with me. Number of answer messages sent by server =3D number of request messages rec= eived by the server. During the overload, the server would receive only those requests which sur= vived throttling. And then the server would send answer messages to only those request messag= es. So "every" and "some" are actually equal in the below equation. No? Regards, Nirav. From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Wednesday, November 06, 2013 8:24 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, Not quite. The question is: "is sending an overload-report in every answer message that corresponds to = request with OC-Feature-Vector present more resource consuming than receivi= ng Ongoing-Throttling-Information in some request messages (only those that= survived a throttling)?" Best regards Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 3:15 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, Thanks for clarification. Then the question would be "is sending overload-report in every answer message is more resource consum= ing than the solution below - i.e. receiving OC-Ongoing-Throttling-Informat= ion in all request message and analyzing the timestamp and then deciding if= the overload-report should be included or not." I am not sure. Regards, Nirav. From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Wednesday, November 06, 2013 7:08 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@iet= f.org Subject: RE: Ongoing Throttling Information in request messages Nirav, thank you for your comments. The comparism is between: Current way: "send OC specific information (Feature-Vector) in every reques= t message and in every corresponding answer message" My proposal: "send OC specific information (Feature-Vector and in some case= s Ongoing-Throttling-Info) in every request message and in corresponding an= swer messages only when required". Sending OC specific information is regarded a resource consuming action an= d we should not put this action to the (overloaded) server where avoidable.= See REQ 13. Best regards Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 12:04 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, Thanks for the detail explanation of your proposal. Just to verify my understanding, Your proposal would allow the reporting node to avoid inclusion of the "sam= e" overload-report in the answer message since the request message indicate= s that the path contains at least one reacting node which already has the l= atest overload-report. In other words, the reporting node need not include overload-report in ever= y message, blindly. To achieve the above objective, the solution below suggest the reacting nod= e to include new AVP OC-Ongoing-Throttling-Information in every request mes= sage, which survives throttling. So the net result is that, the inclusion of the overload-report is prevente= d in every answer message since the OC-Ongoing-Throttling-Information is in= cluded in every request message. [Wiehe, Ulrich (NSN - DE/Munich)] no. ...in every request message that sur= vived a throttling. And hence I am not sure if the solution has sound benefit from the inclusio= n of redundant information point of view. In summary, I think the solution suggested below works as explained. But I fail to see the benefit of using this solution compare to a solution = in which the reporting node includes overload-report in every answer messag= e. Regards, Nirav. From: doc-dt-bounces@ietf.org [mailto:doc-d= t-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich) Sent: Tuesday, November 05, 2013 9:36 PM To: doc-dt@ietf.org; dime@ietf.org Subject: [doc-dt] Ongoing Throttling Information in request messages Hi, draft-docdt-dime-ovli-01 in Appendix B, Table 1, REQ 13 says: .... Another way is to let the request sender (reacting node) insert information in the request to say whether a throttling is actually performed. The reporting node then can base its decision on information received in the request; no need for keeping state to record who has received overload reports. And in Appendix B, Table 1, REQ 18: There has been a proposal to mark messages that survived overload throttling as one method for an overloaded node to address fairness but this proposal is not yet part of the solution. I would like to come back to this proposal. A new AVP OC-Ongoing-Throttling-Information inserted in request messages wo= uld indicate that the request message survived a throttling. Furthermore, i= nformation within the AVP indicates the TimeStamp as received in the previo= us OC-OLR AVP, according to which the ongoing throttling (which was survive= d) is performed. OC-Ongoing-Throttling-Information ::=3D < AVP Header: TBD9 > < TimeStamp > * [ AVP ] Supporting Clients would insert the OC-Ongoing-Throttling-Information AVP = into request messages that survived a throttling performed at that client. Supporting Agents when receiving a request message that contains an OC-Ongo= ing-Throttling-Information AVP would not perform an additional throttling (= since the client or a downstream agent already performed the throttling) , = while, when receiving a request that does not contain OC-Ongoing-Throttling= -Information AVP would perform throttling (on behalf of the client) accordi= ng to a previously received and stored OC-OLR, and if that throttling is su= rvived the agent would insert the OC-Ongoing-Throttling-Information AVP in = the request before sending it further upstream. Servers (or in general reporting nodes) would check presence and content of= the OC-Ongoing-Throttling-Information AVP in received request messages and= could detect (together with a check of presence of OC-Feature-Vector AVP) = whether inserting an OC-OLR AVP in the corresponding answer message is need= ed in order to update the reacting node with a new OC-OLR). This proposal especially addresses use cases like the following: Architecture: +----------------+ | supporting | /| agent A1 |\ +----------------+ / +----------------+ \ | non supporting |/ \ | client C |\ \ +----------------+ \ +----------------+ \ +------------+ +---------= + \| non supporting | \| supporting | | Server = | | agent A2 |------| agent A3 |----| S = | +----------------+ +------------+ +---------+ 1. A request is sent from C via A2 and A3 to S. A3 recognizes that th= ere is no reacting node downstream (no OC-Feature-Vector received) and ther= efore takes the role of the reacting node and inserts an OC-Feature-Vector = AVP. A3 has no valid OLR from S stored and therefore does not perform throt= tling and does not insert an OC-Throttling-Information AVP. 2. S recognizes that there is a reacting node downstream which is act= ually not performing a throttling. S returns a 10% throttling request (Time= Stamp=3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A= 3 and A2 to C. 3. A3 stores the 10% throttling request. 4. A new request is sent from C via A2 and A3 to S. A3 recognizes tha= t there is no reacting node downstream (no OC-Feature-Vector received) and = therefore takes the role of the reacting node and inserts an OC-Feature-Vec= tor AVP. A3 has valid OLR from S stored and performs a 10% throttling. The= request survives and A3 inserts an OC-Throttling-Information AVP with time= Stamp=3Dt1. 5. S recognizes that correct throttling (correct time stamp) is in pl= ace and therefore does not return OC-OLR in the answer. 6. A new request is sent from C via A1 and A3 to S. A1 recognizes tha= t there is no reacting node downstream (no OC-Feature-Vector received) and = therefore takes the role of the reacting node and inserts an OC-Feature-AVP= . A1 has no valid OLR from S stored and therefore does not perform throttli= ng and does not insert an OC-Throttling-Information AVP. A3 recognizes that= there is a reacting node downstream (OC-Feature-Vector received) and there= fore does not take the role of the reacting node. 7. S recognizes that there is a reacting node downstream which is act= ually not performing a throttling. S returns a 10% throttling request (Time= Stamp=3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A= 3 and A1 to C. 8. A1 stores the 10% throttling request. 9. A new request is sent from C via A1 and A3 to S. A1 recognizes tha= t there is no reacting node downstream (no OC-Feature-Vector received) and = therefore takes the role of the reacting node and inserts an OC-Feature-AVP= . A1 has valid OLR from S stored and therefore performs a 10% throttling. = The request survives and A1 inserts an OC-Throttling-Information AVP with t= imeStamp=3Dt1. A3 recognizes that there is a reacting node downstream (OC-F= eature-Vector received) and therefore does not take the role of the reactin= g node. 10. S recognizes that correct throttling (correct time stamp) is in place= and therefore does not return OC-OLR in the answer. 11. Requests sent from C via A1 and A3 to S undergo a 10% throttling at A= 1, requests sent from C via A2 and A3 to S undergo a 10% throttling at A3. 12. Overload situation in S for some reason gets worse, S decides to requ= est 20 % reduction. 13. A new request is sent from C via A1 and A3 to S. A1 recognizes that t= here is no reacting node downstream (no OC-Feature-Vector received) and the= refore takes the role of the reacting node and inserts an OC-Feature-AVP. A= 1 has valid OLR from S stored and therefore performs a 10% throttling. The= request survives and A1 inserts an OC-Throttling-Information AVP with time= Stamp=3Dt1. A3 recognizes that there is a reacting node downstream (OC-Feat= ure-Vector received) and therefore does not take the role of the reacting n= ode. 14. S recognizes that incorrect throttling (wrong time stamp) is in place= and therefore S returns a 20% throttling request (TimeStamp=3Dt2, duration= =3Dx) within OC-OLR in the answer which goes back via A3 and A1 to C. 15. A3 (not taking the role of the reactingt node)may, A1 must store the = 20% throttling request (replacing the 10% request). 16. A new request is sent from C via A2 and A3 to S. A3 recognizes that t= here is no reacting node downstream (no OC-Feature-Vector received) and the= refore takes the role of the reacting node and inserts an OC-Feature-Vector= AVP. A3 has valid OLR from S stored and performs a 10% throttling. The re= quest survives and A3 inserts an OC-Throttling-Information AVP with timeSta= mp=3Dt1. (assuming A3 did not store the 20% request at step 14) 17. S recognizes that incorrect throttling (wrong time stamp) is in place= and therefore S returns a 20% throttling request (TimeStamp=3Dt2, duration= =3Dx) within OC-OLR in the answer which goes back via A3 and A2 to C. 18. A3 stores the 20% throttling request (replacing the 10% request). 19. Requests sent from C via A1 and A3 to S undergo a 20% throttling at A= 1, requests sent from C via A2 and A3 to S undergo a 20% throttling at A3. Comments are welcome. Best regards Ulrich --_000_A9CA33BB78081F478946E4F34BF9AAA014CF3237xmbrcdx10ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ulrich,=

 <= /p>

I might be missing someth= ing here so please bear with me.

 <= /p>

Number of answer messages= sent by server =3D number of request messages received by the server.=

During the overload, the = server would receive only those requests which survived throttling.

And then the server would= send answer messages to only those request messages.

So “every” an= d “some” are actually equal in the below equation. No?

 <= /p>

Regards,

Nirav.<= /p>

 <= /p>

From: Wiehe, U= lrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Sent: Wednesday, November 06, 2013 8:24 PM
To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org
Subject: RE: Ongoing Throttling Information in request messages=

 

Nirav,

 

Not quite.

 <= /p>

The question is:

“is sending an over= load-report in every answer message that corresponds to request with OC-Feature-Vec= tor present more resource consuming than receiving Ongoing-Throttling-Infor= mation in some request messages (only those that survived a throttling)?”= ;

 <= /p>

Best regards

Ulrich<= /p>

 <= /p>

 <= /p>

 <= /p>

From: ext Nira= v Salot (nsalot) [mailto:nsalot@cisco.c= om]
Sent: Wednesday, November 06, 2013 3:15 PM
To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org
Subject: RE: Ongoing Throttling Information in request messages=

 

Ulrich,=

 <= /p>

Thanks for clarification.=

 <= /p>

Then the question would b= e

“is sending overloa= d-report in every answer message is more resource consuming than the soluti= on below – i.e. receiving OC-Ongoing-Throttling-Information in all request message and analyzing the timestamp and then deciding if the o= verload-report should be included or not.”

I am not sure.=

 <= /p>

Regards,

Nirav.<= /p>

 <= /p>

From: Wiehe, U= lrich (NSN - DE/Munich) [mailto:ulr= ich.wiehe@nsn.com]
Sent: Wednesday, November 06, 2013 7:08 PM
To: Nirav Salot (nsalot); doc-dt@= ietf.org; dime@ietf.org
Subject: RE: Ongoing Throttling Information in request messages=

 

Nirav,<= /p>

thank you for your commen= ts.

 <= /p>

The comparism is between:=

Current way: “send = OC specific information (Feature-Vector) in every request message and in ev= ery corresponding answer message”

My proposal: “send = OC specific information (Feature-Vector and in some cases Ongoing-Throttlin= g-Info) in every request message and in corresponding answer messages only when required”.

 <= /p>

Sending OC specific infor= mation  is regarded a resource consuming action and we should not put = this action to the (overloaded) server where avoidable. See REQ 13.

 <= /p>

Best regards

Ulrich<= /p>

 <= /p>

 <= /p>

 <= /p>

 <= /p>

From: ext Nira= v Salot (nsalot) [mailto:nsalot@cisco.c= om]
Sent: Wednesday, November 06, 2013 12:04 PM
To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org
Subject: RE: Ongoing Throttling Information in request messages=

 

Ulrich,=

 <= /p>

Thanks for the detail exp= lanation of your proposal.

 <= /p>

Just to verify my underst= anding,

Your proposal would allow= the reporting node to avoid inclusion of the “same” overload-r= eport in the answer message since the request message indicates that the path contains at least one reacting node which already has the latest = overload-report.

In other words, the repor= ting node need not include overload-report in every message, blindly.<= /o:p>

 <= /p>

To achieve the above obje= ctive, the solution below suggest the reacting node to include new AVP OC-O= ngoing-Throttling-Information in every request message, which survives throttling.

So the net result is that= , the inclusion of the overload-report is prevented in every answer message= since the OC-Ongoing-Throttling-Information is included in every request message.

[Wiehe, Ulrich (NSN= - DE/Munich)] no.  …in every request message that survived a th= rottling.

And hence I am not sure i= f the solution has sound benefit from the inclusion of redundant informatio= n point of view.

 <= /p>

In summary, I think the s= olution suggested below works as explained.

But I fail to see the ben= efit of using this solution compare to a solution in which the reporting no= de includes overload-report in every answer message.

 <= /p>

Regards,

Nirav.<= /p>

 <= /p>

From: doc-dt-bounces@ietf.org [mailto:doc-dt-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: Tuesday, November 05, 2013 9:36 PM
To: doc-dt@ietf.org; dime@ietf.org
Subject: [doc-dt] Ongoing Throttling Information in request messages=

 

Hi,

draft-docdt-dime-ovli-01

in Appendix B, Table 1, REQ 13 says:

      &nb= sp; …. Another way

      &nb= sp; is to let the request sender (reacting node) insert

      &nb= sp; information in the request to say whether a=

      &nb= sp; throttling is actually performed.  The reporting node

      &nb= sp; then can base its decision on information received in

      &nb= sp; the request; no need for keeping state to record who

  has received overload = reports. 

 

And in Appendix B, Table 1, REQ 18:

      &nb= sp; There has been a proposal to mark

      &nb= sp; messages that survived overload throttling as one=

      &nb= sp; method for an overloaded node to address fairness but<= o:p>

      &nb= sp; this proposal is not yet part of the solution. 

 

I would like to come back to this propo= sal.

A new AVP OC-Ongoing-Throttling-Informa= tion inserted in request messages would indicate that the request message s= urvived a throttling. Furthermore, information within the AVP indicates the TimeStamp as received in the previous OC-OLR AVP, accord= ing to which the ongoing throttling (which was survived) is performed.=

 

OC-Ongoing-Throttling-Information ::=3D < AVP Header: T= BD9 >

         &nbs= p;    < TimeStamp >

         &nbs= p;  * [ AVP ]

 

Supporting Clients would insert the OC-= Ongoing-Throttling-Information AVP  into request messages that survive= d a throttling performed at that client.

Supporting Agents when receiving a requ= est message that contains an OC-Ongoing-Throttling-Information AVP would no= t perform an additional throttling (since the client or a downstream agent already performed the throttling) , while, when receivi= ng a request that does not contain OC-Ongoing-Throttling-Information AVP wo= uld perform throttling (on behalf of the client) according to a previously = received and stored OC-OLR, and if that throttling is survived the agent would insert the OC-Ongoing-Throt= tling-Information AVP in the request before sending it further upstream.

Servers (or in general reporting nodes)= would check presence and content of the OC-Ongoing-Throttling-Information = AVP in received request messages and could detect (together with a check of presence of OC-Feature-Vector AVP) whether inserting an OC= -OLR AVP in the corresponding answer message is needed in order to update t= he reacting node with a new OC-OLR).

 

This proposal especially addresses use = cases like the following:

 

Architecture:

 

         &nbs= p;             = +----------------+

         &nbs= p;             = | supporting     |

          &nb= sp;           /| agent A1=        |\   

  +----------------+ / +----------------&= #43; \

  | non supporting |/     &n= bsp;            = ;    \

  | client C       |\&n= bsp;            = ;          \

  +----------------+ \ +----------------&= #43;    \ +------------+    +----= -----+

         &nbs= p;            \| non= supporting |     \| supporting |    | Server=   |

         &nbs= p;             = |  agent A2      |------| agent A3  = ; |----|  S      |

         &nbs= p;            +------= ----------+      +------------+ &= nbsp;  +---------+

 

1.    &nb= sp;  A request is sent from C via A2= and A3 to S. A3 recognizes that there is no reacting node downstream (no O= C-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-Vector AVP. A3 has no valid= OLR from S stored and therefore does not perform throttling and does not i= nsert an OC-Throttling-Information AVP.

2.    &nb= sp;  S recognizes that there is a re= acting node downstream which is actually not performing a throttling. S ret= urns a 10% throttling request (TimeStamp=3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A3 and A2 to C.=

3.    &nb= sp;  A3 stores the 10% throttling re= quest.

4.    &nb= sp;  A new request is sent from C vi= a A2 and A3 to S. A3 recognizes that there is no reacting node downstream (= no OC-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-Vector AVP. A3 has&nbs= p; valid OLR from S stored and performs a 10% throttling. The request survi= ves and A3 inserts an OC-Throttling-Information AVP with timeStamp=3Dt1.

5.    &nb= sp;  S recognizes that correct throt= tling (correct time stamp) is in place and therefore does not return OC-OLR= in the answer.

6.    &nb= sp;  A new request is sent from C vi= a A1 and A3 to S. A1 recognizes that there is no reacting node downstream (= no OC-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 has no valid O= LR from S stored and therefore does not perform throttling and does not ins= ert an OC-Throttling-Information AVP. A3 recognizes that there is a reactin= g node downstream (OC-Feature-Vector received) and therefore does not take the role of the reacting node.<= /o:p>

7.    &nb= sp;  S recognizes that there is a re= acting node downstream which is actually not performing a throttling. S ret= urns a 10% throttling request (TimeStamp=3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A3 and A1 to C.=

8.    &nb= sp;  A1 stores the 10% throttling re= quest.

9.    &nb= sp;  A new request is sent from C vi= a A1 and A3 to S. A1 recognizes that there is no reacting node downstream (= no OC-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 has  vali= d OLR from S stored and therefore performs a 10% throttling. The request su= rvives and A1 inserts an OC-Throttling-Information AVP with timeStamp=3Dt1.= A3 recognizes that there is a reacting node downstream (OC-Feature-Vector received) and therefore does not take t= he role of the reacting node.

10.   S recognizes that correct throt= tling (correct time stamp) is in place and therefore does not return OC-OLR= in the answer.

11.   Requests sent from C via A1 and= A3 to S undergo a 10% throttling at A1, requests sent from C via A2 and A3= to S undergo a 10% throttling at A3.

12.   Overload situation in S for som= e reason gets worse, S decides to request 20 % reduction.=

13.   A new request is sent from C vi= a A1 and A3 to S. A1 recognizes that there is no reacting node downstream (= no OC-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 has  vali= d OLR from S stored and therefore performs a 10% throttling. The request su= rvives and A1 inserts an OC-Throttling-Information AVP with timeStamp=3Dt1.= A3 recognizes that there is a reacting node downstream (OC-Feature-Vector received) and therefore does not take t= he role of the reacting node.

14.   S recognizes that incorrect thr= ottling (wrong time stamp) is in place and therefore S returns a 20% thrott= ling request (TimeStamp=3Dt2, duration=3Dx) within OC-OLR in the answer which goes back via A3 and A1 to C.

15.   A3 (not taking the role of the = reactingt node)may, A1 must store the 20% throttling request (replacing the= 10% request).

16.   A new request is sent from C vi= a A2 and A3 to S. A3 recognizes that there is no reacting node downstream (= no OC-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-Vector AVP. A3 has&nbs= p; valid OLR from S stored and performs a 10% throttling. The request survi= ves and A3 inserts an OC-Throttling-Information AVP with timeStamp=3Dt1. (a= ssuming A3 did not store the 20% request at step 14)

17.   S recognizes that incorrect thr= ottling (wrong time stamp) is in place and therefore S returns a 20% thrott= ling request (TimeStamp=3Dt2, duration=3Dx) within OC-OLR in the answer which goes back via A3 and A2 to C.

18.   A3 stores the 20% throttling re= quest (replacing the 10% request).

19.   Requests sent from C via A1 and= A3 to S undergo a 20% throttling at A1, requests sent from C via A2 and A3= to S undergo a 20% throttling at A3.

 

 

Comments are welcome.=

 

Best regards

Ulrich

 

 

--_000_A9CA33BB78081F478946E4F34BF9AAA014CF3237xmbrcdx10ciscoc_-- From srdonovan@usdonovans.com Wed Nov 6 09:01:19 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBBD411E8231 for ; Wed, 6 Nov 2013 09:01:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.565 X-Spam-Level: X-Spam-Status: No, score=-2.565 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id csRuh5GH3hAu for ; Wed, 6 Nov 2013 09:01:07 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [192.249.113.76]) by ietfa.amsl.com (Postfix) with ESMTP id AAEEA11E8210 for ; Wed, 6 Nov 2013 09:01:00 -0800 (PST) Received: from dhcp-a236.meeting.ietf.org ([31.133.162.54]:55632) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1Ve6TS-0002dV-9q for dime@ietf.org; Wed, 06 Nov 2013 09:00:59 -0800 Message-ID: <527A75C9.3050103@usdonovans.com> Date: Wed, 06 Nov 2013 09:00:57 -0800 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: dime@ietf.org References: <527A6C8B.4080407@usdonovans.com> In-Reply-To: <527A6C8B.4080407@usdonovans.com> X-Forwarded-Message-Id: <527A6C8B.4080407@usdonovans.com> Content-Type: multipart/alternative; boundary="------------040003070405050702050502" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed Subject: [Dime] Fwd: Re: Ongoing Throttling Information in request messages X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 17:01:19 -0000 This is a multi-part message in MIME format. --------------040003070405050702050502 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Resending with most of the message trimmed. My first attempt to send this got a response that the message is awaiting moderator approval because it was bigger than 50k bytes. Steve -------- Original Message -------- Subject: Re: [Dime] Ongoing Throttling Information in request messages Date: Wed, 06 Nov 2013 08:21:31 -0800 From: Steve Donovan To: dime@ietf.org Nirav, One qualification of your point below -- The server would only receive requests that survived throttling from clients that support DOIC. The server will also receive requests from clients that do not support DOIC. One of the benefits of Ulrich's proposal is that it tells the server when a request has not gone through throttling. The server can then choose to do something different with that set of requests. As to the question of which is more work for the server, which is the important question, that isn't yet clear to me. Steve On 11/6/13, 7:02 AM, Nirav Salot (nsalot) wrote: > > Ulrich, > > I might be missing something here so please bear with me. > > Number of answer messages sent by server = number of request messages > received by the server. > > During the overload, the server would receive only those requests > which survived throttling. > > And then the server would send answer messages to only those request > messages. > > So "every" and "some" are actually equal in the below equation. No? > > Regards, > > Nirav. > > --------------040003070405050702050502 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Resending with most of the message trimmed.  My first attempt to send this got a response that the message is awaiting moderator approval because it was bigger than 50k bytes.

Steve

-------- Original Message --------
Subject: Re: [Dime] Ongoing Throttling Information in request messages
Date: Wed, 06 Nov 2013 08:21:31 -0800
From: Steve Donovan <srdonovan@usdonovans.com>
To: dime@ietf.org


Nirav,

One qualification of your point below -- The server would only receive requests that survived throttling from clients that support DOIC.  The server will also receive requests from clients that do not support DOIC.  One of the benefits of Ulrich's proposal is that it tells the server when a request has not gone through throttling.  The server can then choose to do something different with that set of requests.

As to the question of which is more work for the server, which is the important question, that isn't yet clear to me. 

Steve

On 11/6/13, 7:02 AM, Nirav Salot (nsalot) wrote:

Ulrich,

 

I might be missing something here so please bear with me.

 

Number of answer messages sent by server = number of request messages received by the server.

During the overload, the server would receive only those requests which survived throttling.

And then the server would send answer messages to only those request messages.

So “every” and “some” are actually equal in the below equation. No?

 

Regards,

Nirav.




--------------040003070405050702050502-- From jouni.nospam@gmail.com Wed Nov 6 09:03:24 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7363311E8140; Wed, 6 Nov 2013 09:03:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.99 X-Spam-Level: X-Spam-Status: No, score=-1.99 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0IYA9lzAkD0g; Wed, 6 Nov 2013 09:03:23 -0800 (PST) Received: from mail-pa0-x230.google.com (mail-pa0-x230.google.com [IPv6:2607:f8b0:400e:c03::230]) by ietfa.amsl.com (Postfix) with ESMTP id 9402D21E8142; Wed, 6 Nov 2013 09:03:23 -0800 (PST) Received: by mail-pa0-f48.google.com with SMTP id kq14so10761521pab.21 for ; Wed, 06 Nov 2013 09:03:23 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LyVjvCspexLSrpYivHBzu6U9Bll+4brX5VaylA7VMeI=; b=cQVjFKto49pHmdRNQgSjo+e4dBSdBYHxzQLdqGVzoGvOb/FZuu8sOZBulVT0ht9xdA PVBoEUDGp+8iEFHdN4tOPY2y7y01VaHitZ7GjIsBDtrbF/jR1/weJozIQu5x3hlEgBRX KPWNA8M+Y4LRIb5915j2QjIW/pz2yG+hLQQmq+H/BH/4Gojl95Sp7HSYbGJbDh7knRet s1j3ax1LPH6xWfMpk+EbK+USYa98tGW137P7skyZ4Bhw4nTCmhidpC4zwSluXRZP2SI/ bJOrzQlfwEsxJkyrLuNrwUEqlara6TR97rLcnWdfkg8/0cvf2w/yPZYp0a4ng8XSgt74 uuqA== X-Received: by 10.69.8.162 with SMTP id dl2mr4321931pbd.1.1383757402971; Wed, 06 Nov 2013 09:03:22 -0800 (PST) Received: from hotel-wireless-v6.meeting.ietf.org ([2001:67c:370:144:2d14:c95f:b8d:4ce9]) by mx.google.com with ESMTPSA id ry4sm49491275pab.4.2013.11.06.09.03.20 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 06 Nov 2013 09:03:21 -0800 (PST) Content-Type: text/plain; charset=windows-1252 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D9000668151918EC@DEMUMBX014.nsn-intra.net> Date: Wed, 6 Nov 2013 19:03:17 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <65A57E48-7220-4D7C-B3F5-2D10AC7B5855@gmail.com> References: <5BCBA1FC2B7F0B4C9D935572D9000668151918EC@DEMUMBX014.nsn-intra.net> To: "dime@ietf.org" X-Mailer: Apple Mail (2.1510) Cc: doc-dt@ietf.org Subject: Re: [Dime] Ongoing Throttling Information in request messages X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 17:03:24 -0000 Just a reminder. Please avoid using HTML emails ;-) This innocent 13KB = blob of text expanded into ~80KB of HTML goodness after few iterations, = which our email list reflector holds until the moderator accepts it = manually. I'll check if I can raise the maximum message size in a = meanwhile. - JOuni On Nov 5, 2013, at 6:06 PM, "Wiehe, Ulrich (NSN - DE/Munich)" = wrote: > Hi, > draft-docdt-dime-ovli-01 > in Appendix B, Table 1, REQ 13 says: > =85. Another way > is to let the request sender (reacting node) insert > information in the request to say whether a > throttling is actually performed. The reporting node > then can base its decision on information received in > the request; no need for keeping state to record who > has received overload reports.=20 > =20 > And in Appendix B, Table 1, REQ 18: > There has been a proposal to mark > messages that survived overload throttling as one > method for an overloaded node to address fairness but > this proposal is not yet part of the solution.=20 > =20 > I would like to come back to this proposal. > A new AVP OC-Ongoing-Throttling-Information inserted in request = messages would indicate that the request message survived a throttling. = Furthermore, information within the AVP indicates the TimeStamp as = received in the previous OC-OLR AVP, according to which the ongoing = throttling (which was survived) is performed. > =20 > OC-Ongoing-Throttling-Information ::=3D < AVP Header: TBD9 > > < TimeStamp > > * [ AVP ] > =20 > Supporting Clients would insert the OC-Ongoing-Throttling-Information = AVP into request messages that survived a throttling performed at that = client. > Supporting Agents when receiving a request message that contains an = OC-Ongoing-Throttling-Information AVP would not perform an additional = throttling (since the client or a downstream agent already performed the = throttling) , while, when receiving a request that does not contain = OC-Ongoing-Throttling-Information AVP would perform throttling (on = behalf of the client) according to a previously received and stored = OC-OLR, and if that throttling is survived the agent would insert the = OC-Ongoing-Throttling-Information AVP in the request before sending it = further upstream. > Servers (or in general reporting nodes) would check presence and = content of the OC-Ongoing-Throttling-Information AVP in received request = messages and could detect (together with a check of presence of = OC-Feature-Vector AVP) whether inserting an OC-OLR AVP in the = corresponding answer message is needed in order to update the reacting = node with a new OC-OLR). > =20 > This proposal especially addresses use cases like the following: > =20 > Architecture: > =20 > +----------------+ > | supporting | > /| agent A1 |\ =20 > +----------------+ / +----------------+ \ > | non supporting |/ \ > | client C |\ \ > +----------------+ \ +----------------+ \ +------------+ = +---------+ > \| non supporting | \| supporting | | = Server | > | agent A2 |------| agent A3 |----| S = | > +----------------+ +------------+ = +---------+ > =20 > =95 A request is sent from C via A2 and A3 to S. A3 recognizes = that there is no reacting node downstream (no OC-Feature-Vector = received) and therefore takes the role of the reacting node and inserts = an OC-Feature-Vector AVP. A3 has no valid OLR from S stored and = therefore does not perform throttling and does not insert an = OC-Throttling-Information AVP. > =95 S recognizes that there is a reacting node downstream which = is actually not performing a throttling. S returns a 10% throttling = request (TimeStamp=3Dt1, duration=3Dd) within OC-OLR in the answer which = goes back via A3 and A2 to C. > =95 A3 stores the 10% throttling request. > =95 A new request is sent from C via A2 and A3 to S. A3 = recognizes that there is no reacting node downstream (no = OC-Feature-Vector received) and therefore takes the role of the reacting = node and inserts an OC-Feature-Vector AVP. A3 has valid OLR from S = stored and performs a 10% throttling. The request survives and A3 = inserts an OC-Throttling-Information AVP with timeStamp=3Dt1. > =95 S recognizes that correct throttling (correct time stamp) is = in place and therefore does not return OC-OLR in the answer. > =95 A new request is sent from C via A1 and A3 to S. A1 = recognizes that there is no reacting node downstream (no = OC-Feature-Vector received) and therefore takes the role of the reacting = node and inserts an OC-Feature-AVP. A1 has no valid OLR from S stored = and therefore does not perform throttling and does not insert an = OC-Throttling-Information AVP. A3 recognizes that there is a reacting = node downstream (OC-Feature-Vector received) and therefore does not take = the role of the reacting node. > =95 S recognizes that there is a reacting node downstream which = is actually not performing a throttling. S returns a 10% throttling = request (TimeStamp=3Dt1, duration=3Dd) within OC-OLR in the answer which = goes back via A3 and A1 to C. > =95 A1 stores the 10% throttling request. > =95 A new request is sent from C via A1 and A3 to S. A1 = recognizes that there is no reacting node downstream (no = OC-Feature-Vector received) and therefore takes the role of the reacting = node and inserts an OC-Feature-AVP. A1 has valid OLR from S stored and = therefore performs a 10% throttling. The request survives and A1 inserts = an OC-Throttling-Information AVP with timeStamp=3Dt1. A3 recognizes that = there is a reacting node downstream (OC-Feature-Vector received) and = therefore does not take the role of the reacting node. > =95 S recognizes that correct throttling (correct time stamp) is = in place and therefore does not return OC-OLR in the answer. > =95 Requests sent from C via A1 and A3 to S undergo a 10% = throttling at A1, requests sent from C via A2 and A3 to S undergo a 10% = throttling at A3. > =95 Overload situation in S for some reason gets worse, S = decides to request 20 % reduction. > =95 A new request is sent from C via A1 and A3 to S. A1 = recognizes that there is no reacting node downstream (no = OC-Feature-Vector received) and therefore takes the role of the reacting = node and inserts an OC-Feature-AVP. A1 has valid OLR from S stored and = therefore performs a 10% throttling. The request survives and A1 inserts = an OC-Throttling-Information AVP with timeStamp=3Dt1. A3 recognizes that = there is a reacting node downstream (OC-Feature-Vector received) and = therefore does not take the role of the reacting node. > =95 S recognizes that incorrect throttling (wrong time stamp) is = in place and therefore S returns a 20% throttling request (TimeStamp=3Dt2,= duration=3Dx) within OC-OLR in the answer which goes back via A3 and A1 = to C. > =95 A3 (not taking the role of the reactingt node)may, A1 must = store the 20% throttling request (replacing the 10% request). > =95 A new request is sent from C via A2 and A3 to S. A3 = recognizes that there is no reacting node downstream (no = OC-Feature-Vector received) and therefore takes the role of the reacting = node and inserts an OC-Feature-Vector AVP. A3 has valid OLR from S = stored and performs a 10% throttling. The request survives and A3 = inserts an OC-Throttling-Information AVP with timeStamp=3Dt1. (assuming = A3 did not store the 20% request at step 14) > =95 S recognizes that incorrect throttling (wrong time stamp) is = in place and therefore S returns a 20% throttling request (TimeStamp=3Dt2,= duration=3Dx) within OC-OLR in the answer which goes back via A3 and A2 = to C. > =95 A3 stores the 20% throttling request (replacing the 10% = request). > =95 Requests sent from C via A1 and A3 to S undergo a 20% = throttling at A1, requests sent from C via A2 and A3 to S undergo a 20% = throttling at A3. > =20 > =20 > Comments are welcome. > =20 > Best regards > Ulrich > =20 > =20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From srdonovan@usdonovans.com Wed Nov 6 08:21:43 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A56C821F9E9F for ; Wed, 6 Nov 2013 08:21:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.298 X-Spam-Level: X-Spam-Status: No, score=-2.298 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AMmfddFnHB8y for ; Wed, 6 Nov 2013 08:21:38 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [192.249.113.76]) by ietfa.amsl.com (Postfix) with ESMTP id A4E9F21F9E7C for ; Wed, 6 Nov 2013 08:21:36 -0800 (PST) Received: from dhcp-a236.meeting.ietf.org ([31.133.162.54]:54197) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1Ve5rI-0000Ij-QJ for dime@ietf.org; Wed, 06 Nov 2013 08:21:35 -0800 Message-ID: <527A6C8B.4080407@usdonovans.com> Date: Wed, 06 Nov 2013 08:21:31 -0800 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: dime@ietf.org References: <5BCBA1FC2B7F0B4C9D935572D9000668151918EC@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192B2B@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192B90@DEMUMBX014.nsn-intra.net> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010806010009060808030009" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srd+usdonovans.com/only user confirmed/virtual account not confirmed X-Mailman-Approved-At: Wed, 06 Nov 2013 09:23:29 -0800 Subject: Re: [Dime] Ongoing Throttling Information in request messages X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 06 Nov 2013 16:21:43 -0000 This is a multi-part message in MIME format. --------------010806010009060808030009 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Nirav, One qualification of your point below -- The server would only receive requests that survived throttling from clients that support DOIC. The server will also receive requests from clients that do not support DOIC. One of the benefits of Ulrich's proposal is that it tells the server when a request has not gone through throttling. The server can then choose to do something different with that set of requests. As to the question of which is more work for the server, which is the important question, that isn't yet clear to me. Steve On 11/6/13, 7:02 AM, Nirav Salot (nsalot) wrote: > > Ulrich, > > I might be missing something here so please bear with me. > > Number of answer messages sent by server = number of request messages > received by the server. > > During the overload, the server would receive only those requests > which survived throttling. > > And then the server would send answer messages to only those request > messages. > > So "every" and "some" are actually equal in the below equation. No? > > Regards, > > Nirav. > > *From:*Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] > *Sent:* Wednesday, November 06, 2013 8:24 PM > *To:* Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org > *Subject:* RE: Ongoing Throttling Information in request messages > > Nirav, > > Not quite. > > The question is: > > "is sending an overload-report in *every* answer message that > corresponds to request with OC-Feature-Vector present more resource > consuming than receiving Ongoing-Throttling-Information in *some* > request messages (only those that survived a throttling)?" > > Best regards > > Ulrich > > *From:*ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] > *Sent:* Wednesday, November 06, 2013 3:15 PM > *To:* Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org > ; dime@ietf.org > *Subject:* RE: Ongoing Throttling Information in request messages > > Ulrich, > > Thanks for clarification. > > Then the question would be > > "is sending overload-report in every answer message is more resource > consuming than the solution below -- i.e. receiving > OC-Ongoing-Throttling-Information in all request message and analyzing > the timestamp and then deciding if the overload-report should be > included or not." > > I am not sure. > > Regards, > > Nirav. > > *From:*Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] > *Sent:* Wednesday, November 06, 2013 7:08 PM > *To:* Nirav Salot (nsalot); doc-dt@ietf.org ; > dime@ietf.org > *Subject:* RE: Ongoing Throttling Information in request messages > > Nirav, > > thank you for your comments. > > The comparism is between: > > Current way: "send OC specific information (Feature-Vector) in every > request message and in every corresponding answer message" > > My proposal: "send OC specific information (Feature-Vector and in some > cases Ongoing-Throttling-Info) in every request message and in > corresponding answer messages only when required". > > Sending OC specific information is regarded a resource consuming > action and we should not put this action to the (overloaded) server > where avoidable. See REQ 13. > > Best regards > > Ulrich > > *From:*ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] > *Sent:* Wednesday, November 06, 2013 12:04 PM > *To:* Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org > ; dime@ietf.org > *Subject:* RE: Ongoing Throttling Information in request messages > > Ulrich, > > Thanks for the detail explanation of your proposal. > > Just to verify my understanding, > > Your proposal would allow the reporting node to avoid inclusion of the > "same" overload-report in the answer message since the request message > indicates that the path contains at least one reacting node which > already has the latest overload-report. > > In other words, the reporting node need not include overload-report in > every message, blindly. > > To achieve the above objective, the solution below suggest the > reacting node to include new AVP OC-Ongoing-Throttling-Information in > every request message, which survives throttling. > > So the net result is that, the inclusion of the overload-report is > prevented in every answer message since the > OC-Ongoing-Throttling-Information is included in every request message. > > */[Wiehe, Ulrich (NSN - DE/Munich)] no. ...in every request message > that survived a throttling./* > > And hence I am not sure if the solution has sound benefit from the > inclusion of redundant information point of view. > > In summary, I think the solution suggested below works as explained. > > But I fail to see the benefit of using this solution compare to a > solution in which the reporting node includes overload-report in every > answer message. > > Regards, > > Nirav. > > *From:*doc-dt-bounces@ietf.org > [mailto:doc-dt-bounces@ietf.org] *On Behalf Of *Wiehe, Ulrich (NSN - > DE/Munich) > *Sent:* Tuesday, November 05, 2013 9:36 PM > *To:* doc-dt@ietf.org ; dime@ietf.org > > *Subject:* [doc-dt] Ongoing Throttling Information in request messages > > Hi, > > *draft-docdt-dime-ovli-01 * > > in Appendix B, Table 1, REQ 13 says: > > .... Another way > > is to let the request sender (reacting node) insert > > information in the request to say whether a > > throttling is actually performed. The reporting node > > then can base its decision on information received in > > the request; no need for keeping state to record who > > has received overload reports. > > And in Appendix B, Table 1, REQ 18: > > There has been a proposal to mark > > messages that survived overload throttling as one > > method for an overloaded node to address fairness but > > this proposal is not yet part of the solution. > > I would like to come back to this proposal. > > A new AVP OC-Ongoing-Throttling-Information inserted in request > messages would indicate that the request message survived a > throttling. Furthermore, information within the AVP indicates the > TimeStamp as received in the previous OC-OLR AVP, according to which > the ongoing throttling (which was survived) is performed. > > OC-Ongoing-Throttling-Information ::= < AVP Header: TBD9 > > > < TimeStamp > > > * [ AVP ] > > Supporting Clients would insert the OC-Ongoing-Throttling-Information > AVP into request messages that survived a throttling performed at > that client. > > Supporting Agents when receiving a request message that contains an > OC-Ongoing-Throttling-Information AVP would not perform an additional > throttling (since the client or a downstream agent already performed > the throttling) , while, when receiving a request that does not > contain OC-Ongoing-Throttling-Information AVP would perform throttling > (on behalf of the client) according to a previously received and > stored OC-OLR, and if that throttling is survived the agent would > insert the OC-Ongoing-Throttling-Information AVP in the request before > sending it further upstream. > > Servers (or in general reporting nodes) would check presence and > content of the OC-Ongoing-Throttling-Information AVP in received > request messages and could detect (together with a check of presence > of OC-Feature-Vector AVP) whether inserting an OC-OLR AVP in the > corresponding answer message is needed in order to update the reacting > node with a new OC-OLR). > > This proposal especially addresses use cases like the following: > > Architecture: > > +----------------+ > > | supporting | > > /| agent A1 |\ > > +----------------+ / +----------------+ \ > > | non supporting |/ \ > > | client C |\ \ > > +----------------+ \ +----------------+ \ +------------+ > +---------+ > > \| non supporting | \| supporting | | Server | > > | agent A2 |------| agent A3 |----| S | > > +----------------+ +------------+ +---------+ > > 1.A request is sent from C via A2 and A3 to S. A3 recognizes that > there is no reacting node downstream (no OC-Feature-Vector received) > and therefore takes the role of the reacting node and inserts an > OC-Feature-Vector AVP. A3 has no valid OLR from S stored and therefore > does not perform throttling and does not insert an > OC-Throttling-Information AVP. > > 2.S recognizes that there is a reacting node downstream which is > actually not performing a throttling. S returns a 10% throttling > request (TimeStamp=t1, duration=d) within OC-OLR in the answer which > goes back via A3 and A2 to C. > > 3.A3 stores the 10% throttling request. > > 4.A new request is sent from C via A2 and A3 to S. A3 recognizes that > there is no reacting node downstream (no OC-Feature-Vector received) > and therefore takes the role of the reacting node and inserts an > OC-Feature-Vector AVP. A3 has valid OLR from S stored and performs a > 10% throttling. The request survives and A3 inserts an > OC-Throttling-Information AVP with timeStamp=t1. > > 5.S recognizes that correct throttling (correct time stamp) is in > place and therefore does not return OC-OLR in the answer. > > 6.A new request is sent from C via A1 and A3 to S. A1 recognizes that > there is no reacting node downstream (no OC-Feature-Vector received) > and therefore takes the role of the reacting node and inserts an > OC-Feature-AVP. A1 has no valid OLR from S stored and therefore does > not perform throttling and does not insert an > OC-Throttling-Information AVP. A3 recognizes that there is a reacting > node downstream (OC-Feature-Vector received) and therefore does not > take the role of the reacting node. > > 7.S recognizes that there is a reacting node downstream which is > actually not performing a throttling. S returns a 10% throttling > request (TimeStamp=t1, duration=d) within OC-OLR in the answer which > goes back via A3 and A1 to C. > > 8.A1 stores the 10% throttling request. > > 9.A new request is sent from C via A1 and A3 to S. A1 recognizes that > there is no reacting node downstream (no OC-Feature-Vector received) > and therefore takes the role of the reacting node and inserts an > OC-Feature-AVP. A1 has valid OLR from S stored and therefore performs > a 10% throttling. The request survives and A1 inserts an > OC-Throttling-Information AVP with timeStamp=t1. A3 recognizes that > there is a reacting node downstream (OC-Feature-Vector received) and > therefore does not take the role of the reacting node. > > 10.S recognizes that correct throttling (correct time stamp) is in > place and therefore does not return OC-OLR in the answer. > > 11.Requests sent from C via A1 and A3 to S undergo a 10% throttling at > A1, requests sent from C via A2 and A3 to S undergo a 10% throttling > at A3. > > 12.Overload situation in S for some reason gets worse, S decides to > request 20 % reduction. > > 13.A new request is sent from C via A1 and A3 to S. A1 recognizes that > there is no reacting node downstream (no OC-Feature-Vector received) > and therefore takes the role of the reacting node and inserts an > OC-Feature-AVP. A1 has valid OLR from S stored and therefore performs > a 10% throttling. The request survives and A1 inserts an > OC-Throttling-Information AVP with timeStamp=t1. A3 recognizes that > there is a reacting node downstream (OC-Feature-Vector received) and > therefore does not take the role of the reacting node. > > 14.S recognizes that incorrect throttling (wrong time stamp) is in > place and therefore S returns a 20% throttling request (TimeStamp=t2, > duration=x) within OC-OLR in the answer which goes back via A3 and A1 > to C. > > 15.A3 (not taking the role of the reactingt node)may, A1 must store > the 20% throttling request (replacing the 10% request). > > 16.A new request is sent from C via A2 and A3 to S. A3 recognizes that > there is no reacting node downstream (no OC-Feature-Vector received) > and therefore takes the role of the reacting node and inserts an > OC-Feature-Vector AVP. A3 has valid OLR from S stored and performs a > 10% throttling. The request survives and A3 inserts an > OC-Throttling-Information AVP with timeStamp=t1. (assuming A3 did not > store the 20% request at step 14) > > 17.S recognizes that incorrect throttling (wrong time stamp) is in > place and therefore S returns a 20% throttling request (TimeStamp=t2, > duration=x) within OC-OLR in the answer which goes back via A3 and A2 > to C. > > 18.A3 stores the 20% throttling request (replacing the 10% request). > > 19.Requests sent from C via A1 and A3 to S undergo a 20% throttling at > A1, requests sent from C via A2 and A3 to S undergo a 20% throttling > at A3. > > Comments are welcome. > > Best regards > > Ulrich > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --------------010806010009060808030009 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Nirav,

One qualification of your point below -- The server would only receive requests that survived throttling from clients that support DOIC.  The server will also receive requests from clients that do not support DOIC.  One of the benefits of Ulrich's proposal is that it tells the server when a request has not gone through throttling.  The server can then choose to do something different with that set of requests.

As to the question of which is more work for the server, which is the important question, that isn't yet clear to me. 

Steve

On 11/6/13, 7:02 AM, Nirav Salot (nsalot) wrote:

Ulrich,

 

I might be missing something here so please bear with me.

 

Number of answer messages sent by server = number of request messages received by the server.

During the overload, the server would receive only those requests which survived throttling.

And then the server would send answer messages to only those request messages.

So “every” and “some” are actually equal in the below equation. No?

 

Regards,

Nirav.

 

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Sent: Wednesday, November 06, 2013 8:24 PM
To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org
Subject: RE: Ongoing Throttling Information in request messages

 

Nirav,

 

Not quite.

 

The question is:

“is sending an overload-report in every answer message that corresponds to request with OC-Feature-Vector present more resource consuming than receiving Ongoing-Throttling-Information in some request messages (only those that survived a throttling)?”

 

Best regards

Ulrich

 

 

 

From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]
Sent: Wednesday, November 06, 2013 3:15 PM
To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org
Subject: RE: Ongoing Throttling Information in request messages

 

Ulrich,

 

Thanks for clarification.

 

Then the question would be

“is sending overload-report in every answer message is more resource consuming than the solution below – i.e. receiving OC-Ongoing-Throttling-Information in all request message and analyzing the timestamp and then deciding if the overload-report should be included or not.”

I am not sure.

 

Regards,

Nirav.

 

From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]
Sent: Wednesday, November 06, 2013 7:08 PM
To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org
Subject: RE: Ongoing Throttling Information in request messages

 

Nirav,

thank you for your comments.

 

The comparism is between:

Current way: “send OC specific information (Feature-Vector) in every request message and in every corresponding answer message”

My proposal: “send OC specific information (Feature-Vector and in some cases Ongoing-Throttling-Info) in every request message and in corresponding answer messages only when required”.

 

Sending OC specific information  is regarded a resource consuming action and we should not put this action to the (overloaded) server where avoidable. See REQ 13.

 

Best regards

Ulrich

 

 

 

 

From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]
Sent: Wednesday, November 06, 2013 12:04 PM
To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org
Subject: RE: Ongoing Throttling Information in request messages

 

Ulrich,

 

Thanks for the detail explanation of your proposal.

 

Just to verify my understanding,

Your proposal would allow the reporting node to avoid inclusion of the “same” overload-report in the answer message since the request message indicates that the path contains at least one reacting node which already has the latest overload-report.

In other words, the reporting node need not include overload-report in every message, blindly.

 

To achieve the above objective, the solution below suggest the reacting node to include new AVP OC-Ongoing-Throttling-Information in every request message, which survives throttling.

So the net result is that, the inclusion of the overload-report is prevented in every answer message since the OC-Ongoing-Throttling-Information is included in every request message.

[Wiehe, Ulrich (NSN - DE/Munich)] no.  …in every request message that survived a throttling.

And hence I am not sure if the solution has sound benefit from the inclusion of redundant information point of view.

 

In summary, I think the solution suggested below works as explained.

But I fail to see the benefit of using this solution compare to a solution in which the reporting node includes overload-report in every answer message.

 

Regards,

Nirav.

 

From: doc-dt-bounces@ietf.org [mailto:doc-dt-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: Tuesday, November 05, 2013 9:36 PM
To: doc-dt@ietf.org; dime@ietf.org
Subject: [doc-dt] Ongoing Throttling Information in request messages

 

Hi,

draft-docdt-dime-ovli-01

in Appendix B, Table 1, REQ 13 says:

        …. Another way

        is to let the request sender (reacting node) insert

        information in the request to say whether a

        throttling is actually performed.  The reporting node

        then can base its decision on information received in

        the request; no need for keeping state to record who

  has received overload reports. 

 

And in Appendix B, Table 1, REQ 18:

        There has been a proposal to mark

        messages that survived overload throttling as one

        method for an overloaded node to address fairness but

        this proposal is not yet part of the solution. 

 

I would like to come back to this proposal.

A new AVP OC-Ongoing-Throttling-Information inserted in request messages would indicate that the request message survived a throttling. Furthermore, information within the AVP indicates the TimeStamp as received in the previous OC-OLR AVP, according to which the ongoing throttling (which was survived) is performed.

 

OC-Ongoing-Throttling-Information ::= < AVP Header: TBD9 >

              < TimeStamp >

            * [ AVP ]

 

Supporting Clients would insert the OC-Ongoing-Throttling-Information AVP  into request messages that survived a throttling performed at that client.

Supporting Agents when receiving a request message that contains an OC-Ongoing-Throttling-Information AVP would not perform an additional throttling (since the client or a downstream agent already performed the throttling) , while, when receiving a request that does not contain OC-Ongoing-Throttling-Information AVP would perform throttling (on behalf of the client) according to a previously received and stored OC-OLR, and if that throttling is survived the agent would insert the OC-Ongoing-Throttling-Information AVP in the request before sending it further upstream.

Servers (or in general reporting nodes) would check presence and content of the OC-Ongoing-Throttling-Information AVP in received request messages and could detect (together with a check of presence of OC-Feature-Vector AVP) whether inserting an OC-OLR AVP in the corresponding answer message is needed in order to update the reacting node with a new OC-OLR).

 

This proposal especially addresses use cases like the following:

 

Architecture:

 

                       +----------------+

                       | supporting     |

                      /| agent A1       |\   

  +----------------+ / +----------------+ \

  | non supporting |/                      \

  | client C       |\                       \

  +----------------+ \ +----------------+    \ +------------+    +---------+

                      \| non supporting |     \| supporting |    | Server  |

                       |  agent A2      |------| agent A3   |----|  S      |

                      +----------------+      +------------+    +---------+

 

1.       A request is sent from C via A2 and A3 to S. A3 recognizes that there is no reacting node downstream (no OC-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-Vector AVP. A3 has no valid OLR from S stored and therefore does not perform throttling and does not insert an OC-Throttling-Information AVP.

2.       S recognizes that there is a reacting node downstream which is actually not performing a throttling. S returns a 10% throttling request (TimeStamp=t1, duration=d) within OC-OLR in the answer which goes back via A3 and A2 to C.

3.       A3 stores the 10% throttling request.

4.       A new request is sent from C via A2 and A3 to S. A3 recognizes that there is no reacting node downstream (no OC-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-Vector AVP. A3 has  valid OLR from S stored and performs a 10% throttling. The request survives and A3 inserts an OC-Throttling-Information AVP with timeStamp=t1.

5.       S recognizes that correct throttling (correct time stamp) is in place and therefore does not return OC-OLR in the answer.

6.       A new request is sent from C via A1 and A3 to S. A1 recognizes that there is no reacting node downstream (no OC-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 has no valid OLR from S stored and therefore does not perform throttling and does not insert an OC-Throttling-Information AVP. A3 recognizes that there is a reacting node downstream (OC-Feature-Vector received) and therefore does not take the role of the reacting node.

7.       S recognizes that there is a reacting node downstream which is actually not performing a throttling. S returns a 10% throttling request (TimeStamp=t1, duration=d) within OC-OLR in the answer which goes back via A3 and A1 to C.

8.       A1 stores the 10% throttling request.

9.       A new request is sent from C via A1 and A3 to S. A1 recognizes that there is no reacting node downstream (no OC-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 has  valid OLR from S stored and therefore performs a 10% throttling. The request survives and A1 inserts an OC-Throttling-Information AVP with timeStamp=t1. A3 recognizes that there is a reacting node downstream (OC-Feature-Vector received) and therefore does not take the role of the reacting node.

10.   S recognizes that correct throttling (correct time stamp) is in place and therefore does not return OC-OLR in the answer.

11.   Requests sent from C via A1 and A3 to S undergo a 10% throttling at A1, requests sent from C via A2 and A3 to S undergo a 10% throttling at A3.

12.   Overload situation in S for some reason gets worse, S decides to request 20 % reduction.

13.   A new request is sent from C via A1 and A3 to S. A1 recognizes that there is no reacting node downstream (no OC-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 has  valid OLR from S stored and therefore performs a 10% throttling. The request survives and A1 inserts an OC-Throttling-Information AVP with timeStamp=t1. A3 recognizes that there is a reacting node downstream (OC-Feature-Vector received) and therefore does not take the role of the reacting node.

14.   S recognizes that incorrect throttling (wrong time stamp) is in place and therefore S returns a 20% throttling request (TimeStamp=t2, duration=x) within OC-OLR in the answer which goes back via A3 and A1 to C.

15.   A3 (not taking the role of the reactingt node)may, A1 must store the 20% throttling request (replacing the 10% request).

16.   A new request is sent from C via A2 and A3 to S. A3 recognizes that there is no reacting node downstream (no OC-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-Vector AVP. A3 has  valid OLR from S stored and performs a 10% throttling. The request survives and A3 inserts an OC-Throttling-Information AVP with timeStamp=t1. (assuming A3 did not store the 20% request at step 14)

17.   S recognizes that incorrect throttling (wrong time stamp) is in place and therefore S returns a 20% throttling request (TimeStamp=t2, duration=x) within OC-OLR in the answer which goes back via A3 and A2 to C.

18.   A3 stores the 20% throttling request (replacing the 10% request).

19.   Requests sent from C via A1 and A3 to S undergo a 20% throttling at A1, requests sent from C via A2 and A3 to S undergo a 20% throttling at A3.

 

 

Comments are welcome.

 

Best regards

Ulrich

 

 



_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime

--------------010806010009060808030009-- From lionel.morand@orange.com Wed Nov 6 16:33:20 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D2C111E815E for ; Wed, 6 Nov 2013 16:33:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.178 X-Spam-Level: X-Spam-Status: No, score=-2.178 tagged_above=-999 required=5 tests=[AWL=-0.181, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_43=0.6, UNPARSEABLE_RELAY=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OwN39YLNC-L7 for ; Wed, 6 Nov 2013 16:33:13 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) by ietfa.amsl.com (Postfix) with ESMTP id 9B8B621F9D4C for ; Wed, 6 Nov 2013 16:33:10 -0800 (PST) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id 2C5641B83F0 for ; Thu, 7 Nov 2013 01:33:09 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.183]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 0DDAA15805A for ; Thu, 7 Nov 2013 01:33:09 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH02.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Thu, 7 Nov 2013 01:33:08 +0100 From: To: "dime@ietf.org" Thread-Topic: [Dime] Ongoing Throttling Information in request messages Thread-Index: Ac7aQPqQ1tyE3SNOTC+vVrUogwBrJQAnWH+wAADoRNAABgE0oAAA57DwAACoAlAAAOdngAATKBpg Date: Thu, 7 Nov 2013 00:33:07 +0000 Message-ID: <25045_1383784389_527ADFC5_25045_11208_1_6B7134B31289DC4FAF731D844122B36E2E96F3@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: <5BCBA1FC2B7F0B4C9D935572D9000668151918EC@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192B2B@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192B90@DEMUMBX014.nsn-intra.net> <527A6C8B.4080407@usdonovans.com> In-Reply-To: <527A6C8B.4080407@usdonovans.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: multipart/alternative; boundary="_000_6B7134B31289DC4FAF731D844122B36E2E96F3PEXCVZYM13corpora_" MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.6.211815 Subject: Re: [Dime] Ongoing Throttling Information in request messages X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 00:33:20 -0000 --_000_6B7134B31289DC4FAF731D844122B36E2E96F3PEXCVZYM13corpora_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Not so sure that the optimization proposed below is deemed required for the= basic solution. And I don't see anything in the basic proposed solution that would prevent = such optimization in a later stage if finally needed. Lionel De : dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] De la part de Ste= ve Donovan Envoy=E9 : mercredi 6 novembre 2013 17:22 =C0 : dime@ietf.org Objet : Re: [Dime] Ongoing Throttling Information in request messages Nirav, One qualification of your point below -- The server would only receive requ= ests that survived throttling from clients that support DOIC. The server w= ill also receive requests from clients that do not support DOIC. One of th= e benefits of Ulrich's proposal is that it tells the server when a request = has not gone through throttling. The server can then choose to do somethin= g different with that set of requests. As to the question of which is more work for the server, which is the impor= tant question, that isn't yet clear to me. Steve On 11/6/13, 7:02 AM, Nirav Salot (nsalot) wrote: Ulrich, I might be missing something here so please bear with me. Number of answer messages sent by server =3D number of request messages rec= eived by the server. During the overload, the server would receive only those requests which sur= vived throttling. And then the server would send answer messages to only those request messag= es. So "every" and "some" are actually equal in the below equation. No? Regards, Nirav. From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Wednesday, November 06, 2013 8:24 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@iet= f.org Subject: RE: Ongoing Throttling Information in request messages Nirav, Not quite. The question is: "is sending an overload-report in every answer message that corresponds to = request with OC-Feature-Vector present more resource consuming than receivi= ng Ongoing-Throttling-Information in some request messages (only those that= survived a throttling)?" Best regards Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 3:15 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, Thanks for clarification. Then the question would be "is sending overload-report in every answer message is more resource consum= ing than the solution below - i.e. receiving OC-Ongoing-Throttling-Informat= ion in all request message and analyzing the timestamp and then deciding if= the overload-report should be included or not." I am not sure. Regards, Nirav. From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Wednesday, November 06, 2013 7:08 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@iet= f.org Subject: RE: Ongoing Throttling Information in request messages Nirav, thank you for your comments. The comparism is between: Current way: "send OC specific information (Feature-Vector) in every reques= t message and in every corresponding answer message" My proposal: "send OC specific information (Feature-Vector and in some case= s Ongoing-Throttling-Info) in every request message and in corresponding an= swer messages only when required". Sending OC specific information is regarded a resource consuming action an= d we should not put this action to the (overloaded) server where avoidable.= See REQ 13. Best regards Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 12:04 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, Thanks for the detail explanation of your proposal. Just to verify my understanding, Your proposal would allow the reporting node to avoid inclusion of the "sam= e" overload-report in the answer message since the request message indicate= s that the path contains at least one reacting node which already has the l= atest overload-report. In other words, the reporting node need not include overload-report in ever= y message, blindly. To achieve the above objective, the solution below suggest the reacting nod= e to include new AVP OC-Ongoing-Throttling-Information in every request mes= sage, which survives throttling. So the net result is that, the inclusion of the overload-report is prevente= d in every answer message since the OC-Ongoing-Throttling-Information is in= cluded in every request message. [Wiehe, Ulrich (NSN - DE/Munich)] no. ...in every request message that sur= vived a throttling. And hence I am not sure if the solution has sound benefit from the inclusio= n of redundant information point of view. In summary, I think the solution suggested below works as explained. But I fail to see the benefit of using this solution compare to a solution = in which the reporting node includes overload-report in every answer messag= e. Regards, Nirav. From: doc-dt-bounces@ietf.org [mailto:doc-d= t-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich) Sent: Tuesday, November 05, 2013 9:36 PM To: doc-dt@ietf.org; dime@ietf.org Subject: [doc-dt] Ongoing Throttling Information in request messages Hi, draft-docdt-dime-ovli-01 in Appendix B, Table 1, REQ 13 says: .... Another way is to let the request sender (reacting node) insert information in the request to say whether a throttling is actually performed. The reporting node then can base its decision on information received in the request; no need for keeping state to record who has received overload reports. And in Appendix B, Table 1, REQ 18: There has been a proposal to mark messages that survived overload throttling as one method for an overloaded node to address fairness but this proposal is not yet part of the solution. I would like to come back to this proposal. A new AVP OC-Ongoing-Throttling-Information inserted in request messages wo= uld indicate that the request message survived a throttling. Furthermore, i= nformation within the AVP indicates the TimeStamp as received in the previo= us OC-OLR AVP, according to which the ongoing throttling (which was survive= d) is performed. OC-Ongoing-Throttling-Information ::=3D < AVP Header: TBD9 > < TimeStamp > * [ AVP ] Supporting Clients would insert the OC-Ongoing-Throttling-Information AVP = into request messages that survived a throttling performed at that client. Supporting Agents when receiving a request message that contains an OC-Ongo= ing-Throttling-Information AVP would not perform an additional throttling (= since the client or a downstream agent already performed the throttling) , = while, when receiving a request that does not contain OC-Ongoing-Throttling= -Information AVP would perform throttling (on behalf of the client) accordi= ng to a previously received and stored OC-OLR, and if that throttling is su= rvived the agent would insert the OC-Ongoing-Throttling-Information AVP in = the request before sending it further upstream. Servers (or in general reporting nodes) would check presence and content of= the OC-Ongoing-Throttling-Information AVP in received request messages and= could detect (together with a check of presence of OC-Feature-Vector AVP) = whether inserting an OC-OLR AVP in the corresponding answer message is need= ed in order to update the reacting node with a new OC-OLR). This proposal especially addresses use cases like the following: Architecture: +----------------+ | supporting | /| agent A1 |\ +----------------+ / +----------------+ \ | non supporting |/ \ | client C |\ \ +----------------+ \ +----------------+ \ +------------+ +---------+ \| non supporting | \| supporting | | Server | | agent A2 |------| agent A3 |----| S | +----------------+ +------------+ +---------+ 1. A request is sent from C via A2 and A3 to S. A3 recognizes that the= re is no reacting node downstream (no OC-Feature-Vector received) and there= fore takes the role of the reacting node and inserts an OC-Feature-Vector A= VP. A3 has no valid OLR from S stored and therefore does not perform thrott= ling and does not insert an OC-Throttling-Information AVP. 2. S recognizes that there is a reacting node downstream which is actu= ally not performing a throttling. S returns a 10% throttling request (TimeS= tamp=3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A3= and A2 to C. 3. A3 stores the 10% throttling request. 4. A new request is sent from C via A2 and A3 to S. A3 recognizes that= there is no reacting node downstream (no OC-Feature-Vector received) and t= herefore takes the role of the reacting node and inserts an OC-Feature-Vect= or AVP. A3 has valid OLR from S stored and performs a 10% throttling. The = request survives and A3 inserts an OC-Throttling-Information AVP with timeS= tamp=3Dt1. 5. S recognizes that correct throttling (correct time stamp) is in pla= ce and therefore does not return OC-OLR in the answer. 6. A new request is sent from C via A1 and A3 to S. A1 recognizes that= there is no reacting node downstream (no OC-Feature-Vector received) and t= herefore takes the role of the reacting node and inserts an OC-Feature-AVP.= A1 has no valid OLR from S stored and therefore does not perform throttlin= g and does not insert an OC-Throttling-Information AVP. A3 recognizes that = there is a reacting node downstream (OC-Feature-Vector received) and theref= ore does not take the role of the reacting node. 7. S recognizes that there is a reacting node downstream which is actu= ally not performing a throttling. S returns a 10% throttling request (TimeS= tamp=3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A3= and A1 to C. 8. A1 stores the 10% throttling request. 9. A new request is sent from C via A1 and A3 to S. A1 recognizes that= there is no reacting node downstream (no OC-Feature-Vector received) and t= herefore takes the role of the reacting node and inserts an OC-Feature-AVP.= A1 has valid OLR from S stored and therefore performs a 10% throttling. T= he request survives and A1 inserts an OC-Throttling-Information AVP with ti= meStamp=3Dt1. A3 recognizes that there is a reacting node downstream (OC-Fe= ature-Vector received) and therefore does not take the role of the reacting= node. 10. S recognizes that correct throttling (correct time stamp) is in place = and therefore does not return OC-OLR in the answer. 11. Requests sent from C via A1 and A3 to S undergo a 10% throttling at A1= , requests sent from C via A2 and A3 to S undergo a 10% throttling at A3. 12. Overload situation in S for some reason gets worse, S decides to reque= st 20 % reduction. 13. A new request is sent from C via A1 and A3 to S. A1 recognizes that th= ere is no reacting node downstream (no OC-Feature-Vector received) and ther= efore takes the role of the reacting node and inserts an OC-Feature-AVP. A1= has valid OLR from S stored and therefore performs a 10% throttling. The = request survives and A1 inserts an OC-Throttling-Information AVP with timeS= tamp=3Dt1. A3 recognizes that there is a reacting node downstream (OC-Featu= re-Vector received) and therefore does not take the role of the reacting no= de. 14. S recognizes that incorrect throttling (wrong time stamp) is in place = and therefore S returns a 20% throttling request (TimeStamp=3Dt2, duration= =3Dx) within OC-OLR in the answer which goes back via A3 and A1 to C. 15. A3 (not taking the role of the reactingt node)may, A1 must store the 2= 0% throttling request (replacing the 10% request). 16. A new request is sent from C via A2 and A3 to S. A3 recognizes that th= ere is no reacting node downstream (no OC-Feature-Vector received) and ther= efore takes the role of the reacting node and inserts an OC-Feature-Vector = AVP. A3 has valid OLR from S stored and performs a 10% throttling. The req= uest survives and A3 inserts an OC-Throttling-Information AVP with timeStam= p=3Dt1. (assuming A3 did not store the 20% request at step 14) 17. S recognizes that incorrect throttling (wrong time stamp) is in place = and therefore S returns a 20% throttling request (TimeStamp=3Dt2, duration= =3Dx) within OC-OLR in the answer which goes back via A3 and A2 to C. 18. A3 stores the 20% throttling request (replacing the 10% request). 19. Requests sent from C via A1 and A3 to S undergo a 20% throttling at A1= , requests sent from C via A2 and A3 to S undergo a 20% throttling at A3. Comments are welcome. Best regards Ulrich _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. --_000_6B7134B31289DC4FAF731D844122B36E2E96F3PEXCVZYM13corpora_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 = ;

Not so sur= e that the optimization proposed below is deemed required for the basic sol= ution.

And I don'= t see anything in the basic proposed solution that would prevent such optim= ization in a later stage if finally needed.

 = ;

Lionel

 = ;

De := dime-bounces@ietf.org [mailto:dime-bounces@ie= tf.org] De la part de Steve Donovan
Envoy=E9 : mercredi 6 novembre 2013 17:22
=C0 : dime@ietf.org
Objet : Re: [Dime] Ongoing Throttling Information in request me= ssages

 

Nirav,

One qualification of your point below -- The server would only receive requ= ests that survived throttling from clients that support DOIC.  The ser= ver will also receive requests from clients that do not support DOIC. = One of the benefits of Ulrich's proposal is that it tells the server when a request has not gone through throttling= .  The server can then choose to do something different with that set = of requests.

As to the question of which is more work for the server, which is the impor= tant question, that isn't yet clear to me. 

Steve

On 11/6/13, 7:02 AM, Nirav Salot (nsalot) wrote:

Ulrich,=

 <= /p>

I might be missing someth= ing here so please bear with me.

 <= /p>

Number of answer messages= sent by server =3D number of request messages received by the server.

During the overload, the = server would receive only those requests which survived throttling.<= o:p>

And then the server would= send answer messages to only those request messages.

So “every” an= d “some” are actually equal in the below equation. No?

 <= /p>

Regards,

Nirav.<= /p>

 <= /p>

From: Wiehe, U= lrich (NSN - DE/Munich) [mailto:ulr= ich.wiehe@nsn.com]
Sent: Wednesday, November 06, 2013 8:24 PM
To: Nirav Salot (nsalot); doc-dt@= ietf.org; dime@ietf.org
Subject: RE: Ongoing Throttling Information in request messages

 

Nirav,=

 =

Not quite.

 <= /p>

The question is:

“is sending an over= load-report in every answer message that corresponds to request with OC-Feature-Vec= tor present more resource consuming than receiving Ongoing-Throttling-Infor= mation in some request messages (only those that survived a throttling)?”= ;

 <= /p>

Best regards<= /o:p>

Ulrich<= /p>

 <= /p>

 <= /p>

 <= /p>

From: ext Nira= v Salot (nsalot) [mailto:nsalot@cisco.c= om]
Sent: Wednesday, November 06, 2013 3:15 PM
To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org
Subject: RE: Ongoing Throttling Information in request messages

 

Ulrich,=

 <= /p>

Thanks for clarification.=

 <= /p>

Then the question would be

“is sending overloa= d-report in every answer message is more resource consuming than the soluti= on below – i.e. receiving OC-Ongoing-Throttling-Information in all request message and analyzing the timestamp and then deciding if the o= verload-report should be included or not.”

I am not sure.

 <= /p>

Regards,

Nirav.<= /p>

 <= /p>

From: Wiehe, U= lrich (NSN - DE/Munich) [mailto:ulr= ich.wiehe@nsn.com]
Sent: Wednesday, November 06, 2013 7:08 PM
To: Nirav Salot (nsalot); doc-dt@= ietf.org; dime@ietf.org
Subject: RE: Ongoing Throttling Information in request messages

 

Nirav,<= /p>

thank you for your commen= ts.

 <= /p>

The comparism is between:=

Current way: “send = OC specific information (Feature-Vector) in every request message and in ev= ery corresponding answer message”

My proposal: “send = OC specific information (Feature-Vector and in some cases Ongoing-Throttlin= g-Info) in every request message and in corresponding answer messages only when required”.

 <= /p>

Sending OC specific infor= mation  is regarded a resource consuming action and we should not put = this action to the (overloaded) server where avoidable. See REQ 13.

 <= /p>

Best regards<= /o:p>

Ulrich<= /p>

 <= /p>

 <= /p>

 <= /p>

 <= /p>

From: ext Nira= v Salot (nsalot) [mailto:nsalot@cisco.c= om]
Sent: Wednesday, November 06, 2013 12:04 PM
To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org
Subject: RE: Ongoing Throttling Information in request messages

 

Ulrich,=

 <= /p>

Thanks for the detail exp= lanation of your proposal.

 <= /p>

Just to verify my underst= anding,

Your proposal would allow= the reporting node to avoid inclusion of the “same” overload-r= eport in the answer message since the request message indicates that the path contains at least one reacting node which already has the latest = overload-report.

In other words, the repor= ting node need not include overload-report in every message, blindly.

 <= /p>

To achieve the above obje= ctive, the solution below suggest the reacting node to include new AVP OC-O= ngoing-Throttling-Information in every request message, which survives throttling.

So the net result is that= , the inclusion of the overload-report is prevented in every answer message= since the OC-Ongoing-Throttling-Information is included in every request message.

[Wiehe, Ulrich (NSN= - DE/Munich)] no.  …in every request message that survived a th= rottling.

And hence I am not sure i= f the solution has sound benefit from the inclusion of redundant informatio= n point of view.

 <= /p>

In summary, I think the s= olution suggested below works as explained.

But I fail to see the ben= efit of using this solution compare to a solution in which the reporting no= de includes overload-report in every answer message.

 <= /p>

Regards,

Nirav.<= /p>

 <= /p>

From: doc-dt-bounces@ietf.org [mailto:doc-dt-bounces@ietf.org] On Behalf Of Wiehe, Ulrich (NSN - DE/Munich)
Sent: Tuesday, November 05, 2013 9:36 PM
To: doc-dt@ietf.org; dime@ietf.org
Subject: [doc-dt] Ongoing Throttling Information in request messages=

 

Hi,

draft-docdt-dime-ovli-01

in Appendix B, Table 1, REQ 13 says:

      &nb= sp; …. Another way

      &nb= sp; is to let the request sender (reacting node) insert

      &nb= sp; information in the request to say whether a

      &nb= sp; throttling is actually performed.  The reporting node

      &nb= sp; then can base its decision on information received in

      &nb= sp; the request; no need for keeping state to record who

  has received overload = reports. 

 

And in Appendix B, Table 1, REQ 18:

      &nb= sp; There has been a proposal to mark

      &nb= sp; messages that survived overload throttling as one

      &nb= sp; method for an overloaded node to address fairness but

      &nb= sp; this proposal is not yet part of the solution. 

 

I would like to come back to this propo= sal.

A new AVP OC-Ongoing-Throttling-Informa= tion inserted in request messages would indicate that the request message s= urvived a throttling. Furthermore, information within the AVP indicates the TimeStamp as received in the previous OC-OLR AVP, accord= ing to which the ongoing throttling (which was survived) is performed.

 

OC-Ongoing-Throttling-Information ::=3D < AVP Header: T= BD9 >

         &nbs= p;    < TimeStamp >

         &nbs= p;  * [ AVP ]

 

Supporting Clients would insert the OC-= Ongoing-Throttling-Information AVP  into request messages that survive= d a throttling performed at that client.

Supporting Agents when receiving a requ= est message that contains an OC-Ongoing-Throttling-Information AVP would no= t perform an additional throttling (since the client or a downstream agent already performed the throttling) , while, when receivi= ng a request that does not contain OC-Ongoing-Throttling-Information AVP wo= uld perform throttling (on behalf of the client) according to a previously = received and stored OC-OLR, and if that throttling is survived the agent would insert the OC-Ongoing-Throt= tling-Information AVP in the request before sending it further upstream.

Servers (or in general reporting nodes)= would check presence and content of the OC-Ongoing-Throttling-Information = AVP in received request messages and could detect (together with a check of presence of OC-Feature-Vector AVP) whether inserting an OC= -OLR AVP in the corresponding answer message is needed in order to update t= he reacting node with a new OC-OLR).

 

This proposal especially addresses use = cases like the following:

 

Architecture:

 

         &nbs= p;             = +----------------+

         &nbs= p;             = | supporting     |

          &nb= sp;           /| agent A1=        |\   

  +----------------+ / +----------------&= #43; \

  | non supporting |/     &n= bsp;            = ;    \

  | client C       |\&n= bsp;            = ;          \=

  +----------------+ \ +----------------&= #43;    \ +------------+    +----= -----+

         &nbs= p;            \| non= supporting |     \| supporting |    | Server=   |

         &nbs= p;             = |  agent A2      |------| agent A3  = ; |----|  S      |

         &nbs= p;            +------= ----------+      +------------+ &= nbsp;  +---------+

 

1.      A request is = sent from C via A2 and A3 to S. A3 recognizes that there is no reacting nod= e downstream (no OC-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-Vector AVP. = A3 has no valid OLR from S stored and therefore does not perform throttling= and does not insert an OC-Throttling-Information AVP.

2.      S recognizes = that there is a reacting node downstream which is actually not performing a= throttling. S returns a 10% throttling request (TimeStamp=3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A3 and A2 to= C.

3.      A3 stores the= 10% throttling request.

4.      A new request= is sent from C via A2 and A3 to S. A3 recognizes that there is no reacting= node downstream (no OC-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-Vector AVP. = A3 has  valid OLR from S stored and performs a 10% throttling. The req= uest survives and A3 inserts an OC-Throttling-Information AVP with timeStam= p=3Dt1.

5.      S recognizes = that correct throttling (correct time stamp) is in place and therefore does= not return OC-OLR in the answer.

6.      A new request= is sent from C via A1 and A3 to S. A1 recognizes that there is no reacting= node downstream (no OC-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 has = no valid OLR from S stored and therefore does not perform throttling and do= es not insert an OC-Throttling-Information AVP. A3 recognizes that there is= a reacting node downstream (OC-Feature-Vector received) and therefore does not take the role of the reacting node.

7.      S recognizes = that there is a reacting node downstream which is actually not performing a= throttling. S returns a 10% throttling request (TimeStamp=3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A3 and A1 to= C.

8.      A1 stores the= 10% throttling request.

9.      A new request= is sent from C via A1 and A3 to S. A1 recognizes that there is no reacting= node downstream (no OC-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 has&= nbsp; valid OLR from S stored and therefore performs a 10% throttling. The = request survives and A1 inserts an OC-Throttling-Information AVP with timeS= tamp=3Dt1. A3 recognizes that there is a reacting node downstream (OC-Feature-Vector received) and therefore does= not take the role of the reacting node.

10.  S recognizes = that correct throttling (correct time stamp) is in place and therefore does= not return OC-OLR in the answer.

11.  Requests sent= from C via A1 and A3 to S undergo a 10% throttling at A1, requests sent fr= om C via A2 and A3 to S undergo a 10% throttling at A3.

12.  Overload situ= ation in S for some reason gets worse, S decides to request 20 % reduction.=

13.  A new request= is sent from C via A1 and A3 to S. A1 recognizes that there is no reacting= node downstream (no OC-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 has&= nbsp; valid OLR from S stored and therefore performs a 10% throttling. The = request survives and A1 inserts an OC-Throttling-Information AVP with timeS= tamp=3Dt1. A3 recognizes that there is a reacting node downstream (OC-Feature-Vector received) and therefore does= not take the role of the reacting node.

14.  S recognizes = that incorrect throttling (wrong time stamp) is in place and therefore S re= turns a 20% throttling request (TimeStamp=3Dt2, duration=3Dx) within OC-OLR in the answer which goes back via A3 and A1 to C.

15.  A3 (not takin= g the role of the reactingt node)may, A1 must store the 20% throttling requ= est (replacing the 10% request).

16.  A new request= is sent from C via A2 and A3 to S. A3 recognizes that there is no reacting= node downstream (no OC-Feature-Vector received) and therefore takes the role of the reacting node and inserts an OC-Feature-Vector AVP. = A3 has  valid OLR from S stored and performs a 10% throttling. The req= uest survives and A3 inserts an OC-Throttling-Information AVP with timeStam= p=3Dt1. (assuming A3 did not store the 20% request at step 14)

17.  S recognizes = that incorrect throttling (wrong time stamp) is in place and therefore S re= turns a 20% throttling request (TimeStamp=3Dt2, duration=3Dx) within OC-OLR in the answer which goes back via A3 and A2 to C.

18.  A3 stores the= 20% throttling request (replacing the 10% request).

19.  Requests sent= from C via A1 and A3 to S undergo a 20% throttling at A1, requests sent fr= om C via A2 and A3 to S undergo a 20% throttling at A3.

 

 

Comments are welcome.=

 

Best regards

Ulrich

 

 




_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.iet=
f.org/mailman/listinfo/dime

 

______________________________________________________________________=
___________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confiden=
tielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu=
 ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el=
ectroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou =
falsifie. Merci.

This message and its attachments may contain confidential or privileged inf=
ormation that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and dele=
te this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been =
modified, changed or falsified.
Thank you.
--_000_6B7134B31289DC4FAF731D844122B36E2E96F3PEXCVZYM13corpora_-- From ulrich.wiehe@nsn.com Thu Nov 7 00:24:27 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B277221E80B8; Thu, 7 Nov 2013 00:24:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.724 X-Spam-Level: X-Spam-Status: No, score=-5.724 tagged_above=-999 required=5 tests=[AWL=0.275, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hyIO6L5jt1vg; Thu, 7 Nov 2013 00:24:22 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id B7F5F11E80E0; Thu, 7 Nov 2013 00:24:21 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rA78OIrI009442 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 7 Nov 2013 09:24:18 +0100 Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rA78OIN3030418 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Nov 2013 09:24:18 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.198]) by DEMUHTC004.nsn-intra.net ([10.159.42.35]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 09:24:17 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "ext Nirav Salot (nsalot)" , "doc-dt@ietf.org" , "dime@ietf.org" Thread-Topic: Ongoing Throttling Information in request messages Thread-Index: Ac7aQPqQ1tyE3SNOTC+vVrUogwBrJQAnWH+wAADoRNAABgE0oAAA57DwAACoAlAAASWEQAAAqKUAACDdWeA= Date: Thu, 7 Nov 2013 08:24:17 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D900066815192CD2@DEMUMBX014.nsn-intra.net> References: <5BCBA1FC2B7F0B4C9D935572D9000668151918EC@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192B2B@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192B90@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192BF7@DEMUMBX014.nsn-intra.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.113] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 15711 X-purgate-ID: 151667::1383812658-00005753-7DE03B3E/0-0/0-0 Subject: Re: [Dime] Ongoing Throttling Information in request messages X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 08:24:27 -0000 Nirav, thank you for the explanation. This may be a solution which adds more comp= lexity to the reporting node: The reporting node must remember the maximum = not yet expired fraction of duration values it sent when leaving the overlo= ad state and must continue reporting "end of overload condition" until expi= ry. (there is no corresponding complexity at the reacting node in my propos= al) Another question: While doing a throttling, what is the expected behaviour = of the reacting node when receiving an answer message without OC-OLR AVP? (= stop/continue throttling?) (there is no corresponding question in my propos= al since not sending of OC-Ongoing-Throttling-Information clearly means tha= t throttling is not in place) Another question is for the reacting node: What is the expected behaviour w= hen receiving lots of redundant OC-OLR AVPs in answer messages? The reactin= g node needs to check every single OC-OLR AVP in order to find out whether = it contains an update. Is that the correct understanding? (this seems to be= equivalent to checking for redundant OC-Ongoing-Throttling-Information AVP= s in every request by the reporting node in my proposal) Adding dime-list again. Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]=20 Sent: Wednesday, November 06, 2013 4:58 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, During "no overload condition", why should reporting node include overload-= information in all the answer messages? e.g. if the reporting node has advertised overload-report with period-of-va= lidity=3D10 sec., it knows that after that period all the reacting node wil= l automatically stop applying any overload mitigation action. And hence it = does not need to explicitly send any overload-report indicating "no overloa= d condition". In general, I assume that overload period of would be much shorter as compa= red to "no overload" period. And hence I do not see reason to always includ= e overload-report. Regards, Nirav. From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Sent: Wednesday, November 06, 2013 9:12 PM To: Nirav Salot (nsalot); doc-dt@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, "During the overload" yes I agree, but "when no longer in overload" all ans= wer messages would contain the information "no longer in overload" while on= ly few request messages would contain the Ongoing-Throttling-Information. Removing dime-list which bounces. Best regards Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]=20 Sent: Wednesday, November 06, 2013 4:02 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, I might be missing something here so please bear with me. Number of answer messages sent by server =3D number of request messages rec= eived by the server. During the overload, the server would receive only those requests which sur= vived throttling. And then the server would send answer messages to only those request messag= es. So "every" and "some" are actually equal in the below equation. No? Regards, Nirav. From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Sent: Wednesday, November 06, 2013 8:24 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, Not quite. The question is: "is sending an overload-report in every answer message that corresponds to = request with OC-Feature-Vector present more resource consuming than receivi= ng Ongoing-Throttling-Information in some request messages (only those that= survived a throttling)?" Best regards Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]=20 Sent: Wednesday, November 06, 2013 3:15 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, Thanks for clarification. Then the question would be=20 "is sending overload-report in every answer message is more resource consum= ing than the solution below - i.e. receiving OC-Ongoing-Throttling-Informat= ion in all request message and analyzing the timestamp and then deciding if= the overload-report should be included or not." I am not sure. Regards, Nirav. From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Sent: Wednesday, November 06, 2013 7:08 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, thank you for your comments. The comparism is between: Current way: "send OC specific information (Feature-Vector) in every reques= t message and in every corresponding answer message" My proposal: "send OC specific information (Feature-Vector and in some case= s Ongoing-Throttling-Info) in every request message and in corresponding an= swer messages only when required". Sending OC specific information =A0is regarded a resource consuming action = and we should not put this action to the (overloaded) server where avoidabl= e. See REQ 13. Best regards Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]=20 Sent: Wednesday, November 06, 2013 12:04 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, Thanks for the detail explanation of your proposal. Just to verify my understanding, Your proposal would allow the reporting node to avoid inclusion of the "sam= e" overload-report in the answer message since the request message indicate= s that the path contains at least one reacting node which already has the l= atest overload-report. In other words, the reporting node need not include overload-report in ever= y message, blindly. To achieve the above objective, the solution below suggest the reacting nod= e to include new AVP OC-Ongoing-Throttling-Information in every request mes= sage, which survives throttling. So the net result is that, the inclusion of the overload-report is prevente= d in every answer message since the OC-Ongoing-Throttling-Information is in= cluded in every request message. [Wiehe, Ulrich (NSN - DE/Munich)] no.=A0 .in every request message that sur= vived a throttling. And hence I am not sure if the solution has sound benefit from the inclusio= n of redundant information point of view. In summary, I think the solution suggested below works as explained. But I fail to see the benefit of using this solution compare to a solution = in which the reporting node includes overload-report in every answer messag= e. Regards, Nirav. From: doc-dt-bounces@ietf.org [mailto:doc-dt-bounces@ietf.org] On Behalf Of= Wiehe, Ulrich (NSN - DE/Munich) Sent: Tuesday, November 05, 2013 9:36 PM To: doc-dt@ietf.org; dime@ietf.org Subject: [doc-dt] Ongoing Throttling Information in request messages Hi, draft-docdt-dime-ovli-01=20 in Appendix B, Table 1, REQ 13 says: =A0=A0=A0=A0=A0=A0=A0 .. Another way =A0=A0=A0=A0=A0=A0=A0 is to let the request sender (reacting node) insert =A0=A0=A0=A0=A0=A0=A0 information in the request to say whether a =A0=A0=A0=A0=A0=A0=A0 throttling is actually performed.=A0 The reporting no= de =A0=A0=A0=A0=A0=A0=A0 then can base its decision on information received in= =20 =A0=A0=A0=A0=A0=A0=A0 the request; no need for keeping state to record who =A0 has received overload reports.=A0=20 =A0 And in Appendix B, Table 1, REQ 18: =A0=A0=A0=A0=A0=A0=A0 There has been a proposal to mark=20 =A0=A0=A0=A0=A0=A0=A0 messages that survived overload throttling as one =A0=A0=A0=A0=A0=A0=A0 method for an overloaded node to address fairness but =A0=A0=A0=A0=A0=A0=A0 this proposal is not yet part of the solution.=A0=20 =A0 I would like to come back to this proposal.=20 A new AVP OC-Ongoing-Throttling-Information inserted in request messages wo= uld indicate that the request message survived a throttling. Furthermore, i= nformation within the AVP indicates the TimeStamp as received in the previo= us OC-OLR AVP, according to which the ongoing throttling (which was survive= d) is performed. =A0 OC-Ongoing-Throttling-Information ::=3D < AVP Header: TBD9 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 < TimeStamp > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * [ AVP ] =A0 Supporting Clients would insert the OC-Ongoing-Throttling-Information AVP= =A0 into request messages that survived a throttling performed at that clie= nt. Supporting Agents when receiving a request message that contains an OC-Ongo= ing-Throttling-Information AVP would not perform an additional throttling (= since the client or a downstream agent already performed the throttling) , = while, when receiving a request that does not contain OC-Ongoing-Throttling= -Information AVP would perform throttling (on behalf of the client) accordi= ng to a previously received and stored OC-OLR, and if that throttling is su= rvived the agent would insert the OC-Ongoing-Throttling-Information AVP in = the request before sending it further upstream. Servers (or in general reporting nodes) would check presence and content of= the OC-Ongoing-Throttling-Information AVP in received request messages and= could detect (together with a check of presence of OC-Feature-Vector AVP) = whether inserting an OC-OLR AVP in the corresponding answer message is need= ed in order to update the reacting node with a new OC-OLR). =A0 This proposal especially addresses use cases like the following: =A0 Architecture: =A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +-------= ---------+ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | suppor= ting=A0=A0=A0=A0 | =A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /| agent A1= =A0=A0=A0=A0=A0=A0 |\=A0=A0=A0=20 =A0 +----------------+ / +----------------+ \ =A0 | non supporting |/=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 \ =A0 | client C=A0=A0=A0=A0=A0=A0 |\=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 \ =A0 +----------------+ \ +----------------+=A0=A0=A0 \ +------------+=A0=A0= =A0 +---------+ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 \| non supp= orting |=A0=A0=A0=A0 \| supporting | =A0=A0 | Server=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 age= nt A2=A0=A0=A0=A0=A0 |------| agent A3=A0=A0 |----|=A0 S=A0=A0=A0=A0=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0 +------------= ----+=A0=A0=A0=A0=A0 +------------+=A0=A0=A0 +---------+ =A0 1. A request is sent from C via A2 and A3 to S. A3 recognizes that there is= no reacting node downstream (no OC-Feature-Vector received) and therefore = takes the role of the reacting node and inserts an OC-Feature-Vector AVP. A= 3 has no valid OLR from S stored and therefore does not perform throttling = and does not insert an OC-Throttling-Information AVP. 2. S recognizes that there is a reacting node downstream which is actually = not performing a throttling. S returns a 10% throttling request (TimeStamp= =3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A3 and= A2 to C. 3. A3 stores the 10% throttling request. 4. A new request is sent from C via A2 and A3 to S. A3 recognizes that ther= e is no reacting node downstream (no OC-Feature-Vector received) and theref= ore takes the role of the reacting node and inserts an OC-Feature-Vector AV= P. A3 has=A0 valid OLR from S stored and performs a 10% throttling. The req= uest survives and A3 inserts an OC-Throttling-Information AVP with timeStam= p=3Dt1. 5. S recognizes that correct throttling (correct time stamp) is in place an= d therefore does not return OC-OLR in the answer. 6. A new request is sent from C via A1 and A3 to S. A1 recognizes that ther= e is no reacting node downstream (no OC-Feature-Vector received) and theref= ore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 h= as no valid OLR from S stored and therefore does not perform throttling and= does not insert an OC-Throttling-Information AVP. A3 recognizes that there= is a reacting node downstream (OC-Feature-Vector received) and therefore d= oes not take the role of the reacting node. 7. S recognizes that there is a reacting node downstream which is actually = not performing a throttling. S returns a 10% throttling request (TimeStamp= =3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A3 and= A1 to C. 8. A1 stores the 10% throttling request. 9. A new request is sent from C via A1 and A3 to S. A1 recognizes that ther= e is no reacting node downstream (no OC-Feature-Vector received) and theref= ore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 h= as=A0 valid OLR from S stored and therefore performs a 10% throttling. The = request survives and A1 inserts an OC-Throttling-Information AVP with timeS= tamp=3Dt1. A3 recognizes that there is a reacting node downstream (OC-Featu= re-Vector received) and therefore does not take the role of the reacting no= de. 10. S recognizes that correct throttling (correct time stamp) is in place a= nd therefore does not return OC-OLR in the answer. 11. Requests sent from C via A1 and A3 to S undergo a 10% throttling at A1,= requests sent from C via A2 and A3 to S undergo a 10% throttling at A3. 12. Overload situation in S for some reason gets worse, S decides to reques= t 20 % reduction. 13. A new request is sent from C via A1 and A3 to S. A1 recognizes that the= re is no reacting node downstream (no OC-Feature-Vector received) and there= fore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 = has=A0 valid OLR from S stored and therefore performs a 10% throttling. The= request survives and A1 inserts an OC-Throttling-Information AVP with time= Stamp=3Dt1. A3 recognizes that there is a reacting node downstream (OC-Feat= ure-Vector received) and therefore does not take the role of the reacting n= ode. 14. S recognizes that incorrect throttling (wrong time stamp) is in place a= nd therefore S returns a 20% throttling request (TimeStamp=3Dt2, duration= =3Dx) within OC-OLR in the answer which goes back via A3 and A1 to C. 15. A3 (not taking the role of the reactingt node)may, A1 must store the 20= % throttling request (replacing the 10% request). 16. A new request is sent from C via A2 and A3 to S. A3 recognizes that the= re is no reacting node downstream (no OC-Feature-Vector received) and there= fore takes the role of the reacting node and inserts an OC-Feature-Vector A= VP. A3 has=A0 valid OLR from S stored and performs a 10% throttling. The re= quest survives and A3 inserts an OC-Throttling-Information AVP with timeSta= mp=3Dt1. (assuming A3 did not store the 20% request at step 14) 17. S recognizes that incorrect throttling (wrong time stamp) is in place a= nd therefore S returns a 20% throttling request (TimeStamp=3Dt2, duration= =3Dx) within OC-OLR in the answer which goes back via A3 and A2 to C. 18. A3 stores the 20% throttling request (replacing the 10% request). 19. Requests sent from C via A1 and A3 to S undergo a 20% throttling at A1,= requests sent from C via A2 and A3 to S undergo a 20% throttling at A3. =A0 =A0 Comments are welcome. =A0 Best regards Ulrich =A0 =A0 From nsalot@cisco.com Thu Nov 7 01:14:46 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A5F821E80D8; Thu, 7 Nov 2013 01:14:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.299 X-Spam-Level: X-Spam-Status: No, score=-10.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2072U7aXuH4D; Thu, 7 Nov 2013 01:14:39 -0800 (PST) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) by ietfa.amsl.com (Postfix) with ESMTP id 3A85711E8209; Thu, 7 Nov 2013 01:14:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16938; q=dns/txt; s=iport; t=1383815678; x=1385025278; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=rTBxI/857fa0zw3pFpSJrRwVqKF4YjHJsdl7+BdMTh8=; b=UQfi/TgCR1TANfBGatkPcoJxHAcliWVu3MOTU8c+iKFgmu4n+gGz9Wot dybb2l8+8lg42h/w3Shj/JrfBXmPzXrClkvygpSd49EBAh+euQZyME/mw tvn4iAuat/lEQv8S3zP5f6Qf2om5m3S5UElq4BGNEfRFrt6a31Bz0tgsz c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFAPpYe1KtJXG8/2dsb2JhbABagweBC78OgSYWdIIlAQEBBIEFBAIBCBEBAwEBCw8CDAcyFAMGCAIEARIIE4dmvW2PKDgGGgeCeYEQA4kIiySOM4c3gyaBTBwCBRki X-IronPort-AV: E=Sophos;i="4.93,650,1378857600"; d="scan'208";a="281854395" Received: from rcdn-core2-1.cisco.com ([173.37.113.188]) by rcdn-iport-3.cisco.com with ESMTP; 07 Nov 2013 09:14:31 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core2-1.cisco.com (8.14.5/8.14.5) with ESMTP id rA79EVO1027030 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Nov 2013 09:14:31 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.47]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 03:14:30 -0600 From: "Nirav Salot (nsalot)" To: "Wiehe, Ulrich (NSN - DE/Munich)" , "doc-dt@ietf.org" , "dime@ietf.org" Thread-Topic: Ongoing Throttling Information in request messages Thread-Index: Ac7aQPqQ1tyE3SNOTC+vVrUogwBrJQAnWH+wAADoRNAABgE0oAAA57DwAACoAlAAASWEQAAAqKUAACDdWeAAAz9GUA== Date: Thu, 7 Nov 2013 09:14:30 +0000 Message-ID: References: <5BCBA1FC2B7F0B4C9D935572D9000668151918EC@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192B2B@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192B90@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192BF7@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192CD2@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D900066815192CD2@DEMUMBX014.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [64.103.158.22] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Dime] Ongoing Throttling Information in request messages X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 09:14:46 -0000 Ulrich, Please read my responses inline. Regards, Nirav. -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Sent: Thursday, November 07, 2013 1:54 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, thank you for the explanation. This may be a solution which adds more comp= lexity to the reporting node: The reporting node must remember the maximum = not yet expired fraction of duration values it sent when leaving the overlo= ad state and must continue reporting "end of overload condition" until expi= ry. (there is no corresponding complexity at the reacting node in my propos= al) [Nirav] This is not always true, e.g. as I had indicated if the node has ad= vertised 10% reduction-percentage for 10 sec., it need not bother to advert= ise no-overload condition since the validity-period was very small. Another question: While doing a throttling, what is the expected behaviour = of the reacting node when receiving an answer message without OC-OLR AVP? (= stop/continue throttling?) (there is no corresponding question in my propos= al since not sending of OC-Ongoing-Throttling-Information clearly means tha= t throttling is not in place) [Nirav] The reacting node should continue to apply the earlier received OC-= OLR.=20 " (Note: We seem to have consensus that a server MAY repeat OLRs in subsequent messages, but is not required to do so, based on local policy.)" Another question is for the reacting node: What is the expected behaviour w= hen receiving lots of redundant OC-OLR AVPs in answer messages? The reactin= g node needs to check every single OC-OLR AVP in order to find out whether = it contains an update. Is that the correct understanding? (this seems to be= equivalent to checking for redundant OC-Ongoing-Throttling-Information AVP= s in every request by the reporting node in my proposal) [Nirav] Please refer to Timestamp AVP within OC-OLR. The TimeStamp AVP indicates when the original OC-OLR AVP with the current content was created. It is possible to replay the same OC- OLR AVP multiple times between the overload endpoints, however, when the OC-OLR AVP content changes or the other information sending endpoint wants the receiving endpoint to update its overload control information, then the TimeStamp AVP MUST contain a new value. Adding dime-list again. Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 4:58 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, During "no overload condition", why should reporting node include overload-= information in all the answer messages? e.g. if the reporting node has advertised overload-report with period-of-va= lidity=3D10 sec., it knows that after that period all the reacting node wil= l automatically stop applying any overload mitigation action. And hence it = does not need to explicitly send any overload-report indicating "no overloa= d condition". In general, I assume that overload period of would be much shorter as compa= red to "no overload" period. And hence I do not see reason to always includ= e overload-report. Regards, Nirav. From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Wednesday, November 06, 2013 9:12 PM To: Nirav Salot (nsalot); doc-dt@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, "During the overload" yes I agree, but "when no longer in overload" all ans= wer messages would contain the information "no longer in overload" while on= ly few request messages would contain the Ongoing-Throttling-Information. Removing dime-list which bounces. Best regards Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 4:02 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, I might be missing something here so please bear with me. Number of answer messages sent by server =3D number of request messages rec= eived by the server. During the overload, the server would receive only those requests which sur= vived throttling. And then the server would send answer messages to only those request messag= es. So "every" and "some" are actually equal in the below equation. No? Regards, Nirav. From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Wednesday, November 06, 2013 8:24 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, Not quite. The question is: "is sending an overload-report in every answer message that corresponds to = request with OC-Feature-Vector present more resource consuming than receivi= ng Ongoing-Throttling-Information in some request messages (only those that= survived a throttling)?" Best regards Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 3:15 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, Thanks for clarification. Then the question would be "is sending overload-report in every answer message is more resource consum= ing than the solution below - i.e. receiving OC-Ongoing-Throttling-Informat= ion in all request message and analyzing the timestamp and then deciding if= the overload-report should be included or not." I am not sure. Regards, Nirav. From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Wednesday, November 06, 2013 7:08 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, thank you for your comments. The comparism is between: Current way: "send OC specific information (Feature-Vector) in every reques= t message and in every corresponding answer message" My proposal: "send OC specific information (Feature-Vector and in some case= s Ongoing-Throttling-Info) in every request message and in corresponding an= swer messages only when required". Sending OC specific information =A0is regarded a resource consuming action = and we should not put this action to the (overloaded) server where avoidabl= e. See REQ 13. Best regards Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 12:04 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, Thanks for the detail explanation of your proposal. Just to verify my understanding, Your proposal would allow the reporting node to avoid inclusion of the "sam= e" overload-report in the answer message since the request message indicate= s that the path contains at least one reacting node which already has the l= atest overload-report. In other words, the reporting node need not include overload-report in ever= y message, blindly. To achieve the above objective, the solution below suggest the reacting nod= e to include new AVP OC-Ongoing-Throttling-Information in every request mes= sage, which survives throttling. So the net result is that, the inclusion of the overload-report is prevente= d in every answer message since the OC-Ongoing-Throttling-Information is in= cluded in every request message. [Wiehe, Ulrich (NSN - DE/Munich)] no.=A0 .in every request message that sur= vived a throttling. And hence I am not sure if the solution has sound benefit from the inclusio= n of redundant information point of view. In summary, I think the solution suggested below works as explained. But I fail to see the benefit of using this solution compare to a solution = in which the reporting node includes overload-report in every answer messag= e. Regards, Nirav. From: doc-dt-bounces@ietf.org [mailto:doc-dt-bounces@ietf.org] On Behalf Of= Wiehe, Ulrich (NSN - DE/Munich) Sent: Tuesday, November 05, 2013 9:36 PM To: doc-dt@ietf.org; dime@ietf.org Subject: [doc-dt] Ongoing Throttling Information in request messages Hi, draft-docdt-dime-ovli-01 in Appendix B, Table 1, REQ 13 says: =A0=A0=A0=A0=A0=A0=A0 .. Another way =A0=A0=A0=A0=A0=A0=A0 is to let the request sender (reacting node) insert =A0=A0=A0=A0=A0=A0=A0 information in the request to say whether a =A0=A0=A0=A0=A0=A0=A0 throttling is actually performed.=A0 The reporting no= de =A0=A0=A0=A0=A0=A0=A0 then can base its decision on information received in =A0=A0=A0=A0=A0=A0=A0 the request; no need for keeping state to record who =A0 has received overload reports.=A0=20 =A0 And in Appendix B, Table 1, REQ 18: =A0=A0=A0=A0=A0=A0=A0 There has been a proposal to mark =A0=A0=A0=A0=A0=A0=A0 messages that survived overload throttling as one =A0=A0=A0=A0=A0=A0=A0 method for an overloaded node to address fairness but =A0=A0=A0=A0=A0=A0=A0 this proposal is not yet part of the solution.=A0=20 =A0 I would like to come back to this proposal.=20 A new AVP OC-Ongoing-Throttling-Information inserted in request messages wo= uld indicate that the request message survived a throttling. Furthermore, i= nformation within the AVP indicates the TimeStamp as received in the previo= us OC-OLR AVP, according to which the ongoing throttling (which was survive= d) is performed. =A0 OC-Ongoing-Throttling-Information ::=3D < AVP Header: TBD9 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 < TimeStamp > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * [ AVP ] =A0 Supporting Clients would insert the OC-Ongoing-Throttling-Information AVP= =A0 into request messages that survived a throttling performed at that clie= nt. Supporting Agents when receiving a request message that contains an OC-Ongo= ing-Throttling-Information AVP would not perform an additional throttling (= since the client or a downstream agent already performed the throttling) , = while, when receiving a request that does not contain OC-Ongoing-Throttling= -Information AVP would perform throttling (on behalf of the client) accordi= ng to a previously received and stored OC-OLR, and if that throttling is su= rvived the agent would insert the OC-Ongoing-Throttling-Information AVP in = the request before sending it further upstream. Servers (or in general reporting nodes) would check presence and content of= the OC-Ongoing-Throttling-Information AVP in received request messages and= could detect (together with a check of presence of OC-Feature-Vector AVP) = whether inserting an OC-OLR AVP in the corresponding answer message is need= ed in order to update the reacting node with a new OC-OLR). =A0 This proposal especially addresses use cases like the following: =A0 Architecture: =A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +-------= ---------+ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | suppor= ting=A0=A0=A0=A0 | =A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /| agent A1= =A0=A0=A0=A0=A0=A0 |\ =A0 +----------------+ / +----------------+ \ =A0 | non supporting |/=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 \ =A0 | client C=A0=A0=A0=A0=A0=A0 |\=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 \ =A0 +----------------+ \ +----------------+=A0=A0=A0 \ +------------+=A0=A0= =A0 +---------+ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 \| non supp= orting |=A0=A0=A0=A0 \| supporting | =A0=A0 | Server=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 age= nt A2=A0=A0=A0=A0=A0 |------| agent A3=A0=A0 |----|=A0 S=A0=A0=A0=A0=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0 +------------= ----+=A0=A0=A0=A0=A0 +------------+=A0=A0=A0 +---------+ =A0 1. A request is sent from C via A2 and A3 to S. A3 recognizes that there is= no reacting node downstream (no OC-Feature-Vector received) and therefore = takes the role of the reacting node and inserts an OC-Feature-Vector AVP. A= 3 has no valid OLR from S stored and therefore does not perform throttling = and does not insert an OC-Throttling-Information AVP. 2. S recognizes that there is a reacting node downstream which is actually = not performing a throttling. S returns a 10% throttling request (TimeStamp= =3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A3 and= A2 to C. 3. A3 stores the 10% throttling request. 4. A new request is sent from C via A2 and A3 to S. A3 recognizes that ther= e is no reacting node downstream (no OC-Feature-Vector received) and theref= ore takes the role of the reacting node and inserts an OC-Feature-Vector AV= P. A3 has=A0 valid OLR from S stored and performs a 10% throttling. The req= uest survives and A3 inserts an OC-Throttling-Information AVP with timeStam= p=3Dt1. 5. S recognizes that correct throttling (correct time stamp) is in place an= d therefore does not return OC-OLR in the answer. 6. A new request is sent from C via A1 and A3 to S. A1 recognizes that ther= e is no reacting node downstream (no OC-Feature-Vector received) and theref= ore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 h= as no valid OLR from S stored and therefore does not perform throttling and= does not insert an OC-Throttling-Information AVP. A3 recognizes that there= is a reacting node downstream (OC-Feature-Vector received) and therefore d= oes not take the role of the reacting node. 7. S recognizes that there is a reacting node downstream which is actually = not performing a throttling. S returns a 10% throttling request (TimeStamp= =3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A3 and= A1 to C. 8. A1 stores the 10% throttling request. 9. A new request is sent from C via A1 and A3 to S. A1 recognizes that ther= e is no reacting node downstream (no OC-Feature-Vector received) and theref= ore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 h= as=A0 valid OLR from S stored and therefore performs a 10% throttling. The = request survives and A1 inserts an OC-Throttling-Information AVP with timeS= tamp=3Dt1. A3 recognizes that there is a reacting node downstream (OC-Featu= re-Vector received) and therefore does not take the role of the reacting no= de. 10. S recognizes that correct throttling (correct time stamp) is in place a= nd therefore does not return OC-OLR in the answer. 11. Requests sent from C via A1 and A3 to S undergo a 10% throttling at A1,= requests sent from C via A2 and A3 to S undergo a 10% throttling at A3. 12. Overload situation in S for some reason gets worse, S decides to reques= t 20 % reduction. 13. A new request is sent from C via A1 and A3 to S. A1 recognizes that the= re is no reacting node downstream (no OC-Feature-Vector received) and there= fore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 = has=A0 valid OLR from S stored and therefore performs a 10% throttling. The= request survives and A1 inserts an OC-Throttling-Information AVP with time= Stamp=3Dt1. A3 recognizes that there is a reacting node downstream (OC-Feat= ure-Vector received) and therefore does not take the role of the reacting n= ode. 14. S recognizes that incorrect throttling (wrong time stamp) is in place a= nd therefore S returns a 20% throttling request (TimeStamp=3Dt2, duration= =3Dx) within OC-OLR in the answer which goes back via A3 and A1 to C. 15. A3 (not taking the role of the reactingt node)may, A1 must store the 20= % throttling request (replacing the 10% request). 16. A new request is sent from C via A2 and A3 to S. A3 recognizes that the= re is no reacting node downstream (no OC-Feature-Vector received) and there= fore takes the role of the reacting node and inserts an OC-Feature-Vector A= VP. A3 has=A0 valid OLR from S stored and performs a 10% throttling. The re= quest survives and A3 inserts an OC-Throttling-Information AVP with timeSta= mp=3Dt1. (assuming A3 did not store the 20% request at step 14) 17. S recog= nizes that incorrect throttling (wrong time stamp) is in place and therefor= e S returns a 20% throttling request (TimeStamp=3Dt2, duration=3Dx) within = OC-OLR in the answer which goes back via A3 and A2 to C. 18. A3 stores the 20% throttling request (replacing the 10% request). 19. Requests sent from C via A1 and A3 to S undergo a 20% throttling at A1,= requests sent from C via A2 and A3 to S undergo a 20% throttling at A3. =A0 =A0 Comments are welcome. =A0 Best regards Ulrich =A0 =A0 From ulrich.wiehe@nsn.com Thu Nov 7 02:23:46 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2D1721E817F; Thu, 7 Nov 2013 02:23:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.736 X-Spam-Level: X-Spam-Status: No, score=-5.736 tagged_above=-999 required=5 tests=[AWL=0.263, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oKx4X5VX4cGA; Thu, 7 Nov 2013 02:23:41 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 803FF21E815D; Thu, 7 Nov 2013 02:23:35 -0800 (PST) Received: from demuprx017.emea.nsn-intra.net ([10.150.129.56]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rA7ANUIa017348 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 7 Nov 2013 11:23:31 +0100 Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx017.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rA7ANUX0019233 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Nov 2013 11:23:30 +0100 Received: from DEMUHTC005.nsn-intra.net (10.159.42.36) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 7 Nov 2013 11:23:29 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.198]) by DEMUHTC005.nsn-intra.net ([10.159.42.36]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 11:23:29 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "ext Nirav Salot (nsalot)" , "doc-dt@ietf.org" , "dime@ietf.org" Thread-Topic: Ongoing Throttling Information in request messages Thread-Index: Ac7aQPqQ1tyE3SNOTC+vVrUogwBrJQAnWH+wAADoRNAABgE0oAAA57DwAACoAlAAASWEQAAAqKUAACDdWeAAAz9GUAABLecQ Date: Thu, 7 Nov 2013 10:23:28 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D900066815192D5F@DEMUMBX014.nsn-intra.net> References: <5BCBA1FC2B7F0B4C9D935572D9000668151918EC@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192B2B@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192B90@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192BF7@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192CD2@DEMUMBX014.nsn-intra.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.113] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 18686 X-purgate-ID: 151667::1383819811-00004A43-D1F8B7C6/0-0/0-0 Subject: Re: [Dime] Ongoing Throttling Information in request messages X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 10:23:47 -0000 Nirav, please see inline. Best regards Ulrich -----Original Message----- From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]=20 Sent: Thursday, November 07, 2013 10:15 AM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, Please read my responses inline. Regards, Nirav. -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Sent: Thursday, November 07, 2013 1:54 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, thank you for the explanation. This may be a solution which adds more comp= lexity to the reporting node: The reporting node must remember the maximum = not yet expired fraction of duration values it sent when leaving the overlo= ad state and must continue reporting "end of overload condition" until expi= ry. (there is no corresponding complexity at the reacting node in my propos= al) [Nirav] This is not always true, e.g. as I had indicated if the node has ad= vertised 10% reduction-percentage for 10 sec., it need not bother to advert= ise no-overload condition since the validity-period was very small. [Ulrich] Also not always true, e.g. if the reporting node has requested at = 20% reduction for 1000sec at t1 and then at t1 + 10sec sends an update to r= equest a 10% reduction for 10 sec. Although the validity-period is small (1= 0 sec) there may still be a reacting node that did not get the update and k= eeps on throttling by 20% until t1 + 1000sec. Furthermore you seem not to t= ake REQ 10 seriously. My understanding was that timeout is last resort, not= the normal way. Another question: While doing a throttling, what is the expected behaviour = of the reacting node when receiving an answer message without OC-OLR AVP? (= stop/continue throttling?) (there is no corresponding question in my propos= al since not sending of OC-Ongoing-Throttling-Information clearly means tha= t throttling is not in place) [Nirav] The reacting node should continue to apply the earlier received OC-= OLR.=20 " (Note: We seem to have consensus that a server MAY repeat OLRs in subsequent messages, but is not required to do so, based on local policy.)" [Ulrich] This needs to be reconsidered. See the following example: Non supporting client C1 sends a request via supporting agent A1 to Server = S. S returns a 10% throttling request.=20 C sends an new request via supporting agent A2 to S.=20 S decides not to repeat the 10% throttling request (hence A2 is not aware o= f the throttling request).=20 C1 sends a new request via A1.=20 S decides to repeat the throttling request (redundant).=20 Supporting client C2 sends a request via A2 to S. S decides not to repeat.... To avoid this mess we either need to mandate sending OC-OLR in every answer= (while in overload) or let the Server keep track which agent and which cli= ent is updated with the newest info. (or consider my proposal). Another question is for the reacting node: What is the expected behaviour w= hen receiving lots of redundant OC-OLR AVPs in answer messages? The reactin= g node needs to check every single OC-OLR AVP in order to find out whether = it contains an update. Is that the correct understanding? (this seems to be= equivalent to checking for redundant OC-Ongoing-Throttling-Information AVP= s in every request by the reporting node in my proposal) [Nirav] Please refer to Timestamp AVP within OC-OLR. The TimeStamp AVP indicates when the original OC-OLR AVP with the current content was created. It is possible to replay the same OC- OLR AVP multiple times between the overload endpoints, however, when the OC-OLR AVP content changes or the other information sending endpoint wants the receiving endpoint to update its overload control information, then the TimeStamp AVP MUST contain a new value. [Ulrich] This does not explicitly say that the reacting node must check eve= ry TimeStamp received within OC-OLR AVPs. But I guess this is the consequen= ce. Can you please confirm. Adding dime-list again. Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 4:58 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, During "no overload condition", why should reporting node include overload-= information in all the answer messages? e.g. if the reporting node has advertised overload-report with period-of-va= lidity=3D10 sec., it knows that after that period all the reacting node wil= l automatically stop applying any overload mitigation action. And hence it = does not need to explicitly send any overload-report indicating "no overloa= d condition". In general, I assume that overload period of would be much shorter as compa= red to "no overload" period. And hence I do not see reason to always includ= e overload-report. Regards, Nirav. From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Wednesday, November 06, 2013 9:12 PM To: Nirav Salot (nsalot); doc-dt@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, "During the overload" yes I agree, but "when no longer in overload" all ans= wer messages would contain the information "no longer in overload" while on= ly few request messages would contain the Ongoing-Throttling-Information. Removing dime-list which bounces. Best regards Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 4:02 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, I might be missing something here so please bear with me. Number of answer messages sent by server =3D number of request messages rec= eived by the server. During the overload, the server would receive only those requests which sur= vived throttling. And then the server would send answer messages to only those request messag= es. So "every" and "some" are actually equal in the below equation. No? Regards, Nirav. From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Wednesday, November 06, 2013 8:24 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, Not quite. The question is: "is sending an overload-report in every answer message that corresponds to = request with OC-Feature-Vector present more resource consuming than receivi= ng Ongoing-Throttling-Information in some request messages (only those that= survived a throttling)?" Best regards Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 3:15 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, Thanks for clarification. Then the question would be "is sending overload-report in every answer message is more resource consum= ing than the solution below - i.e. receiving OC-Ongoing-Throttling-Informat= ion in all request message and analyzing the timestamp and then deciding if= the overload-report should be included or not." I am not sure. Regards, Nirav. From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Wednesday, November 06, 2013 7:08 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, thank you for your comments. The comparism is between: Current way: "send OC specific information (Feature-Vector) in every reques= t message and in every corresponding answer message" My proposal: "send OC specific information (Feature-Vector and in some case= s Ongoing-Throttling-Info) in every request message and in corresponding an= swer messages only when required". Sending OC specific information =A0is regarded a resource consuming action = and we should not put this action to the (overloaded) server where avoidabl= e. See REQ 13. Best regards Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 12:04 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, Thanks for the detail explanation of your proposal. Just to verify my understanding, Your proposal would allow the reporting node to avoid inclusion of the "sam= e" overload-report in the answer message since the request message indicate= s that the path contains at least one reacting node which already has the l= atest overload-report. In other words, the reporting node need not include overload-report in ever= y message, blindly. To achieve the above objective, the solution below suggest the reacting nod= e to include new AVP OC-Ongoing-Throttling-Information in every request mes= sage, which survives throttling. So the net result is that, the inclusion of the overload-report is prevente= d in every answer message since the OC-Ongoing-Throttling-Information is in= cluded in every request message. [Wiehe, Ulrich (NSN - DE/Munich)] no.=A0 .in every request message that sur= vived a throttling. And hence I am not sure if the solution has sound benefit from the inclusio= n of redundant information point of view. In summary, I think the solution suggested below works as explained. But I fail to see the benefit of using this solution compare to a solution = in which the reporting node includes overload-report in every answer messag= e. Regards, Nirav. From: doc-dt-bounces@ietf.org [mailto:doc-dt-bounces@ietf.org] On Behalf Of= Wiehe, Ulrich (NSN - DE/Munich) Sent: Tuesday, November 05, 2013 9:36 PM To: doc-dt@ietf.org; dime@ietf.org Subject: [doc-dt] Ongoing Throttling Information in request messages Hi, draft-docdt-dime-ovli-01 in Appendix B, Table 1, REQ 13 says: =A0=A0=A0=A0=A0=A0=A0 .. Another way =A0=A0=A0=A0=A0=A0=A0 is to let the request sender (reacting node) insert =A0=A0=A0=A0=A0=A0=A0 information in the request to say whether a =A0=A0=A0=A0=A0=A0=A0 throttling is actually performed.=A0 The reporting no= de =A0=A0=A0=A0=A0=A0=A0 then can base its decision on information received in =A0=A0=A0=A0=A0=A0=A0 the request; no need for keeping state to record who =A0 has received overload reports.=A0=20 =A0 And in Appendix B, Table 1, REQ 18: =A0=A0=A0=A0=A0=A0=A0 There has been a proposal to mark =A0=A0=A0=A0=A0=A0=A0 messages that survived overload throttling as one =A0=A0=A0=A0=A0=A0=A0 method for an overloaded node to address fairness but =A0=A0=A0=A0=A0=A0=A0 this proposal is not yet part of the solution.=A0=20 =A0 I would like to come back to this proposal.=20 A new AVP OC-Ongoing-Throttling-Information inserted in request messages wo= uld indicate that the request message survived a throttling. Furthermore, i= nformation within the AVP indicates the TimeStamp as received in the previo= us OC-OLR AVP, according to which the ongoing throttling (which was survive= d) is performed. =A0 OC-Ongoing-Throttling-Information ::=3D < AVP Header: TBD9 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 < TimeStamp > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * [ AVP ] =A0 Supporting Clients would insert the OC-Ongoing-Throttling-Information AVP= =A0 into request messages that survived a throttling performed at that clie= nt. Supporting Agents when receiving a request message that contains an OC-Ongo= ing-Throttling-Information AVP would not perform an additional throttling (= since the client or a downstream agent already performed the throttling) , = while, when receiving a request that does not contain OC-Ongoing-Throttling= -Information AVP would perform throttling (on behalf of the client) accordi= ng to a previously received and stored OC-OLR, and if that throttling is su= rvived the agent would insert the OC-Ongoing-Throttling-Information AVP in = the request before sending it further upstream. Servers (or in general reporting nodes) would check presence and content of= the OC-Ongoing-Throttling-Information AVP in received request messages and= could detect (together with a check of presence of OC-Feature-Vector AVP) = whether inserting an OC-OLR AVP in the corresponding answer message is need= ed in order to update the reacting node with a new OC-OLR). =A0 This proposal especially addresses use cases like the following: =A0 Architecture: =A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +-------= ---------+ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | suppor= ting=A0=A0=A0=A0 | =A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /| agent A1= =A0=A0=A0=A0=A0=A0 |\ =A0 +----------------+ / +----------------+ \ =A0 | non supporting |/=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 \ =A0 | client C=A0=A0=A0=A0=A0=A0 |\=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 \ =A0 +----------------+ \ +----------------+=A0=A0=A0 \ +------------+=A0=A0= =A0 +---------+ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 \| non supp= orting |=A0=A0=A0=A0 \| supporting | =A0=A0 | Server=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 age= nt A2=A0=A0=A0=A0=A0 |------| agent A3=A0=A0 |----|=A0 S=A0=A0=A0=A0=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0 +------------= ----+=A0=A0=A0=A0=A0 +------------+=A0=A0=A0 +---------+ =A0 1. A request is sent from C via A2 and A3 to S. A3 recognizes that there is= no reacting node downstream (no OC-Feature-Vector received) and therefore = takes the role of the reacting node and inserts an OC-Feature-Vector AVP. A= 3 has no valid OLR from S stored and therefore does not perform throttling = and does not insert an OC-Throttling-Information AVP. 2. S recognizes that there is a reacting node downstream which is actually = not performing a throttling. S returns a 10% throttling request (TimeStamp= =3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A3 and= A2 to C. 3. A3 stores the 10% throttling request. 4. A new request is sent from C via A2 and A3 to S. A3 recognizes that ther= e is no reacting node downstream (no OC-Feature-Vector received) and theref= ore takes the role of the reacting node and inserts an OC-Feature-Vector AV= P. A3 has=A0 valid OLR from S stored and performs a 10% throttling. The req= uest survives and A3 inserts an OC-Throttling-Information AVP with timeStam= p=3Dt1. 5. S recognizes that correct throttling (correct time stamp) is in place an= d therefore does not return OC-OLR in the answer. 6. A new request is sent from C via A1 and A3 to S. A1 recognizes that ther= e is no reacting node downstream (no OC-Feature-Vector received) and theref= ore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 h= as no valid OLR from S stored and therefore does not perform throttling and= does not insert an OC-Throttling-Information AVP. A3 recognizes that there= is a reacting node downstream (OC-Feature-Vector received) and therefore d= oes not take the role of the reacting node. 7. S recognizes that there is a reacting node downstream which is actually = not performing a throttling. S returns a 10% throttling request (TimeStamp= =3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A3 and= A1 to C. 8. A1 stores the 10% throttling request. 9. A new request is sent from C via A1 and A3 to S. A1 recognizes that ther= e is no reacting node downstream (no OC-Feature-Vector received) and theref= ore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 h= as=A0 valid OLR from S stored and therefore performs a 10% throttling. The = request survives and A1 inserts an OC-Throttling-Information AVP with timeS= tamp=3Dt1. A3 recognizes that there is a reacting node downstream (OC-Featu= re-Vector received) and therefore does not take the role of the reacting no= de. 10. S recognizes that correct throttling (correct time stamp) is in place a= nd therefore does not return OC-OLR in the answer. 11. Requests sent from C via A1 and A3 to S undergo a 10% throttling at A1,= requests sent from C via A2 and A3 to S undergo a 10% throttling at A3. 12. Overload situation in S for some reason gets worse, S decides to reques= t 20 % reduction. 13. A new request is sent from C via A1 and A3 to S. A1 recognizes that the= re is no reacting node downstream (no OC-Feature-Vector received) and there= fore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 = has=A0 valid OLR from S stored and therefore performs a 10% throttling. The= request survives and A1 inserts an OC-Throttling-Information AVP with time= Stamp=3Dt1. A3 recognizes that there is a reacting node downstream (OC-Feat= ure-Vector received) and therefore does not take the role of the reacting n= ode. 14. S recognizes that incorrect throttling (wrong time stamp) is in place a= nd therefore S returns a 20% throttling request (TimeStamp=3Dt2, duration= =3Dx) within OC-OLR in the answer which goes back via A3 and A1 to C. 15. A3 (not taking the role of the reactingt node)may, A1 must store the 20= % throttling request (replacing the 10% request). 16. A new request is sent from C via A2 and A3 to S. A3 recognizes that the= re is no reacting node downstream (no OC-Feature-Vector received) and there= fore takes the role of the reacting node and inserts an OC-Feature-Vector A= VP. A3 has=A0 valid OLR from S stored and performs a 10% throttling. The re= quest survives and A3 inserts an OC-Throttling-Information AVP with timeSta= mp=3Dt1. (assuming A3 did not store the 20% request at step 14) 17. S recog= nizes that incorrect throttling (wrong time stamp) is in place and therefor= e S returns a 20% throttling request (TimeStamp=3Dt2, duration=3Dx) within = OC-OLR in the answer which goes back via A3 and A2 to C. 18. A3 stores the 20% throttling request (replacing the 10% request). 19. Requests sent from C via A1 and A3 to S undergo a 20% throttling at A1,= requests sent from C via A2 and A3 to S undergo a 20% throttling at A3. =A0 =A0 Comments are welcome. =A0 Best regards Ulrich =A0 =A0 From nsalot@cisco.com Thu Nov 7 08:28:55 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80DEA21E8121; Thu, 7 Nov 2013 08:28:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.249 X-Spam-Level: X-Spam-Status: No, score=-10.249 tagged_above=-999 required=5 tests=[AWL=-0.250, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F52K20o3jCJW; Thu, 7 Nov 2013 08:28:49 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) by ietfa.amsl.com (Postfix) with ESMTP id 696F111E81C1; Thu, 7 Nov 2013 08:28:49 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=19692; q=dns/txt; s=iport; t=1383841729; x=1385051329; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=4KwrmxDKXVohTjTztGsb0UHd6w3Hzj4r/hb6XEg3MLc=; b=KWKXj7R5yPh1JAr2ve6ObD8EjAuD6Ia7EpFBlc6POCl+GQg7Vs7ojs79 F69hsKN3afQZ6sT9fz69NJP3Iwq07C1HcIlsdLDvuWS4OZOYWjPtmMj36 gpr9M1gPHjQOTtOBezMQjAEjmo+btpkvSwH7+jE/j9e3WE8podhJTUGUc E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgYFACq/e1KtJV2b/2dsb2JhbABagweBC78OgSUWdIIlAQEBBIEFBAIBCBEBAwEBCw8CDAcyFAMGCAIEARIIE4dmvQ+PKDgGGgeCeYEQA4kIiySOM4c3gyaBTBwCBRki X-IronPort-AV: E=Sophos;i="4.93,652,1378857600"; d="scan'208";a="282015996" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by rcdn-iport-6.cisco.com with ESMTP; 07 Nov 2013 16:28:47 +0000 Received: from xhc-aln-x02.cisco.com (xhc-aln-x02.cisco.com [173.36.12.76]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id rA7GSlNY013209 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 7 Nov 2013 16:28:47 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.47]) by xhc-aln-x02.cisco.com ([173.36.12.76]) with mapi id 14.03.0123.003; Thu, 7 Nov 2013 10:28:46 -0600 From: "Nirav Salot (nsalot)" To: "Wiehe, Ulrich (NSN - DE/Munich)" , "doc-dt@ietf.org" , "dime@ietf.org" Thread-Topic: Ongoing Throttling Information in request messages Thread-Index: Ac7aQPqQ1tyE3SNOTC+vVrUogwBrJQAnWH+wAADoRNAABgE0oAAA57DwAACoAlAAASWEQAAAqKUAACDdWeAAAz9GUAABLecQAA4Qc8A= Date: Thu, 7 Nov 2013 16:28:45 +0000 Message-ID: References: <5BCBA1FC2B7F0B4C9D935572D9000668151918EC@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192B2B@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192B90@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192BF7@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192CD2@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192D5F@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D900066815192D5F@DEMUMBX014.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.65.46.153] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Dime] Ongoing Throttling Information in request messages X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Nov 2013 16:28:55 -0000 Ulrich, Not sure the significance of REQ 10 here but I do not agree to enforce the = server to include overload-report (indicating non-zero or zero overload con= dition) in every message. Even in your example, the overload condition will end sometime - e.g. after= 1000 sec. and then the server can stop including the overload-report. Besides, I am still not convince that "during the overload condition, using= some logic to avoid inclusion of overload-report is less resource consumin= g than simply including the same overload-report". Yes, the reason behind defining timestamp is to allow the reacting node to = discard the overload-report if the same was already received from the repor= ting node. Regards, Nirav. -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Sent: Thursday, November 07, 2013 3:53 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, please see inline. Best regards Ulrich -----Original Message----- From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Thursday, November 07, 2013 10:15 AM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, Please read my responses inline. Regards, Nirav. -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Thursday, November 07, 2013 1:54 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, thank you for the explanation. This may be a solution which adds more comp= lexity to the reporting node: The reporting node must remember the maximum = not yet expired fraction of duration values it sent when leaving the overlo= ad state and must continue reporting "end of overload condition" until expi= ry. (there is no corresponding complexity at the reacting node in my propos= al) [Nirav] This is not always true, e.g. as I had indicated if the node ha= s advertised 10% reduction-percentage for 10 sec., it need not bother to ad= vertise no-overload condition since the validity-period was very small. [Ulrich] Also not always true, e.g. if the reporting node has requested at = 20% reduction for 1000sec at t1 and then at t1 + 10sec sends an update to r= equest a 10% reduction for 10 sec. Although the validity-period is small (1= 0 sec) there may still be a reacting node that did not get the update and k= eeps on throttling by 20% until t1 + 1000sec. Furthermore you seem not to t= ake REQ 10 seriously. My understanding was that timeout is last resort, not= the normal way. Another question: While doing a throttling, what is the expected behaviour = of the reacting node when receiving an answer message without OC-OLR AVP? (= stop/continue throttling?) (there is no corresponding question in my propos= al since not sending of OC-Ongoing-Throttling-Information clearly means tha= t throttling is not in place) [Nirav] The reacting node should continue to = apply the earlier received OC-OLR.=20 " (Note: We seem to have consensus that a server MAY repeat OLRs in subsequent messages, but is not required to do so, based on local policy.)" [Ulrich] This needs to be reconsidered. See the following example: Non supporting client C1 sends a request via supporting agent A1 to Server = S. S returns a 10% throttling request.=20 C sends an new request via supporting agent A2 to S.=20 S decides not to repeat the 10% throttling request (hence A2 is not aware o= f the throttling request).=20 C1 sends a new request via A1.=20 S decides to repeat the throttling request (redundant).=20 Supporting client C2 sends a request via A2 to S. S decides not to repeat.... To avoid this mess we either need to mandate sending OC-OLR in every answer= (while in overload) or let the Server keep track which agent and which cli= ent is updated with the newest info. (or consider my proposal). Another question is for the reacting node: What is the expected behaviour w= hen receiving lots of redundant OC-OLR AVPs in answer messages? The reactin= g node needs to check every single OC-OLR AVP in order to find out whether = it contains an update. Is that the correct understanding? (this seems to be= equivalent to checking for redundant OC-Ongoing-Throttling-Information AVP= s in every request by the reporting node in my proposal) [Nirav] Please ref= er to Timestamp AVP within OC-OLR. The TimeStamp AVP indicates when the original OC-OLR AVP with the current content was created. It is possible to replay the same OC- OLR AVP multiple times between the overload endpoints, however, when the OC-OLR AVP content changes or the other information sending endpoint wants the receiving endpoint to update its overload control information, then the TimeStamp AVP MUST contain a new value. [Ulrich] This does not explicitly say that the reacting node must check eve= ry TimeStamp received within OC-OLR AVPs. But I guess this is the consequen= ce. Can you please confirm. Adding dime-list again. Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 4:58 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, During "no overload condition", why should reporting node include overload-= information in all the answer messages? e.g. if the reporting node has advertised overload-report with period-of-va= lidity=3D10 sec., it knows that after that period all the reacting node wil= l automatically stop applying any overload mitigation action. And hence it = does not need to explicitly send any overload-report indicating "no overloa= d condition". In general, I assume that overload period of would be much shorter as compa= red to "no overload" period. And hence I do not see reason to always includ= e overload-report. Regards, Nirav. From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Wednesday, November 06, 2013 9:12 PM To: Nirav Salot (nsalot); doc-dt@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, "During the overload" yes I agree, but "when no longer in overload" all ans= wer messages would contain the information "no longer in overload" while on= ly few request messages would contain the Ongoing-Throttling-Information. Removing dime-list which bounces. Best regards Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 4:02 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, I might be missing something here so please bear with me. Number of answer messages sent by server =3D number of request messages rec= eived by the server. During the overload, the server would receive only those requests which sur= vived throttling. And then the server would send answer messages to only those request messag= es. So "every" and "some" are actually equal in the below equation. No? Regards, Nirav. From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Wednesday, November 06, 2013 8:24 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, Not quite. The question is: "is sending an overload-report in every answer message that corresponds to = request with OC-Feature-Vector present more resource consuming than receivi= ng Ongoing-Throttling-Information in some request messages (only those that= survived a throttling)?" Best regards Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 3:15 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, Thanks for clarification. Then the question would be "is sending overload-report in every answer message is more resource consum= ing than the solution below - i.e. receiving OC-Ongoing-Throttling-Informat= ion in all request message and analyzing the timestamp and then deciding if= the overload-report should be included or not." I am not sure. Regards, Nirav. From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Wednesday, November 06, 2013 7:08 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, thank you for your comments. The comparism is between: Current way: "send OC specific information (Feature-Vector) in every reques= t message and in every corresponding answer message" My proposal: "send OC specific information (Feature-Vector and in some case= s Ongoing-Throttling-Info) in every request message and in corresponding an= swer messages only when required". Sending OC specific information =A0is regarded a resource consuming action = and we should not put this action to the (overloaded) server where avoidabl= e. See REQ 13. Best regards Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 12:04 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, Thanks for the detail explanation of your proposal. Just to verify my understanding, Your proposal would allow the reporting node to avoid inclusion of the "sam= e" overload-report in the answer message since the request message indicate= s that the path contains at least one reacting node which already has the l= atest overload-report. In other words, the reporting node need not include overload-report in ever= y message, blindly. To achieve the above objective, the solution below suggest the reacting nod= e to include new AVP OC-Ongoing-Throttling-Information in every request mes= sage, which survives throttling. So the net result is that, the inclusion of the overload-report is prevente= d in every answer message since the OC-Ongoing-Throttling-Information is in= cluded in every request message. [Wiehe, Ulrich (NSN - DE/Munich)] no.=A0 .in every request message that sur= vived a throttling. And hence I am not sure if the solution has sound benefit from the inclusio= n of redundant information point of view. In summary, I think the solution suggested below works as explained. But I fail to see the benefit of using this solution compare to a solution = in which the reporting node includes overload-report in every answer messag= e. Regards, Nirav. From: doc-dt-bounces@ietf.org [mailto:doc-dt-bounces@ietf.org] On Behalf Of= Wiehe, Ulrich (NSN - DE/Munich) Sent: Tuesday, November 05, 2013 9:36 PM To: doc-dt@ietf.org; dime@ietf.org Subject: [doc-dt] Ongoing Throttling Information in request messages Hi, draft-docdt-dime-ovli-01 in Appendix B, Table 1, REQ 13 says: =A0=A0=A0=A0=A0=A0=A0 .. Another way =A0=A0=A0=A0=A0=A0=A0 is to let the request sender (reacting node) insert =A0=A0=A0=A0=A0=A0=A0 information in the request to say whether a =A0=A0=A0=A0=A0=A0=A0 throttling is actually performed.=A0 The reporting no= de =A0=A0=A0=A0=A0=A0=A0 then can base its decision on information received in =A0=A0=A0=A0=A0=A0=A0 the request; no need for keeping state to record who =A0 has received overload reports.=A0=20 =A0 And in Appendix B, Table 1, REQ 18: =A0=A0=A0=A0=A0=A0=A0 There has been a proposal to mark =A0=A0=A0=A0=A0=A0=A0 messages that survived overload throttling as one =A0=A0=A0=A0=A0=A0=A0 method for an overloaded node to address fairness but =A0=A0=A0=A0=A0=A0=A0 this proposal is not yet part of the solution.=A0=20 =A0 I would like to come back to this proposal.=20 A new AVP OC-Ongoing-Throttling-Information inserted in request messages wo= uld indicate that the request message survived a throttling. Furthermore, i= nformation within the AVP indicates the TimeStamp as received in the previo= us OC-OLR AVP, according to which the ongoing throttling (which was survive= d) is performed. =A0 OC-Ongoing-Throttling-Information ::=3D < AVP Header: TBD9 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 < TimeStamp > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * [ AVP ] =A0 Supporting Clients would insert the OC-Ongoing-Throttling-Information AVP= =A0 into request messages that survived a throttling performed at that clie= nt. Supporting Agents when receiving a request message that contains an OC-Ongo= ing-Throttling-Information AVP would not perform an additional throttling (= since the client or a downstream agent already performed the throttling) , = while, when receiving a request that does not contain OC-Ongoing-Throttling= -Information AVP would perform throttling (on behalf of the client) accordi= ng to a previously received and stored OC-OLR, and if that throttling is su= rvived the agent would insert the OC-Ongoing-Throttling-Information AVP in = the request before sending it further upstream. Servers (or in general reporting nodes) would check presence and content of= the OC-Ongoing-Throttling-Information AVP in received request messages and= could detect (together with a check of presence of OC-Feature-Vector AVP) = whether inserting an OC-OLR AVP in the corresponding answer message is need= ed in order to update the reacting node with a new OC-OLR). =A0 This proposal especially addresses use cases like the following: =A0 Architecture: =A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +-------= ---------+ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | suppor= ting=A0=A0=A0=A0 | =A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /| agent A1= =A0=A0=A0=A0=A0=A0 |\ =A0 +----------------+ / +----------------+ \ =A0 | non supporting |/=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 \ =A0 | client C=A0=A0=A0=A0=A0=A0 |\=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 \ =A0 +----------------+ \ +----------------+=A0=A0=A0 \ +------------+=A0=A0= =A0 +---------+ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 \| non supp= orting |=A0=A0=A0=A0 \| supporting | =A0=A0 | Server=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 age= nt A2=A0=A0=A0=A0=A0 |------| agent A3=A0=A0 |----|=A0 S=A0=A0=A0=A0=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0 +------------= ----+=A0=A0=A0=A0=A0 +------------+=A0=A0=A0 +---------+ =A0 1. A request is sent from C via A2 and A3 to S. A3 recognizes that there is= no reacting node downstream (no OC-Feature-Vector received) and therefore = takes the role of the reacting node and inserts an OC-Feature-Vector AVP. A= 3 has no valid OLR from S stored and therefore does not perform throttling = and does not insert an OC-Throttling-Information AVP. 2. S recognizes that there is a reacting node downstream which is actually = not performing a throttling. S returns a 10% throttling request (TimeStamp= =3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A3 and= A2 to C. 3. A3 stores the 10% throttling request. 4. A new request is sent from C via A2 and A3 to S. A3 recognizes that ther= e is no reacting node downstream (no OC-Feature-Vector received) and theref= ore takes the role of the reacting node and inserts an OC-Feature-Vector AV= P. A3 has=A0 valid OLR from S stored and performs a 10% throttling. The req= uest survives and A3 inserts an OC-Throttling-Information AVP with timeStam= p=3Dt1. 5. S recognizes that correct throttling (correct time stamp) is in place an= d therefore does not return OC-OLR in the answer. 6. A new request is sent from C via A1 and A3 to S. A1 recognizes that ther= e is no reacting node downstream (no OC-Feature-Vector received) and theref= ore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 h= as no valid OLR from S stored and therefore does not perform throttling and= does not insert an OC-Throttling-Information AVP. A3 recognizes that there= is a reacting node downstream (OC-Feature-Vector received) and therefore d= oes not take the role of the reacting node. 7. S recognizes that there is a reacting node downstream which is actually = not performing a throttling. S returns a 10% throttling request (TimeStamp= =3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A3 and= A1 to C. 8. A1 stores the 10% throttling request. 9. A new request is sent from C via A1 and A3 to S. A1 recognizes that ther= e is no reacting node downstream (no OC-Feature-Vector received) and theref= ore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 h= as=A0 valid OLR from S stored and therefore performs a 10% throttling. The = request survives and A1 inserts an OC-Throttling-Information AVP with timeS= tamp=3Dt1. A3 recognizes that there is a reacting node downstream (OC-Featu= re-Vector received) and therefore does not take the role of the reacting no= de. 10. S recognizes that correct throttling (correct time stamp) is in place a= nd therefore does not return OC-OLR in the answer. 11. Requests sent from C via A1 and A3 to S undergo a 10% throttling at A1,= requests sent from C via A2 and A3 to S undergo a 10% throttling at A3. 12. Overload situation in S for some reason gets worse, S decides to reques= t 20 % reduction. 13. A new request is sent from C via A1 and A3 to S. A1 recognizes that the= re is no reacting node downstream (no OC-Feature-Vector received) and there= fore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 = has=A0 valid OLR from S stored and therefore performs a 10% throttling. The= request survives and A1 inserts an OC-Throttling-Information AVP with time= Stamp=3Dt1. A3 recognizes that there is a reacting node downstream (OC-Feat= ure-Vector received) and therefore does not take the role of the reacting n= ode. 14. S recognizes that incorrect throttling (wrong time stamp) is in place a= nd therefore S returns a 20% throttling request (TimeStamp=3Dt2, duration= =3Dx) within OC-OLR in the answer which goes back via A3 and A1 to C. 15. A3 (not taking the role of the reactingt node)may, A1 must store the 20= % throttling request (replacing the 10% request). 16. A new request is sent from C via A2 and A3 to S. A3 recognizes that the= re is no reacting node downstream (no OC-Feature-Vector received) and there= fore takes the role of the reacting node and inserts an OC-Feature-Vector A= VP. A3 has=A0 valid OLR from S stored and performs a 10% throttling. The re= quest survives and A3 inserts an OC-Throttling-Information AVP with timeSta= mp=3Dt1. (assuming A3 did not store the 20% request at step 14) 17. S recog= nizes that incorrect throttling (wrong time stamp) is in place and therefor= e S returns a 20% throttling request (TimeStamp=3Dt2, duration=3Dx) within = OC-OLR in the answer which goes back via A3 and A2 to C. 18. A3 stores the 20% throttling request (replacing the 10% request). 19. Requests sent from C via A1 and A3 to S undergo a 20% throttling at A1,= requests sent from C via A2 and A3 to S undergo a 20% throttling at A3. =A0 =A0 Comments are welcome. =A0 Best regards Ulrich =A0 =A0 From jouni.nospam@gmail.com Fri Nov 8 13:46:31 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B68111E80DC for ; Fri, 8 Nov 2013 13:46:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.566 X-Spam-Level: X-Spam-Status: No, score=-2.566 tagged_above=-999 required=5 tests=[AWL=0.033, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXjcd2Cg6oVi for ; Fri, 8 Nov 2013 13:46:31 -0800 (PST) Received: from mail-pd0-x231.google.com (mail-pd0-x231.google.com [IPv6:2607:f8b0:400e:c02::231]) by ietfa.amsl.com (Postfix) with ESMTP id 1611711E80D9 for ; Fri, 8 Nov 2013 13:46:31 -0800 (PST) Received: by mail-pd0-f177.google.com with SMTP id p10so2686805pdj.36 for ; Fri, 08 Nov 2013 13:46:30 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:message-id :cc:to:mime-version; bh=QtiOkdn5s+PFRnKsaxpemhi+Blllgz+yBNoFselhSkY=; b=tdkONWoZz31z8bk7cpaZ3X5NqSqc9ZoTNiNPbnTopFiYisVvZFxCAVQXX39YbEbOrV PKFrfdbknqp/sodM3+tUgoD89QVm8KS8oKykMbuDIcVHL1TdNUyLQCOHmeIKek58+6PI 7zojBU7ZaU8OZR9r3bSxAx3pBKv5Q8FL9JRTYnROQqckLcE8kDJNAmJ/u3YiVIzI9IIT 7+P1y/1lC7z31dXC9ZtYbO1d3jQXJDiyaS4zaOtHsLhSjYIAniapDEm4+vSaoeVVj6gi 6OoKugviyFN6CwJ5ZosjePHoZtpiQtR7lI7LvC/DfVv/P2AfKztlMfq40bY7499nPvbI jIZA== X-Received: by 10.68.215.4 with SMTP id oe4mr152384pbc.198.1383947190921; Fri, 08 Nov 2013 13:46:30 -0800 (PST) Received: from dhcp-b115.meeting.ietf.org (dhcp-b115.meeting.ietf.org. [31.133.177.21]) by mx.google.com with ESMTPSA id ed3sm14277865pbc.6.2013.11.08.13.46.29 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 08 Nov 2013 13:46:30 -0800 (PST) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Date: Fri, 8 Nov 2013 23:46:27 +0200 Message-Id: To: "dime@ietf.org" Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [Dime] WG adoption call for draft-docdt-dime-ovli-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Nov 2013 21:46:31 -0000 Folks, This mail starts a two week WG adoption call for draft-docdt-dime-ovli-01 to serve as a basis for the Diameter overload indication conveyance. the call ends 22-Nov-2013. Express your support or concerns on the mailing list. - Jouni & Lionel From abooth@pt.com Mon Nov 11 08:36:06 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5C82021E809C for ; Mon, 11 Nov 2013 08:36:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I19PPqus9N6k for ; Mon, 11 Nov 2013 08:36:02 -0800 (PST) Received: from rocgw.pt.com (rocgw.pt.com [74.39.135.225]) by ietfa.amsl.com (Postfix) with ESMTP id 32C7011E8106 for ; Mon, 11 Nov 2013 08:36:02 -0800 (PST) Received: from notes4.pt.com (notes4.corp.pt.com [10.81.15.15]) by rocgw.pt.com (Postfix) with ESMTP id CBC8E6D8B; Mon, 11 Nov 2013 11:36:01 -0500 (EST) X-Disclaimed: 1 MIME-Version: 1.0 Importance: Normal X-Priority: 3 (Normal) In-Reply-To: References: From: Andrew Booth To: Jouni Korhonen Message-ID: Date: Mon, 11 Nov 2013 11:36:01 -0500 X-Mailer: Lotus Domino Web Server Release 8.5.3FP5 July 31, 2013 X-MIMETrack: Serialize by Notes Server on notes4/PTI(Release 8.5.3FP5|July 31, 2013) at 11/11/2013 11:36:01 AM, Serialize complete at 11/11/2013 11:36:01 AM, Itemize by Notes Server on notes4/PTI(Release 8.5.3FP5|July 31, 2013) at 11/11/2013 11:36:01 AM, Serialize by Router on notes4/PTI(Release 8.5.3FP5|July 31, 2013) at 11/11/2013 11:36:01 AM Content-Type: multipart/alternative; boundary="=_alternative 005B303885257C20_=" Cc: "dime@ietf.org" Subject: Re: [Dime] WG adoption call for draft-docdt-dime-ovli-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 16:36:06 -0000 --=_alternative 005B303885257C20_= Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=ISO-8859-1 I support the adoption of this draft as a working group item. Thanks, Andrew -----dime-bounces@ietf.org wrote: ----- To: "dime@ietf.org" From: Jouni Korhonen=20 Sent by: dime-bounces@ietf.org Date: 11/08/2013 04:46PM Subject: [Dime] WG adoption call for draft-docdt-dime-ovli-01 Folks, This mail starts a two week WG adoption call for draft-docdt-dime-ovli-01 to serve as a basis for the Diameter overload indication conveyance. the call ends 22-Nov-2013. Express your support or concerns on the mailing list. - Jouni & Lionel =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --=_alternative 005B303885257C20_= Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=ISO-8859-1 Content-ID: <> I support the adoption of this draft as a working group item.

Thanks= ,
Andrew

-----dime-bounces@ietf.org wrote: ---= --
To: "dime@ietf.org" <dime@ietf.org>
From: Jouni Korhonen
Sent by: dime-bounces@ietf.org
Date: 11/08/2013 04:46PM
Subject: = [Dime] WG adoption call for draft-docdt-dime-ovli-01

Folks,

This mail starts a two week WG adoption call for draft-docdt-dime-ovli-= 01
to serve as a basis for the Diameter overload indication conveyance. the
call ends 22-Nov-2013. Express your support or concerns on the mailing
list.

- Jouni & Lionel




=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime
--=_alternative 005B303885257C20_=-- From Brent.Hirschman@sprint.com Mon Nov 11 09:37:52 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E79A221F9F6F for ; Mon, 11 Nov 2013 09:37:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id itQXCFexW1zI for ; Mon, 11 Nov 2013 09:37:47 -0800 (PST) Received: from db8outboundpool.messaging.microsoft.com (mail-db8lp0184.outbound.messaging.microsoft.com [213.199.154.184]) by ietfa.amsl.com (Postfix) with ESMTP id 8B8F921F9D52 for ; Mon, 11 Nov 2013 09:37:45 -0800 (PST) Received: from mail201-db8-R.bigfish.com (10.174.8.243) by DB8EHSOBE014.bigfish.com (10.174.4.77) with Microsoft SMTP Server id 14.1.225.22; Mon, 11 Nov 2013 17:37:40 +0000 Received: from mail201-db8 (localhost [127.0.0.1]) by mail201-db8-R.bigfish.com (Postfix) with ESMTP id C9B91BA0127; Mon, 11 Nov 2013 17:37:40 +0000 (UTC) X-Forefront-Antispam-Report: CIP:144.230.168.26; KIP:(null); UIP:(null); IPV:NLI; H:plsasdm2.corp.sprint.com; RD:none; EFVD:NLI X-SpamScore: -32 X-BigFish: VS-32(zz9371I9f17R542Izz1f42h208ch1ee6h1de0h1fdah2073h2146h1202h1e76h1d1ah1d2ah1fc6hzz1de098h1033IL8275dh1de097h186068hz2fh109h2a8h839h944hd25hf0ah1220h1288h12a5h12a9h12bdh137ah13b6h1441h1504h1537h153bh15d0h162dh1631h1758h18e1h1946h19b5h1ad9h1b0ah224fh1d0ch1d2eh1d3fh1dfeh1dffh1e1dh1fe8h1ff5h2216h1155h) Received-SPF: pass (mail201-db8: domain of sprint.com designates 144.230.168.26 as permitted sender) client-ip=144.230.168.26; envelope-from=Brent.Hirschman@sprint.com; helo=plsasdm2.corp.sprint.com ; p.sprint.com ; Received: from mail201-db8 (localhost.localdomain [127.0.0.1]) by mail201-db8 (MessageSwitch) id 1384191459510454_2500; Mon, 11 Nov 2013 17:37:39 +0000 (UTC) Received: from DB8EHSMHS008.bigfish.com (unknown [10.174.8.254]) by mail201-db8.bigfish.com (Postfix) with ESMTP id 78EEF980071; Mon, 11 Nov 2013 17:37:39 +0000 (UTC) Received: from plsasdm2.corp.sprint.com (144.230.168.26) by DB8EHSMHS008.bigfish.com (10.174.4.18) with Microsoft SMTP Server (TLS) id 14.16.227.3; Mon, 11 Nov 2013 17:37:38 +0000 Received: from PLSWEH02.ad.sprint.com (plsweh02.corp.sprint.com [144.226.242.131]) by plsasdm2.corp.sprint.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id rABHbaNd015470 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 11 Nov 2013 11:37:37 -0600 Received: from PLSWM14A.ad.sprint.com ([169.254.2.15]) by PLSWEH02.ad.sprint.com ([144.226.242.131]) with mapi id 14.03.0123.003; Mon, 11 Nov 2013 11:37:36 -0600 From: "Hirschman, Brent B [CTO]" To: Jouni Korhonen , "dime@ietf.org" Thread-Topic: [Dime] WG adoption call for draft-docdt-dime-ovli-01 Thread-Index: AQHO3MwAh9CiaNuEbUWGUKI1mpMflJogT6Yw Date: Mon, 11 Nov 2013 17:37:36 +0000 Message-ID: References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.122.53.20] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: sprint.com X-FOPE-CONNECTOR: Id%0$Dn%*$RO%0$TLS%0$FQDN%$TlsDn% Subject: Re: [Dime] WG adoption call for draft-docdt-dime-ovli-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 17:37:53 -0000 I support the adoption of this draft as a working group item. Brent Hirschman Tech Dev Strategist III Sprint Corporation 6220 Sprint Parkway Overland Park, KS 66251 Office - 913-762-6736 Mobile - 913-593-6221 -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Jou= ni Korhonen Sent: Friday, November 08, 2013 3:46 PM To: dime@ietf.org Subject: [Dime] WG adoption call for draft-docdt-dime-ovli-01 Folks, This mail starts a two week WG adoption call for draft-docdt-dime-ovli-01 t= o serve as a basis for the Diameter overload indication conveyance. the cal= l ends 22-Nov-2013. Express your support or concerns on the mailing list. - Jouni & Lionel _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ________________________________ This e-mail may contain Sprint proprietary information intended for the sol= e use of the recipient(s). Any use by others is prohibited. If you are not = the intended recipient, please contact the sender and delete all copies of = the message. From Kalyani.Bogineni@VerizonWireless.com Mon Nov 11 09:55:23 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A79311E81C0 for ; Mon, 11 Nov 2013 09:55:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 08MCegUFBi1c for ; Mon, 11 Nov 2013 09:55:19 -0800 (PST) Received: from vanguard.verizonwireless.com (vanguard.verizonwireless.com [162.115.35.70]) by ietfa.amsl.com (Postfix) with ESMTP id 4C9B911E81B2 for ; Mon, 11 Nov 2013 09:55:19 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=verizonwireless.com; i=@verizonwireless.com; q=dns/txt; s=prodmail; t=1384192519; x=1415728519; h=from:to:cc:date:subject:references:in-reply-to: content-transfer-encoding:mime-version; bh=ymOf50Q8C/YcW/v4Fhyxae0Wzlf/5tJ5eZCvH6FsFzc=; b=KYAU+ySaTm2ueYQaG3n1vRvhvlcw2pkwrNV1POYjAKFLnnZr5JyDPjG2 F8jieAmn9g+OUf6I+5Subsix8pkGpnnEqkcWkglUx8Cld4MKOArp8xnez eElklkiNMSailca5dhMwbVgonelxKBcYsBftjP81GFxf5Y0opg/RaEgQ+ Y=; Received: from ohdub02exhub04.uswin.ad.vzwcorp.com ([10.97.42.166]) by vanguard.verizonwireless.com with ESMTP; 11 Nov 2013 09:55:15 -0800 Received: from OHDUB02EXCV33.uswin.ad.vzwcorp.com ([10.97.42.179]) by OHDUB02EXHUB04.uswin.ad.vzwcorp.com ([10.97.42.166]) with mapi; Mon, 11 Nov 2013 12:55:14 -0500 From: "Bogineni, Kalyani" To: 'Jouni Korhonen' , "dime@ietf.org" Date: Mon, 11 Nov 2013 12:55:14 -0500 Thread-Topic: [Dime] WG adoption call for draft-docdt-dime-ovli-01 Thread-Index: Ac7czAuwbtXBEn3sTUirhNC4t0ZQoACOttXw References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Message-Id: <20131111175519.4C9B911E81B2@ietfa.amsl.com> X-Mailman-Approved-At: Mon, 11 Nov 2013 09:56:31 -0800 Cc: "Bogineni, Kalyani" Subject: Re: [Dime] WG adoption call for draft-docdt-dime-ovli-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 17:55:23 -0000 We support the adoption of draft-docdt-dime-ovli-01 to serve as a basis for= the Diameter overload indication conveyance. Regards, Kalyani Bogineni Verizon -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Jou= ni Korhonen Sent: Friday, November 08, 2013 4:46 PM To: dime@ietf.org Subject: [Dime] WG adoption call for draft-docdt-dime-ovli-01 Folks, This mail starts a two week WG adoption call for draft-docdt-dime-ovli-01 t= o serve as a basis for the Diameter overload indication conveyance. the cal= l ends 22-Nov-2013. Express your support or concerns on the mailing list. - Jouni & Lionel _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From md3135@att.com Mon Nov 11 13:06:35 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F1B011E8103 for ; Mon, 11 Nov 2013 13:06:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.276 X-Spam-Level: X-Spam-Status: No, score=-6.276 tagged_above=-999 required=5 tests=[AWL=0.323, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KIH9zOyjL2Rh for ; Mon, 11 Nov 2013 13:06:29 -0800 (PST) Received: from nbfkord-smmo07.seg.att.com (nbfkord-smmo07.seg.att.com [209.65.160.93]) by ietfa.amsl.com (Postfix) with ESMTP id 5E3D211E80F9 for ; Mon, 11 Nov 2013 13:06:29 -0800 (PST) Received: from unknown [144.160.229.24] (EHLO nbfkord-smmo07.seg.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) with ESMTP id 5d641825.2aaae6e2a940.2069255.00-541.5744816.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 11 Nov 2013 21:06:29 +0000 (UTC) X-MXL-Hash: 528146d524318711-9b31d4aab7d9318ad4622505fb969d5adeff5dbf Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo07.seg.att.com(mxl_mta-6.15.0-1) over TLS secured channel with ESMTP id dc641825.0.2069240.00-263.5744628.nbfkord-smmo07.seg.att.com (envelope-from ); Mon, 11 Nov 2013 21:06:22 +0000 (UTC) X-MXL-Hash: 528146ce5c74142d-e4521cc4064408956bd88bb9f66f88df1d0a6b18 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id rABL6Ld6020220; Mon, 11 Nov 2013 16:06:21 -0500 Received: from mlpi409.sfdc.sbc.com (mlpi409.sfdc.sbc.com [130.9.128.241]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id rABL6EUo020067 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 11 Nov 2013 16:06:16 -0500 Received: from MISOUT7MSGHUB9B.ITServices.sbc.com (MISOUT7MSGHUB9B.itservices.sbc.com [144.151.223.72]) by mlpi409.sfdc.sbc.com (RSA Interceptor); Mon, 11 Nov 2013 21:05:57 GMT Received: from MISOUT7MSGUSR9I.ITServices.sbc.com ([144.151.223.56]) by MISOUT7MSGHUB9B.ITServices.sbc.com ([144.151.223.72]) with mapi id 14.03.0158.001; Mon, 11 Nov 2013 16:05:57 -0500 From: "DOLLY, MARTIN C" To: "Bogineni, Kalyani" , "'Jouni Korhonen'" , "dime@ietf.org" Thread-Topic: [Dime] WG adoption call for draft-docdt-dime-ovli-01 Thread-Index: Ac7czAuwbtXBEn3sTUirhNC4t0ZQoACOttXwAAa2gnA= Date: Mon, 11 Nov 2013 21:05:57 +0000 Message-ID: References: <20131111175519.4C9B911E81B2@ietfa.amsl.com> In-Reply-To: <20131111175519.4C9B911E81B2@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.175.94.53] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-RSA-Inspected: yes X-RSA-Classifications: public X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2010122901)] X-MAIL-FROM: X-SOURCE-IP: [144.160.229.24] X-AnalysisOut: [v=2.0 cv=T8w7uY2Q c=1 sm=0 a=dhB6nF3YHL5t/Ixux6cINA==:17 a] X-AnalysisOut: [=ukffxF_t6NcA:10 a=P4WW_65pI8oA:10 a=ofMgfj31e3cA:10 a=BLc] X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R] X-AnalysisOut: [AAAA:8 a=NXNRMWKahvMA:10 a=48vgC7mUAAAA:8 a=QilCRQw-oStixk] X-AnalysisOut: [2jFBAA:9 a=CjuIK1q_8ugA:10 a=lZB815dzVvQA:10 a=efrpuszYb53] X-AnalysisOut: [tCst7:21 a=VAAYnXxXoBA-vRQc:21] Subject: Re: [Dime] WG adoption call for draft-docdt-dime-ovli-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Nov 2013 21:06:35 -0000 We support adoption.=20 -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Bog= ineni, Kalyani Sent: Monday, November 11, 2013 12:55 PM To: 'Jouni Korhonen'; dime@ietf.org Cc: Bogineni, Kalyani Subject: Re: [Dime] WG adoption call for draft-docdt-dime-ovli-01 We support the adoption of draft-docdt-dime-ovli-01 to serve as a basis for= the Diameter overload indication conveyance. Regards, Kalyani Bogineni Verizon -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Jou= ni Korhonen Sent: Friday, November 08, 2013 4:46 PM To: dime@ietf.org Subject: [Dime] WG adoption call for draft-docdt-dime-ovli-01 Folks, This mail starts a two week WG adoption call for draft-docdt-dime-ovli-01 t= o serve as a basis for the Diameter overload indication conveyance. the cal= l ends 22-Nov-2013. Express your support or concerns on the mailing list. - Jouni & Lionel _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From atle.monrad@ericsson.com Mon Nov 11 18:32:39 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDB3911E80D9 for ; Mon, 11 Nov 2013 18:32:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.337 X-Spam-Level: X-Spam-Status: No, score=-5.337 tagged_above=-999 required=5 tests=[AWL=0.912, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lXdkdKSQUAUG for ; Mon, 11 Nov 2013 18:32:32 -0800 (PST) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id A775821E80FC for ; Mon, 11 Nov 2013 18:32:31 -0800 (PST) X-AuditID: c1b4fb30-b7f228e000003e6c-d9-5281933ed0d3 Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id D3.03.15980.E3391825; Tue, 12 Nov 2013 03:32:30 +0100 (CET) Received: from ESESSMB203.ericsson.se ([169.254.3.135]) by ESESSHC019.ericsson.se ([153.88.183.75]) with mapi id 14.02.0328.009; Tue, 12 Nov 2013 03:32:30 +0100 From: Atle Monrad To: Jouni Korhonen , "dime@ietf.org" Thread-Topic: [Dime] WG adoption call for draft-docdt-dime-ovli-01 Thread-Index: AQHO3Mv950fR/V3nL0a2RERYRDX1Gpog5HDQ Date: Tue, 12 Nov 2013 02:32:29 +0000 Message-ID: <7D2F7D7ADBA812449F25F4A69922881C1E7D28@ESESSMB203.ericsson.se> References: In-Reply-To: Accept-Language: nb-NO, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.149] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLLMWRmVeSWpSXmKPExsUyM+Jvra7d5MYgg0n9qhZze1ewWexf18Dk wOSxc9Zddo8lS34yBTBFcdmkpOZklqUW6dslcGU8e6decJy9omdZH2sD4wy2LkZODgkBE4nn Z/sYIWwxiQv31oPFhQQOMUqsPZ8DYS9hlLg8A6yGTUBH4tzPO6wgtoiAj8SVlRC2sICjxOq5 M5gh4k4SL199ZYOwjSS23v4FFmcRUJVY2HGFHcTmFfCWuH6tnxVivo3EgUtXmEBsTgFbiVW3 T7J0MXJwMArISsxt4gUJMwuIS9x6Mp8J4kwBiSV7zjND2KISLx//Y4WwlSTWHt7OAlGvI7Fg 9yc2CFtbYtnC18wQawUlTs58wjKBUXQWkrGzkLTMQtIyC0nLAkaWVYzsuYmZOenl5psYgVFw cMtvgx2Mm+6LHWKU5mBREuf98NY5SEggPbEkNTs1tSC1KL6oNCe1+BAjEwenVANjzpPv6WUf jz5c7brgJqdrW5PwzTWKwuF+R5mOHS8MfvxPQI/Jf+bBh2kK0iv5TE0XHq9119ubPZ/t7HYD 14a+nNVWtpF9IikbHAx2JNxKvP/237+f1zhsg9gnG7bfaslKb+550BU3z+b7q6eTzljmOH66 8DnGWsx1l/2Kw5vDfe7rrPg1acdUJZbijERDLeai4kQAZ7HDDVACAAA= Subject: Re: [Dime] WG adoption call for draft-docdt-dime-ovli-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 02:32:39 -0000 Jouni, Lionel, all I appreciate that DIME is working hard to fulfill the requirements from 3G= PP on Diameter overload. I support the draft going forward. /atle ________________________________=20 Atle Monrad 3GPP CT Chairman Group Function Technology - Standardization and Technical Regulation=20 Ericsson -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Jou= ni Korhonen Sent: 8. november 2013 13:46 To: dime@ietf.org Subject: [Dime] WG adoption call for draft-docdt-dime-ovli-01 Folks, This mail starts a two week WG adoption call for draft-docdt-dime-ovli-01 t= o serve as a basis for the Diameter overload indication conveyance. the cal= l ends 22-Nov-2013. Express your support or concerns on the mailing list. - Jouni & Lionel _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From jean-jacques.trottin@alcatel-lucent.com Mon Nov 11 19:13:46 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48D4211E81C4 for ; Mon, 11 Nov 2013 19:13:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.542 X-Spam-Level: X-Spam-Status: No, score=-10.542 tagged_above=-999 required=5 tests=[AWL=0.057, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPl7Of03DsIk for ; Mon, 11 Nov 2013 19:13:40 -0800 (PST) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfa.amsl.com (Postfix) with ESMTP id CA72511E81B9 for ; Mon, 11 Nov 2013 19:13:40 -0800 (PST) Received: from fr711usmtp1.zeu.alcatel-lucent.com (h135-239-2-122.lucent.com [135.239.2.122]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id rAC3DZ8s017098 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Mon, 11 Nov 2013 21:13:36 -0600 (CST) Received: from FR712WXCHHUB03.zeu.alcatel-lucent.com (fr712wxchhub03.zeu.alcatel-lucent.com [135.239.2.74]) by fr711usmtp1.zeu.alcatel-lucent.com (GMO) with ESMTP id rAC3DYPV031631 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Tue, 12 Nov 2013 04:13:35 +0100 Received: from FR712WXCHMBA10.zeu.alcatel-lucent.com ([169.254.6.189]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.02.0247.003; Tue, 12 Nov 2013 04:13:35 +0100 From: "TROTTIN, JEAN-JACQUES (JEAN-JACQUES)" To: "'Jouni Korhonen'" , "dime@ietf.org" Thread-Topic: [Dime] WG adoption call for draft-docdt-dime-ovli-01 Thread-Index: AQHO3MwJoRJPzYFkt023E3I7p38qXpogQ/wAgAA1SYCAAHbW0A== Date: Tue, 12 Nov 2013 03:13:33 +0000 Message-ID: References: <20131111175519.4C9B911E81B2@ietfa.amsl.com> In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.239.27.39] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39 Subject: Re: [Dime] WG adoption call for draft-docdt-dime-ovli-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 03:13:46 -0000 Hi.=20 We support the adoption of draft-docdt-dime-ovli-01 to serve as a basis for= the Diameter overload indication conveyance. Jean-Jacques Trottin Alcatel-Lucent -----Original Message----- From: dime-bounces@ietf.org [mailto:dime-bounces@ietf.org] On Behalf Of Jou= ni Korhonen Sent: Friday, November 08, 2013 4:46 PM To: dime@ietf.org Subject: [Dime] WG adoption call for draft-docdt-dime-ovli-01 Folks, This mail starts a two week WG adoption call for draft-docdt-dime-ovli-01 t= o serve as a basis for the Diameter overload indication conveyance. the cal= l ends 22-Nov-2013. Express your support or concerns on the mailing list. - Jouni & Lionel _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime From maria.cruz.bartolome@ericsson.com Mon Nov 11 21:12:48 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1648C21E8108 for ; Mon, 11 Nov 2013 21:12:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.528 X-Spam-Level: X-Spam-Status: No, score=-5.528 tagged_above=-999 required=5 tests=[AWL=0.720, BAYES_00=-2.599, HELO_EQ_SE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wpIjaW9N3Guo for ; Mon, 11 Nov 2013 21:12:43 -0800 (PST) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 6FDA911E81C5 for ; Mon, 11 Nov 2013 21:12:42 -0800 (PST) X-AuditID: c1b4fb25-b7eff8e000000eda-2c-5281b8c7bb9d Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 81.1E.03802.7C8B1825; Tue, 12 Nov 2013 06:12:39 +0100 (CET) Received: from ESESSMB101.ericsson.se ([169.254.1.41]) by ESESSHC018.ericsson.se ([153.88.183.72]) with mapi id 14.02.0328.009; Tue, 12 Nov 2013 06:12:39 +0100 From: Maria Cruz Bartolome To: "dime@ietf.org" Thread-Topic: [Dime] WG adoption call for draft-docdt-dime-ovli-01 Thread-Index: AQHO3vwgJJetid9qjU+XAqNcsJ5p35ohDSoA Date: Tue, 12 Nov 2013 05:12:39 +0000 Message-ID: <087A34937E64E74E848732CFF8354B9209708257@ESESSMB101.ericsson.se> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [153.88.183.148] Content-Type: multipart/alternative; boundary="_000_087A34937E64E74E848732CFF8354B9209708257ESESSMB101erics_" MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrHLMWRmVeSWpSXmKPExsUyM+Jvre7xHY1BBt9X6FjM7V3B5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujC0t3xgLFmtXvHz+hK2B8ZlaFyMnh4SAicTtq01sELaYxIV7 64FsLg4hgUOMEvuWfWGGcBYzSjxaOYsdpIpNwE7i0ukXTF2MHBwiAsoSp385gISFBRwlVs+d wQxiiwg4Sbx89ZUNwjaS+HV1NzNIOYuAqsTDM8EgYV4BX4nXc14wQoxvZJTomLqTBSTBKeAv sXLZHFYQmxHooO+n1jCB2MwC4hK3nsxngjhUQGLJnvPMELaoxMvH/1ghbCWJxiVPWCHq8yUm L7nBDLFMUOLkzCcsExhFZiEZNQtJ2SwkZRBxHYkFuz+xQdjaEssWvmaGsc8ceMyELL6AkX0V I3tuYmZOernRJkZgnBzc8lt1B+OdcyKHGKU5WJTEeT+8dQ4SEkhPLEnNTk0tSC2KLyrNSS0+ xMjEwSnVwLhRrOnclXX9J47sDpQvupf3M2/7w7T0zZtq7/0+/Hztegav1fdfl2wT1l+tdkzh xW/llfPrZuxvN3o4755E49VCz9sGYSuSfA92GFy/tGpKW++Cua5/l2YsOBZ7LCistfR6T/aD C/Z2Zmme61N+y0vuX/vSJvDqmcOXJRKfcWz4XZPF6DXJNbZBiaU4I9FQi7moOBEASe1RDWEC AAA= Subject: Re: [Dime] WG adoption call for draft-docdt-dime-ovli-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 05:12:48 -0000 --_000_087A34937E64E74E848732CFF8354B9209708257ESESSMB101erics_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hello all, We support adoption. Best regards /MCruz -----dime-bounces@ietf.org wrote: ----- To: "dime@ietf.org" From: Jouni Korhonen Sent by: dime-bounces@ietf.org Date: 11/08/2013 04:46PM Subject: [Dime] WG adoption call for draft-docdt-dime-ovli-01 Folks, This mail starts a two week WG adoption call for draft-docdt-dime-ovli-01 to serve as a basis for the Diameter overload indication conveyance. the call ends 22-Nov-2013. Express your support or concerns on the mailing list. - Jouni & Lionel _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime --_000_087A34937E64E74E848732CFF8354B9209708257ESESSMB101erics_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hello all,

 

We support adoption.=

 <= /p>

Best regards

/MCruz<= /p>

 <= /p>


-----dime-bounces@ietf.org wrote: -----

To: &quo= t;dime@ietf.org" <dime@ietf.org>
From: Jouni Korhonen
Sent by: dime-bounces@ietf.org
Date: 11/08/2013 04:46PM
Subject: [Dime] WG adoption call for draft-docdt-dime-ovli-01

Folks,

This mail starts a two week WG adoption call for draft-docdt-dime-ovli-01 to serve as a basis for the Diameter overload indication conveyance. the call ends 22-Nov-2013. Express your support or concerns on the mailing
list.

- Jouni & Lionel




_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org= /mailman/listinfo/dime

--_000_087A34937E64E74E848732CFF8354B9209708257ESESSMB101erics_-- From srdonovan@usdonovans.com Tue Nov 12 14:23:48 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1506D21F9ECA for ; Tue, 12 Nov 2013 14:23:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sUwN1kBSOd3Z for ; Tue, 12 Nov 2013 14:23:43 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [192.249.113.76]) by ietfa.amsl.com (Postfix) with ESMTP id 2092721F9F96 for ; Tue, 12 Nov 2013 14:23:36 -0800 (PST) Received: from [107.17.54.9] (port=59861 helo=SDmac.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1:DHE-RSA-CAMELLIA256-SHA:256) (Exim 4.80) (envelope-from ) id 1VgMMv-0004FV-TR for dime@ietf.org; Tue, 12 Nov 2013 14:23:35 -0800 Message-ID: <5282AA5D.2000903@usdonovans.com> Date: Tue, 12 Nov 2013 14:23:25 -0800 From: Steve Donovan User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: dime@ietf.org References: In-Reply-To: Content-Type: multipart/alternative; boundary="------------080801010705020402070807" X-OutGoing-Spam-Status: No, score=-2.9 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com Subject: Re: [Dime] WG adoption call for draft-docdt-dime-ovli-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Nov 2013 22:23:48 -0000 This is a multi-part message in MIME format. --------------080801010705020402070807 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit All, I support adoption of draft-docdt-dime-ovli. This support is based on the architectural principles outlined in the draft and by Jouni during the DIME working group meeting in Vancouver. Regards, Steve On 11/8/13 1:46 PM, Jouni Korhonen wrote: > Folks, > > This mail starts a two week WG adoption call for draft-docdt-dime-ovli-01 > to serve as a basis for the Diameter overload indication conveyance. the > call ends 22-Nov-2013. Express your support or concerns on the mailing > list. > > - Jouni & Lionel > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > --------------080801010705020402070807 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit All,

I support adoption of draft-docdt-dime-ovli.  This support is based on the architectural principles outlined in the draft and by Jouni during the DIME working group meeting in Vancouver.

Regards,

Steve

On 11/8/13 1:46 PM, Jouni Korhonen wrote:
Folks,

This mail starts a two week WG adoption call for draft-docdt-dime-ovli-01
to serve as a basis for the Diameter overload indication conveyance. the
call ends 22-Nov-2013. Express your support or concerns on the mailing
list.

- Jouni & Lionel




_______________________________________________
DiME mailing list
DiME@ietf.org
https://www.ietf.org/mailman/listinfo/dime


--------------080801010705020402070807-- From ulrich.wiehe@nsn.com Wed Nov 13 07:33:32 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62CE121E8146; Wed, 13 Nov 2013 07:33:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.748 X-Spam-Level: X-Spam-Status: No, score=-5.748 tagged_above=-999 required=5 tests=[AWL=0.251, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id l3rHnMHDSBHi; Wed, 13 Nov 2013 07:33:27 -0800 (PST) Received: from demumfd001.nsn-inter.net (demumfd001.nsn-inter.net [93.183.12.32]) by ietfa.amsl.com (Postfix) with ESMTP id 5A38421E812E; Wed, 13 Nov 2013 07:33:26 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd001.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rADFXN94008601 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 13 Nov 2013 16:33:23 +0100 Received: from DEMUHTC004.nsn-intra.net ([10.159.42.35]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rADFXMTS006713 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 13 Nov 2013 16:33:22 +0100 Received: from DEMUHTC014.nsn-intra.net (10.159.42.45) by DEMUHTC004.nsn-intra.net (10.159.42.35) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 13 Nov 2013 16:33:22 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.198]) by DEMUHTC014.nsn-intra.net ([10.159.42.45]) with mapi id 14.03.0123.003; Wed, 13 Nov 2013 16:33:22 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "ext Nirav Salot (nsalot)" , "doc-dt@ietf.org" , "dime@ietf.org" Thread-Topic: Ongoing Throttling Information in request messages Thread-Index: Ac7aQPqQ1tyE3SNOTC+vVrUogwBrJQAnWH+wAADoRNAABgE0oAAA57DwAACoAlAAASWEQAAAqKUAACDdWeAAAz9GUAABLecQAA4Qc8ABE6PKsA== Date: Wed, 13 Nov 2013 15:33:21 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D90006681519337D@DEMUMBX014.nsn-intra.net> References: <5BCBA1FC2B7F0B4C9D935572D9000668151918EC@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192B2B@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192B90@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192BF7@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192CD2@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192D5F@DEMUMBX014.nsn-intra.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.95] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 21025 X-purgate-ID: 151667::1384356803-00004A43-8884A955/0-0/0-0 Subject: Re: [Dime] Ongoing Throttling Information in request messages X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Nov 2013 15:33:32 -0000 Nirav, in summary it seems that we have two valid options: Option A:=20 A1: the server (or reporting node), while overloaded must insert the load O= C-OLR AVP in every answer message. A2: the server (or reporting node) after leaving the overload state must co= ntinue inserting the OC-OLR AVP (indicating end of throttling request) for = some time (how long needs to be calculated by the server) or the server mus= t rely on expiry of outdated overload reports. A3: the reacting node must/should check the timeStamp in every OC-OLR AVP r= eceived in answer messages in order not to miss an update. Option B: B1: the reacting node, while performing throttling, must insert the OC-Ongo= ing-Throttling-Information in every request message. B2: void (the reacting node , while no longer throttling, simply does not i= nsert OC-Ongoing-Throttling-Information) B3: the reporting node must/should check OC-Ongoing-Throttling-Information = received in a request in order to decide whether or not OC-OLR must be sent= back.=20 Ulrich -----Original Message----- From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]=20 Sent: Thursday, November 07, 2013 5:29 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, Not sure the significance of REQ 10 here but I do not agree to enforce the = server to include overload-report (indicating non-zero or zero overload con= dition) in every message. Even in your example, the overload condition will end sometime - e.g. after= 1000 sec. and then the server can stop including the overload-report. Besides, I am still not convince that "during the overload condition, using= some logic to avoid inclusion of overload-report is less resource consumin= g than simply including the same overload-report". Yes, the reason behind defining timestamp is to allow the reacting node to = discard the overload-report if the same was already received from the repor= ting node. Regards, Nirav. -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Sent: Thursday, November 07, 2013 3:53 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, please see inline. Best regards Ulrich -----Original Message----- From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Thursday, November 07, 2013 10:15 AM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, Please read my responses inline. Regards, Nirav. -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Thursday, November 07, 2013 1:54 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, thank you for the explanation. This may be a solution which adds more comp= lexity to the reporting node: The reporting node must remember the maximum = not yet expired fraction of duration values it sent when leaving the overlo= ad state and must continue reporting "end of overload condition" until expi= ry. (there is no corresponding complexity at the reacting node in my propos= al) [Nirav] This is not always true, e.g. as I had indicated if the node ha= s advertised 10% reduction-percentage for 10 sec., it need not bother to ad= vertise no-overload condition since the validity-period was very small. [Ulrich] Also not always true, e.g. if the reporting node has requested at = 20% reduction for 1000sec at t1 and then at t1 + 10sec sends an update to r= equest a 10% reduction for 10 sec. Although the validity-period is small (1= 0 sec) there may still be a reacting node that did not get the update and k= eeps on throttling by 20% until t1 + 1000sec. Furthermore you seem not to t= ake REQ 10 seriously. My understanding was that timeout is last resort, not= the normal way. Another question: While doing a throttling, what is the expected behaviour = of the reacting node when receiving an answer message without OC-OLR AVP? (= stop/continue throttling?) (there is no corresponding question in my propos= al since not sending of OC-Ongoing-Throttling-Information clearly means tha= t throttling is not in place) [Nirav] The reacting node should continue to = apply the earlier received OC-OLR.=20 " (Note: We seem to have consensus that a server MAY repeat OLRs in subsequent messages, but is not required to do so, based on local policy.)" [Ulrich] This needs to be reconsidered. See the following example: Non supporting client C1 sends a request via supporting agent A1 to Server = S. S returns a 10% throttling request.=20 C sends an new request via supporting agent A2 to S.=20 S decides not to repeat the 10% throttling request (hence A2 is not aware o= f the throttling request).=20 C1 sends a new request via A1.=20 S decides to repeat the throttling request (redundant).=20 Supporting client C2 sends a request via A2 to S. S decides not to repeat.... To avoid this mess we either need to mandate sending OC-OLR in every answer= (while in overload) or let the Server keep track which agent and which cli= ent is updated with the newest info. (or consider my proposal). Another question is for the reacting node: What is the expected behaviour w= hen receiving lots of redundant OC-OLR AVPs in answer messages? The reactin= g node needs to check every single OC-OLR AVP in order to find out whether = it contains an update. Is that the correct understanding? (this seems to be= equivalent to checking for redundant OC-Ongoing-Throttling-Information AVP= s in every request by the reporting node in my proposal) [Nirav] Please ref= er to Timestamp AVP within OC-OLR. The TimeStamp AVP indicates when the original OC-OLR AVP with the current content was created. It is possible to replay the same OC- OLR AVP multiple times between the overload endpoints, however, when the OC-OLR AVP content changes or the other information sending endpoint wants the receiving endpoint to update its overload control information, then the TimeStamp AVP MUST contain a new value. [Ulrich] This does not explicitly say that the reacting node must check eve= ry TimeStamp received within OC-OLR AVPs. But I guess this is the consequen= ce. Can you please confirm. Adding dime-list again. Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 4:58 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, During "no overload condition", why should reporting node include overload-= information in all the answer messages? e.g. if the reporting node has advertised overload-report with period-of-va= lidity=3D10 sec., it knows that after that period all the reacting node wil= l automatically stop applying any overload mitigation action. And hence it = does not need to explicitly send any overload-report indicating "no overloa= d condition". In general, I assume that overload period of would be much shorter as compa= red to "no overload" period. And hence I do not see reason to always includ= e overload-report. Regards, Nirav. From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Wednesday, November 06, 2013 9:12 PM To: Nirav Salot (nsalot); doc-dt@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, "During the overload" yes I agree, but "when no longer in overload" all ans= wer messages would contain the information "no longer in overload" while on= ly few request messages would contain the Ongoing-Throttling-Information. Removing dime-list which bounces. Best regards Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 4:02 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, I might be missing something here so please bear with me. Number of answer messages sent by server =3D number of request messages rec= eived by the server. During the overload, the server would receive only those requests which sur= vived throttling. And then the server would send answer messages to only those request messag= es. So "every" and "some" are actually equal in the below equation. No? Regards, Nirav. From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Wednesday, November 06, 2013 8:24 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, Not quite. The question is: "is sending an overload-report in every answer message that corresponds to = request with OC-Feature-Vector present more resource consuming than receivi= ng Ongoing-Throttling-Information in some request messages (only those that= survived a throttling)?" Best regards Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 3:15 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, Thanks for clarification. Then the question would be "is sending overload-report in every answer message is more resource consum= ing than the solution below - i.e. receiving OC-Ongoing-Throttling-Informat= ion in all request message and analyzing the timestamp and then deciding if= the overload-report should be included or not." I am not sure. Regards, Nirav. From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Wednesday, November 06, 2013 7:08 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, thank you for your comments. The comparism is between: Current way: "send OC specific information (Feature-Vector) in every reques= t message and in every corresponding answer message" My proposal: "send OC specific information (Feature-Vector and in some case= s Ongoing-Throttling-Info) in every request message and in corresponding an= swer messages only when required". Sending OC specific information =A0is regarded a resource consuming action = and we should not put this action to the (overloaded) server where avoidabl= e. See REQ 13. Best regards Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 12:04 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, Thanks for the detail explanation of your proposal. Just to verify my understanding, Your proposal would allow the reporting node to avoid inclusion of the "sam= e" overload-report in the answer message since the request message indicate= s that the path contains at least one reacting node which already has the l= atest overload-report. In other words, the reporting node need not include overload-report in ever= y message, blindly. To achieve the above objective, the solution below suggest the reacting nod= e to include new AVP OC-Ongoing-Throttling-Information in every request mes= sage, which survives throttling. So the net result is that, the inclusion of the overload-report is prevente= d in every answer message since the OC-Ongoing-Throttling-Information is in= cluded in every request message. [Wiehe, Ulrich (NSN - DE/Munich)] no.=A0 .in every request message that sur= vived a throttling. And hence I am not sure if the solution has sound benefit from the inclusio= n of redundant information point of view. In summary, I think the solution suggested below works as explained. But I fail to see the benefit of using this solution compare to a solution = in which the reporting node includes overload-report in every answer messag= e. Regards, Nirav. From: doc-dt-bounces@ietf.org [mailto:doc-dt-bounces@ietf.org] On Behalf Of= Wiehe, Ulrich (NSN - DE/Munich) Sent: Tuesday, November 05, 2013 9:36 PM To: doc-dt@ietf.org; dime@ietf.org Subject: [doc-dt] Ongoing Throttling Information in request messages Hi, draft-docdt-dime-ovli-01 in Appendix B, Table 1, REQ 13 says: =A0=A0=A0=A0=A0=A0=A0 .. Another way =A0=A0=A0=A0=A0=A0=A0 is to let the request sender (reacting node) insert =A0=A0=A0=A0=A0=A0=A0 information in the request to say whether a =A0=A0=A0=A0=A0=A0=A0 throttling is actually performed.=A0 The reporting no= de =A0=A0=A0=A0=A0=A0=A0 then can base its decision on information received in =A0=A0=A0=A0=A0=A0=A0 the request; no need for keeping state to record who =A0 has received overload reports.=A0=20 =A0 And in Appendix B, Table 1, REQ 18: =A0=A0=A0=A0=A0=A0=A0 There has been a proposal to mark =A0=A0=A0=A0=A0=A0=A0 messages that survived overload throttling as one =A0=A0=A0=A0=A0=A0=A0 method for an overloaded node to address fairness but =A0=A0=A0=A0=A0=A0=A0 this proposal is not yet part of the solution.=A0=20 =A0 I would like to come back to this proposal.=20 A new AVP OC-Ongoing-Throttling-Information inserted in request messages wo= uld indicate that the request message survived a throttling. Furthermore, i= nformation within the AVP indicates the TimeStamp as received in the previo= us OC-OLR AVP, according to which the ongoing throttling (which was survive= d) is performed. =A0 OC-Ongoing-Throttling-Information ::=3D < AVP Header: TBD9 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 < TimeStamp > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * [ AVP ] =A0 Supporting Clients would insert the OC-Ongoing-Throttling-Information AVP= =A0 into request messages that survived a throttling performed at that clie= nt. Supporting Agents when receiving a request message that contains an OC-Ongo= ing-Throttling-Information AVP would not perform an additional throttling (= since the client or a downstream agent already performed the throttling) , = while, when receiving a request that does not contain OC-Ongoing-Throttling= -Information AVP would perform throttling (on behalf of the client) accordi= ng to a previously received and stored OC-OLR, and if that throttling is su= rvived the agent would insert the OC-Ongoing-Throttling-Information AVP in = the request before sending it further upstream. Servers (or in general reporting nodes) would check presence and content of= the OC-Ongoing-Throttling-Information AVP in received request messages and= could detect (together with a check of presence of OC-Feature-Vector AVP) = whether inserting an OC-OLR AVP in the corresponding answer message is need= ed in order to update the reacting node with a new OC-OLR). =A0 This proposal especially addresses use cases like the following: =A0 Architecture: =A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +-------= ---------+ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | suppor= ting=A0=A0=A0=A0 | =A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /| agent A1= =A0=A0=A0=A0=A0=A0 |\ =A0 +----------------+ / +----------------+ \ =A0 | non supporting |/=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 \ =A0 | client C=A0=A0=A0=A0=A0=A0 |\=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 \ =A0 +----------------+ \ +----------------+=A0=A0=A0 \ +------------+=A0=A0= =A0 +---------+ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 \| non supp= orting |=A0=A0=A0=A0 \| supporting | =A0=A0 | Server=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 age= nt A2=A0=A0=A0=A0=A0 |------| agent A3=A0=A0 |----|=A0 S=A0=A0=A0=A0=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0 +------------= ----+=A0=A0=A0=A0=A0 +------------+=A0=A0=A0 +---------+ =A0 1. A request is sent from C via A2 and A3 to S. A3 recognizes that there is= no reacting node downstream (no OC-Feature-Vector received) and therefore = takes the role of the reacting node and inserts an OC-Feature-Vector AVP. A= 3 has no valid OLR from S stored and therefore does not perform throttling = and does not insert an OC-Throttling-Information AVP. 2. S recognizes that there is a reacting node downstream which is actually = not performing a throttling. S returns a 10% throttling request (TimeStamp= =3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A3 and= A2 to C. 3. A3 stores the 10% throttling request. 4. A new request is sent from C via A2 and A3 to S. A3 recognizes that ther= e is no reacting node downstream (no OC-Feature-Vector received) and theref= ore takes the role of the reacting node and inserts an OC-Feature-Vector AV= P. A3 has=A0 valid OLR from S stored and performs a 10% throttling. The req= uest survives and A3 inserts an OC-Throttling-Information AVP with timeStam= p=3Dt1. 5. S recognizes that correct throttling (correct time stamp) is in place an= d therefore does not return OC-OLR in the answer. 6. A new request is sent from C via A1 and A3 to S. A1 recognizes that ther= e is no reacting node downstream (no OC-Feature-Vector received) and theref= ore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 h= as no valid OLR from S stored and therefore does not perform throttling and= does not insert an OC-Throttling-Information AVP. A3 recognizes that there= is a reacting node downstream (OC-Feature-Vector received) and therefore d= oes not take the role of the reacting node. 7. S recognizes that there is a reacting node downstream which is actually = not performing a throttling. S returns a 10% throttling request (TimeStamp= =3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A3 and= A1 to C. 8. A1 stores the 10% throttling request. 9. A new request is sent from C via A1 and A3 to S. A1 recognizes that ther= e is no reacting node downstream (no OC-Feature-Vector received) and theref= ore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 h= as=A0 valid OLR from S stored and therefore performs a 10% throttling. The = request survives and A1 inserts an OC-Throttling-Information AVP with timeS= tamp=3Dt1. A3 recognizes that there is a reacting node downstream (OC-Featu= re-Vector received) and therefore does not take the role of the reacting no= de. 10. S recognizes that correct throttling (correct time stamp) is in place a= nd therefore does not return OC-OLR in the answer. 11. Requests sent from C via A1 and A3 to S undergo a 10% throttling at A1,= requests sent from C via A2 and A3 to S undergo a 10% throttling at A3. 12. Overload situation in S for some reason gets worse, S decides to reques= t 20 % reduction. 13. A new request is sent from C via A1 and A3 to S. A1 recognizes that the= re is no reacting node downstream (no OC-Feature-Vector received) and there= fore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 = has=A0 valid OLR from S stored and therefore performs a 10% throttling. The= request survives and A1 inserts an OC-Throttling-Information AVP with time= Stamp=3Dt1. A3 recognizes that there is a reacting node downstream (OC-Feat= ure-Vector received) and therefore does not take the role of the reacting n= ode. 14. S recognizes that incorrect throttling (wrong time stamp) is in place a= nd therefore S returns a 20% throttling request (TimeStamp=3Dt2, duration= =3Dx) within OC-OLR in the answer which goes back via A3 and A1 to C. 15. A3 (not taking the role of the reactingt node)may, A1 must store the 20= % throttling request (replacing the 10% request). 16. A new request is sent from C via A2 and A3 to S. A3 recognizes that the= re is no reacting node downstream (no OC-Feature-Vector received) and there= fore takes the role of the reacting node and inserts an OC-Feature-Vector A= VP. A3 has=A0 valid OLR from S stored and performs a 10% throttling. The re= quest survives and A3 inserts an OC-Throttling-Information AVP with timeSta= mp=3Dt1. (assuming A3 did not store the 20% request at step 14) 17. S recog= nizes that incorrect throttling (wrong time stamp) is in place and therefor= e S returns a 20% throttling request (TimeStamp=3Dt2, duration=3Dx) within = OC-OLR in the answer which goes back via A3 and A2 to C. 18. A3 stores the 20% throttling request (replacing the 10% request). 19. Requests sent from C via A1 and A3 to S undergo a 20% throttling at A1,= requests sent from C via A2 and A3 to S undergo a 20% throttling at A3. =A0 =A0 Comments are welcome. =A0 Best regards Ulrich =A0 =A0 From nsalot@cisco.com Thu Nov 14 06:53:49 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B258311E812F; Thu, 14 Nov 2013 06:53:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.215 X-Spam-Level: X-Spam-Status: No, score=-10.215 tagged_above=-999 required=5 tests=[AWL=-0.216, BAYES_00=-2.599, J_CHICKENPOX_43=0.6, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vQcxaWiqDlaF; Thu, 14 Nov 2013 06:53:43 -0800 (PST) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 8029C11E8132; Thu, 14 Nov 2013 06:53:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21735; q=dns/txt; s=iport; t=1384440823; x=1385650423; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=DGYyyTa6vb9Q2gJUVAU5V/kBUVgqyuK+oAVm9bbDz4k=; b=dEFx+JEt3XkgapSW4khVURu+cz8IV9RnxFHMdHLYH7hy6fgaedsO1bRi 4CgTU13raZRfHqt0Wfud6KqogV1F4i4Anw4iIylwsLV0Bq7KD2AeDCe4z xiVqoIMVg+ms+QO0nLQoc5LB242ZnTaskdRSy5j9v6LdxOZKw98WlZGxz M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ag0FACbjhFKtJV2Z/2dsb2JhbABagweBC78hgR8WdIIlAQEBBIEFBAIBCBEBAwEBCw8CDAcyFAMGCAIEARIIE4dmwB6PLjgGGgeCeYERA4kKiySONoc4gyiBTBwCBRki X-IronPort-AV: E=Sophos;i="4.93,700,1378857600"; d="scan'208";a="284581111" Received: from rcdn-core-2.cisco.com ([173.37.93.153]) by rcdn-iport-1.cisco.com with ESMTP; 14 Nov 2013 14:53:41 +0000 Received: from xhc-rcd-x07.cisco.com (xhc-rcd-x07.cisco.com [173.37.183.81]) by rcdn-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rAEErXGm028856 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 14 Nov 2013 14:53:41 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.47]) by xhc-rcd-x07.cisco.com ([173.37.183.81]) with mapi id 14.03.0123.003; Thu, 14 Nov 2013 08:53:33 -0600 From: "Nirav Salot (nsalot)" To: "Wiehe, Ulrich (NSN - DE/Munich)" , "doc-dt@ietf.org" , "dime@ietf.org" Thread-Topic: Ongoing Throttling Information in request messages Thread-Index: Ac7aQPqQ1tyE3SNOTC+vVrUogwBrJQAnWH+wAADoRNAABgE0oAAA57DwAACoAlAAASWEQAAAqKUAACDdWeAAAz9GUAABLecQAA4Qc8ABE6PKsABJVfJQ Date: Thu, 14 Nov 2013 14:53:32 +0000 Message-ID: References: <5BCBA1FC2B7F0B4C9D935572D9000668151918EC@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192B2B@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192B90@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192BF7@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192CD2@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192D5F@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519337D@DEMUMBX014.nsn-intra.net> In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D90006681519337D@DEMUMBX014.nsn-intra.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.21.67.169] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [Dime] Ongoing Throttling Information in request messages X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Nov 2013 14:53:49 -0000 Ulrich, I confirm the summary below of having two valid options. Just wanted to highlight one aspect, in general. Current definition of the OC-OLR AVP suggest the inclusion of TimeStamp and= ValidityDuration AVPs. And these AVPs are applicable/valid/needed in both = the options below. Additionally, if we decide to go for option B, we would need to define new = AVP OC-Ongoing-Throttling-Information AVP. Regards, Nirav. -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Sent: Wednesday, November 13, 2013 9:03 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, in summary it seems that we have two valid options: Option A:=20 A1: the server (or reporting node), while overloaded must insert the load O= C-OLR AVP in every answer message. A2: the server (or reporting node) after leaving the overload state must co= ntinue inserting the OC-OLR AVP (indicating end of throttling request) for = some time (how long needs to be calculated by the server) or the server mus= t rely on expiry of outdated overload reports. A3: the reacting node must/should check the timeStamp in every OC-OLR AVP r= eceived in answer messages in order not to miss an update. Option B: B1: the reacting node, while performing throttling, must insert the OC-Ongo= ing-Throttling-Information in every request message. B2: void (the reacting node , while no longer throttling, simply does not i= nsert OC-Ongoing-Throttling-Information) B3: the reporting node must/should check OC-Ongoing-Throttling-Information = received in a request in order to decide whether or not OC-OLR must be sent= back.=20 Ulrich -----Original Message----- From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]=20 Sent: Thursday, November 07, 2013 5:29 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, Not sure the significance of REQ 10 here but I do not agree to enforce the = server to include overload-report (indicating non-zero or zero overload con= dition) in every message. Even in your example, the overload condition will end sometime - e.g. after= 1000 sec. and then the server can stop including the overload-report. Besides, I am still not convince that "during the overload condition, using= some logic to avoid inclusion of overload-report is less resource consumin= g than simply including the same overload-report". Yes, the reason behind defining timestamp is to allow the reacting node to = discard the overload-report if the same was already received from the repor= ting node. Regards, Nirav. -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Sent: Thursday, November 07, 2013 3:53 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, please see inline. Best regards Ulrich -----Original Message----- From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Thursday, November 07, 2013 10:15 AM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, Please read my responses inline. Regards, Nirav. -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Thursday, November 07, 2013 1:54 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, thank you for the explanation. This may be a solution which adds more comp= lexity to the reporting node: The reporting node must remember the maximum = not yet expired fraction of duration values it sent when leaving the overlo= ad state and must continue reporting "end of overload condition" until expi= ry. (there is no corresponding complexity at the reacting node in my propos= al) [Nirav] This is not always true, e.g. as I had indicated if the node ha= s advertised 10% reduction-percentage for 10 sec., it need not bother to ad= vertise no-overload condition since the validity-period was very small. [Ulrich] Also not always true, e.g. if the reporting node has requested at = 20% reduction for 1000sec at t1 and then at t1 + 10sec sends an update to r= equest a 10% reduction for 10 sec. Although the validity-period is small (1= 0 sec) there may still be a reacting node that did not get the update and k= eeps on throttling by 20% until t1 + 1000sec. Furthermore you seem not to t= ake REQ 10 seriously. My understanding was that timeout is last resort, not= the normal way. Another question: While doing a throttling, what is the expected behaviour = of the reacting node when receiving an answer message without OC-OLR AVP? (= stop/continue throttling?) (there is no corresponding question in my propos= al since not sending of OC-Ongoing-Throttling-Information clearly means tha= t throttling is not in place) [Nirav] The reacting node should continue to = apply the earlier received OC-OLR.=20 " (Note: We seem to have consensus that a server MAY repeat OLRs in subsequent messages, but is not required to do so, based on local policy.)" [Ulrich] This needs to be reconsidered. See the following example: Non supporting client C1 sends a request via supporting agent A1 to Server = S. S returns a 10% throttling request.=20 C sends an new request via supporting agent A2 to S.=20 S decides not to repeat the 10% throttling request (hence A2 is not aware o= f the throttling request).=20 C1 sends a new request via A1.=20 S decides to repeat the throttling request (redundant).=20 Supporting client C2 sends a request via A2 to S. S decides not to repeat.... To avoid this mess we either need to mandate sending OC-OLR in every answer= (while in overload) or let the Server keep track which agent and which cli= ent is updated with the newest info. (or consider my proposal). Another question is for the reacting node: What is the expected behaviour w= hen receiving lots of redundant OC-OLR AVPs in answer messages? The reactin= g node needs to check every single OC-OLR AVP in order to find out whether = it contains an update. Is that the correct understanding? (this seems to be= equivalent to checking for redundant OC-Ongoing-Throttling-Information AVP= s in every request by the reporting node in my proposal) [Nirav] Please ref= er to Timestamp AVP within OC-OLR. The TimeStamp AVP indicates when the original OC-OLR AVP with the current content was created. It is possible to replay the same OC- OLR AVP multiple times between the overload endpoints, however, when the OC-OLR AVP content changes or the other information sending endpoint wants the receiving endpoint to update its overload control information, then the TimeStamp AVP MUST contain a new value. [Ulrich] This does not explicitly say that the reacting node must check eve= ry TimeStamp received within OC-OLR AVPs. But I guess this is the consequen= ce. Can you please confirm. Adding dime-list again. Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 4:58 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, During "no overload condition", why should reporting node include overload-= information in all the answer messages? e.g. if the reporting node has advertised overload-report with period-of-va= lidity=3D10 sec., it knows that after that period all the reacting node wil= l automatically stop applying any overload mitigation action. And hence it = does not need to explicitly send any overload-report indicating "no overloa= d condition". In general, I assume that overload period of would be much shorter as compa= red to "no overload" period. And hence I do not see reason to always includ= e overload-report. Regards, Nirav. From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Wednesday, November 06, 2013 9:12 PM To: Nirav Salot (nsalot); doc-dt@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, "During the overload" yes I agree, but "when no longer in overload" all ans= wer messages would contain the information "no longer in overload" while on= ly few request messages would contain the Ongoing-Throttling-Information. Removing dime-list which bounces. Best regards Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 4:02 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, I might be missing something here so please bear with me. Number of answer messages sent by server =3D number of request messages rec= eived by the server. During the overload, the server would receive only those requests which sur= vived throttling. And then the server would send answer messages to only those request messag= es. So "every" and "some" are actually equal in the below equation. No? Regards, Nirav. From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Wednesday, November 06, 2013 8:24 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, Not quite. The question is: "is sending an overload-report in every answer message that corresponds to = request with OC-Feature-Vector present more resource consuming than receivi= ng Ongoing-Throttling-Information in some request messages (only those that= survived a throttling)?" Best regards Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 3:15 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, Thanks for clarification. Then the question would be "is sending overload-report in every answer message is more resource consum= ing than the solution below - i.e. receiving OC-Ongoing-Throttling-Informat= ion in all request message and analyzing the timestamp and then deciding if= the overload-report should be included or not." I am not sure. Regards, Nirav. From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Wednesday, November 06, 2013 7:08 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, thank you for your comments. The comparism is between: Current way: "send OC specific information (Feature-Vector) in every reques= t message and in every corresponding answer message" My proposal: "send OC specific information (Feature-Vector and in some case= s Ongoing-Throttling-Info) in every request message and in corresponding an= swer messages only when required". Sending OC specific information =A0is regarded a resource consuming action = and we should not put this action to the (overloaded) server where avoidabl= e. See REQ 13. Best regards Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 12:04 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, Thanks for the detail explanation of your proposal. Just to verify my understanding, Your proposal would allow the reporting node to avoid inclusion of the "sam= e" overload-report in the answer message since the request message indicate= s that the path contains at least one reacting node which already has the l= atest overload-report. In other words, the reporting node need not include overload-report in ever= y message, blindly. To achieve the above objective, the solution below suggest the reacting nod= e to include new AVP OC-Ongoing-Throttling-Information in every request mes= sage, which survives throttling. So the net result is that, the inclusion of the overload-report is prevente= d in every answer message since the OC-Ongoing-Throttling-Information is in= cluded in every request message. [Wiehe, Ulrich (NSN - DE/Munich)] no.=A0 .in every request message that sur= vived a throttling. And hence I am not sure if the solution has sound benefit from the inclusio= n of redundant information point of view. In summary, I think the solution suggested below works as explained. But I fail to see the benefit of using this solution compare to a solution = in which the reporting node includes overload-report in every answer messag= e. Regards, Nirav. From: doc-dt-bounces@ietf.org [mailto:doc-dt-bounces@ietf.org] On Behalf Of= Wiehe, Ulrich (NSN - DE/Munich) Sent: Tuesday, November 05, 2013 9:36 PM To: doc-dt@ietf.org; dime@ietf.org Subject: [doc-dt] Ongoing Throttling Information in request messages Hi, draft-docdt-dime-ovli-01 in Appendix B, Table 1, REQ 13 says: =A0=A0=A0=A0=A0=A0=A0 .. Another way =A0=A0=A0=A0=A0=A0=A0 is to let the request sender (reacting node) insert =A0=A0=A0=A0=A0=A0=A0 information in the request to say whether a =A0=A0=A0=A0=A0=A0=A0 throttling is actually performed.=A0 The reporting no= de =A0=A0=A0=A0=A0=A0=A0 then can base its decision on information received in =A0=A0=A0=A0=A0=A0=A0 the request; no need for keeping state to record who =A0 has received overload reports.=A0=20 =A0 And in Appendix B, Table 1, REQ 18: =A0=A0=A0=A0=A0=A0=A0 There has been a proposal to mark =A0=A0=A0=A0=A0=A0=A0 messages that survived overload throttling as one =A0=A0=A0=A0=A0=A0=A0 method for an overloaded node to address fairness but =A0=A0=A0=A0=A0=A0=A0 this proposal is not yet part of the solution.=A0=20 =A0 I would like to come back to this proposal.=20 A new AVP OC-Ongoing-Throttling-Information inserted in request messages wo= uld indicate that the request message survived a throttling. Furthermore, i= nformation within the AVP indicates the TimeStamp as received in the previo= us OC-OLR AVP, according to which the ongoing throttling (which was survive= d) is performed. =A0 OC-Ongoing-Throttling-Information ::=3D < AVP Header: TBD9 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 < TimeStamp > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * [ AVP ] =A0 Supporting Clients would insert the OC-Ongoing-Throttling-Information AVP= =A0 into request messages that survived a throttling performed at that clie= nt. Supporting Agents when receiving a request message that contains an OC-Ongo= ing-Throttling-Information AVP would not perform an additional throttling (= since the client or a downstream agent already performed the throttling) , = while, when receiving a request that does not contain OC-Ongoing-Throttling= -Information AVP would perform throttling (on behalf of the client) accordi= ng to a previously received and stored OC-OLR, and if that throttling is su= rvived the agent would insert the OC-Ongoing-Throttling-Information AVP in = the request before sending it further upstream. Servers (or in general reporting nodes) would check presence and content of= the OC-Ongoing-Throttling-Information AVP in received request messages and= could detect (together with a check of presence of OC-Feature-Vector AVP) = whether inserting an OC-OLR AVP in the corresponding answer message is need= ed in order to update the reacting node with a new OC-OLR). =A0 This proposal especially addresses use cases like the following: =A0 Architecture: =A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +-------= ---------+ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | suppor= ting=A0=A0=A0=A0 | =A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /| agent A1= =A0=A0=A0=A0=A0=A0 |\ =A0 +----------------+ / +----------------+ \ =A0 | non supporting |/=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 \ =A0 | client C=A0=A0=A0=A0=A0=A0 |\=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 \ =A0 +----------------+ \ +----------------+=A0=A0=A0 \ +------------+=A0=A0= =A0 +---------+ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 \| non supp= orting |=A0=A0=A0=A0 \| supporting | =A0=A0 | Server=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 age= nt A2=A0=A0=A0=A0=A0 |------| agent A3=A0=A0 |----|=A0 S=A0=A0=A0=A0=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0 +------------= ----+=A0=A0=A0=A0=A0 +------------+=A0=A0=A0 +---------+ =A0 1. A request is sent from C via A2 and A3 to S. A3 recognizes that there is= no reacting node downstream (no OC-Feature-Vector received) and therefore = takes the role of the reacting node and inserts an OC-Feature-Vector AVP. A= 3 has no valid OLR from S stored and therefore does not perform throttling = and does not insert an OC-Throttling-Information AVP. 2. S recognizes that there is a reacting node downstream which is actually = not performing a throttling. S returns a 10% throttling request (TimeStamp= =3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A3 and= A2 to C. 3. A3 stores the 10% throttling request. 4. A new request is sent from C via A2 and A3 to S. A3 recognizes that ther= e is no reacting node downstream (no OC-Feature-Vector received) and theref= ore takes the role of the reacting node and inserts an OC-Feature-Vector AV= P. A3 has=A0 valid OLR from S stored and performs a 10% throttling. The req= uest survives and A3 inserts an OC-Throttling-Information AVP with timeStam= p=3Dt1. 5. S recognizes that correct throttling (correct time stamp) is in place an= d therefore does not return OC-OLR in the answer. 6. A new request is sent from C via A1 and A3 to S. A1 recognizes that ther= e is no reacting node downstream (no OC-Feature-Vector received) and theref= ore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 h= as no valid OLR from S stored and therefore does not perform throttling and= does not insert an OC-Throttling-Information AVP. A3 recognizes that there= is a reacting node downstream (OC-Feature-Vector received) and therefore d= oes not take the role of the reacting node. 7. S recognizes that there is a reacting node downstream which is actually = not performing a throttling. S returns a 10% throttling request (TimeStamp= =3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A3 and= A1 to C. 8. A1 stores the 10% throttling request. 9. A new request is sent from C via A1 and A3 to S. A1 recognizes that ther= e is no reacting node downstream (no OC-Feature-Vector received) and theref= ore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 h= as=A0 valid OLR from S stored and therefore performs a 10% throttling. The = request survives and A1 inserts an OC-Throttling-Information AVP with timeS= tamp=3Dt1. A3 recognizes that there is a reacting node downstream (OC-Featu= re-Vector received) and therefore does not take the role of the reacting no= de. 10. S recognizes that correct throttling (correct time stamp) is in place a= nd therefore does not return OC-OLR in the answer. 11. Requests sent from C via A1 and A3 to S undergo a 10% throttling at A1,= requests sent from C via A2 and A3 to S undergo a 10% throttling at A3. 12. Overload situation in S for some reason gets worse, S decides to reques= t 20 % reduction. 13. A new request is sent from C via A1 and A3 to S. A1 recognizes that the= re is no reacting node downstream (no OC-Feature-Vector received) and there= fore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 = has=A0 valid OLR from S stored and therefore performs a 10% throttling. The= request survives and A1 inserts an OC-Throttling-Information AVP with time= Stamp=3Dt1. A3 recognizes that there is a reacting node downstream (OC-Feat= ure-Vector received) and therefore does not take the role of the reacting n= ode. 14. S recognizes that incorrect throttling (wrong time stamp) is in place a= nd therefore S returns a 20% throttling request (TimeStamp=3Dt2, duration= =3Dx) within OC-OLR in the answer which goes back via A3 and A1 to C. 15. A3 (not taking the role of the reactingt node)may, A1 must store the 20= % throttling request (replacing the 10% request). 16. A new request is sent from C via A2 and A3 to S. A3 recognizes that the= re is no reacting node downstream (no OC-Feature-Vector received) and there= fore takes the role of the reacting node and inserts an OC-Feature-Vector A= VP. A3 has=A0 valid OLR from S stored and performs a 10% throttling. The re= quest survives and A3 inserts an OC-Throttling-Information AVP with timeSta= mp=3Dt1. (assuming A3 did not store the 20% request at step 14) 17. S recog= nizes that incorrect throttling (wrong time stamp) is in place and therefor= e S returns a 20% throttling request (TimeStamp=3Dt2, duration=3Dx) within = OC-OLR in the answer which goes back via A3 and A2 to C. 18. A3 stores the 20% throttling request (replacing the 10% request). 19. Requests sent from C via A1 and A3 to S undergo a 20% throttling at A1,= requests sent from C via A2 and A3 to S undergo a 20% throttling at A3. =A0 =A0 Comments are welcome. =A0 Best regards Ulrich =A0 =A0 From wwwrun@rfc-editor.org Mon Nov 18 11:40:26 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F4E71AE16C for ; Mon, 18 Nov 2013 11:40:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hoZXtizPEhbj for ; Mon, 18 Nov 2013 11:40:24 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:126c::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id AD8AE1AE16B for ; Mon, 18 Nov 2013 11:40:24 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 7DEF375E015; Mon, 18 Nov 2013 11:30:07 -0800 (PST) To: vf0213@gmail.com, jari.arkko@ericsson.com, john.loughney@nokia.com, glenzorn@gmail.com, bclaise@cisco.com, joelja@bogus.com, jouni.nospam@gmail.com, lionel.morand@orange.com From: RFC Errata System Message-Id: <20131118193007.7DEF375E015@rfc-editor.org> Date: Mon, 18 Nov 2013 11:30:07 -0800 (PST) X-Mailman-Approved-At: Mon, 18 Nov 2013 11:42:43 -0800 Cc: rfc-editor@rfc-editor.org, dime@ietf.org Subject: [Dime] [Technical Errata Reported] RFC6733 (3805) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 19:40:26 -0000 The following errata report has been submitted for RFC6733, "Diameter Base Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6733&eid=3805 -------------------------------------- Type: Technical Reported by: Lionel Section: 3 Original Text ------------- Message Length The Message Length field is three octets and indicates the length of the Diameter message including the header fields and the padded AVPs. Thus, the Message Length field is always a multiple of 4. Corrected Text -------------- Message Length The Message Length field is three octets and indicates the number of octets of the Diameter message, including the header fields and the padded AVPs. Thus, the Message Length field is always a multiple of 4 octets. Notes ----- the actual text does not indicate the unit of length unit, which may lead to confusion and IOT issues, especially if someone considers bits instead of bytes. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6733 (draft-ietf-dime-rfc3588bis-33) -------------------------------------- Title : Diameter Base Protocol Publication Date : October 2012 Author(s) : V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed. Category : PROPOSED STANDARD Source : Diameter Maintenance and Extensions Area : Operations and Management Stream : IETF Verifying Party : IESG From ben@nostrum.com Mon Nov 18 12:37:35 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7DC431AE3F3 for ; Mon, 18 Nov 2013 12:37:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4I_0GN-2-EWX for ; Mon, 18 Nov 2013 12:37:34 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 7F8F11AE3E7 for ; Mon, 18 Nov 2013 12:37:34 -0800 (PST) Received: from [172.20.10.7] (mobile-166-147-068-167.mycingular.net [166.147.68.167]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rAIKbG41084744 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Mon, 18 Nov 2013 14:37:23 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ben Campbell In-Reply-To: Date: Mon, 18 Nov 2013 14:37:12 -0600 Content-Transfer-Encoding: 7bit Message-Id: References: To: Jouni Korhonen X-Mailer: Apple Mail (2.1822) Received-SPF: pass (shaman.nostrum.com: 166.147.68.167 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" Subject: Re: [Dime] WG adoption call for draft-docdt-dime-ovli-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 20:37:35 -0000 I support adoption. On Nov 8, 2013, at 3:46 PM, Jouni Korhonen wrote: > Folks, > > This mail starts a two week WG adoption call for draft-docdt-dime-ovli-01 > to serve as a basis for the Diameter overload indication conveyance. the > call ends 22-Nov-2013. Express your support or concerns on the mailing > list. > > - Jouni & Lionel > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From lionel.morand@orange.com Mon Nov 18 13:01:13 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 983A91AE47D for ; Mon, 18 Nov 2013 13:01:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.801 X-Spam-Level: X-Spam-Status: No, score=0.801 tagged_above=-999 required=5 tests=[BAYES_50=0.8, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wKtNDGUeXILG for ; Mon, 18 Nov 2013 13:01:11 -0800 (PST) Received: from relais-inet.francetelecom.com (relais-ias244.francetelecom.com [80.12.204.244]) by ietfa.amsl.com (Postfix) with ESMTP id 54CDE1AE3AC for ; Mon, 18 Nov 2013 13:01:10 -0800 (PST) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 431522AC4A5 for ; Mon, 18 Nov 2013 22:01:04 +0100 (CET) Received: from Exchangemail-eme1.itn.ftgroup (unknown [10.114.1.186]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id 2D8D3C805D for ; Mon, 18 Nov 2013 22:01:01 +0100 (CET) Received: from PEXCVZYM13.corporate.adroot.infra.ftgroup ([fe80::cc7e:e40b:42ef:164e]) by PEXCVZYH01.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0158.001; Mon, 18 Nov 2013 22:01:00 +0100 From: To: "dime@ietf.org" Thread-Topic: [Dime] WG adoption call for draft-docdt-dime-ovli-01 Thread-Index: AQHO3Mv9Jb+mY2fY6EWXOV/LFhpdjZorcY8AgAAXN1A= Date: Mon, 18 Nov 2013 21:01:00 +0000 Message-ID: <22322_1384808461_528A800D_22322_108_1_6B7134B31289DC4FAF731D844122B36E2F27B6@PEXCVZYM13.corporate.adroot.infra.ftgroup> References: In-Reply-To: Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.197.38.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.0.3.2322014, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2013.11.17.40914 Subject: Re: [Dime] WG adoption call for draft-docdt-dime-ovli-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 21:01:13 -0000 As individual, I support the adoption of this draft as WG document. Lionel -----Message d'origine----- De=A0: DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell Envoy=E9=A0: lundi 18 novembre 2013 21:37 =C0=A0: Jouni Korhonen Cc=A0: dime@ietf.org Objet=A0: Re: [Dime] WG adoption call for draft-docdt-dime-ovli-01 I support adoption. On Nov 8, 2013, at 3:46 PM, Jouni Korhonen wrote: > Folks, >=20 > This mail starts a two week WG adoption call for draft-docdt-dime-ovli-01 > to serve as a basis for the Diameter overload indication conveyance. the > call ends 22-Nov-2013. Express your support or concerns on the mailing > list. >=20 > - Jouni & Lionel >=20 >=20 >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime _______________________________________________ DiME mailing list DiME@ietf.org https://www.ietf.org/mailman/listinfo/dime ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you. From wwwrun@rfc-editor.org Mon Nov 18 11:52:22 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A53C21AE235 for ; Mon, 18 Nov 2013 11:52:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MxSMgivxiRnN for ; Mon, 18 Nov 2013 11:52:21 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:126c::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 237431AE234 for ; Mon, 18 Nov 2013 11:52:21 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id E6B4E75E016; Mon, 18 Nov 2013 11:42:03 -0800 (PST) To: vf0213@gmail.com, jari.arkko@ericsson.com, john.loughney@nokia.com, glenzorn@gmail.com, bclaise@cisco.com, joelja@bogus.com, jouni.nospam@gmail.com, lionel.morand@orange.com From: RFC Errata System Message-Id: <20131118194203.E6B4E75E016@rfc-editor.org> Date: Mon, 18 Nov 2013 11:42:03 -0800 (PST) X-Mailman-Approved-At: Tue, 19 Nov 2013 02:23:34 -0800 Cc: rfc-editor@rfc-editor.org, dime@ietf.org Subject: [Dime] [Technical Errata Reported] RFC6733 (3806) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Nov 2013 19:52:22 -0000 The following errata report has been submitted for RFC6733, "Diameter Base Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6733&eid=3806 -------------------------------------- Type: Technical Reported by: Lionel Section: 2.7 Original Text ------------- Server Identifier The identity of one or more servers to which the message is to be routed. This identity MUST also be present in the Host Identity field of the peer table (Section 2.6). When the Local Action is set to RELAY or PROXY, this field contains the identity of the server(s) to which the message MUST be routed. When the Local Action field is set to REDIRECT, this field contains the identity of one or more servers to which the message MUST be redirected. Corrected Text -------------- Peer Identifier The identity of one or more peers to which the message is to be routed. This identity MUST also be present in the Host Identity field of the peer table (Section 2.6). When the Local Action is set to RELAY or PROXY, this field contains the identity of the peer(s) to which the message MUST be routed. When the Local Action field is set to REDIRECT, this field contains the identity of one or more peers to which the message MUST be redirected. Notes ----- The host identified in a Routing Table entry is not necessarily a "server". It can also be a Relay, a redirect or a proxy agent. Using "peer" instead of "server" is more appropriate. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6733 (draft-ietf-dime-rfc3588bis-33) -------------------------------------- Title : Diameter Base Protocol Publication Date : October 2012 Author(s) : V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed. Category : PROPOSED STANDARD Source : Diameter Maintenance and Extensions Area : Operations and Management Stream : IETF Verifying Party : IESG From jouni.nospam@gmail.com Tue Nov 19 02:31:43 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0221B1ADBE8 for ; Tue, 19 Nov 2013 02:31:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XS2cn3jbWeWH for ; Tue, 19 Nov 2013 02:31:41 -0800 (PST) Received: from mail-wi0-x22e.google.com (mail-wi0-x22e.google.com [IPv6:2a00:1450:400c:c05::22e]) by ietfa.amsl.com (Postfix) with ESMTP id D05231ADDBD for ; Tue, 19 Nov 2013 02:31:40 -0800 (PST) Received: by mail-wi0-f174.google.com with SMTP id fb10so1210107wid.1 for ; Tue, 19 Nov 2013 02:31:34 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LdInMBlbFEOrnuMKJU/pbkgbEd8KVtmuAbyi/b/n5fU=; b=0ZKVJLXNoNXzBeaSqVBjOxXBWfO3Dnd+Qub40w+ibGihheFrFvbDoXgOIe0O7eC2J0 gho1HXGKluliy0mQCMk+lvh42p93WmgWKugmUyVX8Bm4zAMBffq2hRwWEqnIiElzcIeq rf2YZMLLS2+nz+9ddMWxhuuz+MrVYbI/bX7alpEle5ZyzusjLgVUyd3oU8AeJm7SDYCR oEboIETrEj1Jv2Tn6F/NgUHCs3/WsbeHnYrWI1MQ7l1/ukabKuLZA3qgfplpBdj5o5ek pWKUPPt3iVIgDY7JKF2wtpJ3z9Bw+yPu3jFKGP/yrbYAbVvZLw+6CUVRV7H68tHA26Ja ANyw== X-Received: by 10.180.221.38 with SMTP id qb6mr20211236wic.8.1384857094466; Tue, 19 Nov 2013 02:31:34 -0800 (PST) Received: from [10.216.14.104] ([93.158.44.59]) by mx.google.com with ESMTPSA id ey4sm33105934wic.11.2013.11.19.02.31.30 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Nov 2013 02:31:30 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <20131118194203.E6B4E75E016@rfc-editor.org> Date: Tue, 19 Nov 2013 12:31:39 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131118194203.E6B4E75E016@rfc-editor.org> To: RFC Errata System X-Mailer: Apple Mail (2.1510) Cc: jari.arkko@ericsson.com, joelja@bogus.com, dime@ietf.org Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (3806) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 10:31:43 -0000 I think this is OK clarification. - Jouni On Nov 18, 2013, at 9:42 PM, RFC Errata System = wrote: > The following errata report has been submitted for RFC6733, > "Diameter Base Protocol". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D6733&eid=3D3806 >=20 > -------------------------------------- > Type: Technical > Reported by: Lionel >=20 > Section: 2.7 >=20 > Original Text > ------------- > Server Identifier >=20 > The identity of one or more servers to which the message is to be > routed. This identity MUST also be present in the Host Identity > field of the peer table (Section 2.6). When the Local Action is > set to RELAY or PROXY, this field contains the identity of the > server(s) to which the message MUST be routed. When the Local > Action field is set to REDIRECT, this field contains the identity > of one or more servers to which the message MUST be redirected. >=20 >=20 > Corrected Text > -------------- > Peer Identifier >=20 > The identity of one or more peers to which the message is to be > routed. This identity MUST also be present in the Host Identity > field of the peer table (Section 2.6). When the Local Action is > set to RELAY or PROXY, this field contains the identity of the > peer(s) to which the message MUST be routed. When the Local > Action field is set to REDIRECT, this field contains the identity > of one or more peers to which the message MUST be redirected. >=20 >=20 > Notes > ----- > The host identified in a Routing Table entry is not necessarily a = "server". It can also be a Relay, a redirect or a proxy agent. Using = "peer" instead of "server" is more appropriate. >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary.=20 >=20 > -------------------------------------- > RFC6733 (draft-ietf-dime-rfc3588bis-33) > -------------------------------------- > Title : Diameter Base Protocol > Publication Date : October 2012 > Author(s) : V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, = Ed. > Category : PROPOSED STANDARD > Source : Diameter Maintenance and Extensions > Area : Operations and Management > Stream : IETF > Verifying Party : IESG From john.loughney@nokia.com Tue Nov 19 09:02:29 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A483B1AE0E0 for ; Tue, 19 Nov 2013 09:02:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.726 X-Spam-Level: X-Spam-Status: No, score=-4.726 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3qY4vp9WpaK6 for ; Tue, 19 Nov 2013 09:02:27 -0800 (PST) Received: from mgw-da01.nokia.com (smtp.nokia.com [147.243.128.24]) by ietfa.amsl.com (Postfix) with ESMTP id 3BC781ACC8B for ; Tue, 19 Nov 2013 09:02:27 -0800 (PST) Received: from smtp.mgd.nokia.com ([65.54.30.23]) by mgw-da01.nokia.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id rAJH17cM011704 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=OK); Tue, 19 Nov 2013 19:01:08 +0200 Received: from 008-AM1MPN1-017.mgdnok.nokia.com ([169.254.7.117]) by 008-AM1MMR1-007.mgdnok.nokia.com ([65.54.30.23]) with mapi id 14.03.0136.001; Tue, 19 Nov 2013 17:01:06 +0000 From: To: , Thread-Topic: [Technical Errata Reported] RFC6733 (3806) Thread-Index: AQHO5JexmmL7KctcOUuSkjZ8/VsLaJosW+CAgABsqhA= Date: Tue, 19 Nov 2013 17:01:05 +0000 Message-ID: <2129067463716F46AC77A22602E5CB5C027EF00E@008-AM1MPN1-017.mgdnok.nokia.com> References: <20131118194203.E6B4E75E016@rfc-editor.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.243.190.132] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Nokia-AV: Clean Cc: jari.arkko@ericsson.com, joelja@bogus.com, dime@ietf.org Subject: Re: [Dime] [Technical Errata Reported] RFC6733 (3806) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 17:02:29 -0000 Seems a bit nit-picky, but the change doesn't seem to change anything major= , so if it makes sense, it should be OK. John -----Original Message----- From: ext Jouni Korhonen [mailto:jouni.nospam@gmail.com]=20 Sent: Tuesday, November 19, 2013 2:32 AM To: RFC Errata System Cc: vf0213@gmail.com; jari.arkko@ericsson.com; Loughney John (Nokia-CTO/Sil= iconValley); glenzorn@gmail.com; bclaise@cisco.com; joelja@bogus.com; lione= l.morand@orange.com; dime@ietf.org Subject: Re: [Technical Errata Reported] RFC6733 (3806) I think this is OK clarification. - Jouni On Nov 18, 2013, at 9:42 PM, RFC Errata System = wrote: > The following errata report has been submitted for RFC6733, "Diameter=20 > Base Protocol". >=20 > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=3D6733&eid=3D3806 >=20 > -------------------------------------- > Type: Technical > Reported by: Lionel >=20 > Section: 2.7 >=20 > Original Text > ------------- > Server Identifier >=20 > The identity of one or more servers to which the message is to be > routed. This identity MUST also be present in the Host Identity > field of the peer table (Section 2.6). When the Local Action is > set to RELAY or PROXY, this field contains the identity of the > server(s) to which the message MUST be routed. When the Local > Action field is set to REDIRECT, this field contains the identity > of one or more servers to which the message MUST be redirected. >=20 >=20 > Corrected Text > -------------- > Peer Identifier >=20 > The identity of one or more peers to which the message is to be > routed. This identity MUST also be present in the Host Identity > field of the peer table (Section 2.6). When the Local Action is > set to RELAY or PROXY, this field contains the identity of the > peer(s) to which the message MUST be routed. When the Local > Action field is set to REDIRECT, this field contains the identity > of one or more peers to which the message MUST be redirected. >=20 >=20 > Notes > ----- > The host identified in a Routing Table entry is not necessarily a "server= ". It can also be a Relay, a redirect or a proxy agent. Using "peer" instea= d of "server" is more appropriate. >=20 > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please=20 > use "Reply All" to discuss whether it should be verified or rejected.=20 > When a decision is reached, the verifying party (IESG) can log in to=20 > change the status and edit the report, if necessary. >=20 > -------------------------------------- > RFC6733 (draft-ietf-dime-rfc3588bis-33) > -------------------------------------- > Title : Diameter Base Protocol > Publication Date : October 2012 > Author(s) : V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed= . > Category : PROPOSED STANDARD > Source : Diameter Maintenance and Extensions > Area : Operations and Management > Stream : IETF > Verifying Party : IESG From wwwrun@rfc-editor.org Tue Nov 19 09:13:35 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90B141AE00B; Tue, 19 Nov 2013 09:13:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rjxWkK4Jx9wP; Tue, 19 Nov 2013 09:13:34 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:126c::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 0BE861AE0CD; Tue, 19 Nov 2013 09:13:34 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 5A05675E001; Tue, 19 Nov 2013 09:03:08 -0800 (PST) To: Lionel.morand@orange.com, vf0213@gmail.com, jari.arkko@ericsson.com, john.loughney@nokia.com, glenzorn@gmail.com From: RFC Errata System Message-Id: <20131119170309.5A05675E001@rfc-editor.org> Date: Tue, 19 Nov 2013 09:03:08 -0800 (PST) Cc: dime@ietf.org, iesg@ietf.org, rfc-editor@rfc-editor.org Subject: [Dime] [Errata Verified] RFC6733 (3806) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Nov 2013 17:13:35 -0000 The following errata report has been verified for RFC6733, "Diameter Base Protocol". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6733&eid=3806 -------------------------------------- Status: Verified Type: Technical Reported by: Lionel Date Reported: 2013-11-18 Verified by: Benoit Claise (IESG) Section: 2.7 Original Text ------------- Server Identifier The identity of one or more servers to which the message is to be routed. This identity MUST also be present in the Host Identity field of the peer table (Section 2.6). When the Local Action is set to RELAY or PROXY, this field contains the identity of the server(s) to which the message MUST be routed. When the Local Action field is set to REDIRECT, this field contains the identity of one or more servers to which the message MUST be redirected. Corrected Text -------------- Peer Identifier The identity of one or more peers to which the message is to be routed. This identity MUST also be present in the Host Identity field of the peer table (Section 2.6). When the Local Action is set to RELAY or PROXY, this field contains the identity of the peer(s) to which the message MUST be routed. When the Local Action field is set to REDIRECT, this field contains the identity of one or more peers to which the message MUST be redirected. Notes ----- The host identified in a Routing Table entry is not necessarily a "server". It can also be a Relay, a redirect or a proxy agent. Using "peer" instead of "server" is more appropriate. -------------------------------------- RFC6733 (draft-ietf-dime-rfc3588bis-33) -------------------------------------- Title : Diameter Base Protocol Publication Date : October 2012 Author(s) : V. Fajardo, Ed., J. Arkko, J. Loughney, G. Zorn, Ed. Category : PROPOSED STANDARD Source : Diameter Maintenance and Extensions Area : Operations and Management Stream : IETF Verifying Party : IESG From wwwrun@rfc-editor.org Tue Nov 19 16:25:25 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0C8791AE25C; Tue, 19 Nov 2013 16:25:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnOmPmzruQoa; Tue, 19 Nov 2013 16:25:22 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:126c::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id BB6281AE250; Tue, 19 Nov 2013 16:25:21 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id A963175E020; Tue, 19 Nov 2013 16:14:59 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20131120001459.A963175E020@rfc-editor.org> Date: Tue, 19 Nov 2013 16:14:59 -0800 (PST) Cc: drafts-update-ref@iana.org, dime@ietf.org, rfc-editor@rfc-editor.org Subject: [Dime] RFC 7068 on Diameter Overload Control Requirements X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 00:25:25 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7068 Title: Diameter Overload Control Requirements Author: E. McMurry, B. Campbell Status: Informational Stream: IETF Date: November 2013 Mailbox: emcmurry@computer.org, ben@nostrum.com Pages: 29 Characters: 69536 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-dime-overload-reqs-13.txt URL: http://www.rfc-editor.org/rfc/rfc7068.txt When a Diameter server or agent becomes overloaded, it needs to be able to gracefully reduce its load, typically by advising clients to reduce traffic for some period of time. Otherwise, it must continue to expend resources parsing and responding to Diameter messages, possibly resulting in a progressively severe overload condition. The existing Diameter mechanisms are not sufficient for managing overload conditions. This document describes the limitations of the existing mechanisms. Requirements for new overload management mechanisms are also provided. This document is a product of the Diameter Maintenance and Extensions Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From jouni.nospam@gmail.com Tue Nov 19 22:07:03 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4661E1AE334 for ; Tue, 19 Nov 2013 22:07:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tdj5C3P9dqmE for ; Tue, 19 Nov 2013 22:07:01 -0800 (PST) Received: from mail-wg0-x229.google.com (mail-wg0-x229.google.com [IPv6:2a00:1450:400c:c00::229]) by ietfa.amsl.com (Postfix) with ESMTP id 03E931AE331 for ; Tue, 19 Nov 2013 22:07:00 -0800 (PST) Received: by mail-wg0-f41.google.com with SMTP id n12so6717437wgh.2 for ; Tue, 19 Nov 2013 22:06:54 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date :content-transfer-encoding:message-id:references:to; bh=R15HuYJYBmiqrSHUgQw6bncY8jPmEDMOT8LiazragPA=; b=jWOoBhke6P+WmElQoegLroCrX1BbTOJjve3wgVt68SQ+gTHm+4Mhxse6SY7Xpm6N3A Ho3pEACQW/AZpCCHgfCEbrQ/YVZ8gdW4vfrIdy8ho250yBVPyOnnJdwW4GOIaz8XnBay 8lPYMpG4CngYW2XP1fCtMyRYM7RuOHRDqVgpjrB/yimvS9jVgc91hw7lVoYZwhJ+f+pj dS70MD9mqvFG7D7IPXdh+mS84KL202PQOj10qkgHK5aSXpw6kIi/1mY9iVnNkN3AuBZ3 bnFdpC0etbuRJ9TWAXISz4A8OfGOlsc/Jd3PGzKWFMznyVv8IfOvN/JyI0kj7Orplh07 nq/Q== X-Received: by 10.180.211.237 with SMTP id nf13mr23772112wic.55.1384927614282; Tue, 19 Nov 2013 22:06:54 -0800 (PST) Received: from troma.lan (APuteaux-652-1-7-49.w82-124.abo.wanadoo.fr. [82.124.30.49]) by mx.google.com with ESMTPSA id ey4sm41542232wic.11.2013.11.19.22.06.53 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 19 Nov 2013 22:06:53 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <20131120001459.A963175E020@rfc-editor.org> Date: Wed, 20 Nov 2013 08:06:53 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20131120001459.A963175E020@rfc-editor.org> To: "dime@ietf.org" , Ben Campbell , Eric McMurry X-Mailer: Apple Mail (2.1510) Subject: Re: [Dime] RFC 7068 on Diameter Overload Control Requirements X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 06:07:03 -0000 Congrats Ben & Eric and the rest of the people who contributed!=20 - Jouni & Lionel On Nov 20, 2013, at 2:14 AM, rfc-editor@rfc-editor.org wrote: > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 7068 >=20 > Title: Diameter Overload Control Requirements=20 > Author: E. McMurry, B. Campbell > Status: Informational > Stream: IETF > Date: November 2013 > Mailbox: emcmurry@computer.org,=20 > ben@nostrum.com > Pages: 29 > Characters: 69536 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: draft-ietf-dime-overload-reqs-13.txt >=20 > URL: http://www.rfc-editor.org/rfc/rfc7068.txt >=20 > When a Diameter server or agent becomes overloaded, it needs to be > able to gracefully reduce its load, typically by advising clients to > reduce traffic for some period of time. Otherwise, it must continue > to expend resources parsing and responding to Diameter messages, > possibly resulting in a progressively severe overload condition. The > existing Diameter mechanisms are not sufficient for managing overload > conditions. This document describes the limitations of the existing > mechanisms. Requirements for new overload management mechanisms are > also provided. >=20 > This document is a product of the Diameter Maintenance and Extensions = Working Group of the IETF. >=20 >=20 > INFORMATIONAL: This memo provides information for the Internet = community. > It does not specify an Internet standard of any kind. Distribution of > this memo is unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >=20 > For searching the RFC series, see = http://www.rfc-editor.org/search/rfc_search.php > For downloading RFCs, see http://www.rfc-editor.org/rfc.html >=20 > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. = Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From ulrich.wiehe@nsn.com Wed Nov 20 07:25:06 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4215E1AE018 for ; Wed, 20 Nov 2013 07:25:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id to9MCCX2K7_x for ; Wed, 20 Nov 2013 07:25:01 -0800 (PST) Received: from demumfd002.nsn-inter.net (demumfd002.nsn-inter.net [93.183.12.31]) by ietfa.amsl.com (Postfix) with ESMTP id 134CA1AE012 for ; Wed, 20 Nov 2013 07:25:00 -0800 (PST) Received: from demuprx016.emea.nsn-intra.net ([10.150.129.55]) by demumfd002.nsn-inter.net (8.12.11.20060308/8.12.11) with ESMTP id rAKFOocc025013 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 20 Nov 2013 16:24:50 +0100 Received: from DEMUHTC002.nsn-intra.net ([10.159.42.33]) by demuprx016.emea.nsn-intra.net (8.12.11.20060308/8.12.11) with ESMTP id rAKFOnq1024928 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 20 Nov 2013 16:24:49 +0100 Received: from DEMUHTC008.nsn-intra.net (10.159.42.39) by DEMUHTC002.nsn-intra.net (10.159.42.33) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 20 Nov 2013 16:24:49 +0100 Received: from DEMUMBX014.nsn-intra.net ([169.254.14.198]) by DEMUHTC008.nsn-intra.net ([10.159.42.39]) with mapi id 14.03.0123.003; Wed, 20 Nov 2013 16:24:48 +0100 From: "Wiehe, Ulrich (NSN - DE/Munich)" To: "ext Nirav Salot (nsalot)" , "dime@ietf.org" Thread-Topic: Ongoing Throttling Information in request messages Thread-Index: Ac7aQPqQ1tyE3SNOTC+vVrUogwBrJQAnWH+wAADoRNAABgE0oAAA57DwAACoAlAAASWEQAAAqKUAACDdWeAAAz9GUAABLecQAA4Qc8ABE6PKsABJVfJQASwtPKA= Date: Wed, 20 Nov 2013 15:24:48 +0000 Message-ID: <5BCBA1FC2B7F0B4C9D935572D900066815193EFD@DEMUMBX014.nsn-intra.net> References: <5BCBA1FC2B7F0B4C9D935572D9000668151918EC@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192B2B@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192B90@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192BF7@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192CD2@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192D5F@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D90006681519337D@DEMUMBX014.nsn-intra.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.159.42.95] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-purgate-type: clean X-purgate-Ad: Categorized by eleven eXpurgate (R) http://www.eleven.de X-purgate: clean X-purgate: This mail is considered clean (visit http://www.eleven.de for further information) X-purgate-size: 24005 X-purgate-ID: 151667::1384961090-00005753-53FE4E03/0-0/0-0 Subject: Re: [Dime] Ongoing Throttling Information in request messages X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Nov 2013 15:25:06 -0000 Nirav, thank you for your confirmation. In order to select the best solution let me try to start a comparism: 1) A1 can be compared with B1 as both require to insert an AVP in every mes= sage (answer/request, while overloaded/while performing throttling): A1 add= s (resource consuming) functionality to the (overloaded) server/reporting n= ode while B1 adds to the client/reacting node. Furthermore, the AVP to be i= nserted in A1 (OC-OLR) is the only OC-specific AVP to be inserted to the an= swer whereas the AVP to be inserted in B1 (OC-Ongoing-Throttling-Informatio= n) would be in addition to the OC-Feature-Vector which anyway needs to be a= dded to every request (inserting OC specific info to requests is needed any= way). Furthermore A1 seems to violate REQ 13 from RFC 7068 while B1 does no= t. All this clearly is a pro for option B. 2) A2 can be compared with B2: A2 either requires additional processing at = the server/reporting node or relies on timouts (violating REQ 10) while B2 = does not require any corresponding functionality. This is also a pro for Op= tion B. 3) A3 can be compared with B3 as both recommend to check the presence of ne= w OC-specific info in all received messages: A3 adds the recommended functi= onality to the (overloaded) server/reporting node while B3 adds to the clie= nt/reacting node. This is a pro for option A. 4) Option B adds a feedback channel from client to server making the soluti= on more robust. It also allows the server to give some priority to already = throttled traffic (see REQ 18) and it allows agents to ensure that already = throttled traffic (by a downstream node) is not throttled again. This is a = pro for option B. 5) In Option A it is not clear how the client/reacting node should behave w= hen it receives an answer without OC-OLR AVP while performing throttling. T= his is a con for option A. In summary my preference is for option B. Comments are welcome. Ulrich -----Original Message----- From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]=20 Sent: Thursday, November 14, 2013 3:54 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, I confirm the summary below of having two valid options. Just wanted to highlight one aspect, in general. Current definition of the OC-OLR AVP suggest the inclusion of TimeStamp and= ValidityDuration AVPs. And these AVPs are applicable/valid/needed in both = the options below. Additionally, if we decide to go for option B, we would need to define new = AVP OC-Ongoing-Throttling-Information AVP. Regards, Nirav. -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Sent: Wednesday, November 13, 2013 9:03 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, in summary it seems that we have two valid options: Option A:=20 A1: the server (or reporting node), while overloaded must insert the load O= C-OLR AVP in every answer message. A2: the server (or reporting node) after leaving the overload state must co= ntinue inserting the OC-OLR AVP (indicating end of throttling request) for = some time (how long needs to be calculated by the server) or the server mus= t rely on expiry of outdated overload reports. A3: the reacting node must/should check the timeStamp in every OC-OLR AVP r= eceived in answer messages in order not to miss an update. Option B: B1: the reacting node, while performing throttling, must insert the OC-Ongo= ing-Throttling-Information in every request message. B2: void (the reacting node , while no longer throttling, simply does not i= nsert OC-Ongoing-Throttling-Information) B3: the reporting node must/should check OC-Ongoing-Throttling-Information = received in a request in order to decide whether or not OC-OLR must be sent= back.=20 Ulrich -----Original Message----- From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com]=20 Sent: Thursday, November 07, 2013 5:29 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, Not sure the significance of REQ 10 here but I do not agree to enforce the = server to include overload-report (indicating non-zero or zero overload con= dition) in every message. Even in your example, the overload condition will end sometime - e.g. after= 1000 sec. and then the server can stop including the overload-report. Besides, I am still not convince that "during the overload condition, using= some logic to avoid inclusion of overload-report is less resource consumin= g than simply including the same overload-report". Yes, the reason behind defining timestamp is to allow the reacting node to = discard the overload-report if the same was already received from the repor= ting node. Regards, Nirav. -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com]=20 Sent: Thursday, November 07, 2013 3:53 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, please see inline. Best regards Ulrich -----Original Message----- From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Thursday, November 07, 2013 10:15 AM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, Please read my responses inline. Regards, Nirav. -----Original Message----- From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Thursday, November 07, 2013 1:54 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, thank you for the explanation. This may be a solution which adds more comp= lexity to the reporting node: The reporting node must remember the maximum = not yet expired fraction of duration values it sent when leaving the overlo= ad state and must continue reporting "end of overload condition" until expi= ry. (there is no corresponding complexity at the reacting node in my propos= al) [Nirav] This is not always true, e.g. as I had indicated if the node ha= s advertised 10% reduction-percentage for 10 sec., it need not bother to ad= vertise no-overload condition since the validity-period was very small. [Ulrich] Also not always true, e.g. if the reporting node has requested at = 20% reduction for 1000sec at t1 and then at t1 + 10sec sends an update to r= equest a 10% reduction for 10 sec. Although the validity-period is small (1= 0 sec) there may still be a reacting node that did not get the update and k= eeps on throttling by 20% until t1 + 1000sec. Furthermore you seem not to t= ake REQ 10 seriously. My understanding was that timeout is last resort, not= the normal way. Another question: While doing a throttling, what is the expected behaviour = of the reacting node when receiving an answer message without OC-OLR AVP? (= stop/continue throttling?) (there is no corresponding question in my propos= al since not sending of OC-Ongoing-Throttling-Information clearly means tha= t throttling is not in place) [Nirav] The reacting node should continue to = apply the earlier received OC-OLR.=20 " (Note: We seem to have consensus that a server MAY repeat OLRs in subsequent messages, but is not required to do so, based on local policy.)" [Ulrich] This needs to be reconsidered. See the following example: Non supporting client C1 sends a request via supporting agent A1 to Server = S. S returns a 10% throttling request.=20 C sends an new request via supporting agent A2 to S.=20 S decides not to repeat the 10% throttling request (hence A2 is not aware o= f the throttling request).=20 C1 sends a new request via A1.=20 S decides to repeat the throttling request (redundant).=20 Supporting client C2 sends a request via A2 to S. S decides not to repeat.... To avoid this mess we either need to mandate sending OC-OLR in every answer= (while in overload) or let the Server keep track which agent and which cli= ent is updated with the newest info. (or consider my proposal). Another question is for the reacting node: What is the expected behaviour w= hen receiving lots of redundant OC-OLR AVPs in answer messages? The reactin= g node needs to check every single OC-OLR AVP in order to find out whether = it contains an update. Is that the correct understanding? (this seems to be= equivalent to checking for redundant OC-Ongoing-Throttling-Information AVP= s in every request by the reporting node in my proposal) [Nirav] Please ref= er to Timestamp AVP within OC-OLR. The TimeStamp AVP indicates when the original OC-OLR AVP with the current content was created. It is possible to replay the same OC- OLR AVP multiple times between the overload endpoints, however, when the OC-OLR AVP content changes or the other information sending endpoint wants the receiving endpoint to update its overload control information, then the TimeStamp AVP MUST contain a new value. [Ulrich] This does not explicitly say that the reacting node must check eve= ry TimeStamp received within OC-OLR AVPs. But I guess this is the consequen= ce. Can you please confirm. Adding dime-list again. Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 4:58 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, During "no overload condition", why should reporting node include overload-= information in all the answer messages? e.g. if the reporting node has advertised overload-report with period-of-va= lidity=3D10 sec., it knows that after that period all the reacting node wil= l automatically stop applying any overload mitigation action. And hence it = does not need to explicitly send any overload-report indicating "no overloa= d condition". In general, I assume that overload period of would be much shorter as compa= red to "no overload" period. And hence I do not see reason to always includ= e overload-report. Regards, Nirav. From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Wednesday, November 06, 2013 9:12 PM To: Nirav Salot (nsalot); doc-dt@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, "During the overload" yes I agree, but "when no longer in overload" all ans= wer messages would contain the information "no longer in overload" while on= ly few request messages would contain the Ongoing-Throttling-Information. Removing dime-list which bounces. Best regards Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 4:02 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, I might be missing something here so please bear with me. Number of answer messages sent by server =3D number of request messages rec= eived by the server. During the overload, the server would receive only those requests which sur= vived throttling. And then the server would send answer messages to only those request messag= es. So "every" and "some" are actually equal in the below equation. No? Regards, Nirav. From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Wednesday, November 06, 2013 8:24 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, Not quite. The question is: "is sending an overload-report in every answer message that corresponds to = request with OC-Feature-Vector present more resource consuming than receivi= ng Ongoing-Throttling-Information in some request messages (only those that= survived a throttling)?" Best regards Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 3:15 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, Thanks for clarification. Then the question would be "is sending overload-report in every answer message is more resource consum= ing than the solution below - i.e. receiving OC-Ongoing-Throttling-Informat= ion in all request message and analyzing the timestamp and then deciding if= the overload-report should be included or not." I am not sure. Regards, Nirav. From: Wiehe, Ulrich (NSN - DE/Munich) [mailto:ulrich.wiehe@nsn.com] Sent: Wednesday, November 06, 2013 7:08 PM To: Nirav Salot (nsalot); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Nirav, thank you for your comments. The comparism is between: Current way: "send OC specific information (Feature-Vector) in every reques= t message and in every corresponding answer message" My proposal: "send OC specific information (Feature-Vector and in some case= s Ongoing-Throttling-Info) in every request message and in corresponding an= swer messages only when required". Sending OC specific information =A0is regarded a resource consuming action = and we should not put this action to the (overloaded) server where avoidabl= e. See REQ 13. Best regards Ulrich From: ext Nirav Salot (nsalot) [mailto:nsalot@cisco.com] Sent: Wednesday, November 06, 2013 12:04 PM To: Wiehe, Ulrich (NSN - DE/Munich); doc-dt@ietf.org; dime@ietf.org Subject: RE: Ongoing Throttling Information in request messages Ulrich, Thanks for the detail explanation of your proposal. Just to verify my understanding, Your proposal would allow the reporting node to avoid inclusion of the "sam= e" overload-report in the answer message since the request message indicate= s that the path contains at least one reacting node which already has the l= atest overload-report. In other words, the reporting node need not include overload-report in ever= y message, blindly. To achieve the above objective, the solution below suggest the reacting nod= e to include new AVP OC-Ongoing-Throttling-Information in every request mes= sage, which survives throttling. So the net result is that, the inclusion of the overload-report is prevente= d in every answer message since the OC-Ongoing-Throttling-Information is in= cluded in every request message. [Wiehe, Ulrich (NSN - DE/Munich)] no.=A0 .in every request message that sur= vived a throttling. And hence I am not sure if the solution has sound benefit from the inclusio= n of redundant information point of view. In summary, I think the solution suggested below works as explained. But I fail to see the benefit of using this solution compare to a solution = in which the reporting node includes overload-report in every answer messag= e. Regards, Nirav. From: doc-dt-bounces@ietf.org [mailto:doc-dt-bounces@ietf.org] On Behalf Of= Wiehe, Ulrich (NSN - DE/Munich) Sent: Tuesday, November 05, 2013 9:36 PM To: doc-dt@ietf.org; dime@ietf.org Subject: [doc-dt] Ongoing Throttling Information in request messages Hi, draft-docdt-dime-ovli-01 in Appendix B, Table 1, REQ 13 says: =A0=A0=A0=A0=A0=A0=A0 .. Another way =A0=A0=A0=A0=A0=A0=A0 is to let the request sender (reacting node) insert =A0=A0=A0=A0=A0=A0=A0 information in the request to say whether a =A0=A0=A0=A0=A0=A0=A0 throttling is actually performed.=A0 The reporting no= de =A0=A0=A0=A0=A0=A0=A0 then can base its decision on information received in =A0=A0=A0=A0=A0=A0=A0 the request; no need for keeping state to record who =A0 has received overload reports.=A0=20 =A0 And in Appendix B, Table 1, REQ 18: =A0=A0=A0=A0=A0=A0=A0 There has been a proposal to mark =A0=A0=A0=A0=A0=A0=A0 messages that survived overload throttling as one =A0=A0=A0=A0=A0=A0=A0 method for an overloaded node to address fairness but =A0=A0=A0=A0=A0=A0=A0 this proposal is not yet part of the solution.=A0=20 =A0 I would like to come back to this proposal.=20 A new AVP OC-Ongoing-Throttling-Information inserted in request messages wo= uld indicate that the request message survived a throttling. Furthermore, i= nformation within the AVP indicates the TimeStamp as received in the previo= us OC-OLR AVP, according to which the ongoing throttling (which was survive= d) is performed. =A0 OC-Ongoing-Throttling-Information ::=3D < AVP Header: TBD9 > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 < TimeStamp > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 * [ AVP ] =A0 Supporting Clients would insert the OC-Ongoing-Throttling-Information AVP= =A0 into request messages that survived a throttling performed at that clie= nt. Supporting Agents when receiving a request message that contains an OC-Ongo= ing-Throttling-Information AVP would not perform an additional throttling (= since the client or a downstream agent already performed the throttling) , = while, when receiving a request that does not contain OC-Ongoing-Throttling= -Information AVP would perform throttling (on behalf of the client) accordi= ng to a previously received and stored OC-OLR, and if that throttling is su= rvived the agent would insert the OC-Ongoing-Throttling-Information AVP in = the request before sending it further upstream. Servers (or in general reporting nodes) would check presence and content of= the OC-Ongoing-Throttling-Information AVP in received request messages and= could detect (together with a check of presence of OC-Feature-Vector AVP) = whether inserting an OC-OLR AVP in the corresponding answer message is need= ed in order to update the reacting node with a new OC-OLR). =A0 This proposal especially addresses use cases like the following: =A0 Architecture: =A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +-------= ---------+ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 | suppor= ting=A0=A0=A0=A0 | =A0 =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 /| agent A1= =A0=A0=A0=A0=A0=A0 |\ =A0 +----------------+ / +----------------+ \ =A0 | non supporting |/=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0 \ =A0 | client C=A0=A0=A0=A0=A0=A0 |\=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0= =A0=A0=A0=A0=A0=A0=A0=A0=A0 \ =A0 +----------------+ \ +----------------+=A0=A0=A0 \ +------------+=A0=A0= =A0 +---------+ =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 \| non supp= orting |=A0=A0=A0=A0 \| supporting | =A0=A0 | Server=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 age= nt A2=A0=A0=A0=A0=A0 |------| agent A3=A0=A0 |----|=A0 S=A0=A0=A0=A0=A0 | =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0 +------------= ----+=A0=A0=A0=A0=A0 +------------+=A0=A0=A0 +---------+ =A0 1. A request is sent from C via A2 and A3 to S. A3 recognizes that there is= no reacting node downstream (no OC-Feature-Vector received) and therefore = takes the role of the reacting node and inserts an OC-Feature-Vector AVP. A= 3 has no valid OLR from S stored and therefore does not perform throttling = and does not insert an OC-Throttling-Information AVP. 2. S recognizes that there is a reacting node downstream which is actually = not performing a throttling. S returns a 10% throttling request (TimeStamp= =3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A3 and= A2 to C. 3. A3 stores the 10% throttling request. 4. A new request is sent from C via A2 and A3 to S. A3 recognizes that ther= e is no reacting node downstream (no OC-Feature-Vector received) and theref= ore takes the role of the reacting node and inserts an OC-Feature-Vector AV= P. A3 has=A0 valid OLR from S stored and performs a 10% throttling. The req= uest survives and A3 inserts an OC-Throttling-Information AVP with timeStam= p=3Dt1. 5. S recognizes that correct throttling (correct time stamp) is in place an= d therefore does not return OC-OLR in the answer. 6. A new request is sent from C via A1 and A3 to S. A1 recognizes that ther= e is no reacting node downstream (no OC-Feature-Vector received) and theref= ore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 h= as no valid OLR from S stored and therefore does not perform throttling and= does not insert an OC-Throttling-Information AVP. A3 recognizes that there= is a reacting node downstream (OC-Feature-Vector received) and therefore d= oes not take the role of the reacting node. 7. S recognizes that there is a reacting node downstream which is actually = not performing a throttling. S returns a 10% throttling request (TimeStamp= =3Dt1, duration=3Dd) within OC-OLR in the answer which goes back via A3 and= A1 to C. 8. A1 stores the 10% throttling request. 9. A new request is sent from C via A1 and A3 to S. A1 recognizes that ther= e is no reacting node downstream (no OC-Feature-Vector received) and theref= ore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 h= as=A0 valid OLR from S stored and therefore performs a 10% throttling. The = request survives and A1 inserts an OC-Throttling-Information AVP with timeS= tamp=3Dt1. A3 recognizes that there is a reacting node downstream (OC-Featu= re-Vector received) and therefore does not take the role of the reacting no= de. 10. S recognizes that correct throttling (correct time stamp) is in place a= nd therefore does not return OC-OLR in the answer. 11. Requests sent from C via A1 and A3 to S undergo a 10% throttling at A1,= requests sent from C via A2 and A3 to S undergo a 10% throttling at A3. 12. Overload situation in S for some reason gets worse, S decides to reques= t 20 % reduction. 13. A new request is sent from C via A1 and A3 to S. A1 recognizes that the= re is no reacting node downstream (no OC-Feature-Vector received) and there= fore takes the role of the reacting node and inserts an OC-Feature-AVP. A1 = has=A0 valid OLR from S stored and therefore performs a 10% throttling. The= request survives and A1 inserts an OC-Throttling-Information AVP with time= Stamp=3Dt1. A3 recognizes that there is a reacting node downstream (OC-Feat= ure-Vector received) and therefore does not take the role of the reacting n= ode. 14. S recognizes that incorrect throttling (wrong time stamp) is in place a= nd therefore S returns a 20% throttling request (TimeStamp=3Dt2, duration= =3Dx) within OC-OLR in the answer which goes back via A3 and A1 to C. 15. A3 (not taking the role of the reactingt node)may, A1 must store the 20= % throttling request (replacing the 10% request). 16. A new request is sent from C via A2 and A3 to S. A3 recognizes that the= re is no reacting node downstream (no OC-Feature-Vector received) and there= fore takes the role of the reacting node and inserts an OC-Feature-Vector A= VP. A3 has=A0 valid OLR from S stored and performs a 10% throttling. The re= quest survives and A3 inserts an OC-Throttling-Information AVP with timeSta= mp=3Dt1. (assuming A3 did not store the 20% request at step 14) 17. S recog= nizes that incorrect throttling (wrong time stamp) is in place and therefor= e S returns a 20% throttling request (TimeStamp=3Dt2, duration=3Dx) within = OC-OLR in the answer which goes back via A3 and A2 to C. 18. A3 stores the 20% throttling request (replacing the 10% request). 19. Requests sent from C via A1 and A3 to S undergo a 20% throttling at A1,= requests sent from C via A2 and A3 to S undergo a 20% throttling at A3. =A0 =A0 Comments are welcome. =A0 Best regards Ulrich =A0 =A0 From jouni.nospam@gmail.com Fri Nov 22 05:53:49 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C40AC1ADF0F for ; Fri, 22 Nov 2013 05:53:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.101 X-Spam-Level: X-Spam-Status: No, score=-0.101 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lt-1ffobK_t1 for ; Fri, 22 Nov 2013 05:53:45 -0800 (PST) Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 42FC01ADEB4 for ; Fri, 22 Nov 2013 05:53:45 -0800 (PST) Received: by mail-wi0-f175.google.com with SMTP id hi5so748599wib.8 for ; Fri, 22 Nov 2013 05:53:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ulaJ1mpY82tTlKG6JWdH46axG8DxumeYhx54UIQEO4I=; b=z33dPLKsOVPaC3xImaRBS4eTh6RHfC8ptyROV0hrqvUF+RP7Abey6+R9Zed0iodYXf 1JP9SyBB8+k45e4FvgnWQfwqFKAxb1X0gsO+2vzctLP9ydOZhmMnBhFyt/nO4yvIa/Xf LD9Eqd7jsNZ6pr1vG4d8s/cxCapNJRVxJ9CKD1yjVjGfjLyWTTNLzLS37h3O5wV1+DoA Dw2XcmFrq6dUGw2GxMziVtc3WuEiNQ1QH7or3TANscnhFfr89vNM8qPioNHs7ILYTvUK azzN76NiChQuep7+QSjmDkEkfhkThQMoJB0ZD/SQxlBXKhOKbGzIXScp9pZSGMis3bqw yj9g== X-Received: by 10.194.193.39 with SMTP id hl7mr59385wjc.91.1385128417634; Fri, 22 Nov 2013 05:53:37 -0800 (PST) Received: from [10.216.13.198] ([93.158.55.49]) by mx.google.com with ESMTPSA id y20sm16326815wib.0.2013.11.22.05.53.34 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 22 Nov 2013 05:53:35 -0800 (PST) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) From: Jouni Korhonen In-Reply-To: <22322_1384808461_528A800D_22322_108_1_6B7134B31289DC4FAF731D844122B36E2F27B6@PEXCVZYM13.corporate.adroot.infra.ftgroup> Date: Fri, 22 Nov 2013 15:53:33 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <8A5D5E1A-FD7A-484F-A408-7C63B8C30688@gmail.com> References: <22322_1384808461_528A800D_22322_108_1_6B7134B31289DC4FAF731D844122B36E2F27B6@PEXCVZYM13.corporate.adroot.infra.ftgroup> To: "dime@ietf.org" X-Mailer: Apple Mail (2.1510) Subject: Re: [Dime] WG adoption call for draft-docdt-dime-ovli-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 13:53:50 -0000 Folks, We got clear support for the adoption of the design team proposal. The draft-ietf-dime-ovli-00 will be submitted soon'ish. Note that the -00 version is solely based on the = draft-docdt-dime-ovli-01 and the changes & way forward agreed during the Vancouver meeting will = be implemented into -01 version of the WG document. So expect the -01 = version to appear quite soon after the submission of the WG document -00 = version. - Jouni & Lionel On Nov 18, 2013, at 11:01 PM, lionel.morand@orange.com wrote: > As individual, I support the adoption of this draft as WG document. >=20 > Lionel >=20 > -----Message d'origine----- > De : DiME [mailto:dime-bounces@ietf.org] De la part de Ben Campbell > Envoy=E9 : lundi 18 novembre 2013 21:37 > =C0 : Jouni Korhonen > Cc : dime@ietf.org > Objet : Re: [Dime] WG adoption call for draft-docdt-dime-ovli-01 >=20 > I support adoption. >=20 > On Nov 8, 2013, at 3:46 PM, Jouni Korhonen = wrote: >=20 >> Folks, >>=20 >> This mail starts a two week WG adoption call for = draft-docdt-dime-ovli-01 >> to serve as a basis for the Diameter overload indication conveyance. = the >> call ends 22-Nov-2013. Express your support or concerns on the = mailing >> list. >>=20 >> - Jouni & Lionel >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >> DiME mailing list >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime >=20 > = __________________________________________________________________________= _______________________________________________ >=20 > Ce message et ses pieces jointes peuvent contenir des informations = confidentielles ou privilegiees et ne doivent donc > pas etre diffuses, exploites ou copies sans autorisation. Si vous avez = recu ce message par erreur, veuillez le signaler > a l'expediteur et le detruire ainsi que les pieces jointes. Les = messages electroniques etant susceptibles d'alteration, > Orange decline toute responsabilite si ce message a ete altere, = deforme ou falsifie. Merci. >=20 > This message and its attachments may contain confidential or = privileged information that may be protected by law; > they should not be distributed, used or copied without authorisation. > If you have received this email in error, please notify the sender and = delete this message and its attachments. > As emails may be altered, Orange is not liable for messages that have = been modified, changed or falsified. > Thank you. >=20 > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From internet-drafts@ietf.org Fri Nov 22 08:28:33 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E00E01AE168; Fri, 22 Nov 2013 08:28:33 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u0Anw8AKCHs7; Fri, 22 Nov 2013 08:28:32 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 932DA1AE047; Fri, 22 Nov 2013 08:28:32 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.83.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20131122162832.16557.51277.idtracker@ietfa.amsl.com> Date: Fri, 22 Nov 2013 08:28:32 -0800 Cc: dime@ietf.org Subject: [Dime] I-D Action: draft-ietf-dime-ovli-00.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 16:28:34 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Diameter Maintenance and Extensions Worki= ng Group of the IETF. Title : Diameter Overload Indication Conveyance Author(s) : Jouni Korhonen Steve Donovan Ben Campbell Filename : draft-ietf-dime-ovli-00.txt Pages : 41 Date : 2013-11-22 Abstract: This specification documents a Diameter Overload Control (DOC) base solution and the dissemination of the overload report information. Requirements The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-ovli There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-dime-ovli-00 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From wwwrun@rfc-editor.org Fri Nov 22 10:42:57 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0B0AC1AE230; Fri, 22 Nov 2013 10:42:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.427 X-Spam-Level: X-Spam-Status: No, score=-2.427 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.525, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BxBle0HFsI4q; Fri, 22 Nov 2013 10:42:55 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1890:126c::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 981B51AE233; Fri, 22 Nov 2013 10:42:47 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 30) id 93D6C75E01C; Fri, 22 Nov 2013 10:32:14 -0800 (PST) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20131122183214.93D6C75E01C@rfc-editor.org> Date: Fri, 22 Nov 2013 10:32:14 -0800 (PST) Cc: drafts-update-ref@iana.org, dime@ietf.org, rfc-editor@rfc-editor.org Subject: [Dime] RFC 7075 on Realm-Based Redirection In Diameter X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Nov 2013 18:42:57 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7075 Title: Realm-Based Redirection In Diameter Author: T. Tsou, R. Hao, T. Taylor, Ed. Status: Standards Track Stream: IETF Date: November 2013 Mailbox: tina.tsou.zouting@huawei.com, ruibing_hao@cable.comcast.com, tom.taylor.stds@gmail.com Pages: 10 Characters: 21434 Updates: RFC 6733 I-D Tag: draft-ietf-dime-realm-based-redirect-13.txt URL: http://www.rfc-editor.org/rfc/rfc7075.txt The Diameter protocol includes a capability for message redirection, controlled by an application-independent "redirect agent". In some circumstances, an operator may wish to redirect messages to an alternate domain without specifying individual hosts. This document specifies an application-specific mechanism by which a Diameter server or proxy (node) can perform such a redirection when the Straightforward-Naming Authority Pointer (S-NAPTR) is not used for dynamic peer discovery. A node performing this new function is referred to as a "Realm-based Redirect Server". This memo updates Sections 6.13 and 6.14 of RFC 6733 with respect to the usage of the Redirect-Host-Usage and Redirect-Max-Cache-Time Attribute-Value Pairs (AVPs). This document is a product of the Diameter Maintenance and Extensions Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/search/rfc_search.php For downloading RFCs, see http://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From sdanda@cisco.com Sat Nov 23 00:06:58 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BACE91AE154 for ; Sat, 23 Nov 2013 00:06:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.025 X-Spam-Level: X-Spam-Status: No, score=-10.025 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WCIGrWhAQmiv for ; Sat, 23 Nov 2013 00:06:56 -0800 (PST) Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) by ietfa.amsl.com (Postfix) with ESMTP id 7C29A1AE13E for ; Sat, 23 Nov 2013 00:06:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9150; q=dns/txt; s=iport; t=1385194009; x=1386403609; h=from:to:subject:date:message-id:mime-version; bh=gxibfxhPZ5AR85t2IHorooDjfs8JXU01rcr9n1Z1c30=; b=mLEGyBBzrtXMX2lDlqmRl67AJBQW8XAK9OskgOxIf5bJOwrf77FkOjNH FPxyTjRm22O6ZJLj/jFHjNBitAHNkKpuU7WxfOdhmhxlIXO/iNS19aME9 wTnW3n5i8wuT4klrvGT0z0uqsjTWezFPh3BhPGq0Pp0asNwhgHPFJ/uBs A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlYFAHRhkFKtJV2Y/2dsb2JhbABZgkNEOFO8HYEZFm0HgicBBC1eASpWJgEEG4d5oG2gAReOMiSDWIETA6Jfh0eDKIFqJBw X-IronPort-AV: E=Sophos;i="4.93,757,1378857600"; d="scan'208,217";a="1691947" Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-2.cisco.com with ESMTP; 23 Nov 2013 08:06:49 +0000 Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com [173.37.183.78]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id rAN86mrp016490 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 23 Nov 2013 08:06:48 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.50]) by xhc-rcd-x04.cisco.com ([fe80::200:5efe:173.37.183.34%12]) with mapi id 14.03.0123.003; Sat, 23 Nov 2013 02:06:48 -0600 From: "Satyanarayana Danda (sdanda)" To: "dime@ietf.org" Thread-Topic: RAR Message with possible ReAuth-Reqiest_type Thread-Index: Ac7oIvOUceYo/p9gSMuOeAA17B6+vA== Date: Sat, 23 Nov 2013 08:06:48 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.106.121] Content-Type: multipart/alternative; boundary="_000_E06F3B652F60A4409C49D8E840BEEC921E46790Exmbrcdx14ciscoc_" MIME-Version: 1.0 Subject: [Dime] RAR Message with possible ReAuth-Reqiest_type X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Nov 2013 08:06:58 -0000 --_000_E06F3B652F60A4409C49D8E840BEEC921E46790Exmbrcdx14ciscoc_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi folks, I am looking for a case where Re-Auth-Request is sent to NAS with subscribe= r credentials captured via web Portal (web-logon) case. >From RFC 6733, we do have two options set in ReAuth-Request-Type AVP of the= action expected. From my use-case standpoint, I would like to inform NAS to take AUTHENTICATE_ONLY action by sending AA-Request for credential v= alidation. Since this is not specified as part of this RFC, do you see this needs to b= e addressed? Please let me know in case you want more details on the use-case. Thanks Satya Re-Auth-Request-Type AVP The Re-Auth-Request-Type AVP (AVP Code 285) is of type Enumerated and is included in application-specific auth answers to inform the client of the action expected upon expiration of the Authorization-Lifetime. If the answer message contains an Authorization-Lifetime AVP with a positive value, the Re-Auth-Request-Type AVP MUST be present in an answer message. The following values are defined: AUTHORIZE_ONLY 0 An authorization only re-auth is expected upon expiration of the Authorization-Lifetime. This is the default value if the AVP is not present in answer messages that include the Authorization- Lifetime. AUTHORIZE_AUTHENTICATE 1 An authentication and authorization re-auth is expected upon expiration of the Authorization-Lifetime. --_000_E06F3B652F60A4409C49D8E840BEEC921E46790Exmbrcdx14ciscoc_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi folks,

 

I am looking for a case where Re-Auth-Request= is sent to NAS with subscriber credentials captured via web Portal (web-lo= gon) case.

From RFC 6733, we do have two options set in ReAu= th-Request-Type AVP of the action expected. From my use-case standpoint= , I would like to inform

NAS to take AUTHENTICATE_ONLY action by sendi= ng AA-Request for credential validation.

Since this is not specified as part of this RFC, do = you see this needs to be addressed?

 

Please let me know in case you want more details on = the use-case.

 

Thanks

Satya

 

<snip>

Re-Auth-Request-Type AVP

 
   The Re-Auth-Request-Type AVP (AVP Code 285) is of ty=
pe Enumerated and
   is included in application-specific auth answers to =
inform the client
   of the action expected upon expiration of the Author=
ization-Lifetime.
 
   If the answer message contains an Authorization-Life=
time AVP with a
   positive value, the Re-Auth-Request-Type AVP MUST be=
 present in an
   answer message.  The following values are defin=
ed:
 
   AUTHORIZE_ONLY 0
 
      An authorization only re-auth is e=
xpected upon expiration of the
      Authorization-Lifetime.  This=
 is the default value if the AVP is
      not present in answer messages tha=
t include the Authorization-
      Lifetime.
 
   AUTHORIZE_AUTHENTICATE 1
 
      An authentication and authorizatio=
n re-auth is expected upon
      expiration of the Authorization-Li=
fetime.

</snip>

--_000_E06F3B652F60A4409C49D8E840BEEC921E46790Exmbrcdx14ciscoc_-- From glenzorn@gmail.com Sat Nov 23 00:27:05 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3EA91AE0DF for ; Sat, 23 Nov 2013 00:27:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iz5SqBD4O7aC for ; Sat, 23 Nov 2013 00:27:04 -0800 (PST) Received: from mail-pb0-x235.google.com (mail-pb0-x235.google.com [IPv6:2607:f8b0:400e:c01::235]) by ietfa.amsl.com (Postfix) with ESMTP id 05C671AE025 for ; Sat, 23 Nov 2013 00:27:03 -0800 (PST) Received: by mail-pb0-f53.google.com with SMTP id ma3so2455247pbc.26 for ; Sat, 23 Nov 2013 00:26:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:cc:subject :references:in-reply-to:content-type:content-transfer-encoding; bh=YZZNKNXG9Px+v1otzjlpLQtMJNE8nKEoL2u1sPV3eUs=; b=IzcoOoejsdEf5gy/IncP54l5BFhuJqKl+udDllJqrPWEdu2e8FzPcZPLMVXO+wWjrj Zl08STbEq3LTWGkogsqkxLzvMzBXF5W3lmKu98Jbl2OPdNG7NgIe+/FwzzQp7NNR/JyD WcUlP/pH7WCVmzljFeqDNDS+pbKgzYT3vtAIgy1LvlPJsM4cTQpjljKSEo93UfIRH1OK FsF5NUSgu2Dc9q/p0nv3BZwDn/uG5p32OEB5O1XRe85qMZ32dr5IBvWbP0ckR+FQRoUW 071QGANkGYfeb2wa72jygEaFpno5fiP+4gKQonqpNbQCViNR5NcRFrQ3itDoZNom3MjL bGqg== X-Received: by 10.66.102.66 with SMTP id fm2mr16405156pab.94.1385195216723; Sat, 23 Nov 2013 00:26:56 -0800 (PST) Received: from [192.168.0.104] (ppp-171-96-88-15.revip8.asianet.co.th. [171.96.88.15]) by mx.google.com with ESMTPSA id oa3sm25356569pbb.15.2013.11.23.00.26.54 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 23 Nov 2013 00:26:56 -0800 (PST) Message-ID: <529066CB.8050505@gmail.com> Date: Sat, 23 Nov 2013 15:26:51 +0700 From: Glen Zorn User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130404 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Satyanarayana Danda (sdanda)" References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: "dime@ietf.org" Subject: Re: [Dime] RAR Message with possible ReAuth-Reqiest_type X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Nov 2013 08:27:06 -0000 On 11/23/2013 03:06 PM, Satyanarayana Danda (sdanda) wrote: > Hi folks, > > I am looking for a case where *Re-Auth-Request* is sent to NAS with > subscriber credentials captured via web Portal (web-logon) case. > > From RFC 6733, we do have two options set in *ReAuth-Request-Type* AVP > of the action expected. From my use-case standpoint, I would like to inform > > NAS to take *AUTHENTICATE_ONLY* action by sending AA-Request for > credential validation. > > Since this is not specified as part of this RFC, do you see this needs > to be addressed? > > Please let me know in case you want more details on the use-case. I would like more details. In particular, why do you believe that authorization in unnecessary? > > Thanks > > Satya > > > > > > Re-Auth-Request-Type AVP > > > > The Re-Auth-Request-Type AVP (AVP Code 285) is of type Enumerated and > > is included in application-specific auth answers to inform the client > > of the action expected upon expiration of the Authorization-Lifetime. > > > > If the answer message contains an Authorization-Lifetime AVP with a > > positive value, the Re-Auth-Request-Type AVP MUST be present in an > > answer message. The following values are defined: > > > > AUTHORIZE_ONLY 0 > > > > An authorization only re-auth is expected upon expiration of the > > Authorization-Lifetime. This is the default value if the AVP is > > not present in answer messages that include the Authorization- > > Lifetime. > > > > AUTHORIZE_AUTHENTICATE 1 > > > > An authentication and authorization re-auth is expected upon > > expiration of the Authorization-Lifetime. > > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From sdanda@cisco.com Sat Nov 23 02:35:13 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DE871AE28B for ; Sat, 23 Nov 2013 02:35:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.026 X-Spam-Level: X-Spam-Status: No, score=-10.026 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I_SMbmw-njm9 for ; Sat, 23 Nov 2013 02:35:11 -0800 (PST) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) by ietfa.amsl.com (Postfix) with ESMTP id F1AA21AE09B for ; Sat, 23 Nov 2013 02:35:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3139; q=dns/txt; s=iport; t=1385202904; x=1386412504; h=from:to:cc:subject:date:message-id: content-transfer-encoding:mime-version; bh=CUR/oZ0iJ/Uc5kwFEYpJgeQS4h77hUKa+cSG7F+Mz2M=; b=XDYumZYh3QiJ6kTV4AmUoyXXVjdRCFXE7CU/CTyRDakNY0sLgAcf8RkN fioFOu+8iL//NJ0YXsjEq4ZeL7KidZ9zt2AxRpeAZEoz28i5+URcoo7Yv RftdHGQSKoI3l+BXm3Dgp08gDFvosuf0HJIC6n7lcZ8J46C6+kOoSsQ+s k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AgUFAPGDkFKtJXHA/2dsb2JhbABZgwc4U7wdgRkWdIIlAQEBAwEBAQE3NAsFBwYBCBEEAQELDAEHCSgGCxQJCQEEDgUIh2cDCQYNt2INiCcTBIx4gTokMQ0MAYMNgRMDlimMNoIPhTiDKIFqBxcGHA X-IronPort-AV: E=Sophos;i="4.93,757,1378857600"; d="scan'208";a="1708856" Received: from rcdn-core2-5.cisco.com ([173.37.113.192]) by alln-iport-8.cisco.com with ESMTP; 23 Nov 2013 10:35:03 +0000 Received: from xhc-rcd-x12.cisco.com (xhc-rcd-x12.cisco.com [173.37.183.86]) by rcdn-core2-5.cisco.com (8.14.5/8.14.5) with ESMTP id rANAZ37B008854 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Sat, 23 Nov 2013 10:35:03 GMT Received: from xmb-rcd-x14.cisco.com ([169.254.4.50]) by xhc-rcd-x12.cisco.com ([173.37.183.86]) with mapi id 14.03.0123.003; Sat, 23 Nov 2013 04:35:02 -0600 From: "Satyanarayana Danda (sdanda)" To: Glen Zorn Thread-Topic: [Dime] RAR Message with possible ReAuth-Request_type Thread-Index: Ac7oN6lXuhtLNIIGSNGrl67uVaT0Vg== Date: Sat, 23 Nov 2013 10:35:02 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.142.106.121] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: "dime@ietf.org" Subject: Re: [Dime] RAR Message with possible ReAuth-Request_type X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Nov 2013 10:35:13 -0000 Hi Glen, Thanks and appreciate your quick response! I would like to just validate the user credentials (Authentication) and not= expecting any profile to be downloaded. I am looking for a use-case like this. 1. Authorization Request from NAS with the MAC Address (supposed to be fail= ed) 2. Apply HTTP Redirect on the NAS, so that subscriber will be redirected to= a portal upon first ip traffic seen 3. Subscriber will be prompted for credentials via web login page 4. Portal/Diameter Server pushes RA-R to NAS with the subscriber credential= s 5. NAS would send AA-R just to validate the credentials, not expecting any = profile to be downloaded as part of this. (Just credential validation - Authentication only) 6. Upon Successful authentication, NAS sends CCR-I to PCRF to download the = policy information. (This is real authorization step) Thanks Satya -----Original Message----- From: Glen Zorn [mailto:glenzorn@gmail.com]=20 Sent: Saturday, November 23, 2013 1:57 PM To: Satyanarayana Danda (sdanda) Cc: dime@ietf.org; glenzorn@gmail.com Subject: Re: [Dime] RAR Message with possible ReAuth-Reqiest_type On 11/23/2013 03:06 PM, Satyanarayana Danda (sdanda) wrote: > Hi folks, > > I am looking for a case where *Re-Auth-Request* is sent to NAS with=20 > subscriber credentials captured via web Portal (web-logon) case. > > From RFC 6733, we do have two options set in *ReAuth-Request-Type*=20 > AVP of the action expected. From my use-case standpoint, I would like=20 > to inform > > NAS to take *AUTHENTICATE_ONLY* action by sending AA-Request for=20 > credential validation. > > Since this is not specified as part of this RFC, do you see this needs=20 > to be addressed? > > Please let me know in case you want more details on the use-case. I would like more details. In particular, why do you believe that authoriz= ation in unnecessary? > > Thanks > > Satya > > > > > > Re-Auth-Request-Type AVP > > > > The Re-Auth-Request-Type AVP (AVP Code 285) is of type Enumerated=20 > and > > is included in application-specific auth answers to inform the=20 > client > > of the action expected upon expiration of the Authorization-Lifetime. > > > > If the answer message contains an Authorization-Lifetime AVP with=20 > a > > positive value, the Re-Auth-Request-Type AVP MUST be present in an > > answer message. The following values are defined: > > > > AUTHORIZE_ONLY 0 > > > > An authorization only re-auth is expected upon expiration of=20 > the > > Authorization-Lifetime. This is the default value if the AVP=20 > is > > not present in answer messages that include the Authorization- > > Lifetime. > > > > AUTHORIZE_AUTHENTICATE 1 > > > > An authentication and authorization re-auth is expected upon > > expiration of the Authorization-Lifetime. > > > > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime > From jouni.nospam@gmail.com Sat Nov 23 11:27:54 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F5841AE212 for ; Sat, 23 Nov 2013 11:27:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Oy7RMy29g52s for ; Sat, 23 Nov 2013 11:27:52 -0800 (PST) Received: from mail-bk0-x22c.google.com (mail-bk0-x22c.google.com [IPv6:2a00:1450:4008:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id DDB4A1AE0B0 for ; Sat, 23 Nov 2013 11:27:51 -0800 (PST) Received: by mail-bk0-f44.google.com with SMTP id d7so1254304bkh.17 for ; Sat, 23 Nov 2013 11:27:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:content-type:content-transfer-encoding:subject:date:references :to:message-id:mime-version; bh=gV9B//qnVGzdWas7MyLJ5YDeayxlAf8KzF/LbVmU/xY=; b=tNqz+Qq+fpBnGEf6yjKVFoCwOJ+MkmFG/dYJYomjJD3upDk9UHth9mWp3eaKPE92EL TXYdvJm8y5ZsmQR1HDoLsd58KUNqtqCKkRBtjKFozQ1XiY+9dNmlRktnSEFhy3Rwd9Uj IwMbVMp914VESPynEnfnnwYYKoCivA9xVfvGO+oir9EoARqvY2iMxfOExXgNifSOBdx5 xET1GbEZ7Va10+oR0MtJVFlUhmRuz5qx/s6k+TKQuNMM9kxrsJE5gURfFa8LaKKbCvOH HOAw1oFd1mpfT8IR5zqhZod0DCaLxnA6GrmJgCwn0EdcLKti+6D6rrsJQlsIZiClAzsC luzQ== X-Received: by 10.204.226.135 with SMTP id iw7mr16078829bkb.4.1385234862645; Sat, 23 Nov 2013 11:27:42 -0800 (PST) Received: from ?IPv6:2001:1bc8:101:f101:5844:832a:3ee2:ec59? ([2001:1bc8:101:f101:5844:832a:3ee2:ec59]) by mx.google.com with ESMTPSA id b7sm37437162bkg.1.2013.11.23.11.27.37 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 23 Nov 2013 11:27:38 -0800 (PST) From: Jouni Korhonen Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Date: Sat, 23 Nov 2013 21:27:39 +0200 References: <20131122183214.93D6C75E01C@rfc-editor.org> To: "dime@ietf.org" , "Tina TSOU (Tina.Tsou.Zouting@huawei.com)" , Tom Taylor , "Hao, Ruibing" Message-Id: <5568B6BE-840B-4E8F-9D11-A2AFD44925E8@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\)) X-Mailer: Apple Mail (2.1510) Subject: [Dime] Fwd: RFC 7075 on Realm-Based Redirection In Diameter X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Nov 2013 19:27:54 -0000 Congrats! It took some time but now it's out ;-) Begin forwarded message: > From: rfc-editor@rfc-editor.org > Subject: RFC 7075 on Realm-Based Redirection In Diameter > Date: November 22, 2013 8:32:14 PM GMT+02:00 > To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org > Cc: drafts-update-ref@iana.org, dime@ietf.org, = rfc-editor@rfc-editor.org > Reply-To: ietf@ietf.org >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 7075 >=20 > Title: Realm-Based Redirection In Diameter=20 > Author: T. Tsou,=20 > R. Hao, > T. Taylor, Ed. > Status: Standards Track > Stream: IETF > Date: November 2013 > Mailbox: tina.tsou.zouting@huawei.com,=20 > ruibing_hao@cable.comcast.com,=20 > tom.taylor.stds@gmail.com > Pages: 10 > Characters: 21434 > Updates: RFC 6733 >=20 > I-D Tag: draft-ietf-dime-realm-based-redirect-13.txt >=20 > URL: http://www.rfc-editor.org/rfc/rfc7075.txt >=20 > The Diameter protocol includes a capability for message redirection, > controlled by an application-independent "redirect agent". In some > circumstances, an operator may wish to redirect messages to an > alternate domain without specifying individual hosts. This document > specifies an application-specific mechanism by which a Diameter > server or proxy (node) can perform such a redirection when the > Straightforward-Naming Authority Pointer (S-NAPTR) is not used for > dynamic peer discovery. A node performing this new function is > referred to as a "Realm-based Redirect Server". >=20 > This memo updates Sections 6.13 and 6.14 of RFC 6733 with respect to > the usage of the Redirect-Host-Usage and Redirect-Max-Cache-Time > Attribute-Value Pairs (AVPs). >=20 > This document is a product of the Diameter Maintenance and Extensions = Working Group of the IETF. >=20 > This is now a Proposed Standard. >=20 > STANDARDS TRACK: This document specifies an Internet standards track > protocol for the Internet community,and requests discussion and = suggestions > for improvements. Please refer to the current edition of the Internet > Official Protocol Standards (STD 1) for the standardization state and > status of this protocol. Distribution of this memo is unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > http://www.ietf.org/mailman/listinfo/ietf-announce > http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >=20 > For searching the RFC series, see = http://www.rfc-editor.org/search/rfc_search.php > For downloading RFCs, see http://www.rfc-editor.org/rfc.html >=20 > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. = Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 >=20 From Tina.Tsou.Zouting@huawei.com Sat Nov 23 11:30:39 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A42661AE0B0 for ; Sat, 23 Nov 2013 11:30:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.726 X-Spam-Level: X-Spam-Status: No, score=-4.726 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.525, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XBteyUgQK-hp for ; Sat, 23 Nov 2013 11:30:37 -0800 (PST) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 493A01AE212 for ; Sat, 23 Nov 2013 11:30:36 -0800 (PST) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id BAQ07749; Sat, 23 Nov 2013 19:30:27 +0000 (GMT) Received: from LHREML403-HUB.china.huawei.com (10.201.5.217) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 23 Nov 2013 19:29:14 +0000 Received: from SJCEML402-HUB.china.huawei.com (10.212.94.43) by lhreml403-hub.china.huawei.com (10.201.5.217) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 23 Nov 2013 19:29:31 +0000 Received: from SJCEML501-MBS.china.huawei.com ([169.254.2.242]) by sjceml402-hub.china.huawei.com ([10.212.94.43]) with mapi id 14.03.0158.001; Sat, 23 Nov 2013 11:29:24 -0800 From: Tina TSOU To: Jouni Korhonen , "dime@ietf.org" , Tom Taylor , "Hao, Ruibing" Thread-Topic: RFC 7075 on Realm-Based Redirection In Diameter Thread-Index: AQHO57LPB3mNlewzME2biZP4/GmmhpozNNbXgAAAGMA= Date: Sat, 23 Nov 2013 19:29:25 +0000 Message-ID: References: <20131122183214.93D6C75E01C@rfc-editor.org> <5568B6BE-840B-4E8F-9D11-A2AFD44925E8@gmail.com> In-Reply-To: <5568B6BE-840B-4E8F-9D11-A2AFD44925E8@gmail.com> Accept-Language: en-US, zh-CN Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.212.244.13] Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: Re: [Dime] RFC 7075 on Realm-Based Redirection In Diameter X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Nov 2013 19:30:39 -0000 RGVhciBhbGwsDQpDb29sISBJIHdvdWxkIGxpa2UgdG8gdGFrZSB0aGlzIG9wcG9ydHVuaXR5IHNh eSB0aGFuayB5b3UgZXZlcnlvbmUgYXMgVGhhbmtzZ2l2aW5nIGlzIGNvbWluZy4NCg0KVGhhbmsg eW91LA0KVGluYQ0KDQoNCj4gLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCj4gRnJvbTogSm91 bmkgS29yaG9uZW4gW21haWx0bzpqb3VuaS5ub3NwYW1AZ21haWwuY29tXQ0KPiBTZW50OiAyMDEz xOoxMdTCMjPI1SAxMToyOA0KPiBUbzogZGltZUBpZXRmLm9yZzsgVGluYSBUU09VOyBUb20gVGF5 bG9yOyBIYW8sIFJ1aWJpbmcNCj4gU3ViamVjdDogRndkOiBSRkMgNzA3NSBvbiBSZWFsbS1CYXNl ZCBSZWRpcmVjdGlvbiBJbiBEaWFtZXRlcg0KPiANCj4gDQo+IENvbmdyYXRzISBJdCB0b29rIHNv bWUgdGltZSBidXQgbm93IGl0J3Mgb3V0IDstKQ0KPiANCj4gDQo+IEJlZ2luIGZvcndhcmRlZCBt ZXNzYWdlOg0KPiANCj4gPiBGcm9tOiByZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnDQo+ID4gU3Vi amVjdDogUkZDIDcwNzUgb24gUmVhbG0tQmFzZWQgUmVkaXJlY3Rpb24gSW4gRGlhbWV0ZXINCj4g PiBEYXRlOiBOb3ZlbWJlciAyMiwgMjAxMyA4OjMyOjE0IFBNIEdNVCswMjowMA0KPiA+IFRvOiBp ZXRmLWFubm91bmNlQGlldGYub3JnLCByZmMtZGlzdEByZmMtZWRpdG9yLm9yZw0KPiA+IENjOiBk cmFmdHMtdXBkYXRlLXJlZkBpYW5hLm9yZywgZGltZUBpZXRmLm9yZywNCj4gPiByZmMtZWRpdG9y QHJmYy1lZGl0b3Iub3JnDQo+ID4gUmVwbHktVG86IGlldGZAaWV0Zi5vcmcNCj4gPg0KPiA+IEEg bmV3IFJlcXVlc3QgZm9yIENvbW1lbnRzIGlzIG5vdyBhdmFpbGFibGUgaW4gb25saW5lIFJGQyBs aWJyYXJpZXMuDQo+ID4NCj4gPg0KPiA+ICAgICAgICBSRkMgNzA3NQ0KPiA+DQo+ID4gICAgICAg IFRpdGxlOiAgICAgIFJlYWxtLUJhc2VkIFJlZGlyZWN0aW9uIEluIERpYW1ldGVyDQo+ID4gICAg ICAgIEF1dGhvcjogICAgIFQuIFRzb3UsDQo+ID4gICAgICAgICAgICAgICAgICAgIFIuIEhhbywN Cj4gPiAgICAgICAgICAgICAgICAgICAgVC4gVGF5bG9yLCBFZC4NCj4gPiAgICAgICAgU3RhdHVz OiAgICAgU3RhbmRhcmRzIFRyYWNrDQo+ID4gICAgICAgIFN0cmVhbTogICAgIElFVEYNCj4gPiAg ICAgICAgRGF0ZTogICAgICAgTm92ZW1iZXIgMjAxMw0KPiA+ICAgICAgICBNYWlsYm94OiAgICB0 aW5hLnRzb3Uuem91dGluZ0BodWF3ZWkuY29tLA0KPiA+ICAgICAgICAgICAgICAgICAgICBydWli aW5nX2hhb0BjYWJsZS5jb21jYXN0LmNvbSwNCj4gPiAgICAgICAgICAgICAgICAgICAgdG9tLnRh eWxvci5zdGRzQGdtYWlsLmNvbQ0KPiA+ICAgICAgICBQYWdlczogICAgICAxMA0KPiA+ICAgICAg ICBDaGFyYWN0ZXJzOiAyMTQzNA0KPiA+ICAgICAgICBVcGRhdGVzOiAgICBSRkMgNjczMw0KPiA+ DQo+ID4gICAgICAgIEktRCBUYWc6ICAgIGRyYWZ0LWlldGYtZGltZS1yZWFsbS1iYXNlZC1yZWRp cmVjdC0xMy50eHQNCj4gPg0KPiA+ICAgICAgICBVUkw6ICAgICAgICBodHRwOi8vd3d3LnJmYy1l ZGl0b3Iub3JnL3JmYy9yZmM3MDc1LnR4dA0KPiA+DQo+ID4gVGhlIERpYW1ldGVyIHByb3RvY29s IGluY2x1ZGVzIGEgY2FwYWJpbGl0eSBmb3IgbWVzc2FnZSByZWRpcmVjdGlvbiwNCj4gPiBjb250 cm9sbGVkIGJ5IGFuIGFwcGxpY2F0aW9uLWluZGVwZW5kZW50ICJyZWRpcmVjdCBhZ2VudCIuICBJ biBzb21lDQo+ID4gY2lyY3Vtc3RhbmNlcywgYW4gb3BlcmF0b3IgbWF5IHdpc2ggdG8gcmVkaXJl Y3QgbWVzc2FnZXMgdG8gYW4NCj4gPiBhbHRlcm5hdGUgZG9tYWluIHdpdGhvdXQgc3BlY2lmeWlu ZyBpbmRpdmlkdWFsIGhvc3RzLiAgVGhpcyBkb2N1bWVudA0KPiA+IHNwZWNpZmllcyBhbiBhcHBs aWNhdGlvbi1zcGVjaWZpYyBtZWNoYW5pc20gYnkgd2hpY2ggYSBEaWFtZXRlciBzZXJ2ZXINCj4g PiBvciBwcm94eSAobm9kZSkgY2FuIHBlcmZvcm0gc3VjaCBhIHJlZGlyZWN0aW9uIHdoZW4gdGhl DQo+ID4gU3RyYWlnaHRmb3J3YXJkLU5hbWluZyBBdXRob3JpdHkgUG9pbnRlciAoUy1OQVBUUikg aXMgbm90IHVzZWQgZm9yDQo+ID4gZHluYW1pYyBwZWVyIGRpc2NvdmVyeS4gIEEgbm9kZSBwZXJm b3JtaW5nIHRoaXMgbmV3IGZ1bmN0aW9uIGlzDQo+ID4gcmVmZXJyZWQgdG8gYXMgYSAiUmVhbG0t YmFzZWQgUmVkaXJlY3QgU2VydmVyIi4NCj4gPg0KPiA+IFRoaXMgbWVtbyB1cGRhdGVzIFNlY3Rp b25zIDYuMTMgYW5kIDYuMTQgb2YgUkZDIDY3MzMgd2l0aCByZXNwZWN0IHRvDQo+ID4gdGhlIHVz YWdlIG9mIHRoZSBSZWRpcmVjdC1Ib3N0LVVzYWdlIGFuZCBSZWRpcmVjdC1NYXgtQ2FjaGUtVGlt ZQ0KPiA+IEF0dHJpYnV0ZS1WYWx1ZSBQYWlycyAoQVZQcykuDQo+ID4NCj4gPiBUaGlzIGRvY3Vt ZW50IGlzIGEgcHJvZHVjdCBvZiB0aGUgRGlhbWV0ZXIgTWFpbnRlbmFuY2UgYW5kIEV4dGVuc2lv bnMNCj4gV29ya2luZyBHcm91cCBvZiB0aGUgSUVURi4NCj4gPg0KPiA+IFRoaXMgaXMgbm93IGEg UHJvcG9zZWQgU3RhbmRhcmQuDQo+ID4NCj4gPiBTVEFOREFSRFMgVFJBQ0s6IFRoaXMgZG9jdW1l bnQgc3BlY2lmaWVzIGFuIEludGVybmV0IHN0YW5kYXJkcyB0cmFjaw0KPiA+IHByb3RvY29sIGZv ciB0aGUgSW50ZXJuZXQgY29tbXVuaXR5LGFuZCByZXF1ZXN0cyBkaXNjdXNzaW9uIGFuZA0KPiA+ IHN1Z2dlc3Rpb25zIGZvciBpbXByb3ZlbWVudHMuICBQbGVhc2UgcmVmZXIgdG8gdGhlIGN1cnJl bnQgZWRpdGlvbiBvZg0KPiA+IHRoZSBJbnRlcm5ldCBPZmZpY2lhbCBQcm90b2NvbCBTdGFuZGFy ZHMgKFNURCAxKSBmb3IgdGhlDQo+ID4gc3RhbmRhcmRpemF0aW9uIHN0YXRlIGFuZCBzdGF0dXMg b2YgdGhpcyBwcm90b2NvbC4gIERpc3RyaWJ1dGlvbiBvZg0KPiB0aGlzIG1lbW8gaXMgdW5saW1p dGVkLg0KPiA+DQo+ID4gVGhpcyBhbm5vdW5jZW1lbnQgaXMgc2VudCB0byB0aGUgSUVURi1Bbm5v dW5jZSBhbmQgcmZjLWRpc3QgbGlzdHMuDQo+ID4gVG8gc3Vic2NyaWJlIG9yIHVuc3Vic2NyaWJl LCBzZWUNCj4gPiAgaHR0cDovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2lldGYtYW5u b3VuY2UNCj4gPiAgaHR0cDovL21haWxtYW4ucmZjLWVkaXRvci5vcmcvbWFpbG1hbi9saXN0aW5m by9yZmMtZGlzdA0KPiA+DQo+ID4gRm9yIHNlYXJjaGluZyB0aGUgUkZDIHNlcmllcywgc2VlDQo+ ID4gaHR0cDovL3d3dy5yZmMtZWRpdG9yLm9yZy9zZWFyY2gvcmZjX3NlYXJjaC5waHANCj4gPiBG b3IgZG93bmxvYWRpbmcgUkZDcywgc2VlIGh0dHA6Ly93d3cucmZjLWVkaXRvci5vcmcvcmZjLmh0 bWwNCj4gPg0KPiA+IFJlcXVlc3RzIGZvciBzcGVjaWFsIGRpc3RyaWJ1dGlvbiBzaG91bGQgYmUg YWRkcmVzc2VkIHRvIGVpdGhlciB0aGUNCj4gPiBhdXRob3Igb2YgdGhlIFJGQyBpbiBxdWVzdGlv biwgb3IgdG8gcmZjLWVkaXRvckByZmMtZWRpdG9yLm9yZy4NCj4gPiBVbmxlc3Mgc3BlY2lmaWNh bGx5IG5vdGVkIG90aGVyd2lzZSBvbiB0aGUgUkZDIGl0c2VsZiwgYWxsIFJGQ3MgYXJlDQo+ID4g Zm9yIHVubGltaXRlZCBkaXN0cmlidXRpb24uDQo+ID4NCj4gPg0KPiA+IFRoZSBSRkMgRWRpdG9y IFRlYW0NCj4gPiBBc3NvY2lhdGlvbiBNYW5hZ2VtZW50IFNvbHV0aW9ucywgTExDDQo+ID4NCj4g Pg0KDQo= From bclaise@cisco.com Mon Nov 25 03:18:42 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70C0A1AD7BE for ; Mon, 25 Nov 2013 03:18:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.502 X-Spam-Level: X-Spam-Status: No, score=-9.502 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id C5OyxLmaBsW5 for ; Mon, 25 Nov 2013 03:18:41 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) by ietfa.amsl.com (Postfix) with ESMTP id DB3441ACCF0 for ; Mon, 25 Nov 2013 03:18:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=108; q=dns/txt; s=iport; t=1385378319; x=1386587919; h=message-id:date:from:mime-version:to:subject: content-transfer-encoding; bh=Z9Lo0foOva67tVqGiPs+b1JXHFFFmY8HjxAYMmhzZsI=; b=Q6ynfHqdpF3pKW0XbN2e9AsA8CIvuzdpfPVHtFKQ5hA+SAVb6tCpJR2U EbspTQ1/4YvixF1WVEe2YJ5+Y8u3Mq8mlSmaqd1pXS3NN9wfHWr75wHQj RGxDP47YxackbMsz5q1QVPjeoOnmFT5gOFWqWDPIPsbbnAvBbmEWSDIl0 E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ah8FAAkxk1KQ/khL/2dsb2JhbABZgwe+XBZ0gmRAPRYYAwIBAgFLDQgBARCHbZ1fn32TQQOYFIZEi06DKTs X-IronPort-AV: E=Sophos;i="4.93,767,1378857600"; d="scan'208";a="587152" Received: from ams-core-2.cisco.com ([144.254.72.75]) by aer-iport-2.cisco.com with ESMTP; 25 Nov 2013 11:18:38 +0000 Received: from [10.60.67.86] (ams-bclaise-8915.cisco.com [10.60.67.86]) by ams-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id rAPBIVWj004473 for ; Mon, 25 Nov 2013 11:18:33 GMT Message-ID: <52933207.8000205@cisco.com> Date: Mon, 25 Nov 2013 12:18:31 +0100 From: Benoit Claise User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.1.1 MIME-Version: 1.0 To: dime mailing list Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Dime] New RFC 7068 and RFC 7075 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 11:18:42 -0000 Congrats to the community, WG chairs, document shepherds, and obviously the authors! Regards, Benoit From ben@nostrum.com Tue Nov 26 11:56:57 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 06A421ADF9B; Tue, 26 Nov 2013 11:56:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.036 X-Spam-Level: X-Spam-Status: No, score=-1.036 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SBQTa8VsLCTE; Tue, 26 Nov 2013 11:56:56 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id E132A1ADF93; Tue, 26 Nov 2013 11:56:55 -0800 (PST) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rAQJukhr094284 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Tue, 26 Nov 2013 13:56:48 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=iso-8859-1 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ben Campbell In-Reply-To: <5BCBA1FC2B7F0B4C9D935572D900066815192D5F@DEMUMBX014.nsn-intra.net> Date: Tue, 26 Nov 2013 13:56:45 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: References: <5BCBA1FC2B7F0B4C9D935572D9000668151918EC@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192B2B@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192B90@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192BF7@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192CD2@DEMUMBX014.nsn-intra.net> <5BCBA1FC2B7F0B4C9D935572D900066815192D5F@DEMUMBX014.nsn-intra.net> To: "Wiehe, Ulrich (NSN - DE/Munich)" X-Mailer: Apple Mail (2.1822) Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism) Cc: "dime@ietf.org" , "doc-dt@ietf.org" Subject: Re: [Dime] Ongoing Throttling Information in request messages X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 19:56:57 -0000 On Nov 7, 2013, at 4:23 AM, Wiehe, Ulrich (NSN - DE/Munich) = wrote: > Furthermore you seem not to take REQ 10 seriously. My understanding = was that timeout is last resort, not the normal way. I disagree with that conclusion. Quoting RFC 7068: > Consumers of overload information MUST be able to determine > when the overload condition improves or ends. That text does not contemplate any particular mechanism, e.g. timeouts = vs explicit notification. It merely requires that a mechanism exists. = The solution draft actually has _two_ mechanism for this (i.e. timeouts = and explicit notification.) It's up to the implementation to figure out = the exact details. Sure, it would be bad form for a node to declare an = hour long overload period, have it resolve in a few seconds, and then = leave the reacting nodes hanging for the rest of the hour. OTOH, I see nothing wrong at the protocol level with Nirav's case of = having a short timeout, and just letting it expire. Whether it's the = most efficient approach is another issue. We might offer guidance on = that, but I would expect such guidance to be non-normative advice. From ben@nostrum.com Tue Nov 26 12:20:52 2013 Return-Path: X-Original-To: dime@ietfa.amsl.com Delivered-To: dime@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B13ED1AE057 for ; Tue, 26 Nov 2013 12:20:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.164 X-Spam-Level: X-Spam-Status: No, score=0.164 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_25=0.6, J_CHICKENPOX_36=0.6] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zpnkHW9-qY2K for ; Tue, 26 Nov 2013 12:20:50 -0800 (PST) Received: from shaman.nostrum.com (nostrum-pt.tunnel.tserv2.fmt.ipv6.he.net [IPv6:2001:470:1f03:267::2]) by ietfa.amsl.com (Postfix) with ESMTP id 243C11ADF54 for ; Tue, 26 Nov 2013 12:20:50 -0800 (PST) Received: from [10.0.1.29] (cpe-173-172-146-58.tx.res.rr.com [173.172.146.58]) (authenticated bits=0) by shaman.nostrum.com (8.14.3/8.14.3) with ESMTP id rAQKKmCe095341 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO) for ; Tue, 26 Nov 2013 14:20:49 -0600 (CST) (envelope-from ben@nostrum.com) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) From: Ben Campbell In-Reply-To: <66DEB166-8DEB-42CA-A46E-8128F0D0900B@nostrum.com> Date: Tue, 26 Nov 2013 14:20:47 -0600 Content-Transfer-Encoding: quoted-printable Message-Id: <4CFE9D80-E25A-4B8F-96D1-EB7C21F2F11A@nostrum.com> References: <66DEB166-8DEB-42CA-A46E-8128F0D0900B@nostrum.com> To: "dime@ietf.org list" X-Mailer: Apple Mail (2.1822) Received-SPF: pass (shaman.nostrum.com: 173.172.146.58 is authenticated by a trusted mechanism) Subject: Re: [Dime] Proposed Example Text for draft-docdt-dime-ovli-01 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2013 20:20:52 -0000 [I've received a number of in-person comments on this, but non on the = list. Given that I will never remember everything people said to me when = traveling, I'd appreciate it if people would repeat their comments on = list. Failing to do so risks me describing your argument incorrectly; = resulting in an unintentional strawman. ] That being said, if I understand the comments correctly, there are a few = major open questions here: 1) Is this a real problem? Several people argued to me that, if the agent load intelligently load = balances traffic across all the servers, then the servers should become = overloaded roughly at the same time. OTOH, certain sessions may have = much more traffic than other sessions. If these "big" sessions are = distributed proportionately across the servers, load should still be = fairly balanced. IMHO, we cannot assume smart load balancing, as there is no standard for = doing it. Our solution should still work for agents that use simple (and = perhaps naive) load distributions strategies. But even if we do have = super-smart load balancing, things like hardware failures can throw = things out of balance. Also, the argument that "big" sessions should = still be proportionately distributed only works if you have a large = enough sample of "big" sessions to distribute, compared to the number of = servers. That may be true most of the time, but I don't think we want a = solution that fails if it's not true. 2) Lionel argued that OLRs are best used to describe overload for the = realm as a whole. Overload for specific nodes would be better handled by = sending Diameter error codes, either by fixing one or more existing = error codes to have the correct semantics, or introducing new ones. If = we did this, we would not need different report types. My opinion is that I would like a consistent way of reporting overload, = that is, I don't like using OLRs for one kind of overload, and error = result codes for another. In particular, I would like to be able to = report overload before reaching the point that I need to fail a = transaction, i.e. I would like to be able to report any kind of overload = in a Diameter answer message with a result code of DIAMETER_SUCCESS. 3) Are we allowed to put more than one OLRs in a single answer, as my = example shows in step 8? It might be possible to construct an example where you never see more = than one OLR in a single answer. But I don't see what purpose would be = served by such a limitation, as long as multiple OLRs do not contradict = each other. Since the reports in the example have different report = types, there is no conflict. On disadvantage of _not_ allowing multiple = reports in one answer is that, if the servers choose to send reports in = every answer, life gets complicated for the agent when trying to find a = place to put the "realm" report. It either needs to strip the server = reports (which is hard given that the server overload conditions are = best handled by the clients.) Or it needs to originate its own answers, = which means forcing the failure of at least some transactions. On Nov 4, 2013, at 6:36 PM, Ben Campbell wrote: > Hi, >=20 > draft-docdt-dime-ovli-01 has a TBD item in appendix C, section 3. = Namely, an example showing a mix of Destination-Realm and = Destination-Host routed requests. Here's a straw man proposal for that = example. I don't expect this to be the "one true way" to approach the = scenario; rather, it's a possible way to do it, and there are likely = other ways as well. >=20 > Comments solicited. >=20 > Thanks! >=20 > Ben. >=20 > ---------------------------- >=20 > C.3. Mix of Destination-Realm routed requests and Destination-Host > reouted requests >=20 > Diameter allows a client to optionally select the destination = server > of a request, even if there are agents between the client and the > server. The client does this using the Destination-Host AVP. In > cases where the client does not care if a specific server receives > the request, it can omit Destination-Host and route the request = using > the Destination-Realm and ApplicationId AVPs, effectively letting = an > agent select the server. >=20 > Clients commonly send mixtures of Destination-Host and Destination- > Realm routed requests. For example, in an application that uses = user > sessions, a client typically won't care which server handles a > session-initiating requests. But once the session is initiated, = the > client will send all subsequent requests in that session to the = same > server. Therefore it would send the initial request with no > Destination-Host AVP. If it receives a successful answer, the = client > would copy the Origin-Host value from the answer message into a > Destination-Host AVP in each subsequent request in the session. >=20 > An agent has very limited options in applying overload abatement to > requests that contain Destination-Host AVPs. It typically cannot > route the request to a different server than the one identified in > Destination-Host. It's only remaining options are to throttle such > requests locally, or to send an overload report back towards the > client so the client can throttle the requests. The second choice = is > usually more efficient, since it prevents any throttled requests = from > being sent in the first place, and removes the agent's need to send > errors back to the client for each dropped request. >=20 > On the other hand, an agent has much more leeway to apply overload > abatement for requests that do not contain Destination-Host AVPs. = If > the agent has multiple servers in its peer table for the given = realm > and application, it can route such requests to other, less = overloaded > servers. >=20 > If the overload severity increases, the agent may reach a point = where > there is not sufficient capacity across all servers to handle even >=20 >=20 >=20 > Korhonen, et al. Expires May 03, 2014 [Page = 35] > Internet-Draft DOIC October = 2013 >=20 >=20 > realm-routed requests. In this case, the realm itself can be > considered overloaded. The agent may need the client to throttle > realm-routed requests in addition to Destination-Host routed > requests. The overload severity may be different for each server, > and the severity for the realm at is likely to be different than = for > any specific server. Therefore, an agent may need to forward, or > originate, multiple overload reports with differing ReportType and > Reduction-Percentage values. >=20 > Figure 8 illustrates such a mixed-routing scenario. In this = example, > the servers S1, S2, and S3 handle requests for the realm "realm". > Any of the three can handle requests that are not part of a user > session (i.e. routed by Destination-Realm). But once a session is > established, all requests in that session must go to the same = server. >=20 > Client Agent S1 S2 S3 > | | | | | > | | | | | > | | | | | > |(1) Request (DR:realm) | | > |-------->| | | | > | | | | | > | | | | | > | |Agent selects S1 | | > | | | | | > | | | | | > | | | | | > | |(2) Request (DR:realm) | > | |-------->| | | > | | | | | > | | | | | > | | |S1 overloaded, returns OLR > | | | | | > | | | | | > | | | | | > | |(3) Answer (OR:realm,OH:S1,OLR:RT=3DDH) > | |<--------| | | > | | | | | > | | | | | > | |sees OLR,routes DR traffic to S2&S3 > | | | | | > | | | | | > | | | | | > |(4) Answer (OR:realm,OH:S1, OLR:RT=3DDH) | > |<--------| | | | > | | | | | > | | | | | > |Client throttles requests with DH:S1 | > | | | | | > | | | | | > | | | | | > |(5) Request (DR:realm) | | > |-------->| | | | > | | | | | > | | | | | > | |Agent selects S2 | | > | | | | | > | | | | | > | | | | | > | |(6) Request (DR:realm) | > | |------------------>| | > | | | | | > | | | | | > | | | |S2 is = overloaded... > | | | | | > | | | | | > | | | | | > | |(7) Answer (OH:S2, OLR:RT=3DDH)| > | |<------------------| | > | | | | | > | | | | | > | |Agent sees OLR, realm now overloaded > | | | | | > | | | | | > | | | | | > |(8) Answer (OR:realm,OH:S2, OLR:RT=3DDH, OLR: = RT=3DR) > |<--------| | | | > | | | | | > | | | | | > |Client throttles DH:S1, DH:S2, and DR:realm > | | | | | > | | | | | > | | | | | > | | | | | > | | | | | >=20 >=20 > Figure 8: Mix of Destination-Host and Destination-Realm Routed > Requests >=