Re: [Dime] Last Call: <draft-ietf-dime-agent-overload-08.txt> (Diameter Agent Overload and the Peer Overload Report) to Proposed Standard
Steve Donovan <srdonovan@usdonovans.com> Fri, 20 January 2017 17:16 UTC
Return-Path: <srdonovan@usdonovans.com>
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 E336C129490 for <dime@ietfa.amsl.com>; Fri, 20 Jan 2017 09:16:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.12
X-Spam-Level:
X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 m1t0NF3cc1Ki for <dime@ietfa.amsl.com>; Fri, 20 Jan 2017 09:16:41 -0800 (PST)
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 7CB16126B6D for <dime@ietf.org>; Fri, 20 Jan 2017 09:16:41 -0800 (PST)
Received: from [67.139.165.143] (port=62869 helo=Steves-MacBook-Air.local) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from <srdonovan@usdonovans.com>) id 1cUcni-003MYm-5a; Fri, 20 Jan 2017 09:16:41 -0800
To: Misha Zaytsev <misha.zaytsev.rus@gmail.com>, dime@ietf.org
References: <148397251720.24904.6589163339967252298.idtracker@ietfa.amsl.com> <CABPQr26jB94UCE+PcMh29PC+_=zxuTac4j-JMcuBKFYvWYPjDA@mail.gmail.com>
From: Steve Donovan <srdonovan@usdonovans.com>
Message-ID: <1ccf026a-ba8d-ca26-f258-47cc78b49a1f@usdonovans.com>
Date: Fri, 20 Jan 2017 09:16:33 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:45.0) Gecko/20100101 Thunderbird/45.6.0
MIME-Version: 1.0
In-Reply-To: <CABPQr26jB94UCE+PcMh29PC+_=zxuTac4j-JMcuBKFYvWYPjDA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------B464943CB6BE9BAB3E42BA76"
X-OutGoing-Spam-Status: No, score=-1.0
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: <https://mailarchive.ietf.org/arch/msg/dime/Bmfa0WuzHIFLcE_gznqisZ89FYo>
Subject: Re: [Dime] Last Call: <draft-ietf-dime-agent-overload-08.txt> (Diameter Agent Overload and the Peer Overload Report) to Proposed Standard
X-BeenThere: dime@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Diameter Maintanence and Extentions Working Group <dime.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dime>, <mailto:dime-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/dime/>
List-Post: <mailto:dime@ietf.org>
List-Help: <mailto:dime-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dime>, <mailto:dime-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 20 Jan 2017 17:16:43 -0000
Misha, Thanks for the detailed review. In the future this type of message only needs to go to the DIME mailing list. I will deal with all of your comments in one email. Regards, Steve On 1/17/17 12:23 PM, Misha Zaytsev wrote: > Hi All, > > Here are my comments/questions to an agent overload draft. > This the first part. Later on I will complete my review and send out > the second portion of the comments. > > 1. section 1 (editorial) removed "is" before "feasible". > > In the base specification, the goal is to handle abatement of the > overload occurrence as close to the source of the Diameter traffic as > feasible. > > "scenaios" -> "scenarios" > > The Peer overload report type is > defined in a generic fashion so that it can also be used for other > Diameter overload*scenarios*. > > 2. section 3.1.1 (editorial) replaced "were"-> "was" > > In both of these cases, the occurrence of overload in the single > agent must by handled by the client in a similar fashion as if the > client*was* handling the overload of a directly connected server. > > 3. section 3.1.1 (question) > > An appropriate error response is sent back to the originator > of the request. > Who sends "an appropriate" error response" in this case? > > 4. section 3.1.2 (editorial) changed "to"->"the" > > When the client has an active and a standby connection to the two > agents then an alternative strategy for responding to an overload > report from an agent is to change*the *standby connection to active and > route all traffic through the new active connection. > > 5. section 3.1.3 (editorial) > > An example of this type of deployment include*s* when there are Diameter > agents between administrative domains. > 6. section 3.1.3 > > There is no section 2.2. I guess section 3.1.2 was meant here, right? > > Handling of overload of one or both of agents a11 or a12 in this case > is equivalent to that discussed in section 2.2. > > 7. section 3.2.1 > > It is not clear which usage scenario is meant here. > > It is envisioned that abatement algorithms will be defined that will > support the option for Diameter Endpoints to send peer reports. For > instance, it is envisioned that one usage scenario for the rate > algorithm, [I-D.ietf-dime-doic-rate-control], which is being worked > on by the DIME working group as this document is being written, will > involve abatement being done on a hop-by-hop basis. > 8. section 4 > Why is throttling to be applied and not diversion (like in case of > redundant agents)? > In this scenario the reacting node should first handle the throttling of the > overloaded host or realm. > "LOSS" Is it a new type defined in the scope of this draft? > 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*. > 9. section 5.1.1 > Probably it is better to describe OC_PEER_REPORT feature in section 5.1? > Otherwise, it is used as a well-known one while it is the first place > where it is mentioned. > Also I think it is better to add more specific in this draft related > to peer report handling: > - define Peer Report Reacting Node and Peer Report Reporting Node > terms explicitly and use them through the draft and especially > starting from section 5.1 > - add "Peer Report" prefix to all the described procedures > Example: Capability Announcement -> Peer Report Capability Announcement > 10. section 5.1.1/general > "DiameterIdentity" and "Diameter identity" > My proposal is to use one term through the spec. > Under "DOIC node", an agent is meant here? > 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. > My proposal is to use peer report reacting node here re-phrasing this > statement below in the following way: > When relaying a request that includes a SourceID AVP in the > OC-Supported-Features AVP, a peer report reacting node MUST remove the received SourceID AVP and > replace it with a SourceID AVP containing its own DiameterIdentity. > 11. section 5.1.2 > added the missed "to" > changed "PEER_REPORT"-> "PEER" > Note: The transaction state is used when the DOIC node is acting > as a peer-report reporting node and needs*to *send OC-OLR reports of > type*PEER *in answer messages. The peer overload reports > are only included in answer messages being sent to peers that > support the OC_PEER_REPORT feature. > "Diameter ID" term is not clarified anywhere. > Re-phrased the appropriate statement a little bit, changed "Diameter > ID"->"value" > Also there are other places in the draft where "Diameter ID" term is used. > The peer supports the OC_PEER_REPORT feature if the received request > contains an OC-Supported-Features AVP with the OC-Feature-Vector with > the OC_PEER_REPORT feature bit set and with a SourceID AVP with a > value that matches the DiameterIdentity of the peer from which > the request was received. > Agent is meant under "reporting node" here? > Should not SourceID AVP not just stripped from the relayed answer, but > replaced with the SourceID AVP containing the DiameterIdentity of the > agent supporting OC_PEER_REPORT feature? > When an agent relays an answer message, a reporting node that > supports the OC_PEER_REPORT feature MUST strip any SourceID AVP from > the OC-Supported-Features AVP. > Hard to follow what was wanted to say here: > Corrected the statement, but this is just my best guess. > The OC-Peer-Algo AVP MUST indicate the overload abatement > algorithm that the reporting node wants the reacting nodes to use > *when *the reporting node send*s* a peer overload report as a result of > becoming overloaded. > Should not we add a separate if- statement for the case when the peer > does not support OC_PEER_REPORT feature when sending an answer message? > 12. section 5.1.1 and 5.1.2 > Probably it is more helpful to illustrate OC_PEER_REPORT feature CA > using sequence diagrams like in the load info conveyance draft. > 13. general. > What about to use the writing for the same terms through the spec? > Example1: "DOIC node" and "DOIC Node" > Example2: "peer-report reporting node" and "peer report reporting node" > 14. section 5.2.1.2, 5.2.2, 5.2.3 and general > "peer-type OCS" and "peer report OCS" define the same term? > Why not to use only one? > Another example: "peer report" and "peer report-type" and "report of > type PEER" > 15. section 5.2.3 > Probably it is better to re-phrase this statement a little bit + > corrected the misprints. > If a*peer report* reacting node receives an OC-OLR AVP of type peer and the > SourceID matches the*DiameterIdentity *of the peer from which the*report* > was received then the report was*generated *by the peer. > Similar comment + corrected misprints for the next statement: > If a peer report reacting node receives an OC-OLR AVP of type peer and the > SourceID does not match the*DiameterIdentity *of the peer from which the > *report *was received then the reacting node MUST ignore the overload > report. > Also I think it is useful to use one wording for the same term: > "Peer Report OLR", "OC-OLR AVP", "OLR" > Let's use a generic one "peer report"? > Just minor comment: "the existing..." and "a new overload condition" > for all occurrences if my English is correct. > 16. section 5.2.3 > How may it happen that peer report reacting node receives a peer > report not from the peer that generated it? > Peer reports can be sent only to peer report reacting node, right? And > peer reports are not relayed, right? > Best regards, > /Misha > 2017-01-09 17:35 GMT+03:00 The IESG <iesg-secretary@ietf.org > <mailto:iesg-secretary@ietf.org>>: > > The IESG has received a request from the Diameter Maintenance and > Extensions WG (dime) to consider the following document: - > 'Diameter Agent Overload and the Peer Overload Report' > <draft-ietf-dime-agent-overload-08.txt> as Proposed Standard The > IESG plans to make a decision in the next few weeks, and solicits > final comments on this action. Please send substantive comments to > the ietf@ietf.org <mailto:ietf@ietf.org> mailing lists by > 2017-01-23. Exceptionally, comments may be sent to iesg@ietf.org > <mailto:iesg@ietf.org> instead. In either case, please retain the > beginning of the Subject line to allow automated sorting. Abstract > This specification documents an extension to RFC 7683 (Diameter > Overload Indication Conveyance (DOIC)) base solution. The > extension defines the Peer overload report type. The initial > use case for the Peer report is the handling of occurrences of > overload of a Diameter agent. Requirements The file can be > obtained via > https://datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/ > <https://datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/> > IESG discussion can be tracked via > https://datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/ballot/ > <https://datatracker.ietf.org/doc/draft-ietf-dime-agent-overload/ballot/> > No IPR declarations have been submitted directly on this I-D. The > document contains these normative downward references. See RFC > 3967 for additional information: > draft-roach-dime-overload-ctrl: A Mechanism for Diameter Overload > Control (None - ) Note that some of these references may already > be listed in the acceptable Downref Registry. > _______________________________________________ DiME mailing list > DiME@ietf.org <mailto:DiME@ietf.org> > https://www.ietf.org/mailman/listinfo/dime > <https://www.ietf.org/mailman/listinfo/dime> >
- [Dime] Last Call: <draft-ietf-dime-agent-overload… The IESG
- Re: [Dime] Last Call: <draft-ietf-dime-agent-over… Misha Zaytsev
- Re: [Dime] Last Call: <draft-ietf-dime-agent-over… Misha Zaytsev
- Re: [Dime] Last Call: <draft-ietf-dime-agent-over… Gunn, Janet P
- Re: [Dime] Last Call: <draft-ietf-dime-agent-over… Gunn, Janet P
- Re: [Dime] Last Call: <draft-ietf-dime-agent-over… Misha Zaytsev
- Re: [Dime] Last Call: <draft-ietf-dime-agent-over… Misha Zaytsev
- Re: [Dime] Last Call: <draft-ietf-dime-agent-over… Misha Zaytsev
- Re: [Dime] Last Call: <draft-ietf-dime-agent-over… Steve Donovan
- Re: [Dime] Last Call: <draft-ietf-dime-agent-over… Misha Zaytsev
- Re: [Dime] Last Call: <draft-ietf-dime-agent-over… Stephen Farrell
- Re: [Dime] Last Call: <draft-ietf-dime-agent-over… Steve Donovan
- Re: [Dime] Last Call: <draft-ietf-dime-agent-over… Steve Donovan