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.

= ;

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

= ;

Regards,

= ;

Lionel

= ;

   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; | agent A2 |------| agen= t A3 |----| S |

&= nbsp; &n= bsp; +----------------+ +--------= ----+ +---------+

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.
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.
A3 stores the 10% throttling req= uest.
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.
S recognizes that cor= rect throttling (correct time stamp) is in place and therefore does not ret= urn OC-OLR in the answer.
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.
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.
A1 stores the 10% throttling request.
S recognizes that correct throttling (correct time stamp) is = in place and therefore does not return OC-OLR in the answer.
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.
Over= load situation in S for some reason gets worse, S decides to request 20 % r= eduction.
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.
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.
A3 (not taking the role of the reactingt node)may, A1 must store= the 20% throttling request (replacing the 10% request).
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)
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.
A3 stores the 20% throttling request (replac= ing the 10% request).
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; | 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; = | 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>

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,

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>

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.

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.

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; = | agent A2 |------| agent A3 = ; |----| S |

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

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

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.

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

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.=

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

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,

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.

= ;

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.

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.

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; | agent A2 |------| agen= t A3 |----| S |

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

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

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

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

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.

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

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>

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

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>

Ulrich,=

<= /p>

Thanks for the detail exp= lanation of your proposal.

<= /p>

Just to verify my underst= anding,

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>

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.

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.

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; = | agent A2 |------| agent A3 = ; |----| S |

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

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

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.

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

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.=

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

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:

<snip>

Re-Auth-Request-Type AVP