From nobody Mon Feb 4 11:29:36 2019 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 E3E79130F43 for ; Mon, 4 Feb 2019 11:29:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.121 X-Spam-Level: X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 51fFhtVJpuTe for ; Mon, 4 Feb 2019 11:29:30 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) (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 D65A6130F5F for ; Mon, 4 Feb 2019 11:29:29 -0800 (PST) Received: from [97.99.21.33] (port=62415 helo=SDmac.lan) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gqjvh-00GSXZ-VK for dime@ietf.org; Mon, 04 Feb 2019 11:29:28 -0800 To: dime@ietf.org References: <154827019075.7547.9421622385944852216.idtracker@ietfa.amsl.com> From: Steve Donovan Message-ID: <2032a50a-9e1e-d97f-114b-974dc97c3870@usdonovans.com> Date: Mon, 4 Feb 2019 13:29:17 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <154827019075.7547.9421622385944852216.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-0.2 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] Benjamin Kaduk's No Objection on draft-ietf-dime-doic-rate-control-10: (with COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2019 19:29:35 -0000 Benjamin, Thanks for the review and comments. Please see my responses below. Steve On 1/23/19 1:03 PM, Benjamin Kaduk wrote: > Benjamin Kaduk has entered the following ballot position for > draft-ietf-dime-doic-rate-control-10: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dime-doic-rate-control/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for this well-written document! My comments are all essentially > editorial in nature. > > One comment of a general note regards the usage of the word "indicate" -- > usually when I read "indicate" I expect that to be part of some > protocol message or other formal data structure, but IIUC the OCS is > entirely a local matter, so "indicating" something in the OCS could be > equally well said as "storing" or "noting" or similar. (I do see other > similar usage of "indicate" in RFC 7683, so it's unclear that there are > really any grounds for changing the usage in this document.) SRD> I would prefer to not make changes unless there is strong feedback for the need to not use the word indicate in the fashion it is used. > > Section 4 > > nit: Saying that nodes MUST indicate support for *both* loss and rate seems > to duplicate the requirement from RFC 7683 and would potentially complicate > future updates. The descriptive note about "nodes supporting the rate > feature will support both" seems a better way to phrase things. SRD> An update has already been made based on Ben's comments. Let me know if you think the following is acceptable: DOIC reacting nodes supporting the rate feature MUST indicate support for both the loss and rate algorithms in the OC-Feature-Vector AVP and MAY indicate support for other algorithms. > > Section 5.1 > > Is keeping track of how much a reacting node is actually sending considered > to not be part of the OCS (as opposed to the allocated rate, which is part > of the OCS as noted here)? SRD> There was been no discussion around keeping track of the actual rate in the OCS. It is likely that this rate will be tracked by the rate algorithm but that is very dynamic state information. There is little value in storing in the OCS, which is used to build overload report sent to the reacting node. > > Section 6.2 > > This extension does not define new overload report types. The > existing report types of host and realm defined in [RFC7683] apply to > the rate control algorithm. The peer report type defined in > [I-D.ietf-dime-agent-overload] also applies to the rate control > algorithm. > > side note: I'm curious how the directionality is such that the report type > applies to the algorithm, as opposed to the other way around. SRD> I'm not sure I understand the question. There are three report types defined -- realm, host and peer. This is just saying that both loss and rate apply to all three report types. Can you clarify the question? > > Section 7.1 > > Upon receiving the overload report with a target maximum Diameter > request rate, each reacting node applies abatement treatment for new > Diameter requests towards the reporting node. > > (nit?) My (hasty) reading of 7683 is that "abatement treatment" means > either diversion or throttling, and that traffic processed normally is not > considered to receive "abatement treatment". If that reading is correct, > then this text is suggesting that no new requests receive normal treatment > after the reception of an OLR with a target rate, which does not seem quite > right. SRD> RFC7683 talks about overload abatement as the follows: Reacting nodes perform overload abatement according to an agreed-upon abatement algorithm. An abatement algorithm defines the meaning of some of the parameters of an OLR and the procedures required for overload abatement. An overload abatement algorithm separates Diameter requests into two sets. The first set contains the requests that are to undergo overload abatement treatment of either throttling or diversion. The second set contains the requests that are to be given normal routing treatment. This document specifies a single "must-support" algorithm, namely, the "loss" algorithm (Section 6). Future specifications may introduce new algorithms. I can see the confusion with using "abatement treatment" in the paragraph you reference. I propose changing "abatement treatment" to "overload abatement". > Section 7.2 > > Note that the value of OC-Maximum-Rate AVP (in request messages per > second) for the rate algorithm provides an upper bound on the traffic > sent by the reacting node to the reporting node. > > I see that this is not using normative language, and that the following > paragraph does clarify the caveats, but "upper bound" usually is read as > "strict upper bound", and there are several ways in which this bound could > (at least temporarily) not be strict. Perhaps "loose upper bound" is > better phrasing. SRD> Agreed. > > Section 7.3.1 > > Perhaps note explicitly that "//" denotes comments? SRD> Done. > > In determining whether or not to transmit a specific message, the > reacting node can use any algorithm that limits the message rate to > the OC-Maximum-Rate AVP value in units of messages per second. For > ease of discussion, we define T = 1/[OC-Maximum-Rate] as the target > inter-Diameter request interval. It may be strictly deterministic, > or it may be probabilistic. It may, or may not, have a tolerance > > nit: The intervening sentence defining 'T' seems to change the binding of > "It" away from "the algorithm". > Note that when the OC-Maximum-Rate value is 0 with a non-zero OC- > Validity-Duration, then the reacting node should apply abatement > treatment to 100% of Diameter requests destined to the overloaded > reporting node. However, when the OC-Validity-Duration value is 0, > the reacting node should stop applying abatement treatment. > > nit: this paragraph seems like it would be better placed elsewhere, as its > content is independent of any particular throttling algorithm. > > Reporting nodes with a very large number of reacting nodes, each with > a relatively small arrival rate, will generally benefit from a > smaller value for TAU in order to limit queuing (and hence response > times) at the reporting node when subjected to a sudden surge of > traffic from all reacting nodes. Conversely, a reporting node with a > relatively small number of reacting nodes, each with proportionally > larger arrival rate, will benefit from a larger value of TAU. > > Am I correct in assuming that "larger" and "smaller" values of TAU here are > to be measured with respect to T (i.e., as a ratio)? This may be worth > stating more explicitly. SRD> I'm reluctant to change the above as they are consistent with the wording in the SIP Overload specification. > > Section 8.3 > > Do you want to add this requirement as a "Note" on the IANA registry > itself? SRD> I don't understand the subtlety of the question. Do you have suggested wording or can you explain what a "Note" on the IANA registry is? > > Section 9 > > Other than what Mirja has already noted, I only have one minor remark. > > It seems that an attacker that can set up reacting nodes has a slightly > different way to disrupt legitimate traffic when "rate" is used vs. "loss", > but the details of any attack depend on implementation behavior at the > reporting node (e.g., whether it divides its total capacity evenly amongst > reacting nodes or uses a more complicated allocation scheme). And since an > attacker that can set up new reacting nodes is almost certainly able to > send traffic from those nodes, in practice there is no substantial > difference, so the decision to ignore this difference and just refer to the 7683 security > considerations seems justified. > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Mon Feb 4 11:37:34 2019 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 08CF8130EEF for ; Mon, 4 Feb 2019 11:37:32 -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, 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 C0bmlVflt6Yk for ; Mon, 4 Feb 2019 11:37:30 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) (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 023F7130EED for ; Mon, 4 Feb 2019 11:37:30 -0800 (PST) Received: from [97.99.21.33] (port=62457 helo=SDmac.lan) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gqk3S-00GXhX-KU for dime@ietf.org; Mon, 04 Feb 2019 11:37:29 -0800 To: dime@ietf.org References: <154820200372.13175.6427829494337126533.idtracker@ietfa.amsl.com> From: Steve Donovan Message-ID: <32a4a01d-e5e4-450f-acdb-a6ddffe40297@usdonovans.com> Date: Mon, 4 Feb 2019 13:37:18 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <154820200372.13175.6427829494337126533.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------717831DAACAE5483E90D618A" 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: Subject: Re: [Dime] Spencer Dawkins' Yes on draft-ietf-dime-doic-rate-control-10: (with COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2019 19:37:32 -0000 This is a multi-part message in MIME format. --------------717831DAACAE5483E90D618A Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Spencer, Thanks for the review and comments. Please see my comments inline. Steve On 1/22/19 6:06 PM, Spencer Dawkins wrote: > Spencer Dawkins has entered the following ballot position for > draft-ietf-dime-doic-rate-control-10: Yes > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dime-doic-rate-control/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thank you for doing this work, and for basing it on SIP Overload Control. It's > nice when protocol designers adopt good ideas from each other. > > There are three SHOULDs in Section 5.1, Reporting Node Overload Control State, > I'd like to understand better. > > A reporting node that uses the rate abatement algorithm SHOULD > maintain reporting node Overload Control State (OCS) for each > reacting node to which it sends a rate Overload Report (OLR). > > ^^ This one - I'm guessing that this is "SHOULD unless you're still writing > code upgrading an implementation that treats all reacting nodes the same way", > based on this next sentence, but I'm guessing. Why wouldn't you do this? SRD> If all reacting nodes are equal then an implementation could choose to have a single OCS entry the applies to all nodes. > > This is different from the behavior defined in [RFC7683] where a > single loss percentage sent to all reacting nodes. > > A reporting node SHOULD maintain OCS entries when using the rate > abatement algorithm per supported Diameter application, per targeted > reacting node and per report type. > > ^^ Your answer to my previous question is likely to help me understand this > one, but I'm guessing reasons why you wouldn't do this. SRD> Same reason as above. > > A rate OCS entry is identified by the tuple of Application-Id, report > type and DiameterIdentity of the target of the rate OLR. > > The rate OCS entry SHOULD include the rate allocated to the reacting > note. > > ^^ I'm really interested on this one - does the rate abatement algorithm work > without knowing the rate that's allocated? but assuming that it does work, I'm > still guessing why you wouldn't do this. SRD> It's related to the above. If the implementation chooses to always calculate the rate sent to a reacting node based a simple calculation of "max rate" divided by "number of reacting nodes", then it would not need to store the rate in the OCS. > > A reporting node that has selected the rate overload abatement > algorithm MUST indicate the rate requested to be applied by DOIC > reacting nodes in the OC-Maximum-Rate AVP included in the OC-OLR AVP. > > All other elements for the OCS defined in [RFC7683] and > [I-D.ietf-dime-agent-overload] also apply to the reporting nodes OCS > when using the rate abatement algorithm. > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --------------717831DAACAE5483E90D618A Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit Spencer,

Thanks for the review and comments.  Please see my comments inline.

Steve

On 1/22/19 6:06 PM, Spencer Dawkins wrote:
Spencer Dawkins has entered the following ballot position for
draft-ietf-dime-doic-rate-control-10: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dime-doic-rate-control/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

Thank you for doing this work, and for basing it on SIP Overload Control. It's
nice when protocol designers adopt good ideas from each other.

There are three SHOULDs in Section 5.1, Reporting Node Overload Control State,
I'd like to understand better.

   A reporting node that uses the rate abatement algorithm SHOULD
   maintain reporting node Overload Control State (OCS) for each
   reacting node to which it sends a rate Overload Report (OLR).

^^ This one - I'm guessing that this is "SHOULD unless you're still writing
code upgrading an implementation that treats all reacting nodes the same way",
based on this next sentence, but I'm guessing. Why wouldn't you do this?
SRD> If all reacting nodes are equal then an implementation could choose to have a single OCS entry the applies to all nodes.

      This is different from the behavior defined in [RFC7683] where a
      single loss percentage sent to all reacting nodes.

   A reporting node SHOULD maintain OCS entries when using the rate
   abatement algorithm per supported Diameter application, per targeted
   reacting node and per report type.

^^ Your answer to my previous question is likely to help me understand this
one, but I'm guessing reasons why you wouldn't do this.
SRD> Same reason as above.  

   A rate OCS entry is identified by the tuple of Application-Id, report
   type and DiameterIdentity of the target of the rate OLR.

   The rate OCS entry SHOULD include the rate allocated to the reacting
   note.

^^ I'm really interested on this one - does the rate abatement algorithm work
without knowing the rate that's allocated? but assuming that it does work, I'm
still guessing why you wouldn't do this.
SRD> It's related to the above.  If the implementation chooses to always calculate the rate sent to a reacting node based a simple calculation of "max rate" divided by "number of reacting nodes", then it would not need to store the rate in the OCS.

   A reporting node that has selected the rate overload abatement
   algorithm MUST indicate the rate requested to be applied by DOIC
   reacting nodes in the OC-Maximum-Rate AVP included in the OC-OLR AVP.

   All other elements for the OCS defined in [RFC7683] and
   [I-D.ietf-dime-agent-overload] also apply to the reporting nodes OCS
   when using the rate abatement algorithm.


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

--------------717831DAACAE5483E90D618A-- From nobody Mon Feb 4 11:51:07 2019 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 AF697130EEF for ; Mon, 4 Feb 2019 11:51:05 -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, 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 QydkSLKV2xrm for ; Mon, 4 Feb 2019 11:51:02 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) (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 A48D6126DBF for ; Mon, 4 Feb 2019 11:51:02 -0800 (PST) Received: from [97.99.21.33] (port=62536 helo=SDmac.lan) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gqkGZ-00GgGT-By for dime@ietf.org; Mon, 04 Feb 2019 11:51:02 -0800 To: dime@ietf.org References: <154820228584.13271.9727761853618479099.idtracker@ietfa.amsl.com> From: Steve Donovan Message-ID: <3a7150e2-5347-f7af-7aa0-b4e0471dba69@usdonovans.com> Date: Mon, 4 Feb 2019 13:50:50 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <154820228584.13271.9727761853618479099.idtracker@ietfa.amsl.com> Content-Type: multipart/alternative; boundary="------------C8CCDD70D9D64403C00E1B4E" 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: Subject: Re: [Dime] Adam Roach's No Objection on draft-ietf-dime-doic-rate-control-10: (with COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Feb 2019 19:51:06 -0000 This is a multi-part message in MIME format. --------------C8CCDD70D9D64403C00E1B4E Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Adam, Thanks for your review and comments. Please see my responses inline. Steve On 1/22/19 6:11 PM, Adam Roach wrote: > Adam Roach has entered the following ballot position for > draft-ietf-dime-doic-rate-control-10: No Objection > > When responding, please keep the subject line intact and reply to all > email addresses included in the To and CC lines. (Feel free to cut this > introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-dime-doic-rate-control/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > > Thanks to everyone who worked on this document. I have a handful of editorial > comments on its contents that the editor may wish to consider when revising it > to address the I-D nits identified by the document shepherd. > > --------------------------------------------------------------------------- > > §1: > >> of reporting nodes when subjected to rapidly changing loads. The > Nit: "...rapidly-changing..." > >> One of the benefits of a rate based algorithm over the loss algorithm > Nit: "...rate-based..." > >> to distribute it's load over the set of reacting nodes from which it > Nit: "...its load..." > >> specify the amount of traffic on a per reacting node basis implies > Nit: "...per-reacting-node basis..." > >> traffic to that reacting node. If the number of reacting node >> changes, either because new nodes are added, nodes are removed from > Nit: "...number of reacting nodes..." > >> Conveyance (DOIC) solution [RFC7683] to add support for the rate >> based overload abatement algorithm. > Nit: "...rate-based..." SRD> The above changes have been made. My English teaching wife would be embarrassed by the use of "it's"... > > --------------------------------------------------------------------------- > > §4: > >> As defined in [RFC7683], a DOIC reporting node supporting the rate >> feature MUST select a single abatement algorithm > Consider whether normatively reiterating normative language from another > specification makes sense. In the general case, this is a bad idea, since it > opens the door to conflicting normative definitions of behavior. Non-normative > restatement of behavior with a citation to the document that has the normative > description is typically safer. SRD> Good suggestion. Changed to: As defined in [RFC7683], a DOIC reporting node supporting the rate feature selects a single abatement algorithm in the OC-Feature-Vector AVP and OC-Peer-Algo AVP in the answer message sent to the DOIC reacting nodes. > > --------------------------------------------------------------------------- > > §5.1: > >> This is different from the behavior defined in [RFC7683] where a >> single loss percentage sent to all reacting nodes. > Nit: "...percentage is sent..." (consider also: "...where a reporting node > sends a single loss percentage to all reacting nodes.") SRD> Changes made. > > --------------------------------------------------------------------------- > > §5.2: > >> OC-OLR AVP as an element of the abatement algorithm specific portion > Nit: "...abatement-algorithm-specific portion..." SRD> Change made. > > --------------------------------------------------------------------------- > > §5.3: > >> A reporting node that has selected the rate overload abatement >> algorithm and enters an overload condition MUST indicate rate as the >> abatement algorithm in the resulting reporting node OCS entries. >> >> A reporting node that has selected the rate abatement algorithm and >> enters an overload condition MUST indicate the selected rate in the >> resulting reporting node OCS entries. > These paragraphs are similar enough that it's kind of tricky to pull out the > intended distinction being made. Consider: > > A reporting node that has selected the rate overload abatement > algorithm and enters an overload condition MUST indicate rate as the > abatement algorithm and MUST indicate the selected rate in the resulting > reporting node OCS entries. SRD> Change made. > > --------------------------------------------------------------------------- > > §5.6: > >> Other algorithms for controlling the rate MAY be implemented by >> the reacting node. Any algorithm implemented MUST result in the >> correct rate of traffic being sent to the reporting node. > It's not clear why this paragraph is indented. In some RFCs, it's conventional > to indent non-normative editor's notes to help with clarity. The presence of > normative language in this paragraph points away from that usage. Consider > either un-indenting this paragraph, or explaining the way in which this document > uses indented paragraphs (e.g., in the Introduction) SRD> I'm not sure why it was indented. I've removed the indentation. > --------------------------------------------------------------------------- > > §7. Rate Based Abatement Algorithm > > Nit: "Rate-Based..." SRD> Change made. > > > > --------------------------------------------------------------------------- > > §8.1: > >> New AVPs defined by this specification are listed in Section 6. All >> AVP codes are allocated from the 'Authentication, Authorization, and >> Accounting (AAA) Parameters' AVP Codes registry. > This is a bit confusing -- it's not clear to me whether the information in §6.3 > requires IANA action. It would probably be best to be a bit more explicit in > this section about specifically which actions IANA needs to take. > > --------------------------------------------------------------------------- > > §8.3: > >> All DOIC report types defined in the future MUST indicate whether or >> not the rate algorithm can be used with that report type. > It is also unclear what actions IANA is expected to perform based on this input. > > --------------------------------------------------------------------------- > > §10: > > Either remove or (preferably) populate this section. > > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --------------C8CCDD70D9D64403C00E1B4E Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit Adam,

Thanks for your review and comments.

Please see my responses inline.

Steve

On 1/22/19 6:11 PM, Adam Roach wrote:
Adam Roach has entered the following ballot position for
draft-ietf-dime-doic-rate-control-10: No Objection

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dime-doic-rate-control/



----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


Thanks to everyone who worked on this document. I have a handful of editorial
comments on its contents that the editor may wish to consider when revising it
to address the I-D nits identified by the document shepherd.

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

§1:


 of reporting nodes when subjected to rapidly changing loads.  The

Nit: "...rapidly-changing..."


 One of the benefits of a rate based algorithm over the loss algorithm

Nit: "...rate-based..."


 to distribute it's load over the set of reacting nodes from which it

Nit: "...its load..."


 specify the amount of traffic on a per reacting node basis implies

Nit: "...per-reacting-node basis..."


 traffic to that reacting node.  If the number of reacting node
 changes, either because new nodes are added, nodes are removed from

Nit: "...number of reacting nodes..."


 Conveyance (DOIC) solution [RFC7683] to add support for the rate
 based overload abatement algorithm.

Nit: "...rate-based..."
SRD> The above changes have been made.  My English teaching wife would be embarrassed by the use of "it's"...

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

§4:


 As defined in [RFC7683], a DOIC reporting node supporting the rate
 feature MUST select a single abatement algorithm

Consider whether normatively reiterating normative language from another
specification makes sense. In the general case, this is a bad idea, since it
opens the door to conflicting normative definitions of behavior. Non-normative
restatement of behavior with a citation to the document that has the normative
description is typically safer.
SRD>  Good suggestion.  Changed to:

        As defined in [RFC7683], a DOIC reporting node supporting the rate
        feature selects a single abatement algorithm in the OC-Feature-Vector
        AVP and OC-Peer-Algo AVP in the answer message sent to the DOIC reacting nodes.

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

§5.1:


    This is different from the behavior defined in [RFC7683] where a
    single loss percentage sent to all reacting nodes.

Nit: "...percentage is sent..." (consider also: "...where a reporting node
sends a single loss percentage to all reacting nodes.")
SRD> Changes made.

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

§5.2:


 OC-OLR AVP as an element of the abatement algorithm specific portion

Nit: "...abatement-algorithm-specific portion..."
SRD> Change made.

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

§5.3:


 A reporting node that has selected the rate overload abatement
 algorithm and enters an overload condition MUST indicate rate as the
 abatement algorithm in the resulting reporting node OCS entries.

 A reporting node that has selected the rate abatement algorithm and
 enters an overload condition MUST indicate the selected rate in the
 resulting reporting node OCS entries.

These paragraphs are similar enough that it's kind of tricky to pull out the
intended distinction being made. Consider:

   A reporting node that has selected the rate overload abatement
   algorithm and enters an overload condition MUST indicate rate as the
   abatement algorithm and MUST indicate the selected rate in the resulting
   reporting node OCS entries.
SRD> Change made.

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

§5.6:


    Other algorithms for controlling the rate MAY be implemented by
    the reacting node.  Any algorithm implemented MUST result in the
    correct rate of traffic being sent to the reporting node.

It's not clear why this paragraph is indented. In some RFCs, it's conventional
to indent non-normative editor's notes to help with clarity. The presence of
normative language in this paragraph points away from that usage. Consider
either un-indenting this paragraph, or explaining the way in which this document
uses indented paragraphs (e.g., in the Introduction)
SRD> I'm not sure why it was indented.  I've removed the indentation.
---------------------------------------------------------------------------

§7.  Rate Based Abatement Algorithm

Nit: "Rate-Based..."
SRD> Change made.



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

§8.1:


 New AVPs defined by this specification are listed in Section 6.  All
 AVP codes are allocated from the 'Authentication, Authorization, and
 Accounting (AAA) Parameters' AVP Codes registry.

This is a bit confusing -- it's not clear to me whether the information in §6.3
requires IANA action. It would probably be best to be a bit more explicit in
this section about specifically which actions IANA needs to take.

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

§8.3:


 All DOIC report types defined in the future MUST indicate whether or
 not the rate algorithm can be used with that report type.

It is also unclear what actions IANA is expected to perform based on this input.

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

§10:

Either remove or (preferably) populate this section.


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

--------------C8CCDD70D9D64403C00E1B4E-- From nobody Mon Feb 11 08:02:52 2019 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id ED48E13104A; Mon, 11 Feb 2019 08:02:50 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Secretariat To: Cc: dime@ietf.org, ipr-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <154990097096.29544.14655506851310972297@ietfa.amsl.com> Date: Mon, 11 Feb 2019 08:02:50 -0800 Archived-At: Subject: [Dime] IPR Disclosure Huawei Technologies Co., Ltd's Statement about IPR related to RFC 6737 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.29 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 16:02:51 -0000 Dear Glen Zorn, Jiao Kang: An IPR disclosure that pertains to your RFC entitled "The Diameter Capabilities Update Application" (RFC6737) was submitted to the IETF Secretariat on and has been posted on the "IETF Page of Intellectual Property Rights Disclosures" (https://datatracker.ietf.org/ipr/3421/). The title of the IPR disclosure is "Huawei Technologies Co.,Ltd's Statement about IPR related to RFC 6737" Thank you IETF Secretariat From nobody Mon Feb 11 08:49:05 2019 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F657131058; Mon, 11 Feb 2019 08:49:03 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: dime@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: dime@ietf.org Message-ID: <154990374360.29604.1703112415632645054@ietfa.amsl.com> Date: Mon, 11 Feb 2019 08:49:03 -0800 Archived-At: Subject: [Dime] I-D Action: draft-ietf-dime-doic-rate-control-11.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.29 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Feb 2019 16:49:04 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Diameter Maintenance and Extensions WG of the IETF. Title : Diameter Overload Rate Control Authors : Steve Donovan Eric Noel Filename : draft-ietf-dime-doic-rate-control-11.txt Pages : 20 Date : 2019-02-11 Abstract: This specification documents an extension to the Diameter Overload Indication Conveyance (DOIC) [RFC7683] base solution. This extension adds a new overload control abatement algorithm. This abatement algorithm allows for a DOIC reporting node to specify a maximum rate at which a DOIC reacting node sends Diameter requests to the DOIC reporting node. Requirements The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-doic-rate-control/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-dime-doic-rate-control-11 https://datatracker.ietf.org/doc/html/draft-ietf-dime-doic-rate-control-11 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-doic-rate-control-11 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Feb 11 08:51:36 2019 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 35C18131058 for ; Mon, 11 Feb 2019 08:51:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.29 X-Spam-Level: * X-Spam-Status: No, score=1.29 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANY_SPAN_IN_TEXT=2.399, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, T_HTML_ATTACH=0.01, URIBL_BLOCKED=0.001] 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 aeYb0WT01mNY for ; Mon, 11 Feb 2019 08:51:29 -0800 (PST) Received: from biz131.inmotionhosting.com (biz131.inmotionhosting.com [173.247.247.114]) (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 31DA31310AC for ; Mon, 11 Feb 2019 08:51:29 -0800 (PST) Received: from [97.99.21.33] (port=61367 helo=SDmac.lan) by biz131.inmotionhosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.91) (envelope-from ) id 1gtEnU-002xEt-RR for dime@ietf.org; Mon, 11 Feb 2019 08:51:28 -0800 To: dime@ietf.org References: <154990374360.29604.1703112415632645054@ietfa.amsl.com> From: Steve Donovan Message-ID: <3d5202a6-4406-8067-de67-23700a3bb7e5@usdonovans.com> Date: Mon, 11 Feb 2019 10:51:08 -0600 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <154990374360.29604.1703112415632645054@ietfa.amsl.com> Content-Type: multipart/mixed; boundary="------------10D1CBF1B622CDB1FFD02278" X-OutGoing-Spam-Status: No, score=5.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: Subject: Re: [Dime] I-D Action: draft-ietf-dime-doic-rate-control-11.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.29 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 Feb 2019 16:51:34 -0000 This is a multi-part message in MIME format. --------------10D1CBF1B622CDB1FFD02278 Content-Type: multipart/alternative; boundary="------------77992F637D6B29242A99997B" --------------77992F637D6B29242A99997B Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit This update captures changes resulting from the IESG review. I've attached a diff file showing the changes between version 10 and 11. Regards, Steve On 2/11/19 10:49 AM, internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Diameter Maintenance and Extensions WG of the IETF. > > Title : Diameter Overload Rate Control > Authors : Steve Donovan > Eric Noel > Filename : draft-ietf-dime-doic-rate-control-11.txt > Pages : 20 > Date : 2019-02-11 > > Abstract: > This specification documents an extension to the Diameter Overload > Indication Conveyance (DOIC) [RFC7683] base solution. This extension > adds a new overload control abatement algorithm. This abatement > algorithm allows for a DOIC reporting node to specify a maximum rate > at which a DOIC reacting node sends Diameter requests to the DOIC > reporting node. > > Requirements > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-dime-doic-rate-control/ > > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-dime-doic-rate-control-11 > https://datatracker.ietf.org/doc/html/draft-ietf-dime-doic-rate-control-11 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-doic-rate-control-11 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime --------------77992F637D6B29242A99997B Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 7bit This update captures changes resulting from the IESG review.

I've attached a diff file showing the changes between version 10 and 11.

Regards,

Steve

On 2/11/19 10:49 AM, internet-drafts@ietf.org wrote:
A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Diameter Maintenance and Extensions WG of the IETF.

        Title           : Diameter Overload Rate Control
        Authors         : Steve Donovan
                          Eric Noel
	Filename        : draft-ietf-dime-doic-rate-control-11.txt
	Pages           : 20
	Date            : 2019-02-11

Abstract:
   This specification documents an extension to the Diameter Overload
   Indication Conveyance (DOIC) [RFC7683] base solution.  This extension
   adds a new overload control abatement algorithm.  This abatement
   algorithm allows for a DOIC reporting node to specify a maximum rate
   at which a DOIC reacting node sends Diameter requests to the DOIC
   reporting node.

Requirements

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dime-doic-rate-control/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-dime-doic-rate-control-11
https://datatracker.ietf.org/doc/html/draft-ietf-dime-doic-rate-control-11

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dime-doic-rate-control-11


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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

--------------77992F637D6B29242A99997B-- --------------10D1CBF1B622CDB1FFD02278 Content-Type: text/html; charset=UTF-8; name="Diff draft-ietf-dime-doic-rate-control-10.txt - draft-ietf-dime-doic-rate-control-11.txt.html" Content-Transfer-Encoding: 8bit Content-Disposition: attachment; filename*0="Diff draft-ietf-dime-doic-rate-control-10.txt - draft-ietf-"; filename*1="dime-doic-rate-control-11.txt.html" Diff: draft-ietf-dime-doic-rate-control-10.txt - draft-ietf-dime-doic-rate-control-11.txt
< draft-ietf-dime-doic-rate-control-10.txt   draft-ietf-dime-doic-rate-control-11.txt >
Diameter Maintenance and Extensions (DIME) S. Donovan, Ed. Diameter Maintenance and Extensions (DIME) S. Donovan, Ed.
Internet-Draft Oracle Internet-Draft Oracle
Intended status: Standards Track E. Noel Intended status: Standards Track E. Noel
Expires: April 6, 2019 AT&T Labs Expires: August 15, 2019 AT&T Labs
October 3, 2018 February 11, 2019
Diameter Overload Rate Control Diameter Overload Rate Control
draft-ietf-dime-doic-rate-control-10 draft-ietf-dime-doic-rate-control-11
Abstract Abstract
This specification documents an extension to the Diameter Overload This specification documents an extension to the Diameter Overload
Indication Conveyance (DOIC) [RFC7683] base solution. This extension Indication Conveyance (DOIC) [RFC7683] base solution. This extension
adds a new overload control abatement algorithm. This abatement adds a new overload control abatement algorithm. This abatement
algorithm allows for a DOIC reporting node to specify a maximum rate algorithm allows for a DOIC reporting node to specify a maximum rate
at which a DOIC reacting node sends Diameter requests to the DOIC at which a DOIC reacting node sends Diameter requests to the DOIC
reporting node. reporting node.
skipping to change at page 1, line 44 ¶ skipping to change at page 1, line 44 ¶
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on April 6, 2019. This Internet-Draft will expire on August 15, 2019.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2019 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 39 ¶ skipping to change at page 2, line 39 ¶
5.3. Reporting Node Maintenance of Overload Control State . . 7 5.3. Reporting Node Maintenance of Overload Control State . . 7
5.4. Reacting Node Maintenance of Overload Control State . . . 8 5.4. Reacting Node Maintenance of Overload Control State . . . 8
5.5. Reporting Node Behavior for Rate Abatement Algorithm . . 8 5.5. Reporting Node Behavior for Rate Abatement Algorithm . . 8
5.6. Reacting Node Behavior for Rate Abatement Algorithm . . . 9 5.6. Reacting Node Behavior for Rate Abatement Algorithm . . . 9
6. Rate Abatement Algorithm AVPs . . . . . . . . . . . . . . . . 9 6. Rate Abatement Algorithm AVPs . . . . . . . . . . . . . . . . 9
6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 9 6.1. OC-Supported-Features AVP . . . . . . . . . . . . . . . . 9
6.1.1. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . 9 6.1.1. OC-Feature-Vector AVP . . . . . . . . . . . . . . . . 9
6.2. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 9 6.2. OC-OLR AVP . . . . . . . . . . . . . . . . . . . . . . . 9
6.2.1. OC-Maximum-Rate AVP . . . . . . . . . . . . . . . . . 10 6.2.1. OC-Maximum-Rate AVP . . . . . . . . . . . . . . . . . 10
6.3. Attribute Value Pair Flag Rules . . . . . . . . . . . . . 10 6.3. Attribute Value Pair Flag Rules . . . . . . . . . . . . . 10
7. Rate Based Abatement Algorithm . . . . . . . . . . . . . . . 10 7. Rate-Based Abatement Algorithm . . . . . . . . . . . . . . . 10
7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . 11
7.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 11 7.2. Reporting Node Behavior . . . . . . . . . . . . . . . . . 11
7.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 12 7.3. Reacting Node Behavior . . . . . . . . . . . . . . . . . 12
7.3.1. Default Algorithm for Rate-based Control . . . . . . 12 7.3.1. Default Algorithm for Rate-based Control . . . . . . 12
7.3.2. Priority Treatment . . . . . . . . . . . . . . . . . 15 7.3.2. Priority Treatment . . . . . . . . . . . . . . . . . 15
7.3.3. Optional Enhancement: Avoidance of Resonance . . . . 17 7.3.3. Optional Enhancement: Avoidance of Resonance . . . . 17
8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 18 8. IANA Consideration . . . . . . . . . . . . . . . . . . . . . 18
8.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 18 8.1. AVP Codes . . . . . . . . . . . . . . . . . . . . . . . . 18
8.2. New Registries . . . . . . . . . . . . . . . . . . . . . 18 8.2. OC-Supported-Features . . . . . . . . . . . . . . . . . . 18
8.3. New DOIC report types . . . . . . . . . . . . . . . . . . 18 8.3. New DOIC report types . . . . . . . . . . . . . . . . . . 19
9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 19
11.1. Normative References . . . . . . . . . . . . . . . . . . 19 11.1. Normative References . . . . . . . . . . . . . . . . . . 19
11.2. Informative References . . . . . . . . . . . . . . . . . 19 11.2. Informative References . . . . . . . . . . . . . . . . . 20
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
This document defines a new Diameter overload control abatement This document defines a new Diameter overload control abatement
algorithm, the "rate" algorithm. algorithm, the "rate" algorithm.
The base Diameter overload specification [RFC7683] defines the "loss" The base Diameter overload specification [RFC7683] defines the "loss"
algorithm as the default Diameter overload abatement algorithm. The algorithm as the default Diameter overload abatement algorithm. The
loss algorithm allows a reporting node (see Section 2) to instruct a loss algorithm allows a reporting node (see Section 2) to instruct a
reacting node (see Section 2) to reduce the amount of traffic sent to reacting node (see Section 2) to reduce the amount of traffic sent to
the reporting node by abating (diverting or throttling) a percentage the reporting node by abating (diverting or throttling) a percentage
of requests sent to the server. While this can effectively decrease of requests sent to the server. While this can effectively decrease
the load handled by the server, it does not directly address cases the load handled by the server, it does not directly address cases
where the rate of arrival of service requests changes quickly. For where the rate of arrival of service requests changes quickly. For
instance, if the service requests that result in Diameter instance, if the service requests that result in Diameter
transactions increase quickly then the loss algorithm cannot transactions increase quickly then the loss algorithm cannot
guarantee the load presented to the server remains below a specific guarantee the load presented to the server remains below a specific
rate level. The loss algorithm can be slow to ensure the stability rate level. The loss algorithm can be slow to ensure the stability
of reporting nodes when subjected to rapidly changing loads. The of reporting nodes when subjected to rapidly-changing loads. The
"loss" algorithm errs both in throttling too much when there is a dip "loss" algorithm errs both in throttling too much when there is a dip
in offered load, and throttling not enough when there is a spike in in offered load, and throttling not enough when there is a spike in
offered load. offered load.
Consider the case where a reacting node is handling 100 service Consider the case where a reacting node is handling 100 service
requests per second, where each of these service requests results in requests per second, where each of these service requests results in
one Diameter transaction being sent to a reporting node. If the one Diameter transaction being sent to a reporting node. If the
reporting node is approaching an overload state, or is already in an reporting node is approaching an overload state, or is already in an
overload state, it will send a Diameter overload report requesting a overload state, it will send a Diameter overload report requesting a
percentage reduction in traffic sent when the loss algorithm is used percentage reduction in traffic sent when the loss algorithm is used
skipping to change at page 4, line 16 ¶ skipping to change at page 4, line 16 ¶
report requesting that the reacting node abate 91% of requests to get report requesting that the reacting node abate 91% of requests to get
back to the desired 90 transactions per second. However, once the back to the desired 90 transactions per second. However, once the
spike has abated and the reacting node handled service requests spike has abated and the reacting node handled service requests
returns to 100 per second, this will result in just 9 transactions returns to 100 per second, this will result in just 9 transactions
per second being sent to the reporting node, requiring a new overload per second being sent to the reporting node, requiring a new overload
report setting the reduction percentage back to 10%. This control report setting the reduction percentage back to 10%. This control
feedback loop has the potential to make the situation worse by feedback loop has the potential to make the situation worse by
causing wide fluctuations in traffic on multiple nodes in the causing wide fluctuations in traffic on multiple nodes in the
Diameter network. Diameter network.
One of the benefits of a rate based algorithm over the loss algorithm One of the benefits of a rate-based algorithm over the loss algorithm
is that it better handles spikes in traffic. Instead of sending a is that it better handles spikes in traffic. Instead of sending a
request to reduce traffic by a percentage, the rate approach allows request to reduce traffic by a percentage, the rate approach allows
the reporting node to specify the maximum number of Diameter requests the reporting node to specify the maximum number of Diameter requests
per second that can be sent to the reporting node. For instance, in per second that can be sent to the reporting node. For instance, in
this example, the reporting node could send a rate-based request this example, the reporting node could send a rate-based request
specifying the maximum transactions per second to be 90. The specifying the maximum transactions per second to be 90. The
reacting node will send the 90 regardless of whether it is receiving reacting node will send the 90 regardless of whether it is receiving
100 or 1000 service requests per second. 100 or 1000 service requests per second.
It should be noted that one of the implications of the rate based It should be noted that one of the implications of the rate-based
algorithm is that the reporting node needs to determine how it wants algorithm is that the reporting node needs to determine how it wants
to distribute it's load over the set of reacting nodes from which it to distribute its load over the set of reacting nodes from which it
is receiving traffic. For instance, if the reporting node is is receiving traffic. For instance, if the reporting node is
receiving Diameter traffic from 10 reacting nodes and has a capacity receiving Diameter traffic from 10 reacting nodes and has a capacity
of 100 transactions per second then the reporting node could choose of 100 transactions per second then the reporting node could choose
to set the rate for each of the reacting nodes to 10 transactions per to set the rate for each of the reacting nodes to 10 transactions per
second. This, of course, is assuming that each of the reacting nodes second. This, of course, is assuming that each of the reacting nodes
has equal performance characteristics. The reporting node could also has equal performance characteristics. The reporting node could also
choose to have a high capacity reacting node send 55 transactions per choose to have a high capacity reacting node send 55 transactions per
second and the remaining 9 low capacity reacting nodes send 5 second and the remaining 9 low capacity reacting nodes send 5
transactions per second. The ability of the reporting node to transactions per second. The ability of the reporting node to
specify the amount of traffic on a per reacting node basis implies specify the amount of traffic on a per-reacting-node basis implies
that the reporting node must maintain state for each of the reacting that the reporting node must maintain state for each of the reacting
nodes. This state includes the current allocation of Diameter nodes. This state includes the current allocation of Diameter
traffic to that reacting node. If the number of reacting node traffic to that reacting node. If the number of reacting nodes
changes, either because new nodes are added, nodes are removed from changes, either because new nodes are added, nodes are removed from
service or nodes fail, then the reporting node will need to service or nodes fail, then the reporting node will need to
redistribute the maximum Diameter transactions over the new set of redistribute the maximum Diameter transactions over the new set of
reacting nodes. reacting nodes.
This document extends the base Diameter Overload Indication This document extends the base Diameter Overload Indication
Conveyance (DOIC) solution [RFC7683] to add support for the rate Conveyance (DOIC) solution [RFC7683] to add support for the rate-
based overload abatement algorithm. based overload abatement algorithm.
This document draws heavily on work in the SIP Overload Control This document draws heavily on work in the SIP Overload Control
working group. The definition of the rate abatement algorithm is working group. The definition of the rate abatement algorithm is
copied almost verbatim from the SIP Overload Control (SOC) document copied almost verbatim from the SIP Overload Control (SOC) document
[RFC7415], with changes focused on making the wording consistent with [RFC7415], with changes focused on making the wording consistent with
the DOIC solution and the Diameter protocol. the DOIC solution and the Diameter protocol.
2. Terminology 2. Terminology
skipping to change at page 6, line 15 ¶ skipping to change at page 6, line 15 ¶
4. Capability Announcement 4. Capability Announcement
This document defines the rate abatement algorithm (referred to as This document defines the rate abatement algorithm (referred to as
rate in this document) feature. Support for the rate feature by a rate in this document) feature. Support for the rate feature by a
DOIC node will be indicated by a new value of the OC-Feature-Vector DOIC node will be indicated by a new value of the OC-Feature-Vector
AVP, as described in Section 6.1.1, per the rules defined in AVP, as described in Section 6.1.1, per the rules defined in
[RFC7683]. [RFC7683].
Since all nodes that support DOIC are required to support the loss Since all nodes that support DOIC are required to support the loss
algorithm, DOIC nodes supporting the rate feature will support both algorithm, DOIC nodes supporting the rate feature will support both
the loss and rate based abatement algorithms. the loss and rate-based abatement algorithms.
DOIC reacting nodes supporting the rate feature MUST indicate support DOIC reacting nodes supporting the rate feature MUST indicate support
for both the loss and rate algorithms in the OC-Feature-Vector AVP. for both the loss and rate algorithms in the OC-Feature-Vector AVP
and MAY indicate support for other algorithms.
As defined in [RFC7683], a DOIC reporting node supporting the rate As defined in [RFC7683], a DOIC reporting node supporting the rate
feature MUST select a single abatement algorithm in the OC-Feature- feature selects a single abatement algorithm in the OC-Feature-Vector
Vector AVP and OC-Peer-Algo AVP in the answer message sent to the AVP and OC-Peer-Algo AVP in the answer message sent to the DOIC
DOIC reacting nodes. reacting nodes.
A reporting node can select one abatement algorithm to apply to host A reporting node can select one abatement algorithm to apply to host
and realm reports and a different algorithm to apply to peer reports. and realm reports and a different algorithm to apply to peer reports.
For host or realm reports the selected algorithm is reflected in For host or realm reports the selected algorithm is reflected in
the OC-Feature-Vector AVP sent as part of the OC-Supported- the OC-Feature-Vector AVP sent as part of the OC-Supported-
Features AVP included in answer messages for transaction where the Features AVP included in answer messages for transaction where the
request contained an OC-Supported-Features AVP. This is per the request contained an OC-Supported-Features AVP. This is per the
procedures defined in [RFC7683]. procedures defined in [RFC7683].
skipping to change at page 7, line 6 ¶ skipping to change at page 7, line 6 ¶
[RFC7683] for handling of overload reports when the rate overload [RFC7683] for handling of overload reports when the rate overload
abatement algorithm is used. abatement algorithm is used.
5.1. Reporting Node Overload Control State 5.1. Reporting Node Overload Control State
A reporting node that uses the rate abatement algorithm SHOULD A reporting node that uses the rate abatement algorithm SHOULD
maintain reporting node Overload Control State (OCS) for each maintain reporting node Overload Control State (OCS) for each
reacting node to which it sends a rate Overload Report (OLR). reacting node to which it sends a rate Overload Report (OLR).
This is different from the behavior defined in [RFC7683] where a This is different from the behavior defined in [RFC7683] where a
single loss percentage sent to all reacting nodes. reporting node sends a single loss percentage to all reacting
nodes.
A reporting node SHOULD maintain OCS entries when using the rate A reporting node SHOULD maintain OCS entries when using the rate
abatement algorithm per supported Diameter application, per targeted abatement algorithm per supported Diameter application, per targeted
reacting node and per report type. reacting node and per report type.
A rate OCS entry is identified by the tuple of Application-Id, report A rate OCS entry is identified by the tuple of Application-Id, report
type and DiameterIdentity of the target of the rate OLR. type and DiameterIdentity of the target of the rate OLR.
The rate OCS entry SHOULD include the rate allocated to the reacting The rate OCS entry SHOULD include the rate allocated to the reacting
note. note.
skipping to change at page 7, line 35 ¶ skipping to change at page 7, line 36 ¶
5.2. Reacting Node Overload Control State 5.2. Reacting Node Overload Control State
A reacting node that supports the rate abatement algorithm MUST A reacting node that supports the rate abatement algorithm MUST
indicate rate as the selected abatement algorithm in the reacting indicate rate as the selected abatement algorithm in the reacting
node OCS based on the OC-Feature-Vector AVP or the OC-Peer-Algo AVP node OCS based on the OC-Feature-Vector AVP or the OC-Peer-Algo AVP
in the received OC-Supported-Features AVP. in the received OC-Supported-Features AVP.
A reacting node that supports the rate abatement algorithm MUST A reacting node that supports the rate abatement algorithm MUST
include the rate specified in the OC-Maximum-Rate AVP included in the include the rate specified in the OC-Maximum-Rate AVP included in the
OC-OLR AVP as an element of the abatement algorithm specific portion OC-OLR AVP as an element of the abatement-algorithm-specific portion
of reacting node OCS entries. of reacting node OCS entries.
All other elements for the OCS defined in [RFC7683] and All other elements for the OCS defined in [RFC7683] and
[I-D.ietf-dime-agent-overload] also apply to the reporting nodes OCS [I-D.ietf-dime-agent-overload] also apply to the reporting nodes OCS
when using the rate abatement algorithm. when using the rate abatement algorithm.
5.3. Reporting Node Maintenance of Overload Control State 5.3. Reporting Node Maintenance of Overload Control State
A reporting node that has selected the rate overload abatement A reporting node that has selected the rate overload abatement
algorithm and enters an overload condition MUST indicate rate as the algorithm and enters an overload condition MUST indicate rate as the
abatement algorithm in the resulting reporting node OCS entries. abatement algorithm and MUST indicate the selected rate in the
A reporting node that has selected the rate abatement algorithm and
enters an overload condition MUST indicate the selected rate in the
resulting reporting node OCS entries. resulting reporting node OCS entries.
When selecting the rate algorithm in the response to a request that When selecting the rate algorithm in the response to a request that
contained an OC-Supporting-Features AVP with an OC-Feature-Vector AVP contained an OC-Supporting-Features AVP with an OC-Feature-Vector AVP
indicating support for the rate feature, a reporting node MUST ensure indicating support for the rate feature, a reporting node MUST ensure
that a reporting node OCS entry exists for the target of the overload that a reporting node OCS entry exists for the target of the overload
report. The target is defined as follows: report. The target is defined as follows:
o For Host reports, the target is the DiameterIdentity contained in o For Host reports, the target is the DiameterIdentity contained in
the Origin-Host AVP received in the request. the Origin-Host AVP received in the request.
skipping to change at page 8, line 48 ¶ skipping to change at page 8, line 44 ¶
5.5. Reporting Node Behavior for Rate Abatement Algorithm 5.5. Reporting Node Behavior for Rate Abatement Algorithm
When in an overload condition with rate selected as the overload When in an overload condition with rate selected as the overload
abatement algorithm and when handling a request that contained an OC- abatement algorithm and when handling a request that contained an OC-
Supported-Features AVP that indicated support for the rate abatement Supported-Features AVP that indicated support for the rate abatement
algorithm, a reporting node SHOULD include an OC-OLR AVP for the rate algorithm, a reporting node SHOULD include an OC-OLR AVP for the rate
algorithm using the parameters stored in the reporting node OCS for algorithm using the parameters stored in the reporting node OCS for
the target of the overload report. the target of the overload report.
Note: It is also possible for the reporting node to send overload Note: It is also possible for the reporting node to send overload
reports with the rate algorithm indicated when the reporting node reports with the rate algorithm indicated even when the reporting
is not in an overloaded state. This could be a strategy to node is not in an overloaded state. This could be a strategy to
proactively avoid entering into an overloaded state. Whether to proactively avoid entering into an overloaded state. Whether to
do so is up to local policy. do so is up to local policy.
When sending an overload report for the rate algorithm, the OC- When sending an overload report for the rate algorithm, the OC-
Maximum-Rate AVP MUST be included in the OC-OLR AVP and the OC- Maximum-Rate AVP MUST be included in the OC-OLR AVP and the OC-
Reduction-Percentage AVP MUST NOT be included. Reduction-Percentage AVP MUST NOT be included.
5.6. Reacting Node Behavior for Rate Abatement Algorithm 5.6. Reacting Node Behavior for Rate Abatement Algorithm
When determining if abatement treatment should be applied to a When determining if abatement treatment should be applied to a
request being sent to a reporting node that has selected the rate request being sent to a reporting node that has selected the rate
overload abatement algorithm, the reacting node MAY use the algorithm overload abatement algorithm, the reacting node can choose to use the
detailed in Section 7. algorithm detailed in Section 7.
Other algorithms for controlling the rate MAY be implemented by Other algorithms for controlling the rate MAY be implemented by the
the reacting node. Any algorithm implemented MUST result in the reacting node. Any algorithm implemented MUST correctly limit the
correct rate of traffic being sent to the reporting node. maximum rate of traffic being sent to the reporting node.
Once a determination is made by the reacting node that an individual Once a determination is made by the reacting node that an individual
Diameter request is to be subjected to abatement treatment then the Diameter request is to be subjected to abatement treatment then the
procedures for throttling and diversion defined in [RFC7683] and procedures for throttling and diversion defined in [RFC7683] and
[I-D.ietf-dime-agent-overload] apply. [I-D.ietf-dime-agent-overload] apply.
6. Rate Abatement Algorithm AVPs 6. Rate Abatement Algorithm AVPs
6.1. OC-Supported-Features AVP 6.1. OC-Supported-Features AVP
skipping to change at page 10, line 43 ¶ skipping to change at page 10, line 43 ¶
+---------+ +---------+
|AVP flag | |AVP flag |
|rules | |rules |
+----+----+ +----+----+
AVP Section | |MUST| AVP Section | |MUST|
Attribute Name Code Defined Value Type |MUST| NOT| Attribute Name Code Defined Value Type |MUST| NOT|
+---------------------------------------------------------+----+----+ +---------------------------------------------------------+----+----+
|OC-Maximum-Rate TBD1 6.2 Unsigned32 | | V | |OC-Maximum-Rate TBD1 6.2 Unsigned32 | | V |
+---------------------------------------------------------+----+----+ +---------------------------------------------------------+----+----+
7. Rate Based Abatement Algorithm 7. Rate-Based Abatement Algorithm
This section is pulled from [RFC7415], with minor changes needed to This section is pulled from [RFC7415], with minor changes needed to
make it apply to the Diameter protocol. make it apply to the Diameter protocol.
7.1. Overview 7.1. Overview
The reporting node is the one protected by the overload control The reporting node is the one protected by the overload control
algorithm defined here. The reacting node is the one that abates algorithm defined here. The reacting node is the one that abates
traffic towards the server. traffic towards the server.
skipping to change at page 11, line 25 ¶ skipping to change at page 11, line 25 ¶
(e.g. CPU utilization or queuing delay) to evaluate its overload (e.g. CPU utilization or queuing delay) to evaluate its overload
state and estimate a target maximum Diameter request rate in number state and estimate a target maximum Diameter request rate in number
of requests per second (as opposed to target percent reduction in the of requests per second (as opposed to target percent reduction in the
case of loss-based abatement). case of loss-based abatement).
When in an overloaded state, the reporting node uses the OC-OLR AVP When in an overloaded state, the reporting node uses the OC-OLR AVP
to inform reacting nodes of its overload state and of the target to inform reacting nodes of its overload state and of the target
Diameter request rate. Diameter request rate.
Upon receiving the overload report with a target maximum Diameter Upon receiving the overload report with a target maximum Diameter
request rate, each reacting node applies abatement treatment for new request rate, each reacting node applies overload abatement for new
Diameter requests towards the reporting node. Diameter requests towards the reporting node.
7.2. Reporting Node Behavior 7.2. Reporting Node Behavior
The actual algorithm used by the reporting node to determine its The actual algorithm used by the reporting node to determine its
overload state and estimate a target maximum Diameter request rate is overload state and estimate a target maximum Diameter request rate is
beyond the scope of this document. beyond the scope of this document.
However, the reporting node MUST periodically evaluate its overload However, the reporting node MUST periodically evaluate its overload
state and estimate a target Diameter request rate beyond which it state and estimate a target Diameter request rate beyond which it
skipping to change at page 12, line 8 ¶ skipping to change at page 12, line 8 ¶
When setting the maximum rate for a particular reacting node, the When setting the maximum rate for a particular reacting node, the
reporting node may need take into account the workload (e.g. CPU reporting node may need take into account the workload (e.g. CPU
load per request) of the distribution of message types from that load per request) of the distribution of message types from that
reacting node. Furthermore, because the reacting node may prioritize reacting node. Furthermore, because the reacting node may prioritize
the specific types of messages it sends while under overload the specific types of messages it sends while under overload
restriction, this distribution of message types may be different from restriction, this distribution of message types may be different from
the message distribution for that reacting node under non-overload the message distribution for that reacting node under non-overload
conditions (e.g., either higher or lower CPU load). conditions (e.g., either higher or lower CPU load).
Note that the value of OC-Maximum-Rate AVP (in request messages per Note that the value of OC-Maximum-Rate AVP (in request messages per
second) for the rate algorithm provides an upper bound on the traffic second) for the rate algorithm provides a loose upper bound on the
sent by the reacting node to the reporting node. traffic sent by the reacting node to the reporting node.
In other words, when multiple reacting nodes are being controlled by In other words, when multiple reacting nodes are being controlled by
an overloaded reporting node, at any given time, some reporting nodes an overloaded reporting node, at any given time, some reporting nodes
may receive requests at a rate below its target maximum Diameter may receive requests at a rate below its target maximum Diameter
request rate while others above that target rate. But the resulting request rate while others above that target rate. But the resulting
request rate presented to the overloaded reporting node will converge request rate presented to the overloaded reporting node will converge
towards the target Diameter request rate or a lower rate. towards the target Diameter request rate or a lower rate.
Upon detection of overload, and the determination to invoke overload Upon detection of overload, and the determination to invoke overload
controls, the reporting node follows the specifications in [RFC7683] controls, the reporting node follows the specifications in [RFC7683]
skipping to change at page 12, line 34 ¶ skipping to change at page 12, line 34 ¶
The reporting node uses the OC-Maximum-Rate AVP defined in this The reporting node uses the OC-Maximum-Rate AVP defined in this
specification to communicate a target maximum Diameter request rate specification to communicate a target maximum Diameter request rate
to each of its clients. to each of its clients.
7.3. Reacting Node Behavior 7.3. Reacting Node Behavior
7.3.1. Default Algorithm for Rate-based Control 7.3.1. Default Algorithm for Rate-based Control
A reference algorithm is shown below. A reference algorithm is shown below.
Note that use of // below inidcates a comment.
No priority case: No priority case:
// T: inter-transmission interval, set to 1 / OC-Maximum-Rate // T: inter-transmission interval, set to 1 / OC-Maximum-Rate
// TAU: tolerance parameter // TAU: tolerance parameter
// ta: arrival time of the most recent arrival // ta: arrival time of the most recent arrival
// LCT: arrival time of last Diameter request that // LCT: arrival time of last Diameter request that
// was sent to the server // was sent to the server
// (initialized to the first arrival time) // (initialized to the first arrival time)
// X: current value of the leaky bucket counter (initialized to // X: current value of the leaky bucket counter (initialized to
// TAU0) // TAU0)
skipping to change at page 16, line 18 ¶ skipping to change at page 16, line 18 ¶
// ta: arrival time of the most recent arrival // ta: arrival time of the most recent arrival
// LCT: arrival time of last Diameter request that // LCT: arrival time of last Diameter request that
// was sent to the server // was sent to the server
// (initialized to the first arrival time) // (initialized to the first arrival time)
// X: current value of the leaky bucket counter (initialized to // X: current value of the leaky bucket counter (initialized to
// TAU0) // TAU0)
// After most recent arrival, calculate auxiliary variable Xp // After most recent arrival, calculate auxiliary variable Xp
Xp = X - (ta - LCT); Xp = X - (ta - LCT);
if (AnyRequestReceived && Xp <= TAU1) || (PriorityRequestReceived && if (AnyRequestReceived && Xp <= TAU1) || (PriorityRequestReceived &&
Xp <= TAU2 && Xp > TAU1) { Xp <= TAU2 && Xp > TAU1) {
// Transmit Diameter request // Transmit Diameter request
// Update X and LCT // Update X and LCT
X = max (0, Xp) + T; X = max (0, Xp) + T;
LCT = ta; LCT = ta;
} else { } else {
// Apply abatement treatment to Diameter request // Apply abatement treatment to Diameter request
// Do not update X and LCT // Do not update X and LCT
} }
skipping to change at page 18, line 43 ¶ skipping to change at page 18, line 43 ¶
'phasing' of the buckets remains. 'phasing' of the buckets remains.
8. IANA Consideration 8. IANA Consideration
8.1. AVP Codes 8.1. AVP Codes
New AVPs defined by this specification are listed in Section 6. All New AVPs defined by this specification are listed in Section 6. All
AVP codes are allocated from the 'Authentication, Authorization, and AVP codes are allocated from the 'Authentication, Authorization, and
Accounting (AAA) Parameters' AVP Codes registry. Accounting (AAA) Parameters' AVP Codes registry.
8.2. New Registries 8.2. OC-Supported-Features
There are no new IANA registries introduced by this document. As indicated in Section 6.1.1, a new allocation is required in the
OC-Feature-Vector AVP.
8.3. New DOIC report types 8.3. New DOIC report types
All DOIC report types defined in the future MUST indicate whether or All DOIC report types defined in the future MUST indicate whether or
not the rate algorithm can be used with that report type. not the rate algorithm can be used with that report type.
9. Security Considerations 9. Security Considerations
The rate overload abatement mechanism is an extension to the base The rate overload abatement mechanism is an extension to the base
Diameter overload mechanism. As such, all of the security Diameter overload mechanism. As such, all of the security
considerations outlined in [RFC7683] apply to the rate overload considerations outlined in [RFC7683] apply to the rate overload
abatement mechanism. abatement mechanism.
In addition, the rate algorithm could be used to handle DoS attacks
more effectively than the loss algorithm.
10. Acknowledgements 10. Acknowledgements
Lionel Morand for his contributions to the document.
11. References 11. References
11.1. Normative References 11.1. Normative References
[I-D.ietf-dime-agent-overload] [I-D.ietf-dime-agent-overload]
Donovan, S., "Diameter Agent Overload", draft-ietf-dime- Donovan, S., "Diameter Agent Overload", draft-ietf-dime-
agent-overload-00 (work in progress), December 2014. agent-overload-00 (work in progress), December 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
 End of changes. 32 change blocks. 
41 lines changed or deleted 48 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/
--------------10D1CBF1B622CDB1FFD02278-- From nobody Tue Feb 12 12:46:51 2019 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 4FEED130DEC for ; Tue, 12 Feb 2019 12:46:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com 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 dsn2avSrHtOa for ; Tue, 12 Feb 2019 12:46:48 -0800 (PST) Received: from mail-lj1-x235.google.com (mail-lj1-x235.google.com [IPv6:2a00:1450:4864:20::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D382F12F1A5 for ; Tue, 12 Feb 2019 12:46:47 -0800 (PST) Received: by mail-lj1-x235.google.com with SMTP id o1-v6so27650ljc.10 for ; Tue, 12 Feb 2019 12:46:47 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rPJsJPuVEa6ydgf7YFXese7BnQumk0QY9OHL42IYFS0=; b=HVxD/Iqf9dLT7VX/SHCXp/6cKqE15+jKsFAxDrxBNx0TuEvNcoxGs+iINsLNKUBN3Y HjTarLufEZbNWxXg+v2sDJ302nFW1HAHn4VkhGc1k4R1nvXbXv9o70vCy1bGEuicNEwR igEzgEKRcnQgNjyea4a0+fXJZZHqASkQzznrb2KNCsIvcI96wBRRpQqYqCob8r3M11Dr Sep2UOR2gUBLjUw24k1c7rOl2qLG29mAqvcxo//lA12VF/QJ9Pq9I6G4ZD2JvWcV0tce hwL+L55gj/eOB9egKddrnOGjOryM1mrE//GQpBm1kdOQCEqhM0K9hsIXxt/qmKA2Zvp2 A0AA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=rPJsJPuVEa6ydgf7YFXese7BnQumk0QY9OHL42IYFS0=; b=lNdc4ReXEvzaiLUI9yBG3JGnrclKRscRh+DhoTq4+RhrKQTrWZ7tCs54zKIWTfD/8v bByQrGWLAIXlmoPQN2oI7YhSm+RUHL1p76XALe4cvLkg2Ww1/98WxQyTnb2Kb8cMz5iI Z1lzs0NoVRzK5zUUoJM2BXSnGv+ls8urHadcUGiahc3kauip/KrXFcjDz/fVlhDyJD0V RI5jsK/Z7L6ckH+zn2K6H4J294QA6XfKm8SZgsWuIMJG+b960y8z3zgw2bMz2ocQBfUq tYN+TA/ZkmXF4X/WL10D5YpVKTt8XwHO+d49OcAm71Fh9YA2NxRhHhDuXS3Tj0uY8kO7 xE5w== X-Gm-Message-State: AHQUAuY0UQHTTg4Z49CHr8Ve0CV35FM53e8tviZONNZ4/5cbmXzj/3Rx kIPUE1PgR9KR9A2SUzr8v5fWmwG+CA4= X-Google-Smtp-Source: AHgI3Iaeezpg9YTJABtCDu3jVhDXYl35NUDQYBowFmUuLhisIaBccMFqy+Z8TzPmrORZox5KWKtPEA== X-Received: by 2002:a2e:8554:: with SMTP id u20-v6mr3406625ljj.193.1550004405809; Tue, 12 Feb 2019 12:46:45 -0800 (PST) Received: from [172.16.69.59] ([83.150.126.201]) by smtp.gmail.com with ESMTPSA id f140sm2116152lff.41.2019.02.12.12.46.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 12 Feb 2019 12:46:44 -0800 (PST) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\)) From: Jouni In-Reply-To: <3d5202a6-4406-8067-de67-23700a3bb7e5@usdonovans.com> Date: Tue, 12 Feb 2019 22:46:42 +0200 Cc: dime@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <154990374360.29604.1703112415632645054@ietfa.amsl.com> <3d5202a6-4406-8067-de67-23700a3bb7e5@usdonovans.com> To: Steve Donovan X-Mailer: Apple Mail (2.3445.9.1) Archived-At: Subject: Re: [Dime] I-D Action: draft-ietf-dime-doic-rate-control-11.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Feb 2019 20:46:50 -0000 Thanks Steve. Looks OK to me now. Maybe you could also add similar into = overload draft? It also seems to miss the IANA section reference to = feature vector. - Jouni > On 11 Feb 2019, at 18.51, Steve Donovan = wrote: >=20 > This update captures changes resulting from the IESG review. >=20 > I've attached a diff file showing the changes between version 10 and = 11. >=20 > Regards, >=20 > Steve >=20 > On 2/11/19 10:49 AM, internet-drafts@ietf.org wrote: >> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >> This draft is a work item of the Diameter Maintenance and Extensions = WG of the IETF. >>=20 >> Title : Diameter Overload Rate Control >> Authors : Steve Donovan >> Eric Noel >> Filename : draft-ietf-dime-doic-rate-control-11.txt >> Pages : 20 >> Date : 2019-02-11 >>=20 >> Abstract: >> This specification documents an extension to the Diameter Overload >> Indication Conveyance (DOIC) [RFC7683] base solution. This = extension >> adds a new overload control abatement algorithm. This abatement >> algorithm allows for a DOIC reporting node to specify a maximum = rate >> at which a DOIC reacting node sends Diameter requests to the DOIC >> reporting node. >>=20 >> Requirements >>=20 >> The IETF datatracker status page for this draft is: >>=20 >> https://datatracker.ietf.org/doc/draft-ietf-dime-doic-rate-control/ >>=20 >>=20 >> There are also htmlized versions available at: >>=20 >> https://tools.ietf.org/html/draft-ietf-dime-doic-rate-control-11 >> = https://datatracker.ietf.org/doc/html/draft-ietf-dime-doic-rate-control-11= >>=20 >>=20 >> A diff from the previous version is available at: >>=20 >> = https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-doic-rate-control-11 >>=20 >>=20 >>=20 >> Please note that it may take a couple of minutes from the time of = submission >> until the htmlized version and diff are available at tools.ietf.org. >>=20 >> Internet-Drafts are also available by anonymous FTP at: >>=20 >> ftp://ftp.ietf.org/internet-drafts/ >>=20 >>=20 >> _______________________________________________ >> DiME mailing list >>=20 >> DiME@ietf.org >> https://www.ietf.org/mailman/listinfo/dime >=20 > ____________________________= ___________________ > DiME mailing list > DiME@ietf.org > https://www.ietf.org/mailman/listinfo/dime From nobody Tue Feb 12 20:13:31 2019 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 A3B8512D4F3 for ; Tue, 12 Feb 2019 20:13:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com 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 65JA340nlFNK for ; Tue, 12 Feb 2019 20:13:28 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1697012D4ED for ; Tue, 12 Feb 2019 20:13:27 -0800 (PST) Received: from [10.0.1.29] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x1D4DP4R055309 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 12 Feb 2019 22:13:26 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1550031207; bh=OPsCnW9Pe9u6TmERZZA/OlJhpmG66WrudE99riX7lLs=; h=From:Subject:Date:In-Reply-To:Cc:To:References; b=T3gXLwvR0k6ty+klr/BFEUsLs+8G1jYmGbLRNCkRKM1n4TyrnemGRHwPud4DeVjnP 9oEZHNFpku/p2mfpJiOk2WNLjqpNsvB8ZLcPmLhEpFMc6/agXuA40bc+B0LMJdwSPA HjEN1iqqpi/PjmQd1C6AP2p+VQjwUU9vHK1pXNeQ= X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.29] From: Ben Campbell Message-Id: <71CF24E2-EA3D-4A02-9DFB-36403507829C@nostrum.com> Content-Type: multipart/signed; boundary="Apple-Mail=_69D671D0-2DC7-497A-B583-EB362803167F"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Tue, 12 Feb 2019 22:13:23 -0600 In-Reply-To: <2032a50a-9e1e-d97f-114b-974dc97c3870@usdonovans.com> Cc: dime@ietf.org To: Steve Donovan References: <154827019075.7547.9421622385944852216.idtracker@ietfa.amsl.com> <2032a50a-9e1e-d97f-114b-974dc97c3870@usdonovans.com> X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: Re: [Dime] Benjamin Kaduk's No Objection on draft-ietf-dime-doic-rate-control-10: (with COMMENT) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 04:13:30 -0000 --Apple-Mail=_69D671D0-2DC7-497A-B583-EB362803167F Content-Type: multipart/alternative; boundary="Apple-Mail=_6AE9B181-7C1E-4533-8085-C14E58D148F9" --Apple-Mail=_6AE9B181-7C1E-4533-8085-C14E58D148F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Responding to one question below: > On Feb 4, 2019, at 1:29 PM, Steve Donovan = wrote: >=20 >> Do you want to add this requirement as a "Note" on the IANA registry >> itself? > SRD> I don't understand the subtlety of the question. Do you have > suggested wording or can you explain what a "Note" on the IANA = registry is? >=20 I think Benjamin asks if we want IANA to put a note at the beginning of = the registry with the requirement that new report type registrations = need to indicate if they support rate. If the answer is yes, I think = that can be handled with an email to IANA rather than requiring a change = to the draft. (It=E2=80=99s explicitly stated in the IANA = considerations, so they might do so anyway.) Ben. --Apple-Mail=_6AE9B181-7C1E-4533-8085-C14E58D148F9 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Responding to one question below:

On Feb = 4, 2019, at 1:29 PM, Steve Donovan <srdonovan@usdonovans.com> wrote:

Do = you want to add this requirement as a "Note" on the IANA registry
itself?
SRD> I don't understand the subtlety of the question. =  Do you have
suggested wording or can you explain what a "Note" on the = IANA registry is?


I think Benjamin asks if we want IANA to put = a note at the beginning of the registry with the requirement that new = report type registrations need to indicate if they support rate. =  If the answer is yes, I think that can be handled with an email to = IANA rather than requiring a change to the draft. (It=E2=80=99s = explicitly stated in the IANA considerations, so they might do so = anyway.)

Ben.


= --Apple-Mail=_6AE9B181-7C1E-4533-8085-C14E58D148F9-- --Apple-Mail=_69D671D0-2DC7-497A-B583-EB362803167F Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlxjmWMACgkQgFZKbJXz 1A0xuxAAhJBpC4RVp9C/lzmlPR1IZE8pGQPlHUqylyy7kkeIXhtkLU8pahhUhWq8 6eugvq3SpUZIE3uEEQVstjXMwPXvUY4unARlISTW3UGYLNFIenX2E7URUXBO9Qb9 Ab6slGBTo5d0+2F5RTeYAhKf++GBImeInB+82WuJQtDn3vkwIPqvx9iDYNXXyEAN /7tTKxX/VaWivb320rPNyI7A5elTC+ceEt6CmfBFudjCclKSm6jZfWarMV4x1aW5 czyyC1aBauqOLHIjgs6Huzv9EDrbHTT6MFuoBl9mCVYry8qJp7xmVx5/rp86Ro+O Yte8gPSQnrSxtm/WeE83LBEqqocW98W4HlxzZIt5FQIPyWXHCx3hulqPr0hZvpSP uFI05NiYyovZn9Jgpid8K6ei33BrJVQJkG79bA+w++36KtQqYq/NMKh9saMX5Clz KkG7D9DLjKmbuK1LnKvEFETLhsFMxTR978d4JG01TUHBel7k+vuXeWI28Bd9C9tw fjCaF6Qe9xSYo6CLG/++JK3ZFGY5JQEe4lY8i+9yLvA/whWrSoxX0//HQ2HiGyjp 8VBIS+BRL7EpzTX8hjyvQT9A/CKNKwD/QAxDeDZ7G3IxBn06Cyy2kCSiNU72CD8/ UkK+TTAgbWGE5ayDJmyfIAOTMvrUexwufBZbXLgYueaUIOC7ue4= =xbCS -----END PGP SIGNATURE----- --Apple-Mail=_69D671D0-2DC7-497A-B583-EB362803167F-- From nobody Tue Feb 12 20:14:38 2019 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 7525B12D4ED; Tue, 12 Feb 2019 20:14:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.978 X-Spam-Level: X-Spam-Status: No, score=-1.978 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com 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 ECRwNyGLJA0R; Tue, 12 Feb 2019 20:14:36 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 16CD312D4EC; Tue, 12 Feb 2019 20:14:36 -0800 (PST) Received: from [10.0.1.29] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x1D4EXtn055449 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 12 Feb 2019 22:14:35 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1550031275; bh=h8w/7OMm0dVj2iEbAgmsiqzmldHUz9G6xwQj9F7hNnc=; h=From:Subject:Date:References:Cc:To; b=OW4LRod+CPjw/iU3dNQduZVrHCLB8xxd/thKCiiu2PL/4JEAGLQfSHcx11CNJ18XL n9eziptXGA02e7MU+FKTy7Hb9+GHmlJBSXLFACPfQarrO/XiszgXxIgV7SWsEkwa54 k82bXp2LDknvgn2vthDG3Z3XNW9DTQJS+zXblDS8= X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.29] From: Ben Campbell Content-Type: multipart/signed; boundary="Apple-Mail=_87D43E8D-E1CC-4E76-9233-AC9EF731C00D"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Date: Tue, 12 Feb 2019 22:14:32 -0600 References: <154990374375.29604.8164947170462883980.idtracker@ietfa.amsl.com> Cc: dime@ietf.org To: draft-ietf-dime-doic-rate-control.all@ietf.org Message-Id: X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: [Dime] Fwd: New Version Notification - draft-ietf-dime-doic-rate-control-11.txt X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 04:14:37 -0000 --Apple-Mail=_87D43E8D-E1CC-4E76-9233-AC9EF731C00D Content-Type: multipart/alternative; boundary="Apple-Mail=_E8007EC6-7695-4905-9A8D-30EF76F5D9C7" --Apple-Mail=_E8007EC6-7695-4905-9A8D-30EF76F5D9C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii I think this version is ready for the RFC Editor. I will approve it = momentarily. Thanks! Ben. > Begin forwarded message: >=20 > From: internet-drafts@ietf.org > Subject: New Version Notification - = draft-ietf-dime-doic-rate-control-11.txt > Date: February 11, 2019 at 10:49:03 AM CST > To: , "Lionel Morand" >=20 >=20 > A new version (-11) has been submitted for = draft-ietf-dime-doic-rate-control: > = https://www.ietf.org/internet-drafts/draft-ietf-dime-doic-rate-control-11.= txt >=20 > Sub state has been changed to AD Followup from Revised ID Needed >=20 >=20 > The IETF datatracker page for this Internet-Draft is: > https://datatracker.ietf.org/doc/draft-ietf-dime-doic-rate-control/ >=20 > Diff from previous version: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-doic-rate-control-11= >=20 > Please note that it may take a couple of minutes from the time of = submission > until the diff is available at tools.ietf.org. >=20 > IETF Secretariat. >=20 --Apple-Mail=_E8007EC6-7695-4905-9A8D-30EF76F5D9C7 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii I = think this version is ready for the RFC Editor. I will approve it = momentarily.

Thanks!

Ben.

Begin forwarded = message:

From: = internet-drafts@ietf.org
Subject: = New Version = Notification - draft-ietf-dime-doic-rate-control-11.txt
Date: = February 11, 2019 at 10:49:03 = AM CST
To: = <ben@nostrum.com>, = "Lionel Morand" <lionel.morand@orange.com>

A new version = (-11) has been submitted for draft-ietf-dime-doic-rate-control:
https://www.ietf.org/internet-drafts/draft-ietf-dime-doic-rate-= control-11.txt

Sub state has been = changed to AD Followup from Revised ID Needed


The IETF datatracker page for this = Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-dime-doic-rate-cont= rol/

Diff from previous version:
https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-dime-doic-rate-c= ontrol-11

Please note that it may take a = couple of minutes from the time of submission
until the = diff is available at tools.ietf.org.

IETF = Secretariat.


= --Apple-Mail=_E8007EC6-7695-4905-9A8D-30EF76F5D9C7-- --Apple-Mail=_87D43E8D-E1CC-4E76-9233-AC9EF731C00D Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlxjmagACgkQgFZKbJXz 1A3WNRAApxGhOK8vWEM63uYeiDm6PZQqdZjWHAShf40Qv87gknCvtihFsrszjfXd lk5s/tFjcpAtRnT0FO39BvfaQJILN3A6Jc5Ke2t4XII4lWtSp33q2UU9Ie1qziWq qK1/bRqisBVIi+kqtqEI1DHe7aPuV6X9pTCa/O3W3ezu3iEfiEIeAB4wSA44mwXo izJzDjT9BJLMNFT0r+Mygcgb8pEDr5+9809WD+He37rfeGTWuHBWjSUP2IBSU07M 0ztCE8FyI9TtiLiMMlgOKqfsUaf2eS2tyBiVxJoECZcEXpqdmxCZpLi9uh4wxfRr dCUGYD2Gp7gHo0Hi4vbTN+YfsNz4AXGLZdO+43SqYxyMEJp+Ac6GHHxpvbp3Z0z5 635fxHDvsK0ZyKVaH0/8cfpnsM4izWgoRNM1oSMf86+GSbA/ZY6wnDrYuqOssSxp OAVQkNQlAZ2O3E3pVrhSKoDaOepD85aIYcOS24qRY5wJvek8ylAUAYmrQoaW2Owr sxO8ylqyGra1IRmYuW05ZSzLy7EBOPMihlpb4gDi9GCpyx0JkLEwaykni659AwAj 5vI31iPpLny3+jwMd4r0tEGhZYhMoPRGg6bT5sCIJbZavj+AEgn+w8u+EYg82sL2 dZ0AKLO3iYif0np0JUxMO2cldR3951BArDk8Mf9AJVxybbPHr14= =n2Ve -----END PGP SIGNATURE----- --Apple-Mail=_87D43E8D-E1CC-4E76-9233-AC9EF731C00D-- From nobody Wed Feb 13 06:04:19 2019 Return-Path: X-Original-To: dime@ietf.org Delivered-To: dime@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 061541274D0; Wed, 13 Feb 2019 06:04:10 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: The IESG To: "IETF-Announce" X-Test-IDTracker: no X-IETF-IDTracker: 6.91.0 Auto-Submitted: auto-generated Precedence: bulk Cc: ben@nostrum.com, The IESG , lionel.morand@orange.com, dime-chairs@ietf.org, dime@ietf.org, Lionel Morand , draft-ietf-dime-doic-rate-control@ietf.org, rfc-editor@rfc-editor.org MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-ID: <155006664997.9441.16572412616140380853.idtracker@ietfa.amsl.com> Date: Wed, 13 Feb 2019 06:04:09 -0800 Archived-At: Subject: [Dime] Protocol Action: 'Diameter Overload Rate Control' to Proposed Standard (draft-ietf-dime-doic-rate-control-11.txt) X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.29 List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Feb 2019 14:04:10 -0000 The IESG has approved the following document: - 'Diameter Overload Rate Control' (draft-ietf-dime-doic-rate-control-11.txt) as Proposed Standard This document is the product of the Diameter Maintenance and Extensions Working Group. The IESG contact persons are Warren Kumari, Ignas Bagdonas and Ben Campbell. A URL of this Internet Draft is: https://datatracker.ietf.org/doc/draft-ietf-dime-doic-rate-control/ Technical Summary In the Diameter Overload Indication Conveyance (DOIC) base solution, the default algorithm to support is the "loss" algorithm, used to request a percentage reduction in the amount of traffic received. The present document defines a new algorihtm, "rate", that is used to announce a maximum rate instead of a percentage of requested traffic reduction. Highlighting the limits of the loss algorithm, this new algorithm is designed to better handle spikes in traffic. It heavily relies on the rate-based algorithm defined by the SIP Overload Control working group adapting to the DOIC solution and the Diameter protocol. The algorithm used to estimate a target maximum Diameter request rate is left out of scope of this document but some recommendations are given. Any algorithm can be used to limit the message rate to comply with requested maximum sending rate. However, a default algorithm is described in the document. Working Group Summary The document received a large support for adoption when initiated and it has been reviewed multiple times, with detailed comments and corrections. There is a strong WG consensus on the content of this document, with a broad range of people, including key experts. Document Quality The proposed solution has not been implemented yet, as vendors are waiting for IANA AVP code value assignment before implementing. However, no issues are expected with implementation. Moreover, the solution defined in this document inherits from the work done for SIP. It is known that 3GPP operators want to use this rate-based mechanism instead of the loss algo in their network, using a similar mechanism in SIP/IMS. Personnel The document shepherd is Lionel Morand. The responsible AD is Ben Campbell. From nobody Mon Feb 18 22:14:11 2019 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 E0207130E71; Mon, 18 Feb 2019 22:14:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.98 X-Spam-Level: X-Spam-Status: No, score=-1.98 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nostrum.com 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 lqCe7KPQ2O2U; Mon, 18 Feb 2019 22:14:06 -0800 (PST) Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9A7C51200B3; Mon, 18 Feb 2019 22:14:02 -0800 (PST) Received: from [10.0.1.29] (cpe-70-122-203-106.tx.res.rr.com [70.122.203.106]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id x1J6DxTK025760 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 19 Feb 2019 00:14:00 -0600 (CST) (envelope-from ben@nostrum.com) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=nostrum.com; s=default; t=1550556841; bh=gHKrtiqabTq/JqOwP1qFHYAuz/f5RJS2Q9TSNCIm9fM=; h=From:Subject:Date:Cc:To; b=KOGGnnfk6xRtQFRtPyG3VLSIzgeA/EbAIG01S+/YtowYxg6ex4e2B4fhviuPbsMMj lstVQtSrHh0/XFHDRhV40HL5oJfYRVObm06Ktl6SyU9vg3ftuVAfqhMkBLchMnwlay zqdZFmdSTQVIEhwcIHRo3cmyWWaTU12tpz1WERh4= X-Authentication-Warning: raven.nostrum.com: Host cpe-70-122-203-106.tx.res.rr.com [70.122.203.106] claimed to be [10.0.1.29] From: Ben Campbell Content-Type: multipart/signed; boundary="Apple-Mail=_3946243B-46B6-4335-AD95-5485281D1B79"; protocol="application/pgp-signature"; micalg=pgp-sha512 Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Message-Id: <555EE6E7-E817-4D12-9DF1-4AAE4CF5BA41@nostrum.com> Date: Tue, 19 Feb 2019 00:13:57 -0600 Cc: dime@ietf.org To: draft-ietf-dime-group-signaling.all@ietf.org X-Mailer: Apple Mail (2.3445.102.3) Archived-At: Subject: [Dime] AD Evaluation of draft-ietf-dime-group-signaling-12 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Feb 2019 06:14:10 -0000 --Apple-Mail=_3946243B-46B6-4335-AD95-5485281D1B79 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Hi, This is my AD evaluation of draft-ietf-dime-group-signaling-12. This draft is on the right track, but is not ready for IETF LC. I have a = few substantive comments and a number of editorial comments that need to = be resolved first. Thanks! Ben. *** Substantive Comments *** - General: There were comments in the shepherd=E2=80=99s report that = need to be addressed. =C2=A74.1: Why is the SHOULD not a MUST? What would be the consequences = of not following it? =C2=A74.1.2, last paragraph: How long should a node remember that = another node has announced support for groups? Is that memory forever? = What happens if that node ceases to support groups in the future? =C2=A74.2: - "A Diameter node MUST also keep a record about sessions, which have been assigned to a session group by itself.=E2=80=9D Is this the same as saying a node MUST record the owner of each group? = Why does it matter which node assigned a specific session to a group? =C2=A74.2 and children: I=E2=80=99d like to see more text about what combinations are allowed = and there order of application. For example, if the presence of a = Session-Group-Info AVP with the SESSION_GROUP_ALLOCATION_ACTION flag = cleared and Session-Group-Id AVP absent indicates deletion of a session = from all groups, what if the message also contains other = Session-Group-Info AVPs that assign groups? Is that the same thing as = moving a session between groups? I=E2=80=99d also like to see some earlier text describing the meaning of = Session-Id AVPs in group management and group operations. There=E2=80=99s = a mention of that in the =E2=80=9Cformat=E2=80=9D section, but that = seems an odd place to put it. =C2=A74.2.1: - General: Am I correct to assume that failure of a Diameter command = means no groups are assigned? If so, please state that explicitly. - first paragraph: The =E2=80=9CMUST=E2=80=9D seems like a statement of = fact. That is, there=E2=80=99s no implementation choice to make here. - "If the Diameter server accepts the client=E2=80=99s request for a = group assignment, but the assignment of the session to one or some of the multiple identified session groups fails,=E2=80=9D This seems self contradictory; if the assignment fails then how can the = server have accepted it? Is there a practical difference between = assignment failure and assignment rejection? - "If the Diameter server receives a command request from a Diameter client and the command comprises one or multiple Session-Group-Info AVPs and none of them includes a Session-Group-Id AVP, the server MAY decide to assign the session to one or multiple session groups.=E2=80=9D Is there an expectation that the server assigns the session to the same = number of groups as the the number of Session-Group-Id AVPs included by = the client? If not, why would the client ever include more than one. Is the client prohibited from sending multiple AVPs, some of which = contain session IDs and some of which do not? - "the Diameter client SHOULD NOT retry to request group assignment for this session, but MAY try to request group assignment for other new sessions.=E2=80=9D Why is the SHOULD NOT not a MUST NOT? =C2=A74.2.3: - "When a Diameter server enforces an update to the assigned groups = midsession, it sends a Re-Authorization Request (RAR) message to the client identifying the session=E2=80=A6=E2=80=9D Should that say =E2=80=9Cor service-specific request=E2=80=9D? Or is = this operation limited to applications that use RAR? =C2=A74.4.1: - "If the process of the request is delay-sensitive, the sender SHOULD NOT set the Group-Response- Action AVP to ALL_GROUPS (1) or PER_GROUP (2).=E2=80=9D Why not MUST NOT? - "If the answer can be sent before the complete process of the request for all the sessions or if the request timeout timer is high enough, the sender MAY set the Group-Response-Action AVP to ALL_GROUPS (1) or PER_GROUP (2).=E2=80=9D= Can you offer guidance on how to decide if a timeout timer is high = enough? =C2=A75: - It=E2=80=99s worth mentioning that a stateful proxy must advertise = support. - "Session group related AVPs being defined as optional AVP SHOULD be ignored by stateless Proxy Agents and SHOULD NOT be removed from the Diameter commands.=E2=80=9D This seems to put normative requirements on nodes that do not implement = this spec. Or is it really a statement of fact? =C2=A77.3: Can you offer guidance on how to ensure sufficient = uniqueness? =E2=80=9CEternal=E2=80=9D seems like a pretty high bar; is = that really the intention? =C2=A710: It doesn=E2=80=99t seem likely that the e2e protection work = for Diameter will ever complete, or at least not in the near future. I = suggest toning down the hopeful language that talks about it. *** Editorial Comments and Nits ** - General: The draft needs at least another proofreading and editing = pass to improve readability and clarity. In particular, it needs to be = proofread for the following: - plural agreement - Comma usage (there are many placed incorrectly, and many missing where = needed) - Proper use of =E2=80=9Cwhich=E2=80=9D vs =E2=80=9Cthat=E2=80=9D (and = the associated comma use.) - Convoluted sentence structure =C2=A72: Please use the new boilerplate from RFC 8174. i =C2=A73.1, - first paragraph: =E2=80=9Ce.g.=E2=80=9D requires a comma afterwards: = =E2=80=9Ce.g.,=E2=80=9D (There are several instances of this throughout = the draft.) - "In case of mobile users, the user=E2=80=99s session may get = transferred to a new Diameter client during handover and assigned to a different group, which is maintained at the new Diameter client, mid-session.=E2=80=9D= This is hard to parse. I suggest moving =E2=80=9Cmid-session=E2=80=9D to = earlier in the sentence. For example, =E2=80=9C=E2=80=A6 session may get = transferred mid-session to a new Diameter client=E2=80=A6=E2=80=9D =C2=A73.2: I gather this section is an example. If say, please state = that explicitly. =C2=A73.3: - This section uses confusing language to describe which nodes can do = what. In particular, it often says =E2=80=9Cany=E2=80=9D node, where I = think it means =E2=80=9Ceither the client or the server=E2=80=9D. I = assume nodes that are not a party to a session-group can=E2=80=99t = modify it, correct? Likewise it says =E2=80=9Ceach=E2=80=9D node when I = think it means =E2=80=9Ceither node=E2=80=9D. - "Prerequisite for deletion of a session group is that the Diameter node created the session beforehand, hence the node became the group owner.=E2=80=9D This seems like a complicated way to explain a simple concept. I suggest = something to the effect of =E2=80=9CA session group may only be deleted = by the Diameter node that created it.=E2=80=9D - "The enforcement of more constrained permissions is left to the specification of a particular group signaling enabled Diameter application and compliant implementations of such application MUST enforce the associated permission model.=E2=80=9D This is overly complicated language. I suggest something to the effect = of ""Diameter application with explicit support for session groups may = define a more constrained permission model.=E2=80=9D Also, the MUST is = not really appropriate; it=E2=80=99s up to the definitions of those = applications to set normative requirements on implementations, not = _this_ draft. - "specification. For example, a more constrained model could require that a client MUST NOT remove a session from a group which is owned by the server.=E2=80=9D Please do not use normative keywords in an example; examples are by = definition non-normative. - Default permissions table: I am confused by the =E2=80=9Cclient=E2=80=9D= and =E2=80=9Cserver=E2=80=9D columns. If I understand this section = correctly, the role of =E2=80=9Cclient=E2=80=9D and =E2=80=9Cserver=E2=80=9D= is not relevant. (It is telling that each row has the same value in = both columns.) Please consider stating this in terms of group = =E2=80=9Cowner=E2=80=9D and =E2=80=9Cnon-owner=E2=80=9D. - Editor=E2=80=99s note: If this draft does not consider overruling a = node=E2=80=99s assignment, why talk about it at all? (Although it seems = like it _does_ support that, in the sense that a server can reject or = change assignments proposed by a client.) =C2=A74.1: Please avoid normative language in the form of = =E2=80=9CSHOULD=E2=80=A6only=E2=80=A6=E2=80=9D. That can be ambiguous. = It=E2=80=99s better to say =E2=80=9CSHOULD NOT =E2=80=A6 unless. For = example, =E2=80=9CSHOULD NOT perform group operations with a node unless = the node has advertised support=E2=80=9D. =C2=A74.1.1: - It seems to me that =C2=A74.1.1 and =C2=A74.1.2 have =E2=80=9Cexplicit=E2= =80=9D and =E2=80=9Cimplicit=E2=80=9D reversed, in the sense that, if a = Diameter application supports groups, then the announcement of group = support is =E2=80=9Cimplied=E2=80=9D by the announcement of support for = the application. OTOH, the use of Session-Group-Capability-Vector is an = =E2=80=9Cexplicit=E2=80=9D announcement of group support. - "New Diameter applications may consider support =E2=80=9C s/consider/specify - "Such applications provide intrinsic discovery for the support of group commands and announce this capability through the assigned application ID.=E2=80=9D This is confusing. I think you mean support for groups is implied by the = announcement of support for the application that explicitly supports = it.But it can be read to mean a separate explicit announcement of group = support. =C2=A74.2: - "It is left to the application to determine the policy of session grouping.=E2=80=9D Does =E2=80=9Capplication=E2=80=9D mean Diameter application, or just = =E2=80=9Cimplementation=E2=80=9D? Also, this is vague; I think this = still talks about limits to the number of groups a session belongs to, = which is much more precise than =E2=80=9Cthe policy of session = grouping=E2=80=9D. - The second paragraph seems redundant with =C2=A73.3. The phrase =E2=80=9Csingle or multiple=E2=80=9D would be easier to read = as =E2=80=9Cone or more=E2=80=9D. (This pattern repeats throughout the = draft, along with some instances of =E2=80=9Cone or multiple=E2=80=9D) - =E2=80=9CA list of all known session groups should be locally = maintained on each node, each group pointing to individual sessions being assigned to the group." s/should be/is =C2=A74.2.1: - =E2=80=9C=E2=80=A6 the server MUST assign the new session to each of = the one or multiple identified session groups when present in =E2=80=A6=E2=80=9D - "If the Diameter server receives a command request from a Diameter client and the command comprises at least one Session-Group-Info AVP=E2=80= =9D s/comprises/includes (=E2=80=9Ccomprises=E2=80=9D means =E2=80=9Cmade = up of=E2=80=9D, which would suggest that the request contains only = Session-Group-Info AVPs). (This occurs several times throughout the = draft.) What does =E2=80=9Cwhen=E2=80=9D mean in context? Would =E2=80=9C...sessio= n groups present in=E2=80=A6=E2=80=9D mean the same thing? - "In case one or multiple identified session groups are not already stored by the server=E2=80=9D =E2=80=9CIn case=E2=80=9D usually refers to planning for a contingency = (For example, =E2=80=9CI have a fire extinguisher in case of fire=E2=80=9D= ). I suggest =E2=80=9CIn the case where=E2=80=A6=E2=80=9D or even = better, =E2=80=9CIf=E2=80=A6=E2=80=9D (Variations of this pattern occur = several times.) - "the server MUST store the new identified group(s)=E2=80=9D s/new/newly - "The server sends the response to the client and MAY include as information to the client only those Session-Group- Info AVPs for which the group assignment failed.=E2=80=9D Hard to parse. - "session. When the Diameter client is confident that the Diameter server supports session grouping=E2=80=A6=E2=80= =9D Since this should always be true before the client sends _any_ group = operation, why restate it here? =C2=A74.4.1: - "Either Diameter node (client or server) can request the recipient of a request to process an associated command for all sessions being assigned to one or multiple groups by identifying these groups in the request.=E2=80=9D s/sessions being assigned/sessions assigned - Please expand =E2=80=9CCCF=E2=80=9D on first mention. - sentence starting with "When a server sends, as example, a = Re-Authorization Request (RAR) or a service-specific server-initiated request=E2=80=A6=E2=80=9D The sentence is hard to parse. - "If the sender sends a request including the Group-Response-Action AVP set to ALL_GROUPS (1) or PER_GROUP (2), it MUST expect some delay=E2=80=A6= =E2=80=9D =E2=80=9Cexpect=E2=80=9D is vague for use in a MUST requirement. Please = state this in terms of concrete actions or state it descriptively. =C2=A7A.1, first paragraph: Please don=E2=80=99t use normative keywords = to describe requirements defined in other documents. Doing so introduces = a high chance of error if either document is updated in the future. --Apple-Mail=_3946243B-46B6-4335-AD95-5485281D1B79 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIzBAEBCgAdFiEExW9rpd7ez4DexOFOgFZKbJXz1A0FAlxrnqUACgkQgFZKbJXz 1A2hWRAAxKZKpJWYqRPts0kCGM9qFIzO+nl5NJaZ6vqADSYw+vC7I+WHUbZ0xmmz N7P6VSw4jsNGt386piwv0hUvN6AM5Kyi8t1SJIicgzh5/rwMOm9kxGzxQbSPTZOl MlHJWWGVfoXz88JCKIea3LuETrpqAJCxT4toPOUKZsZVwGT9vRyShQMH5BM4Ttgn J0oqwtAAGO3rmMuTmYODwuMxXdDx2TMYEA4xGduKg3g6BK0+wpHAcBFqL/PM1Nwz JR6Qfb1mxdVJfI/J/K8vca82hR/Ofug6oPbXka91Ci6cwfXq4IZdbIBn5R2zqTVq MGyzD6c2ZqhDMraHsrHvi0PR6UMTI9QEzLsa0TxdKBGY3MdhYH8jNvB3HDcyC0x4 SfCCUbro3Wa8mSzVALxkbjNRdu34gtfNBAnbcRCZnE8oWuG9GUYi9PdvTtKOe52Q VZ7trlRtesMZxOHEkobPs3xFBD0eue3Roxks7sAUP1MKF7Gn9NdGCTU0HKYlntn9 2YseLMbDinMonGxcq1us0MRNc68syhzpSUAn3D34etYl2YA+Vv4mc9PKuxwMBL4I oEWbUhnoBKK7RfFAMGZt21IR2M0WqH75h+79YNeffFVvk7DxcQE9d18qgMf/6/Hf vMJmLYboJsKSCbsl0UCWNsrxlfuRhAJn+q6lgXAUMHAKoLoSG30= =gDTX -----END PGP SIGNATURE----- --Apple-Mail=_3946243B-46B6-4335-AD95-5485281D1B79-- From nobody Tue Feb 26 06:48:38 2019 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 A7427130E5D; Tue, 26 Feb 2019 06:48:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham 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 tuueBreoHGvp; Tue, 26 Feb 2019 06:48:34 -0800 (PST) Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E108E128CE4; Tue, 26 Feb 2019 06:48:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id 34C9A104E5E; Tue, 26 Feb 2019 15:48:29 +0100 (CET) X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de) Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PckDd6Mq_Tvi; Tue, 26 Feb 2019 15:48:29 +0100 (CET) X-ENC: Last-Hop-TLS-encrypted X-ENC: Last-Hop-TLS-encrypted Received: from METHONE.office.hd (METHONE.office.hd [192.168.24.54]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id 0A725104E59; Tue, 26 Feb 2019 15:48:23 +0100 (CET) Received: from PALLENE.office.hd ([169.254.1.27]) by METHONE.office.hd ([192.168.24.54]) with mapi id 14.03.0319.002; Tue, 26 Feb 2019 15:48:22 +0100 From: Marco Liebsch To: Ben Campbell , "draft-ietf-dime-group-signaling.all@ietf.org" CC: "dime@ietf.org" Thread-Topic: AD Evaluation of draft-ietf-dime-group-signaling-12 Thread-Index: AQHUyBpZ9rDRKpjjhEiLZB0dpvnpN6XyM56w Date: Tue, 26 Feb 2019 14:48:21 +0000 Message-ID: <69756203DDDDE64E987BC4F70B71A26DE592EE54@PALLENE.office.hd> References: <555EE6E7-E817-4D12-9DF1-4AAE4CF5BA41@nostrum.com> In-Reply-To: <555EE6E7-E817-4D12-9DF1-4AAE4CF5BA41@nostrum.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.1.6.170] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [Dime] AD Evaluation of draft-ietf-dime-group-signaling-12 X-BeenThere: dime@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Diameter Maintanence and Extentions Working Group List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2019 14:48:38 -0000 SGkgQmVuLA0KDQp0aGFua3MgYSBsb3QgZm9yIHRoZSByZXZpZXcgYW5kIGRldGFpbGVkIGNvbW1l bnRzLiBXZSdsbCBhZGRyZXNzIGVkaXRvcmlhbCBpdGVtcyBmaXJzdCBhbmQgY29udmVyZ2Ugb24g dGhlIHN1YnN0YW50aXZlIGNvbW1lbnRzLg0KRm9yIHRoZSBjb21tZW50cyBwZXIgdGhlIHNoZXBo ZXJk4oCZcyByZXBvcnQsIEkgdGhvdWdodCB3ZSBhZGRyZXNzZWQgYWxsIG9mIHRoZW0gYW5kIGNv bmZpcm1lZCB3aXRoIEpvdW5pIGF0IHRoYXQgcG9pbnQgaW4gdGltZSwNCmJ1dCB3ZSdsbCBjaGVj ayBhZ2Fpbi4gDQoNCk1hcmNvDQoNCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206 IEJlbiBDYW1wYmVsbCBbbWFpbHRvOmJlbkBub3N0cnVtLmNvbV0gDQpTZW50OiBEaWVuc3RhZywg MTkuIEZlYnJ1YXIgMjAxOSAwNzoxNA0KVG86IGRyYWZ0LWlldGYtZGltZS1ncm91cC1zaWduYWxp bmcuYWxsQGlldGYub3JnDQpDYzogZGltZUBpZXRmLm9yZw0KU3ViamVjdDogQUQgRXZhbHVhdGlv biBvZiBkcmFmdC1pZXRmLWRpbWUtZ3JvdXAtc2lnbmFsaW5nLTEyDQoNCkhpLA0KDQpUaGlzIGlz IG15IEFEIGV2YWx1YXRpb24gb2YgZHJhZnQtaWV0Zi1kaW1lLWdyb3VwLXNpZ25hbGluZy0xMi4N Cg0KVGhpcyBkcmFmdCBpcyBvbiB0aGUgcmlnaHQgdHJhY2ssIGJ1dCBpcyBub3QgcmVhZHkgZm9y IElFVEYgTEMuIEkgaGF2ZSBhIGZldyBzdWJzdGFudGl2ZSBjb21tZW50cyBhbmQgYSBudW1iZXIg b2YgZWRpdG9yaWFsIGNvbW1lbnRzIHRoYXQgbmVlZCB0byBiZSByZXNvbHZlZCBmaXJzdC4NCg0K VGhhbmtzIQ0KDQpCZW4uDQoNCioqKiBTdWJzdGFudGl2ZSBDb21tZW50cyAqKioNCi0gR2VuZXJh bDogVGhlcmUgd2VyZSBjb21tZW50cyBpbiB0aGUgc2hlcGhlcmTigJlzIHJlcG9ydCB0aGF0IG5l ZWQgdG8gYmUgYWRkcmVzc2VkLg0KDQrCpzQuMTogV2h5IGlzIHRoZSBTSE9VTEQgbm90IGEgTVVT VD8gV2hhdCB3b3VsZCBiZSB0aGUgY29uc2VxdWVuY2VzIG9mIG5vdCBmb2xsb3dpbmcgaXQ/DQoN CsKnNC4xLjIsIGxhc3QgcGFyYWdyYXBoOiBIb3cgbG9uZyBzaG91bGQgYSBub2RlIHJlbWVtYmVy IHRoYXQgYW5vdGhlciBub2RlIGhhcyBhbm5vdW5jZWQgc3VwcG9ydCBmb3IgZ3JvdXBzPyBJcyB0 aGF0IG1lbW9yeSBmb3JldmVyPyBXaGF0IGhhcHBlbnMgaWYgdGhhdCBub2RlIGNlYXNlcyB0byBz dXBwb3J0IGdyb3VwcyBpbiB0aGUgZnV0dXJlPw0KDQrCpzQuMjoNCg0KLSAiQSBEaWFtZXRlciBu b2RlIE1VU1QgYWxzbyBrZWVwIGEgcmVjb3JkIGFib3V0IHNlc3Npb25zLCB3aGljaCBoYXZlIGJl ZW4gYXNzaWduZWQgdG8gYSBzZXNzaW9uIGdyb3VwIGJ5IGl0c2VsZi7igJ0NCg0KSXMgdGhpcyB0 aGUgc2FtZSBhcyBzYXlpbmcgYSBub2RlIE1VU1QgcmVjb3JkIHRoZSBvd25lciBvZiBlYWNoIGdy b3VwPyBXaHkgZG9lcyBpdCBtYXR0ZXIgd2hpY2ggbm9kZSBhc3NpZ25lZCBhIHNwZWNpZmljIHNl c3Npb24gdG8gYSBncm91cD8NCg0Kwqc0LjIgYW5kIGNoaWxkcmVuOg0KDQpJ4oCZZCBsaWtlIHRv IHNlZSBtb3JlIHRleHQgYWJvdXQgd2hhdCBjb21iaW5hdGlvbnMgYXJlIGFsbG93ZWQgYW5kIHRo ZXJlIG9yZGVyIG9mIGFwcGxpY2F0aW9uLiBGb3IgZXhhbXBsZSwgaWYgdGhlIHByZXNlbmNlIG9m IGEgU2Vzc2lvbi1Hcm91cC1JbmZvIEFWUCB3aXRoIHRoZSBTRVNTSU9OX0dST1VQX0FMTE9DQVRJ T05fQUNUSU9OIGZsYWcgY2xlYXJlZCBhbmQgU2Vzc2lvbi1Hcm91cC1JZCBBVlAgYWJzZW50IGlu ZGljYXRlcyBkZWxldGlvbiBvZiBhIHNlc3Npb24gZnJvbSBhbGwgZ3JvdXBzLCB3aGF0IGlmIHRo ZSBtZXNzYWdlIGFsc28gY29udGFpbnMgb3RoZXIgU2Vzc2lvbi1Hcm91cC1JbmZvIEFWUHMgdGhh dCBhc3NpZ24gZ3JvdXBzPyBJcyB0aGF0IHRoZSBzYW1lIHRoaW5nIGFzIG1vdmluZyBhIHNlc3Np b24gYmV0d2VlbiBncm91cHM/DQoNCknigJlkIGFsc28gbGlrZSB0byBzZWUgc29tZSBlYXJsaWVy IHRleHQgZGVzY3JpYmluZyB0aGUgbWVhbmluZyBvZiBTZXNzaW9uLUlkIEFWUHMgaW4gZ3JvdXAg bWFuYWdlbWVudCBhbmQgZ3JvdXAgb3BlcmF0aW9ucy4gVGhlcmXigJlzIGEgbWVudGlvbiBvZiB0 aGF0IGluIHRoZSDigJxmb3JtYXTigJ0gc2VjdGlvbiwgYnV0IHRoYXQgc2VlbXMgYW4gb2RkIHBs YWNlIHRvIHB1dCBpdC4NCg0KDQrCpzQuMi4xOg0KDQotIEdlbmVyYWw6IEFtIEkgY29ycmVjdCB0 byBhc3N1bWUgdGhhdCBmYWlsdXJlIG9mIGEgRGlhbWV0ZXIgY29tbWFuZCBtZWFucyBubyBncm91 cHMgYXJlIGFzc2lnbmVkPyBJZiBzbywgcGxlYXNlIHN0YXRlIHRoYXQgZXhwbGljaXRseS4NCg0K LSBmaXJzdCBwYXJhZ3JhcGg6IFRoZSDigJxNVVNU4oCdIHNlZW1zIGxpa2UgYSBzdGF0ZW1lbnQg b2YgZmFjdC4gVGhhdCBpcywgdGhlcmXigJlzIG5vIGltcGxlbWVudGF0aW9uIGNob2ljZSB0byBt YWtlIGhlcmUuDQoNCi0gIklmIHRoZSBEaWFtZXRlciBzZXJ2ZXIgYWNjZXB0cyB0aGUgY2xpZW50 4oCZcyByZXF1ZXN0IGZvciBhIGdyb3VwIGFzc2lnbm1lbnQsIGJ1dCB0aGUgYXNzaWdubWVudCBv ZiB0aGUgc2Vzc2lvbiB0byBvbmUgb3Igc29tZSBvZiB0aGUgbXVsdGlwbGUgaWRlbnRpZmllZCBz ZXNzaW9uIGdyb3VwcyBmYWlscyzigJ0NCg0KVGhpcyBzZWVtcyBzZWxmIGNvbnRyYWRpY3Rvcnk7 IGlmIHRoZSBhc3NpZ25tZW50IGZhaWxzIHRoZW4gaG93IGNhbiB0aGUgc2VydmVyIGhhdmUgYWNj ZXB0ZWQgaXQ/IElzIHRoZXJlIGEgcHJhY3RpY2FsIGRpZmZlcmVuY2UgYmV0d2VlbiBhc3NpZ25t ZW50IGZhaWx1cmUgYW5kIGFzc2lnbm1lbnQgcmVqZWN0aW9uPw0KDQotICJJZiB0aGUgRGlhbWV0 ZXIgc2VydmVyIHJlY2VpdmVzIGEgY29tbWFuZCByZXF1ZXN0IGZyb20gYSBEaWFtZXRlciBjbGll bnQgYW5kIHRoZSBjb21tYW5kIGNvbXByaXNlcyBvbmUgb3IgbXVsdGlwbGUgU2Vzc2lvbi1Hcm91 cC1JbmZvIEFWUHMgYW5kIG5vbmUgb2YgdGhlbSBpbmNsdWRlcyBhIFNlc3Npb24tR3JvdXAtSWQg QVZQLCB0aGUgc2VydmVyIE1BWSBkZWNpZGUgdG8gYXNzaWduIHRoZSBzZXNzaW9uIHRvIG9uZSBv ciBtdWx0aXBsZSBzZXNzaW9uIGdyb3Vwcy7igJ0NCg0KSXMgdGhlcmUgYW4gZXhwZWN0YXRpb24g dGhhdCB0aGUgc2VydmVyIGFzc2lnbnMgdGhlIHNlc3Npb24gdG8gdGhlIHNhbWUgbnVtYmVyIG9m IGdyb3VwcyBhcyB0aGUgdGhlIG51bWJlciBvZiBTZXNzaW9uLUdyb3VwLUlkIEFWUHMgaW5jbHVk ZWQgYnkgdGhlIGNsaWVudD8gSWYgbm90LCB3aHkgd291bGQgdGhlIGNsaWVudCBldmVyIGluY2x1 ZGUgbW9yZSB0aGFuIG9uZS4NCg0KSXMgdGhlIGNsaWVudCBwcm9oaWJpdGVkIGZyb20gc2VuZGlu ZyBtdWx0aXBsZSBBVlBzLCBzb21lIG9mIHdoaWNoIGNvbnRhaW4gc2Vzc2lvbiBJRHMgYW5kIHNv bWUgb2Ygd2hpY2ggZG8gbm90Pw0KDQotICJ0aGUgRGlhbWV0ZXIgY2xpZW50IFNIT1VMRCBOT1Qg cmV0cnkgdG8gcmVxdWVzdCBncm91cCBhc3NpZ25tZW50IGZvciB0aGlzIHNlc3Npb24sIGJ1dCBN QVkgdHJ5IHRvIHJlcXVlc3QgZ3JvdXAgYXNzaWdubWVudCBmb3Igb3RoZXIgbmV3IHNlc3Npb25z LuKAnQ0KDQpXaHkgaXMgdGhlIFNIT1VMRCBOT1Qgbm90IGEgTVVTVCBOT1Q/DQoNCsKnNC4yLjM6 DQotICJXaGVuIGEgRGlhbWV0ZXIgc2VydmVyIGVuZm9yY2VzIGFuIHVwZGF0ZSB0byB0aGUgYXNz aWduZWQgZ3JvdXBzIG1pZHNlc3Npb24sIGl0IHNlbmRzIGEgUmUtQXV0aG9yaXphdGlvbiBSZXF1 ZXN0IChSQVIpIG1lc3NhZ2UgdG8gdGhlIGNsaWVudCBpZGVudGlmeWluZyB0aGUgc2Vzc2lvbuKA puKAnQ0KDQpTaG91bGQgdGhhdCBzYXkg4oCcb3Igc2VydmljZS1zcGVjaWZpYyByZXF1ZXN04oCd PyBPciBpcyB0aGlzIG9wZXJhdGlvbiBsaW1pdGVkIHRvIGFwcGxpY2F0aW9ucyB0aGF0IHVzZSBS QVI/DQoNCsKnNC40LjE6DQoNCi0gIklmIHRoZSBwcm9jZXNzIG9mIHRoZSByZXF1ZXN0DQppcyBk ZWxheS1zZW5zaXRpdmUsIHRoZSBzZW5kZXIgU0hPVUxEIE5PVCBzZXQgdGhlIEdyb3VwLVJlc3Bv bnNlLSBBY3Rpb24gQVZQIHRvIEFMTF9HUk9VUFMgKDEpIG9yIFBFUl9HUk9VUCAoMiku4oCdDQoN CldoeSBub3QgTVVTVCBOT1Q/DQoNCi0gIklmIHRoZSBhbnN3ZXIgY2FuIGJlDQpzZW50IGJlZm9y ZSB0aGUgY29tcGxldGUgcHJvY2VzcyBvZiB0aGUgcmVxdWVzdCBmb3IgYWxsIHRoZSBzZXNzaW9u cyBvciBpZiB0aGUgcmVxdWVzdCB0aW1lb3V0IHRpbWVyIGlzIGhpZ2ggZW5vdWdoLCB0aGUgc2Vu ZGVyIE1BWSBzZXQgdGhlIEdyb3VwLVJlc3BvbnNlLUFjdGlvbiBBVlAgdG8gQUxMX0dST1VQUyAo MSkgb3IgUEVSX0dST1VQICgyKS7igJ0NCg0KQ2FuIHlvdSBvZmZlciBndWlkYW5jZSBvbiBob3cg dG8gZGVjaWRlIGlmIGEgdGltZW91dCB0aW1lciBpcyBoaWdoIGVub3VnaD8NCg0Kwqc1Og0KDQot IEl04oCZcyB3b3J0aCBtZW50aW9uaW5nIHRoYXQgYSBzdGF0ZWZ1bCBwcm94eSBtdXN0IGFkdmVy dGlzZSBzdXBwb3J0Lg0KDQotICJTZXNzaW9uIGdyb3VwIHJlbGF0ZWQgQVZQcyBiZWluZyBkZWZp bmVkIGFzIG9wdGlvbmFsIEFWUCBTSE9VTEQgYmUgaWdub3JlZCBieSBzdGF0ZWxlc3MgUHJveHkg QWdlbnRzIGFuZCBTSE9VTEQgTk9UIGJlIHJlbW92ZWQgZnJvbSB0aGUgRGlhbWV0ZXIgY29tbWFu ZHMu4oCdDQoNClRoaXMgc2VlbXMgdG8gcHV0IG5vcm1hdGl2ZSByZXF1aXJlbWVudHMgb24gbm9k ZXMgdGhhdCBkbyBub3QgaW1wbGVtZW50IHRoaXMgc3BlYy4gT3IgaXMgaXQgcmVhbGx5IGEgc3Rh dGVtZW50IG9mIGZhY3Q/DQoNCsKnNy4zOiBDYW4geW91IG9mZmVyIGd1aWRhbmNlIG9uIGhvdyB0 byBlbnN1cmUgc3VmZmljaWVudCB1bmlxdWVuZXNzPyDigJxFdGVybmFs4oCdIHNlZW1zIGxpa2Ug YSBwcmV0dHkgaGlnaCBiYXI7IGlzIHRoYXQgcmVhbGx5IHRoZSBpbnRlbnRpb24/DQoNCsKnMTA6 IEl0IGRvZXNu4oCZdCBzZWVtIGxpa2VseSB0aGF0IHRoZSBlMmUgcHJvdGVjdGlvbiB3b3JrIGZv ciBEaWFtZXRlciB3aWxsIGV2ZXIgY29tcGxldGUsIG9yIGF0IGxlYXN0IG5vdCBpbiB0aGUgbmVh ciBmdXR1cmUuIEkgc3VnZ2VzdCB0b25pbmcgZG93biB0aGUgaG9wZWZ1bCBsYW5ndWFnZSB0aGF0 IHRhbGtzIGFib3V0IGl0Lg0KDQoNCioqKiBFZGl0b3JpYWwgQ29tbWVudHMgYW5kIE5pdHMgKioN Cg0KLSBHZW5lcmFsOiBUaGUgZHJhZnQgbmVlZHMgYXQgbGVhc3QgYW5vdGhlciBwcm9vZnJlYWRp bmcgYW5kIGVkaXRpbmcgcGFzcyB0byBpbXByb3ZlIHJlYWRhYmlsaXR5IGFuZCBjbGFyaXR5LiBJ biBwYXJ0aWN1bGFyLCBpdCBuZWVkcyB0byBiZSBwcm9vZnJlYWQgZm9yIHRoZSBmb2xsb3dpbmc6 DQotIHBsdXJhbCBhZ3JlZW1lbnQNCi0gQ29tbWEgdXNhZ2UgKHRoZXJlIGFyZSBtYW55IHBsYWNl ZCBpbmNvcnJlY3RseSwgYW5kIG1hbnkgbWlzc2luZyB3aGVyZSBuZWVkZWQpDQotIFByb3BlciB1 c2Ugb2Yg4oCcd2hpY2jigJ0gdnMg4oCcdGhhdOKAnSAoYW5kIHRoZSBhc3NvY2lhdGVkIGNvbW1h IHVzZS4pDQotIENvbnZvbHV0ZWQgc2VudGVuY2Ugc3RydWN0dXJlDQoNCsKnMjogUGxlYXNlIHVz ZSB0aGUgbmV3IGJvaWxlcnBsYXRlIGZyb20gUkZDIDgxNzQuDQppDQrCpzMuMSwNCi0gIGZpcnN0 IHBhcmFncmFwaDog4oCcZS5nLuKAnSByZXF1aXJlcyBhIGNvbW1hIGFmdGVyd2FyZHM6IOKAnGUu Zy4s4oCdICAoVGhlcmUgYXJlIHNldmVyYWwgaW5zdGFuY2VzIG9mIHRoaXMgdGhyb3VnaG91dCB0 aGUgZHJhZnQuKQ0KDQotICJJbiBjYXNlIG9mIG1vYmlsZSB1c2VycywgdGhlIHVzZXLigJlzIHNl c3Npb24gbWF5IGdldCB0cmFuc2ZlcnJlZCB0byBhIG5ldyBEaWFtZXRlciBjbGllbnQgZHVyaW5n IGhhbmRvdmVyIGFuZCBhc3NpZ25lZCB0byBhIGRpZmZlcmVudCBncm91cCwgd2hpY2ggaXMgbWFp bnRhaW5lZCBhdCB0aGUgbmV3IERpYW1ldGVyIGNsaWVudCwgbWlkLXNlc3Npb24u4oCdDQoNClRo aXMgaXMgaGFyZCB0byBwYXJzZS4gSSBzdWdnZXN0IG1vdmluZyDigJxtaWQtc2Vzc2lvbuKAnSB0 byBlYXJsaWVyIGluIHRoZSBzZW50ZW5jZS4gRm9yIGV4YW1wbGUsIOKAnOKApiBzZXNzaW9uIG1h eSBnZXQgdHJhbnNmZXJyZWQgbWlkLXNlc3Npb24gdG8gYSBuZXcgRGlhbWV0ZXIgY2xpZW504oCm 4oCdDQoNCsKnMy4yOiBJIGdhdGhlciB0aGlzIHNlY3Rpb24gaXMgYW4gZXhhbXBsZS4gSWYgc2F5 LCBwbGVhc2Ugc3RhdGUgdGhhdCBleHBsaWNpdGx5Lg0KDQrCpzMuMzoNCi0gVGhpcyBzZWN0aW9u IHVzZXMgY29uZnVzaW5nIGxhbmd1YWdlIHRvIGRlc2NyaWJlIHdoaWNoIG5vZGVzIGNhbiBkbyB3 aGF0LiBJbiBwYXJ0aWN1bGFyLCBpdCBvZnRlbiBzYXlzIOKAnGFueeKAnSBub2RlLCB3aGVyZSBJ IHRoaW5rIGl0IG1lYW5zIOKAnGVpdGhlciB0aGUgY2xpZW50IG9yIHRoZSBzZXJ2ZXLigJ0uIEkg YXNzdW1lIG5vZGVzIHRoYXQgYXJlIG5vdCBhIHBhcnR5IHRvIGEgc2Vzc2lvbi1ncm91cCBjYW7i gJl0IG1vZGlmeSBpdCwgY29ycmVjdD8gTGlrZXdpc2UgaXQgc2F5cyDigJxlYWNo4oCdIG5vZGUg d2hlbiBJIHRoaW5rIGl0IG1lYW5zIOKAnGVpdGhlciBub2Rl4oCdLg0KDQotICJQcmVyZXF1aXNp dGUgZm9yIGRlbGV0aW9uDQpvZiBhIHNlc3Npb24gZ3JvdXAgaXMgdGhhdCB0aGUgRGlhbWV0ZXIg bm9kZSBjcmVhdGVkIHRoZSBzZXNzaW9uIGJlZm9yZWhhbmQsIGhlbmNlIHRoZSBub2RlIGJlY2Ft ZSB0aGUgZ3JvdXAgb3duZXIu4oCdDQoNClRoaXMgc2VlbXMgbGlrZSBhIGNvbXBsaWNhdGVkIHdh eSB0byBleHBsYWluIGEgc2ltcGxlIGNvbmNlcHQuIEkgc3VnZ2VzdCBzb21ldGhpbmcgdG8gdGhl IGVmZmVjdCBvZiDigJxBIHNlc3Npb24gZ3JvdXAgbWF5IG9ubHkgYmUgZGVsZXRlZCBieSB0aGUg RGlhbWV0ZXIgbm9kZSB0aGF0IGNyZWF0ZWQgaXQu4oCdDQoNCi0gIlRoZSBlbmZvcmNlbWVudCBv ZiBtb3JlIGNvbnN0cmFpbmVkIHBlcm1pc3Npb25zIGlzIGxlZnQgdG8gdGhlIHNwZWNpZmljYXRp b24gb2YgYSBwYXJ0aWN1bGFyIGdyb3VwIHNpZ25hbGluZyBlbmFibGVkIERpYW1ldGVyIGFwcGxp Y2F0aW9uIGFuZCBjb21wbGlhbnQgaW1wbGVtZW50YXRpb25zIG9mIHN1Y2ggYXBwbGljYXRpb24g TVVTVCBlbmZvcmNlIHRoZSBhc3NvY2lhdGVkIHBlcm1pc3Npb24gbW9kZWwu4oCdDQoNClRoaXMg aXMgb3Zlcmx5IGNvbXBsaWNhdGVkIGxhbmd1YWdlLiBJIHN1Z2dlc3Qgc29tZXRoaW5nIHRvIHRo ZSBlZmZlY3Qgb2YgIiJEaWFtZXRlciBhcHBsaWNhdGlvbiB3aXRoIGV4cGxpY2l0IHN1cHBvcnQg Zm9yIHNlc3Npb24gZ3JvdXBzIG1heSBkZWZpbmUgYSBtb3JlIGNvbnN0cmFpbmVkIHBlcm1pc3Np b24gbW9kZWwu4oCdIEFsc28sIHRoZSBNVVNUIGlzIG5vdCByZWFsbHkgYXBwcm9wcmlhdGU7IGl0 4oCZcyB1cCB0byB0aGUgZGVmaW5pdGlvbnMgb2YgdGhvc2UgYXBwbGljYXRpb25zIHRvIHNldCBu b3JtYXRpdmUgcmVxdWlyZW1lbnRzIG9uIGltcGxlbWVudGF0aW9ucywgbm90IF90aGlzXyBkcmFm dC4NCg0KLSAic3BlY2lmaWNhdGlvbi4gRm9yIGV4YW1wbGUsIGEgbW9yZSBjb25zdHJhaW5lZCBt b2RlbCBjb3VsZCByZXF1aXJlIHRoYXQgYSBjbGllbnQgTVVTVCBOT1QgcmVtb3ZlIGEgc2Vzc2lv biBmcm9tIGEgZ3JvdXAgd2hpY2ggaXMgb3duZWQgYnkgdGhlIHNlcnZlci7igJ0NCg0KUGxlYXNl IGRvIG5vdCB1c2Ugbm9ybWF0aXZlIGtleXdvcmRzIGluIGFuIGV4YW1wbGU7IGV4YW1wbGVzIGFy ZSBieSBkZWZpbml0aW9uIG5vbi1ub3JtYXRpdmUuDQoNCi0gRGVmYXVsdCBwZXJtaXNzaW9ucyB0 YWJsZTogSSBhbSBjb25mdXNlZCBieSB0aGUg4oCcY2xpZW504oCdIGFuZCDigJxzZXJ2ZXLigJ0g Y29sdW1ucy4gSWYgSSB1bmRlcnN0YW5kIHRoaXMgc2VjdGlvbiBjb3JyZWN0bHksIHRoZSByb2xl IG9mIOKAnGNsaWVudOKAnSBhbmQg4oCcc2VydmVy4oCdIGlzIG5vdCByZWxldmFudC4gKEl0IGlz IHRlbGxpbmcgdGhhdCBlYWNoIHJvdyBoYXMgdGhlIHNhbWUgdmFsdWUgaW4gYm90aCBjb2x1bW5z LikgUGxlYXNlIGNvbnNpZGVyIHN0YXRpbmcgdGhpcyBpbiB0ZXJtcyBvZiBncm91cCDigJxvd25l cuKAnSBhbmQg4oCcbm9uLW93bmVy4oCdLg0KDQotIEVkaXRvcuKAmXMgbm90ZTogSWYgdGhpcyBk cmFmdCBkb2VzIG5vdCBjb25zaWRlciBvdmVycnVsaW5nIGEgbm9kZeKAmXMgYXNzaWdubWVudCwg d2h5IHRhbGsgYWJvdXQgaXQgYXQgYWxsPyAgKEFsdGhvdWdoIGl0IHNlZW1zIGxpa2UgaXQgX2Rv ZXNfIHN1cHBvcnQgdGhhdCwgaW4gdGhlIHNlbnNlIHRoYXQgYSBzZXJ2ZXIgY2FuIHJlamVjdCBv ciBjaGFuZ2UgYXNzaWdubWVudHMgcHJvcG9zZWQgYnkgYSBjbGllbnQuKQ0KDQrCpzQuMTogUGxl YXNlIGF2b2lkIG5vcm1hdGl2ZSBsYW5ndWFnZSBpbiB0aGUgZm9ybSBvZiDigJxTSE9VTETigKZv bmx54oCm4oCdLiBUaGF0IGNhbiBiZSBhbWJpZ3VvdXMuIEl04oCZcyBiZXR0ZXIgdG8gc2F5IOKA nFNIT1VMRCBOT1Qg4oCmIHVubGVzcy4gRm9yIGV4YW1wbGUsIOKAnFNIT1VMRCBOT1QgcGVyZm9y bSBncm91cCBvcGVyYXRpb25zIHdpdGggYSBub2RlIHVubGVzcyB0aGUgbm9kZSBoYXMgYWR2ZXJ0 aXNlZCBzdXBwb3J04oCdLg0KDQrCpzQuMS4xOg0KDQotIEl0IHNlZW1zIHRvIG1lIHRoYXQgwqc0 LjEuMSBhbmQgwqc0LjEuMiBoYXZlIOKAnGV4cGxpY2l04oCdIGFuZCDigJxpbXBsaWNpdOKAnSBy ZXZlcnNlZCwgaW4gdGhlIHNlbnNlIHRoYXQsIGlmIGEgRGlhbWV0ZXIgYXBwbGljYXRpb24gc3Vw cG9ydHMgZ3JvdXBzLCB0aGVuIHRoZSBhbm5vdW5jZW1lbnQgb2YgZ3JvdXAgc3VwcG9ydCBpcyDi gJxpbXBsaWVk4oCdIGJ5IHRoZSBhbm5vdW5jZW1lbnQgb2Ygc3VwcG9ydCBmb3IgdGhlIGFwcGxp Y2F0aW9uLiBPVE9ILCB0aGUgdXNlIG9mIFNlc3Npb24tR3JvdXAtQ2FwYWJpbGl0eS1WZWN0b3Ig aXMgYW4g4oCcZXhwbGljaXTigJ0gYW5ub3VuY2VtZW50IG9mIGdyb3VwIHN1cHBvcnQuDQoNCi0g Ik5ldyBEaWFtZXRlciBhcHBsaWNhdGlvbnMgbWF5IGNvbnNpZGVyIHN1cHBvcnQg4oCcDQoNCnMv Y29uc2lkZXIvc3BlY2lmeQ0KDQotICJTdWNoIGFwcGxpY2F0aW9ucyBwcm92aWRlIGludHJpbnNp YyBkaXNjb3ZlcnkgZm9yIHRoZSBzdXBwb3J0IG9mIGdyb3VwIGNvbW1hbmRzIGFuZCBhbm5vdW5j ZSB0aGlzIGNhcGFiaWxpdHkgdGhyb3VnaCB0aGUgYXNzaWduZWQgYXBwbGljYXRpb24gSUQu4oCd DQoNClRoaXMgaXMgY29uZnVzaW5nLiBJIHRoaW5rIHlvdSBtZWFuIHN1cHBvcnQgZm9yIGdyb3Vw cyBpcyBpbXBsaWVkIGJ5IHRoZSBhbm5vdW5jZW1lbnQgb2Ygc3VwcG9ydCBmb3IgdGhlIGFwcGxp Y2F0aW9uIHRoYXQgZXhwbGljaXRseSBzdXBwb3J0cyBpdC5CdXQgaXQgY2FuIGJlIHJlYWQgdG8g bWVhbiBhIHNlcGFyYXRlIGV4cGxpY2l0IGFubm91bmNlbWVudCBvZiBncm91cCBzdXBwb3J0Lg0K DQrCpzQuMjoNCi0gIkl0IGlzIGxlZnQgdG8gdGhlIGFwcGxpY2F0aW9uIHRvDQpkZXRlcm1pbmUg dGhlIHBvbGljeSBvZiBzZXNzaW9uIGdyb3VwaW5nLuKAnQ0KRG9lcyDigJxhcHBsaWNhdGlvbuKA nSBtZWFuIERpYW1ldGVyIGFwcGxpY2F0aW9uLCBvciBqdXN0IOKAnGltcGxlbWVudGF0aW9u4oCd PyBBbHNvLCB0aGlzIGlzIHZhZ3VlOyBJIHRoaW5rIHRoaXMgc3RpbGwgdGFsa3MgYWJvdXQgbGlt aXRzIHRvIHRoZSBudW1iZXIgb2YgZ3JvdXBzIGEgIHNlc3Npb24gYmVsb25ncyB0bywgd2hpY2gg aXMgbXVjaCBtb3JlIHByZWNpc2UgdGhhbiDigJx0aGUgcG9saWN5IG9mIHNlc3Npb24gZ3JvdXBp bmfigJ0uDQoNCi0gVGhlIHNlY29uZCBwYXJhZ3JhcGggc2VlbXMgcmVkdW5kYW50IHdpdGggwqcz LjMuDQoNClRoZSBwaHJhc2Ug4oCcc2luZ2xlIG9yIG11bHRpcGxl4oCdIHdvdWxkIGJlIGVhc2ll ciB0byByZWFkIGFzIOKAnG9uZSBvciBtb3Jl4oCdLiAoVGhpcyBwYXR0ZXJuIHJlcGVhdHMgdGhy b3VnaG91dCB0aGUgZHJhZnQsIGFsb25nIHdpdGggc29tZSBpbnN0YW5jZXMgb2Yg4oCcb25lIG9y IG11bHRpcGxl4oCdKQ0KDQotIOKAnEEgbGlzdCBvZiBhbGwga25vd24gc2Vzc2lvbiBncm91cHMg c2hvdWxkIGJlIGxvY2FsbHkgbWFpbnRhaW5lZCBvbiBlYWNoIG5vZGUsIGVhY2ggZ3JvdXAgcG9p bnRpbmcgdG8gaW5kaXZpZHVhbCBzZXNzaW9ucyBiZWluZyBhc3NpZ25lZCB0byB0aGUgZ3JvdXAu Ig0KDQpzL3Nob3VsZCBiZS9pcw0KDQrCpzQuMi4xOg0KDQotIOKAnOKApiB0aGUgc2VydmVyIE1V U1QgYXNzaWduIHRoZSBuZXcgc2Vzc2lvbiB0byBlYWNoIG9mIHRoZSBvbmUgb3IgbXVsdGlwbGUg aWRlbnRpZmllZCBzZXNzaW9uIGdyb3VwcyB3aGVuIHByZXNlbnQgaW4g4oCm4oCdDQoNCi0gIklm IHRoZSBEaWFtZXRlciBzZXJ2ZXIgcmVjZWl2ZXMgYSBjb21tYW5kIHJlcXVlc3QgZnJvbSBhIERp YW1ldGVyIGNsaWVudCBhbmQgdGhlIGNvbW1hbmQgY29tcHJpc2VzIGF0IGxlYXN0IG9uZSBTZXNz aW9uLUdyb3VwLUluZm8gQVZQ4oCdDQoNCnMvY29tcHJpc2VzL2luY2x1ZGVzICAo4oCcY29tcHJp c2Vz4oCdIG1lYW5zIOKAnG1hZGUgdXAgb2bigJ0sIHdoaWNoIHdvdWxkIHN1Z2dlc3QgdGhhdCB0 aGUgcmVxdWVzdCBjb250YWlucyBvbmx5IFNlc3Npb24tR3JvdXAtSW5mbyBBVlBzKS4gIChUaGlz IG9jY3VycyBzZXZlcmFsIHRpbWVzIHRocm91Z2hvdXQgdGhlIGRyYWZ0LikNCg0KV2hhdCBkb2Vz IOKAnHdoZW7igJ0gbWVhbiBpbiBjb250ZXh0PyBXb3VsZCDigJwuLi5zZXNzaW9uIGdyb3VwcyBw cmVzZW50IGlu4oCm4oCdIG1lYW4gdGhlIHNhbWUgdGhpbmc/DQoNCi0gIkluIGNhc2Ugb25lIG9y IG11bHRpcGxlIGlkZW50aWZpZWQgc2Vzc2lvbiBncm91cHMgYXJlIG5vdCBhbHJlYWR5IHN0b3Jl ZCBieSB0aGUgc2VydmVy4oCdDQoNCuKAnEluIGNhc2XigJ0gdXN1YWxseSByZWZlcnMgdG8gcGxh bm5pbmcgZm9yIGEgY29udGluZ2VuY3kgKEZvciBleGFtcGxlLCDigJxJIGhhdmUgYSBmaXJlIGV4 dGluZ3Vpc2hlciBpbiBjYXNlIG9mIGZpcmXigJ0pLiBJIHN1Z2dlc3Qg4oCcSW4gdGhlIGNhc2Ug d2hlcmXigKbigJ0gb3IgZXZlbiBiZXR0ZXIsIOKAnElm4oCm4oCdICAoVmFyaWF0aW9ucyBvZiB0 aGlzIHBhdHRlcm4gb2NjdXIgc2V2ZXJhbCB0aW1lcy4pDQoNCi0gInRoZSBzZXJ2ZXIgTVVTVCBz dG9yZSB0aGUgbmV3DQppZGVudGlmaWVkIGdyb3VwKHMp4oCdDQpzL25ldy9uZXdseQ0KDQotICJU aGUgc2VydmVyIHNlbmRzIHRoZSByZXNwb25zZSB0byB0aGUgY2xpZW50IGFuZCBNQVkgaW5jbHVk ZSBhcyBpbmZvcm1hdGlvbiB0byB0aGUgY2xpZW50IG9ubHkgdGhvc2UgU2Vzc2lvbi1Hcm91cC0g SW5mbyBBVlBzIGZvciB3aGljaCB0aGUgZ3JvdXAgYXNzaWdubWVudCBmYWlsZWQu4oCdDQoNCkhh cmQgdG8gcGFyc2UuDQoNCi0gInNlc3Npb24uIFdoZW4gdGhlIERpYW1ldGVyIGNsaWVudCBpcw0K Y29uZmlkZW50IHRoYXQgdGhlIERpYW1ldGVyIHNlcnZlciBzdXBwb3J0cyBzZXNzaW9uIGdyb3Vw aW5n4oCm4oCdDQoNClNpbmNlIHRoaXMgc2hvdWxkIGFsd2F5cyBiZSB0cnVlIGJlZm9yZSB0aGUg Y2xpZW50IHNlbmRzIF9hbnlfIGdyb3VwIG9wZXJhdGlvbiwgd2h5IHJlc3RhdGUgaXQgaGVyZT8N Cg0Kwqc0LjQuMToNCg0KLSAiRWl0aGVyIERpYW1ldGVyIG5vZGUgKGNsaWVudCBvciBzZXJ2ZXIp IGNhbiByZXF1ZXN0IHRoZSByZWNpcGllbnQgb2YgYSByZXF1ZXN0IHRvIHByb2Nlc3MgYW4gYXNz b2NpYXRlZCBjb21tYW5kIGZvciBhbGwgc2Vzc2lvbnMgYmVpbmcgYXNzaWduZWQgdG8gb25lIG9y IG11bHRpcGxlIGdyb3VwcyBieSBpZGVudGlmeWluZyB0aGVzZSBncm91cHMgaW4gdGhlIHJlcXVl c3Qu4oCdDQoNCnMvc2Vzc2lvbnMgYmVpbmcgYXNzaWduZWQvc2Vzc2lvbnMgYXNzaWduZWQNCg0K LSBQbGVhc2UgZXhwYW5kIOKAnENDRuKAnSBvbiBmaXJzdCBtZW50aW9uLg0KDQotIHNlbnRlbmNl IHN0YXJ0aW5nIHdpdGggIldoZW4gYSBzZXJ2ZXIgc2VuZHMsIGFzIGV4YW1wbGUsIGEgUmUtQXV0 aG9yaXphdGlvbiBSZXF1ZXN0DQooUkFSKSBvciBhIHNlcnZpY2Utc3BlY2lmaWMgc2VydmVyLWlu aXRpYXRlZCByZXF1ZXN04oCm4oCdDQoNClRoZSBzZW50ZW5jZSBpcyBoYXJkIHRvIHBhcnNlLg0K DQotICJJZiB0aGUgc2VuZGVyIHNlbmRzIGEgcmVxdWVzdCBpbmNsdWRpbmcgdGhlIEdyb3VwLVJl c3BvbnNlLUFjdGlvbiBBVlAgc2V0IHRvIEFMTF9HUk9VUFMgKDEpIG9yIFBFUl9HUk9VUCAoMiks IGl0IE1VU1QgZXhwZWN0IHNvbWUgZGVsYXnigKbigJ0NCg0K4oCcZXhwZWN04oCdIGlzIHZhZ3Vl IGZvciB1c2UgaW4gYSBNVVNUIHJlcXVpcmVtZW50LiBQbGVhc2Ugc3RhdGUgdGhpcyBpbiB0ZXJt cyBvZiBjb25jcmV0ZSBhY3Rpb25zIG9yIHN0YXRlIGl0IGRlc2NyaXB0aXZlbHkuDQoNCsKnQS4x LCBmaXJzdCBwYXJhZ3JhcGg6IFBsZWFzZSBkb27igJl0IHVzZSBub3JtYXRpdmUga2V5d29yZHMg dG8gZGVzY3JpYmUgcmVxdWlyZW1lbnRzIGRlZmluZWQgaW4gb3RoZXIgZG9jdW1lbnRzLiBEb2lu ZyBzbyBpbnRyb2R1Y2VzIGEgaGlnaCBjaGFuY2Ugb2YgZXJyb3IgaWYgZWl0aGVyIGRvY3VtZW50 IGlzIHVwZGF0ZWQgaW4gdGhlIGZ1dHVyZS4NCg0KDQoNCg0KDQoNCg0KDQo=