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 61F5812DE2F for ; Tue, 21 Jun 2016 14:47:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.139 X-Spam-Level: X-Spam-Status: No, score=-0.139 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_FONT_FACE_BAD=0.981, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5A0HRsevVUoz for ; Tue, 21 Jun 2016 14:47:14 -0700 (PDT) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [74.124.197.190]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9F98212D63E for ; Tue, 21 Jun 2016 14:47:14 -0700 (PDT) Received: from cpe-97-99-50-102.tx.res.rr.com ([97.99.50.102]:51715 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:DHE-RSA-AES256-SHA:256) (Exim 4.86_1) (envelope-from ) id 1bFTVl-002E20-Ci; Tue, 21 Jun 2016 14:47:14 -0700 To: lionel.morand@orange.com, Maria Cruz Bartolome , "dime@ietf.org" References: <5bba2470-8921-f7db-0f1b-aad280eae684@gmail.com> <087A34937E64E74E848732CFF8354B92181E2DAF@ESESSMB101.ericsson.se> <0f981f69-cea1-6cc4-6837-213d27649963@usdonovans.com> <087A34937E64E74E848732CFF8354B92181F08F6@ESESSMB101.ericsson.se> <77df2a07-ca55-df36-30bb-87a2ff506418@usdonovans.com> <087A34937E64E74E848732CFF8354B92181F1907@ESESSMB101.ericsson.se> <004a3446-c750-05e8-7444-673a14cc10c3@usdonovans.com> <087A34937E64E74E848732CFF8354B92181F1F8F@ESESSMB101.ericsson.se> <6945_1465823177_575EAFC9_6945_1776_1_6B7134B31289DC4FAF731D844122B36E01EB0E02@OPEXCLILM43.corporate.adroot.infra.ftgroup> <30422_1465849510_575F16A6_30422_8006_1_6B7134B31289DC4FAF731D844122B36E01EB11F4@OPEXCLILM43.corporate.adroot.infra.ftgroup> <21294_1465983917_576123AD_21294_1316_1_6B7134B31289DC4FAF731D844122B36E01EB40C2@OPEXCLILM43.corporate.adroot.infra.ftgroup> From: Steve Donovan Message-ID: Date: Tue, 21 Jun 2016 16:47:08 -0500 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.1.1 MIME-Version: 1.0 In-Reply-To: <21294_1465983917_576123AD_21294_1316_1_6B7134B31289DC4FAF731D844122B36E01EB40C2@OPEXCLILM43.corporate.adroot.infra.ftgroup> Content-Type: multipart/alternative; boundary="------------BD008D089BED85CCD300503C" X-OutGoing-Spam-Status: No, score=-0.7 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - biz131.inmotionhosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - usdonovans.com X-Get-Message-Sender-Via: biz131.inmotionhosting.com: authenticated_id: srdonovan@usdonovans.com X-Authenticated-Sender: biz131.inmotionhosting.com: srdonovan@usdonovans.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [Dime] =?utf-8?q?RE=C2=A0=3A_Re=3A_WGLC_=231_for_draft-ietf-dime-?= =?utf-8?q?agent-overload-05?= X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.17 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, 21 Jun 2016 21:47:18 -0000 This is a multi-part message in MIME format. --------------BD008D089BED85CCD300503C Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Lionel, Thanks for the review. See my comments inline. Regards, Steve On 6/15/16 4:45 AM, lionel.morand@orange.com wrote: > Hi, > > As indicated, here is a review of the draft for discussion. > The main focus in my review is the alignment with the RFC7683. > > Regards, > > Lionel > > ********* > 1. Introduction > > [LM] I would start directly the introduction with: > > This document extends the base Diameter endpoint overload > specification to address the case when Diameter Agents become > overloaded. [...] > > [LM] followed by a brief description of the base mechanism and to > better explain then why this document "defines new overload report type". SRD> I'd be happy to copy the abstract to the first paragraph of the introduction. The remainder of the introduction section explains why a new report type is defined. > > > 3.1.3. Agent Chains > > There are also deployment scenarios where there can be multiple > Diameter Agents between Diameter Clients and Diameter Servers. > Examples of this type of deployment include when there are edge > agents between Diameter networks. Another example of this type of > deployment is when there are multiple sets of servers, each > supporting a subset of the Diameter traffic. > > OLD: > > Examples of this type of deployment include when there are edge > agents between Diameter networks. > > NEW: > > Examples of this type of deployment include when there are edge > agents between Diameter networks. SRD> I don't see a suggested change. > > OLD: > > Another example of this type of > deployment is when there are multiple sets of servers, each > supporting a subset of the Diameter traffic. > > NEW: > > Another example of this type of > deployment is when when servers of a domain are grouped in pools, > each pool supporting a subset of the Diameter traffic received by > front-end proxies. SRD> This example has already been removed based on previous comments. > > 3.2. Diameter Endpoint Use Cases > > [LM] In this section, it would be helpful to clearly see what is > different here compared to what is possible with the RFC7683. > For instance, by emphasizing from the beginning the difference between > "host" and "peer" reports and between "end-to-end" and "hop-by-hop". > Otherwise, it would be difficult to understand the title "Diameter > endpoint use cases" in this document. SRD> I'm not seeing the concern here. The section discusses the case when an endpoint would send a peer report. Can you be more specific in suggested wording? > > 5.1.1. Reacting Node Behavior > > When sending a Diameter request a DOIC node that supports the > OC_PEER_REPORT feature MUST include an OC-Supported-Features AVP with > an OC-Feature-Vector AVP with the OC_PEER_REPORT bit set. > > [LM] the "MUST" here is not appropriate. A DOIC node MUST insert the > OC-Supported-Features AVP as per RFC7683. > It is not a new requirement introduced by this document. > It should rather be: "MUST include in the OC-Supported-Features AVP an > OC-Feature-Vector AVP with the OC_PEER_REPORT bit set." SRD> It isn't saying that it must insert the OC-S-F AVP. It is saying it must include the OC-S-F AVP with specific conditions. I don't see the issue. > > Note: The sender of a request can be a Diameter Client or Diameter > Server that originates the Diamter request or a Diameter Agent > that relays the request. > > [LM] Not sure that the NOTE is required here. SRD> I'm okay with removing the note. > > Support for the OC_PEER_REPORT feature does not impact the logic for > setting of other feature bits in the OC-Feature-Vector AVP. > > [LM] not sure it is relevant. If it is, could be more appropriate in > section 6.1.1 SRD> I'm okay with removing this as well. > > When sending a request a DOIC node that supports the OC_PEER_REPORT > feature MUST include an OC-SourceID AVP in the OC-Supported-Features > AVP with its own DiameterIdentity. > > Note: This allows the DOIC nodes in the path of the request to > determine if the indication of support came from a Diameter peer > or if the request traversed a node that does not support the > OC_PEER_REPORT feature. > > [LM] not required as it is explained in the section defining the > OC-SourceID and its use is described in other sections. SRD> The description of SourceID (we agreed to remove the OC- prefix earlier) doesn't not indicate that it MUST be included. As such, I think this requirement is needed. > > When relaying a request that includes an OC-SourceID AVP in the OC- > Supported-Features AVP, a DOIC node that supports the OC_PEER_REPORT > feature must remove the received OC-SourceID AVP and replace it with > an OC-SourceID AVP containing its own Diameter identity. > > [LM] if the comments are accepted, the section could be simplified as > follow: > > NEW: > > When sending a Diameter request, a DOIC node that supports the > OC_PEER_REPORT feature MUST include in the OC-Supported-Features AVP > an OC-Feature-Vector AVP with the OC_PEER_REPORT bit set. The > OC-Supported-Features AVP MUST include an OC-SourceID AVP with the > DOIC node sending the request. > > When relaying a request that includes an OC-SourceID AVP in the OC- > Supported-Features AVP, a DOIC node that supuports the OC_PEER_REPORT > feature must remove the received OC-SourceID AVP and replace it with > an OC-SourceID AVP containing its own Diameter identity. SRD> I propose the following: When sending a Diameter request a DOIC node that supports the OC_PEER_REPORT feature MUST include an OC-Supported-Features AVP with an OC-Feature-Vector AVP with the OC_PEER_REPORT bit set. When sending a request a DOIC node that supports the OC_PEER_REPORT feature MUST include a SourceID AVP in the OC-Supported-Features AVP with its own DiameterIdentity. Note: This allows the DOIC nodes in the path of the request to determine if the indication of support came from a Diameter peer or if the request traversed a node that does not support the OC_PEER_REPORT feature. When an agent relays a request that includes a SourceID AVP in the OC-Supported-Features AVP, a DOIC node that supports the OC_PEER_REPORT feature MUST remove the received SourceID AVP and replace it with a SourceID AVP containing its own Diameter identity. > > 5.1.2. Reporting Node Behavior > > When receiving a request a DOIC node that supports the OC_PEER_REPORT > feature MUST update transaction state with an indication of whether > or not the peer from which the request was received supports the > OC_PEER_REPORT feature. > > Note: The transaction state is used when the DOIC node is acting > as a peer-report reporting node and needs send OC-OLR reports of > type PEER_REPORT in answer messages. The peer overload reports > are only included in answer messages being sent to peers that > support the OC_PEER_REPORT feature. > > [LM] Not sure of the need for the transaction state, that is not > really defined in this document, compared to the OCS entry required by > the RFC7683. > > [LM] the base mechanism is governed by the following requirement in > RFC7683: > > A reporting node MUST NOT include the OC-Supported-Features AVP, > OC-OLR AVP, or any other overload control AVPs defined in extension > documents in response messages for transactions where the request > message does not include the OC-Supported-Features AVP. Lack of the > OC-Supported-Features AVP in the request message indicates that there > is no reacting node for the transaction. > > [LM] is there any need to modify this requirement? > [LM] the NOTE is not required if you follow the RFC7683 SRD> Are you suggesting using OCS as the way to determine if the peer supports the peer report type? > > When relaying an answer message, a reporting node that supports the > OC_PEER_REPORT feature MUST strip any SourceID AVP from the OC- > Supported-Features AVP. > > [LM] I know that it was discussed by Jean but I didn't get the > conclusion: does the node strip any existing sourceID and include its own? SRD> A relay will strip received SourceID information. It will include its own SourceID based on the requirements statement three paragraphs later. > > When sending an answer message, a reporting node that supports the > OC_PEER_REPORT feature MUST determine if the peer to which the answer > is to be sent supports the OC_PEER_REPORT feature. [...] > > [LM] in the rest of the section, the only clarification with the basic > mechanism defined in RFC7683 is on how to check the support of peer > report. Some "MUST" are not appropriate as implicitly required by the > support of RFC7683. SRD> All of the requirements in this section are specific to the peer report. I don't see any that are implicitly required by RFC7683. Can you clarify the concern? > > > 5.2.1. Overload Control State > > [LM] consistency with RFC7683 is important. SRD> Agreed. In general I agree with your suggestions on this section. I will clean up the section to make the reference to RFC7683 stronger and only talk about deltas needed for the peer report. This should make this section much cleaner. I'll send the resulting text in a separate email. > > 5.2.1.1. Reporting Node Peer Report OCS > > > A DOIC Node that supports the OC_PEER_REPORT feature SHOULD maintain > Reporting Node Peer Report OCS. This is used to record overload > events and build overload reports at the reporting node. > > [LM] in the RFC7683, it is said: > > "A reporting node maintains OCS entries per supported Diameter > application, per supported (and eventually selected) abatement > algorithm, and per report type. > > An OCS entry is identified by the tuple of Application-ID, report > type, and abatement algorithm, and it includes the following > information (the actual information stored is an implementation > decision): > > o Sequence number > > o Validity duration > > o Expiration time > > o Input data that is algorithm specific (for example, the reduction > percentage for the loss abatement algorithm)" > > [LM] does it apply for the peer report also? If yes, why do not reuse > the text from RFC7683, with a specific reference? Especially, the mean > for OCS entry identification and notion of "application" disappear in > this document. > > If different abatement specific contents are sent to each peer then > the reporting node MUST maintain a separate peer node peer report OCS > entry per peer to which a peer overload report is sent. > > Note: The rate overload abatement algorithm allows for different > rates to be sent to each peer. > > [LM] not sure that it is required if it is said that there is an OCS > entry per peer from the beginning. > > The Reporting Node Peer Report OCS entry MAY include the following > information (the actual information stored is an implementation > decision): > > [LM] see comment above > > 5.2.1.2. Reacting Node Peer Report OCS > > A DOIC node that supports the OC_PEER_REPORT feature SHOULD maintain > Reacting Node Peer Report OCS for each peer with which it > communicates. This is used to record overload reports received from > peer nodes. > > A Reacting Node Peer Report OCS entry is identified by the > DiameterIdentity of the peer as communicated during the RFC6733 > defined Capability Exchange procedure. > > The Reacting Node Peer Report OCS entry MAY include the following > information (the actual information stored is an implementation > decision): > > o Sequence number > > o Expiration Time > > o Abatement Algorithm > > o Algorithm specific input data (for example, the Reduction > Percentage for the Loss Abatement Algorithm) > > [LM] in RFC7683, we have: > > "A reacting node maintains the following OCS per supported Diameter > application: > > o a host-type OCS entry for each Destination-Host to which it sends > host-type requests and > > o a realm-type OCS entry for each Destination-Realm to which it > sends realm-type requests. > > A host-type OCS entry is identified by the pair of Application-ID and > the node's DiameterIdentity. > > A realm-type OCS entry is identified by the pair of Application-ID > and realm. > > The host-type and realm-type OCS entries include the following > information (the actual information stored is an implementation > decision): > > o Sequence number (as received in OC-OLR; see Section 7.3) > > o Time of expiry (derived from OC-Validity-Duration AVP received in > the OC-OLR AVP and time of reception of the message carrying > OC-OLR AVP) > > o Selected abatement algorithm (as received in the OC-Supported- > Features AVP) > > o Input data that is abatement algorithm specific (as received in > the OC-OLR AVP -- for example, OC-Reduction-Percentage for the > loss abatement algorithm)" > > [LM] when adapted to this document, we should have: > > A reacting node maintains the following OCS per supported Diameter > application: > > o a peer-type OCS entry for each peer to which it sends > host-type requests > > A peer-type OCS entry is identified by the pair of Application-ID and > the peer's DiameterIdentity. > > The peer-type OCS entry include the following > information (the actual information stored is an implementation > decision): > > o Sequence number (as received in OC-OLR; see Section 7.3) > > o Time of expiry (derived from OC-Validity-Duration AVP received in > the OC-OLR AVP and time of reception of the message carrying > OC-OLR AVP) > > o Selected abatement algorithm (as received in the OC-Supported- > Features AVP) > > o Input data that is abatement algorithm specific (as received in > the OC-OLR AVP -- for example, OC-Reduction-Percentage for the > loss abatement algorithm) > > [LM] is there any reason to deviate from this approach? > > 5.2.2. Reporting Node Maintenance of Peer Report OCS > > A reporting node SHOULD create a new Reporting Node Peer Report OCS > entry Section 5.2.1.1 in an overload condition and sending a peer > overload report to a peer for the first time. > > [LM] "sending" is not part of the OCS entry maintenance > > If the reporting node knows that there are no reacting nodes > supporting the OC_PEER_REPORT feature then the reporting node can > choose to not create OCS entries. > > All rules for managing the reporting node OCS entries defined in > [RFC7683] apply to the peer report. > > [LM] I think that there is nothing specific to peer report here. Only > the last paragraph could be kept. > > 5.2.3. Reacting Node Maintenance of Peer Report OCS > > When a reacting node receives an OC-OLR AVP with a report type of > peer it MUST determine if the report was generated by the Diameter > peer from which the report was received. > > If the DiameterID in the SourceID contained in the OLR matches the > DiameterIdentity of the peer from which the request was received then > the report was received from a Diameter peer. > > [LM] As discussed above, the match is performed per application in > RFC7683. Any reason to deviate? > > If a reacting node receives an OC-OLR AVP of type peer and the > SourceID does not match the ID of the Diameter peer from which the > request was received then the reacting node MUST ignore the overload > report. > > [LM] s/SourceID/DiemeterIdentity contained in the SourceID AVP > s/ID of the Diameter peer/DiameterIdentity > > In all cases, if the reacting node is a relay then it MUST strip the > OC-OLR AVP from the message. > > [LM] not part of the OCS entry maintenance. > > If the Peer Report OLR was received from a Diameter peer then the > reacting node MUST determine if it is for an existing or new overload > condition. > > The OLR is for an existing overload condition if the reacting node > has an OCS that matches the received OLR. For a peer report-type > this means the DiameterIdentity received in the SourceID AVP matches > the DiameterIdentity of an existing peer report OLR. > > [LM] Based on RFC7683, For peer report, the text could be: > > "The OLR is for an existing overload condition if a reacting node has > an OCS that matches the received OLR. > > For a peer report, this means it matches the Application-ID and the > peer's DiameterIdentity in an existing peer OCS entry." > > [LM] OK with rest of the section > > [LM] No specific comment on the rest of the document. > > > *De :* Lionel MORAND > *Envoyé :* ‎lundi‎ ‎13‎ ‎juin‎ ‎2016 ‎22‎:‎25 > *À :* Steve Donovan , Maria Cruz > Bartolome , dime@ietf.org > > > Hi Steve, > > Reviewing the draft, I have additional comments that I will post > tomorrow. > > Regards, > > Lionel > > Envoyé de mon Orange Nura 2 > > Le 13 juin 2016 22:14, Steve Donovan a écrit : > Lionel, > Jouni, > > I've incorporated all of the suggested changes into the draft. I > believe the time period for the WGLC has expired. Please advise if I > should publish the new version or if you want to wait for more comments. > > Regards, > > Steve > > On 6/13/16 8:06 AM, lionel.morand@orange.com wrote: > > Thank you for the useful discussion. > > I'm OK with the output and the proposed changes. > > > > regards, > > > > Lionel > > > >> -----Message d'origine----- > >> De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz > Bartolome > >> Envoyé : vendredi 10 juin 2016 10:02 > >> À : Steve Donovan; dime@ietf.org > >> Objet : Re: [Dime] WGLC #1 for draft-ietf-dime-agent-overload-05 > >> > >>>>> 2. Clause 5.2.3 > >>>>> "In all cases, if the reacting node is a relay then it > MUST strip the > >>>>> OC-OLR AVP from the message." > >>>>> > >>>>> But, will the relay react against the overload report > received? i.e. is it a > >> "reacting node" or it is just relaying the message? > >>>> SRD> That is determined by the other statements in that section. If > >>>> SRD> the > >>>> SourceID received in the message matches that of a peer then the > relay is a > >> reacting node. If it doesn't match then it is not a reacting > node. Either way, the > >> OC-OLR AVP is stripped. > >>>> MCRUZ> But a relay can't be a "reacting node", can it? A relay > does not read > >> or understand any AVP apart from routing related AVPs. > >>> SRD> Yes a relay is the reacting node for any next hop that generates > >>> SRD> a > >>> peer overload report. As with base DOIC, a relay must be able to > handle DOIC > >> AVPs, in addition to the routing AVPs. > >>> MCRUZ> In DOIC this is not explicitly mentioned, and I do not see > the need. > >> Moreover, this changes the definition of what a relay is. > >> SRD2> You are correct, it should say agent, not relay. In my mind an > >> agent that is a relay can also be a reacting node by expanding the > definition of > >> routing related AVPs to include DOIC AVPs. I consider this valid > as these AVPs, > >> and the LOAD AVPs all impact routing decisions. This, however, is > somewhat > >> academic as the practical impact of calling an agent that is a > reacting node a > >> relay or a proxy isn't meaningful. > >> > >> SRD> I'll change the word in the above clause to agent. > >> MCRUZ> Thanks Steve. I think this change applies to other places in > the draft. > >> > >> > >>>>> 8. Clause 4 > >>>>> > >>>>> "Any messages that survive throttling due > >>>>> to host or realm reports should then go through abatement > for the > >>>>> peer overload report." > >>>>> > >>>>> There is an interaction between PEER and HOST reports. The > reduction of > >> traffic towards a HOST reduces as well the traffic through the > agents in the path. > >> This should be taken into account when applying reduction for that > particular > >> PEER. However, depending on the routing schema it may not be > straight forward > >> to identify what is the reduction for each agent path when reducing > traffic > >> towards a HOST. > >>>> SRD> The goal of this statement is to say that when a Diameter node > >>>> SRD> is > >>>> applying overload abatement algorithms, the order in which active > >>>> overload reports are applied is host/realm report first and then peer > >>>> report. In other words, abatement is done for traffic being sent to > >>>> a host and then independent abatement is done for the peer to which > >>>> the request is to be routed. If these are treated as independent > >>>> actions then I don't understand the issue you are raising. > >>>> > >>>> MCRUZ> If you think the PEER algorithm is RATE, then there is not > >> interaction, as long as when PEER abatement is performed after > HOST/REALM, > >> it simply keeps a RATE. However, if the PEER algorithm is LOSS, > when performed > >> after HOST/REALM it should be stated that it is the initial traffic > (before any > >> HOST/REALM abatement) the one that should be taken into account. > Then, I > >> think a clarification is required. > >>> SRD> While it is true that, as stated, the presence of a HOST LOSS > >>> report and a peer LOSS report could result in extra messages being > abated, I > >> would prefer to keep the definition of the interaction as simple as > possible and > >> not change the requirement. My reasoning is that there is value in > keeping it > >> simple, especially given that it a self correcting scenario. The > next hop will see > >> more of a reduction than it was expecting and will subsequently > update the > >> requested reduction. If there isn't consensus on this approach we > can do a > >> special case on this scenario. > >>> MCRUZ> I think we need to cover these cases, since having extra > throttling > >> even if it is compensated later will cause first unnecessary drop > messages and > >> second traffic oscillations. Both things should be avoided. > >> SRD> How about if we add the following: > >> > >> Any messages that survive throttling due to host or realm > reports should then > >> go through abatement for the > >> peer overload report. In this scenario, when doing > abatement on the PEER > >> report, the reacting node SHOULD > >> take into consideration the number of messages already > throttled by the > >> handling of the HOST/REALM report abatement. > >> > >> Note: The goal is to avoid traffic oscillations that > might result from > >> throttling of messages for both > >> the HOST/REALM overload reports and the PEER overload > reports. This is > >> especially a concern if both > >> reports are of type LOSS. > >> > >> MCRUZ> I think this is fine. Thanks > >> > >> _______________________________________________ > >> DiME mailing list > >> DiME@ietf.org > >> https://www.ietf.org/mailman/listinfo/dime > > > _________________________________________________________________________________________________________________________ > > > > 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. > > > > _________________________________________________________________________________________________________________________ > > 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. > _________________________________________________________________________________________________________________________ > > 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. --------------BD008D089BED85CCD300503C Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Lionel,

Thanks for the review.  See my comments inline.

Regards,

Steve

On 6/15/16 4:45 AM, lionel.morand@orange.com wrote:
Hi,

As indicated, here is a review of the draft for discussion.
The main focus in my review is the alignment with the RFC7683.

Regards,

Lionel

*********
1.  Introduction

[LM] I would start directly the introduction with:

   This document extends the base Diameter endpoint overload
   specification to address the case when Diameter Agents become
   overloaded. [...]

[LM] followed by a brief description of the base mechanism and to better explain then why this document "defines new overload report type".
SRD>  I'd be happy to copy the abstract to the first paragraph of the introduction.  The remainder of the introduction section explains why a new report type is defined.


3.1.3.  Agent Chains

   There are also deployment scenarios where there can be multiple
   Diameter Agents between Diameter Clients and Diameter Servers.
   Examples of this type of deployment include when there are edge
   agents between Diameter networks.  Another example of this type of
   deployment is when there are multiple sets of servers, each
   supporting a subset of the Diameter traffic.

OLD:

   Examples of this type of deployment include when there are edge
   agents between Diameter networks.

NEW:

   Examples of this type of deployment include when there are edge
   agents between Diameter networks.
SRD> I don't see a suggested change.

OLD:

   Another example of this type of
   deployment is when there are multiple sets of servers, each
   supporting a subset of the Diameter traffic.

NEW:

   Another example of this type of
   deployment is when when servers of a domain are grouped in pools,
   each pool supporting a subset of the Diameter traffic received by
   front-end proxies.
SRD> This example has already been removed based on previous comments.

3.2.  Diameter Endpoint Use Cases

[LM] In this section, it would be helpful to clearly see what is different here compared to what is possible with the RFC7683.
For instance, by emphasizing from the beginning the difference between "host" and "peer" reports and between "end-to-end" and "hop-by-hop".
Otherwise, it would be difficult to understand the title "Diameter endpoint use cases" in this document.
SRD> I'm not seeing the concern here.  The section discusses the case when an endpoint would send a peer report.  Can you be more specific in suggested wording?

5.1.1.  Reacting Node Behavior

   When sending a Diameter request a DOIC node that supports the
   OC_PEER_REPORT feature MUST include an OC-Supported-Features AVP with
   an OC-Feature-Vector AVP with the OC_PEER_REPORT bit set.

[LM] the "MUST" here is not appropriate. A DOIC node MUST insert the OC-Supported-Features AVP as per RFC7683.
It is not a new requirement introduced by this document.
It should rather be: "MUST include in the OC-Supported-Features AVP an OC-Feature-Vector AVP with the OC_PEER_REPORT bit set."
SRD> It isn't saying that it must insert the OC-S-F AVP.  It is saying it must include the OC-S-F AVP with specific conditions.  I don't see the issue.

      Note: The sender of a request can be a Diameter Client or Diameter
      Server that originates the Diamter request or a Diameter Agent
      that relays the request.

[LM] Not sure that the NOTE is required here.
SRD> I'm okay with removing the note.

   Support for the OC_PEER_REPORT feature does not impact the logic for
   setting of other feature bits in the OC-Feature-Vector AVP.

[LM] not sure it is relevant. If it is, could be more appropriate in section 6.1.1
SRD> I'm okay with removing this as well.

   When sending a request a DOIC node that supports the OC_PEER_REPORT
   feature MUST include an OC-SourceID AVP in the OC-Supported-Features
   AVP with its own DiameterIdentity.

      Note: This allows the DOIC nodes in the path of the request to
      determine if the indication of support came from a Diameter peer
      or if the request traversed a node that does not support the
      OC_PEER_REPORT feature.

[LM] not required as it is explained in the section defining the OC-SourceID and its use is described in other sections.
SRD> The description of SourceID (we agreed to remove the OC- prefix earlier) doesn't not indicate that it MUST be included.  As such, I think this requirement is needed.

   When relaying a request that includes an OC-SourceID AVP in the OC-
   Supported-Features AVP, a DOIC node that supports the OC_PEER_REPORT
   feature must remove the received OC-SourceID AVP and replace it with
   an OC-SourceID AVP containing its own Diameter identity.

[LM] if the comments are accepted, the section could be simplified as follow:

NEW:

   When sending a Diameter request, a DOIC node that supports the
   OC_PEER_REPORT feature MUST include in the OC-Supported-Features AVP
   an OC-Feature-Vector AVP with the OC_PEER_REPORT bit set. The
   OC-Supported-Features AVP MUST include an OC-SourceID AVP with the
   DOIC node sending the request.

   When relaying a request that includes an OC-SourceID AVP in the OC-
   Supported-Features AVP, a DOIC node that supuports the OC_PEER_REPORT
   feature must remove the received OC-SourceID AVP and replace it with
   an OC-SourceID AVP containing its own Diameter identity.
SRD>  I propose the following:

   When sending a Diameter request a DOIC node that supports the
   OC_PEER_REPORT feature MUST include an OC-Supported-Features AVP with
   an OC-Feature-Vector AVP with the OC_PEER_REPORT bit set.

   When sending a request a DOIC node that supports the OC_PEER_REPORT
   feature MUST include a SourceID AVP in the OC-Supported-Features AVP
   with its own DiameterIdentity.

      Note: This allows the DOIC nodes in the path of the request to
      determine if the indication of support came from a Diameter peer
      or if the request traversed a node that does not support the
      OC_PEER_REPORT feature.

   When an agent relays a request that includes a SourceID AVP in the
   OC-Supported-Features AVP, a DOIC node that supports the
   OC_PEER_REPORT feature MUST remove the received SourceID AVP and
   replace it with a SourceID AVP containing its own Diameter identity.


5.1.2.  Reporting Node Behavior

   When receiving a request a DOIC node that supports the OC_PEER_REPORT
   feature MUST update transaction state with an indication of whether
   or not the peer from which the request was received supports the
   OC_PEER_REPORT feature.

      Note: The transaction state is used when the DOIC node is acting
      as a peer-report reporting node and needs send OC-OLR reports of
      type PEER_REPORT in answer messages.  The peer overload reports
      are only included in answer messages being sent to peers that
      support the OC_PEER_REPORT feature.

[LM] Not sure of the need for the transaction state, that is not really defined in this document, compared to the OCS entry required by the RFC7683.

[LM] the base mechanism is governed by the following requirement in RFC7683:  

   A reporting node MUST NOT include the OC-Supported-Features AVP,
   OC-OLR AVP, or any other overload control AVPs defined in extension
   documents in response messages for transactions where the request
   message does not include the OC-Supported-Features AVP.  Lack of the
   OC-Supported-Features AVP in the request message indicates that there
   is no reacting node for the transaction.

[LM] is there any need to modify this requirement?
[LM] the NOTE is not required if you follow the RFC7683
SRD> Are you suggesting using OCS as the way to determine if the peer supports the peer report type?

   When relaying an answer message, a reporting node that supports the
   OC_PEER_REPORT feature MUST strip any SourceID AVP from the OC-
   Supported-Features AVP.

[LM] I know that it was discussed by Jean but I didn't get the conclusion: does the node strip any existing sourceID and include its own?
SRD> A relay will strip received SourceID information.  It will include its own SourceID based on the requirements statement three paragraphs later.

   When sending an answer message, a reporting node that supports the
   OC_PEER_REPORT feature MUST determine if the peer to which the answer
   is to be sent supports the OC_PEER_REPORT feature. [...]

[LM] in the rest of the section, the only clarification with the basic mechanism defined in RFC7683 is on how to check the support of peer report. Some "MUST" are not appropriate as implicitly required by the support of RFC7683.
SRD> All of the requirements in this section are specific to the peer report.  I don't see any that are implicitly required by RFC7683.  Can you clarify the concern?


5.2.1.  Overload Control State

[LM] consistency with RFC7683 is important.
SRD>  Agreed.  In general I agree with your suggestions on this section.  I will clean up the section to make the reference to RFC7683 stronger and only talk about deltas needed for the peer report.  This should make this section much cleaner.  I'll send the resulting text in a separate email.

5.2.1.1.  Reporting Node Peer Report OCS


   A DOIC Node that supports the OC_PEER_REPORT feature SHOULD maintain
   Reporting Node Peer Report OCS.  This is used to record overload
   events and build overload reports at the reporting node.

[LM] in the RFC7683, it is said:

  "A reporting node maintains OCS entries per supported Diameter
   application, per supported (and eventually selected) abatement
   algorithm, and per report type.

   An OCS entry is identified by the tuple of Application-ID, report
   type, and abatement algorithm, and it includes the following
   information (the actual information stored is an implementation
   decision):

   o  Sequence number

   o  Validity duration

   o  Expiration time

   o  Input data that is algorithm specific (for example, the reduction
      percentage for the loss abatement algorithm)"

[LM] does it apply for the peer report also? If yes, why do not reuse the text from RFC7683, with a specific reference? Especially, the mean for OCS entry identification and notion of "application" disappear in this document.

   If different abatement specific contents are sent to each peer then
   the reporting node MUST maintain a separate peer node peer report OCS
   entry per peer to which a peer overload report is sent.

      Note: The rate overload abatement algorithm allows for different
      rates to be sent to each peer.

[LM] not sure that it is required if it is said that there is an OCS entry per peer from the beginning.

   The Reporting Node Peer Report OCS entry MAY include the following
   information (the actual information stored is an implementation
   decision):

[LM] see comment above

5.2.1.2.  Reacting Node Peer Report OCS

   A DOIC node that supports the OC_PEER_REPORT feature SHOULD maintain
   Reacting Node Peer Report OCS for each peer with which it
   communicates.  This is used to record overload reports received from
   peer nodes.

   A Reacting Node Peer Report OCS entry is identified by the
   DiameterIdentity of the peer as communicated during the RFC6733
   defined Capability Exchange procedure.

   The Reacting Node Peer Report OCS entry MAY include the following
   information (the actual information stored is an implementation
   decision):

   o  Sequence number

   o  Expiration Time

   o  Abatement Algorithm

   o  Algorithm specific input data (for example, the Reduction
      Percentage for the Loss Abatement Algorithm)

[LM] in RFC7683, we have:

  "A reacting node maintains the following OCS per supported Diameter
   application:

   o  a host-type OCS entry for each Destination-Host to which it sends
      host-type requests and

   o  a realm-type OCS entry for each Destination-Realm to which it
      sends realm-type requests.

   A host-type OCS entry is identified by the pair of Application-ID and
   the node's DiameterIdentity.

   A realm-type OCS entry is identified by the pair of Application-ID
   and realm.

   The host-type and realm-type OCS entries include the following
   information (the actual information stored is an implementation
   decision):

   o  Sequence number (as received in OC-OLR; see Section 7.3)

   o  Time of expiry (derived from OC-Validity-Duration AVP received in
      the OC-OLR AVP and time of reception of the message carrying
      OC-OLR AVP)

   o  Selected abatement algorithm (as received in the OC-Supported-
      Features AVP)

   o  Input data that is abatement algorithm specific (as received in
      the OC-OLR AVP -- for example, OC-Reduction-Percentage for the
      loss abatement algorithm)"

[LM] when adapted to this document, we should have:

   A reacting node maintains the following OCS per supported Diameter
   application:

   o  a peer-type OCS entry for each peer to which it sends
      host-type requests

   A peer-type OCS entry is identified by the pair of Application-ID and
   the peer's DiameterIdentity.

   The peer-type OCS entry include the following
   information (the actual information stored is an implementation
   decision):

   o  Sequence number (as received in OC-OLR; see Section 7.3)

   o  Time of expiry (derived from OC-Validity-Duration AVP received in
      the OC-OLR AVP and time of reception of the message carrying
      OC-OLR AVP)

   o  Selected abatement algorithm (as received in the OC-Supported-
      Features AVP)

   o  Input data that is abatement algorithm specific (as received in
      the OC-OLR AVP -- for example, OC-Reduction-Percentage for the
      loss abatement algorithm)

[LM] is there any reason to deviate from this approach?

5.2.2.  Reporting Node Maintenance of Peer Report OCS

   A reporting node SHOULD create a new Reporting Node Peer Report OCS
   entry Section 5.2.1.1 in an overload condition and sending a peer
   overload report to a peer for the first time.

[LM] "sending" is not part of the OCS entry maintenance

      If the reporting node knows that there are no reacting nodes
      supporting the OC_PEER_REPORT feature then the reporting node can
      choose to not create OCS entries.

   All rules for managing the reporting node OCS entries defined in
   [RFC7683] apply to the peer report.

[LM] I think that there is nothing specific to peer report here. Only the last paragraph could be kept.

5.2.3.  Reacting Node Maintenance of Peer Report OCS

   When a reacting node receives an OC-OLR AVP with a report type of
   peer it MUST determine if the report was generated by the Diameter
   peer from which the report was received.

   If the DiameterID in the SourceID contained in the OLR matches the
   DiameterIdentity of the peer from which the request was received then
   the report was received from a Diameter peer.

[LM] As discussed above, the match is performed per application in RFC7683. Any reason to deviate?

   If a reacting node receives an OC-OLR AVP of type peer and the
   SourceID does not match the ID of the Diameter peer from which the
   request was received then the reacting node MUST ignore the overload
   report.

[LM] s/SourceID/DiemeterIdentity contained in the SourceID AVP
     s/ID of the Diameter peer/DiameterIdentity

   In all cases, if the reacting node is a relay then it MUST strip the
   OC-OLR AVP from the message.

[LM] not part of the OCS entry maintenance.

   If the Peer Report OLR was received from a Diameter peer then the
   reacting node MUST determine if it is for an existing or new overload
   condition.

   The OLR is for an existing overload condition if the reacting node
   has an OCS that matches the received OLR.  For a peer report-type
   this means the DiameterIdentity received in the SourceID AVP matches
   the DiameterIdentity of an existing peer report OLR.

[LM] Based on RFC7683, For peer report, the text could be:

  "The OLR is for an existing overload condition if a reacting node has
   an OCS that matches the received OLR.

   For a peer report, this means it matches the Application-ID and the
   peer's DiameterIdentity in an existing peer OCS entry."

[LM] OK with rest of the section

[LM] No specific comment on the rest of the document.


De : Lionel MORAND
Envoyé : ‎lundi‎ ‎13‎ ‎juin‎ ‎2016 ‎22‎:‎25
À : Steve Donovan, Maria Cruz Bartolome, dime@ietf.org

Hi Steve,

Reviewing the draft, I have additional comments that I will post tomorrow.

Regards,

Lionel

Envoyé de mon Orange Nura 2

Le 13 juin 2016 22:14, Steve Donovan <srdonovan@usdonovans.com> a écrit :
Lionel,
Jouni,

I've incorporated all of the suggested changes into the draft.  I
believe the time period for the WGLC has expired.  Please advise if I
should publish the new version or if you want to wait for more comments.

Regards,

Steve

On 6/13/16 8:06 AM, lionel.morand@orange.com wrote:
> Thank you for the useful discussion.
> I'm OK with the output and the proposed changes.
>
> regards,
>
> Lionel
>
>> -----Message d'origine-----
>> De : DiME [mailto:dime-bounces@ietf.org] De la part de Maria Cruz Bartolome
>> Envoyé : vendredi 10 juin 2016 10:02
>> À : Steve Donovan; dime@ietf.org
>> Objet : Re: [Dime] WGLC #1 for draft-ietf-dime-agent-overload-05
>>
>>>>> 2. Clause 5.2.3
>>>>>       "In all cases, if the reacting node is a relay then it MUST strip the
>>>>>        OC-OLR AVP from the message."
>>>>>
>>>>>        But, will the relay react against the overload report received? i.e. is it a
>> "reacting node" or it is just relaying the message?
>>>> SRD> That is determined by the other statements in that section. If
>>>> SRD> the
>>>> SourceID received in the message matches that of a peer then the relay is a
>> reacting node.  If it doesn't match then it is not a reacting node.  Either way, the
>> OC-OLR AVP is stripped.
>>>> MCRUZ> But a relay can't be a "reacting node", can it? A relay does not read
>> or understand any AVP apart from routing related AVPs.
>>> SRD> Yes a relay is the reacting node for any next hop that generates
>>> SRD> a
>>> peer overload report.  As with base DOIC, a relay must be able to handle DOIC
>> AVPs, in addition to the routing AVPs.
>>> MCRUZ> In DOIC this is not explicitly mentioned, and I do not see the need.
>> Moreover, this changes the definition of what a relay is.
>> SRD2> You are correct, it should say agent, not relay.  In my mind an
>> agent that is a relay can also be a reacting node by expanding the definition of
>> routing related AVPs to include DOIC AVPs.  I consider this valid as these AVPs,
>> and the LOAD AVPs all impact routing decisions.  This, however, is somewhat
>> academic as the practical impact of calling an agent that is a reacting node a
>> relay or a proxy isn't meaningful.
>>
>> SRD> I'll change the word in the above clause to agent.
>> MCRUZ> Thanks Steve. I think this change applies to other places in the draft.
>>
>>
>>>>> 8. Clause 4
>>>>>
>>>>> "Any messages that survive throttling due
>>>>>        to host or realm reports should then go through abatement for the
>>>>>        peer overload report."
>>>>>
>>>>>       There is an interaction between PEER and HOST reports. The reduction of
>> traffic towards a HOST reduces as well the traffic through the agents in the path.
>> This should be taken into account when applying reduction for that particular
>> PEER. However, depending on the routing schema it may not be straight forward
>> to identify what is the reduction for each agent path when reducing traffic
>> towards a HOST.
>>>> SRD> The goal of this statement is to say that when a Diameter node
>>>> SRD> is
>>>> applying overload abatement algorithms, the order in which active
>>>> overload reports are applied is host/realm report first and then peer
>>>> report.  In other words, abatement is done for traffic being sent to
>>>> a host and then independent abatement is done for the peer to which
>>>> the request is to be routed.  If these are treated as independent
>>>> actions then I don't understand the issue you are raising.
>>>>
>>>> MCRUZ> If you think the PEER algorithm is RATE, then there is not
>> interaction, as long as when PEER abatement is performed after HOST/REALM,
>> it simply keeps a RATE. However, if the PEER algorithm is LOSS, when performed
>> after HOST/REALM it should be stated that it is the initial traffic (before any
>> HOST/REALM abatement) the one that should be taken into account. Then, I
>> think a clarification is required.
>>> SRD> While it is true that, as stated, the presence of a HOST LOSS
>>> report and a peer LOSS report could result in extra messages being abated, I
>> would prefer to keep the definition of the interaction as simple as possible and
>> not change the requirement. My reasoning is that there is value in keeping it
>> simple, especially given that it a self correcting scenario.  The next hop will see
>> more of a reduction than it was expecting and will subsequently update the
>> requested reduction.  If there isn't consensus on this approach we can do a
>> special case on this scenario.
>>> MCRUZ> I think we need to cover these cases, since having extra throttling
>> even if it is compensated later will cause first unnecessary drop messages and
>> second traffic oscillations. Both things should be avoided.
>> SRD> How about if we add the following:
>>
>>        Any messages that survive throttling due to host or realm reports should then
>> go through abatement for the
>>        peer overload report.  In this scenario, when doing abatement on the PEER
>> report, the reacting node SHOULD
>>        take into consideration the number of messages already throttled by the
>> handling of the HOST/REALM report abatement.
>>
>>            Note: The goal is to avoid traffic oscillations that might result from
>> throttling of messages for both
>>            the HOST/REALM overload reports and the PEER overload reports.  This is
>> especially a concern if both
>>            reports are of type LOSS.
>>
>> MCRUZ> I think this is fine. Thanks
>>
>> _______________________________________________
>> DiME mailing list
>> DiME@ietf.org
>> https://www.ietf.org/mailman/listinfo/dime
> _________________________________________________________________________________________________________________________
>
> 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.
>

 
_________________________________________________________________________________________________________________________

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.

_________________________________________________________________________________________________________________________

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.

--------------BD008D089BED85CCD300503C--