Diameter Overload Rate Control
RFC 8582
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2019-08-15
|
11 | (System) | Received changes through RFC Editor sync (created alias RFC 8582, changed abstract to 'This specification documents an extension to the Diameter Overload Indication Conveyance … Received changes through RFC Editor sync (created alias RFC 8582, changed abstract to 'This specification documents an extension to the Diameter Overload Indication Conveyance (DOIC) base solution, which is defined in RFC 7683. 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.', changed standardization level to Proposed Standard, changed state to RFC, added RFC published event at 2019-08-15, changed IESG state to RFC Published) |
|
2019-08-15
|
11 | (System) | RFC published |
|
2019-08-07
|
11 | (System) | RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc8582">AUTH48-DONE</a> from AUTH48 |
|
2019-05-01
|
11 | Ignas Bagdonas | Shepherding AD changed to Ignas Bagdonas |
|
2019-04-16
|
11 | (System) | RFC Editor state changed to <a href="http://www.rfc-editor.org/auth48/rfc8582">AUTH48</a> from RFC-EDITOR |
|
2019-03-20
|
11 | (System) | RFC Editor state changed to RFC-EDITOR from REF |
|
2019-03-11
|
11 | (System) | RFC Editor state changed to REF from EDIT |
|
2019-03-04
|
11 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
|
2019-03-04
|
11 | (System) | IANA Action state changed to Waiting on RFC Editor from In Progress |
|
2019-03-04
|
11 | (System) | IANA Action state changed to In Progress from Waiting on Authors |
|
2019-02-27
|
11 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
|
2019-02-27
|
11 | (System) | IANA Action state changed to In Progress from Waiting on WGC |
|
2019-02-26
|
11 | (System) | IANA Action state changed to Waiting on WGC from In Progress |
|
2019-02-26
|
11 | (System) | IANA Action state changed to In Progress from Waiting on WGC |
|
2019-02-22
|
11 | (System) | IANA Action state changed to Waiting on WGC from In Progress |
|
2019-02-13
|
11 | (System) | RFC Editor state changed to EDIT |
|
2019-02-13
|
11 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
|
2019-02-13
|
11 | (System) | Announcement was received by RFC Editor |
|
2019-02-13
|
11 | (System) | IANA Action state changed to In Progress |
|
2019-02-13
|
11 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
|
2019-02-13
|
11 | Amy Vezza | IESG has approved the document |
|
2019-02-13
|
11 | Amy Vezza | Closed "Approve" ballot |
|
2019-02-12
|
11 | Ben Campbell | Ballot approval text was generated |
|
2019-02-12
|
11 | Ben Campbell | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
|
2019-02-11
|
11 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
|
2019-02-11
|
11 | Steve Donovan | New version available: draft-ietf-dime-doic-rate-control-11.txt |
|
2019-02-11
|
11 | (System) | New version approved |
|
2019-02-11
|
11 | (System) | Request for posting confirmation emailed to previous authors: Steve Donovan <srdonovan@usdonovans.com>, Eric Noel <ecnoel@research.att.com> |
|
2019-02-11
|
11 | Steve Donovan | Uploaded new revision |
|
2019-01-31
|
10 | Amanda Baber | IANA Review state changed to IANA OK - Actions Needed from IANA - Not OK |
|
2019-01-28
|
10 | Magnus Westerlund | Closed request for Last Call review by TSVART with state 'No Response' |
|
2019-01-24
|
10 | Jean Mahoney | Closed request for Last Call review by GENART with state 'No Response' |
|
2019-01-24
|
10 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from Waiting for AD Go-Ahead |
|
2019-01-24
|
10 | Ignas Bagdonas | [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas |
|
2019-01-24
|
10 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
|
2019-01-24
|
10 | Martin Vigoureux | [Ballot Position Update] New position, No Objection, has been recorded for Martin Vigoureux |
|
2019-01-23
|
10 | Eric Rescorla | [Ballot Position Update] New position, No Objection, has been recorded for Eric Rescorla |
|
2019-01-23
|
10 | Terry Manderson | [Ballot Position Update] New position, No Objection, has been recorded for Terry Manderson |
|
2019-01-23
|
10 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
|
2019-01-23
|
10 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
|
2019-01-23
|
10 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
|
2019-01-23
|
10 | Benjamin Kaduk | [Ballot 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 … [Ballot 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.) 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. 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)? 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. 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. 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. Section 7.3.1 Perhaps note explicitly that "//" denotes comments? 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. Section 8.3 Do you want to add this requirement as a "Note" on the IANA registry itself? 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. |
|
2019-01-23
|
10 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
|
2019-01-23
|
10 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
|
2019-01-22
|
10 | Adam Roach | [Ballot comment] Thanks to everyone who worked on this document. I have a handful of editorial comments on its contents that the editor may wish … [Ballot 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..." --------------------------------------------------------------------------- §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. --------------------------------------------------------------------------- §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.") --------------------------------------------------------------------------- §5.2: > OC-OLR AVP as an element of the abatement algorithm specific portion Nit: "...abatement-algorithm-specific portion..." --------------------------------------------------------------------------- §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. --------------------------------------------------------------------------- §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) --------------------------------------------------------------------------- §7. Rate Based Abatement Algorithm Nit: "Rate-Based..." --------------------------------------------------------------------------- §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. |
|
2019-01-22
|
10 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
|
2019-01-22
|
10 | Spencer Dawkins | [Ballot 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 … [Ballot 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? 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. 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. 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. |
|
2019-01-22
|
10 | Spencer Dawkins | Ballot comment text updated for Spencer Dawkins |
|
2019-01-22
|
10 | Spencer Dawkins | [Ballot 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 … [Ballot 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 sends information to all reacting nodes", based on this next sentence, but I'm guessing. Why wouldn't you do this? 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. 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. 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. |
|
2019-01-22
|
10 | Spencer Dawkins | [Ballot Position Update] New position, Yes, has been recorded for Spencer Dawkins |
|
2019-01-21
|
10 | Susan Hares | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Susan Hares. Sent review to list. |
|
2019-01-21
|
10 | Mirja Kühlewind | [Ballot comment] The security considerations of rfc7683 have an own section on non-complaint nodes (section 10.3). While this is discussed in rfc7683, I think … [Ballot comment] The security considerations of rfc7683 have an own section on non-complaint nodes (section 10.3). While this is discussed in rfc7683, I think it is especially important for this document to remind the reader that there may be non-compliant nodes that may send with a higher than indicated rate. I would recommend to add one more statement to the security considerations section of this doc and potentially point the reader explicitly at section 10.3 of rfc7683. Two comments on normative language: 1) Section 5.6: "Any algorithm implemented MUST result in the correct rate of traffic being sent to the reporting node." I would recommend to maybe change this to: "Any algorithm implemented MUST correctly limit the maximum rate of traffic being sent to the reporting node." Otherwise I would think this is hard to implement in practice. 2) Section 7.2: "... the reporting node MUST periodically evaluate its overload state..." Not sure if the normative language is really appropriate here as this does not impact interoperability, nor can be checked. If at all, I guess I would recommend a "SHOULD" instead. And two more editorial comments: 1) As section 7.3 only describes (in quite some detail) an example algorithm, I would rather have put this in an appendix. But I guess that's a matter of taste... 2) I don't think section 8.2. is needed. |
|
2019-01-21
|
10 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
|
2019-01-16
|
10 | Cindy Morgan | Placed on agenda for telechat - 2019-01-24 |
|
2019-01-16
|
10 | Ben Campbell | Ballot has been issued |
|
2019-01-16
|
10 | Ben Campbell | [Ballot Position Update] New position, Yes, has been recorded for Ben Campbell |
|
2019-01-16
|
10 | Ben Campbell | Created "Approve" ballot |
|
2019-01-16
|
10 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
|
2019-01-14
|
10 | Ben Campbell | Ballot writeup was changed |
|
2019-01-14
|
10 | Ben Campbell | Ballot approval text was generated |
|
2019-01-14
|
10 | (System) | IANA Review state changed to IANA - Not OK from IANA - Review Needed |
|
2019-01-14
|
10 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-dime-doic-rate-control-10. If any part of this review is inaccurate, please let … (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has completed its review of draft-ietf-dime-doic-rate-control-10. If any part of this review is inaccurate, please let us know. The IANA Functions Operator has a question about one of the actions requested in the IANA Considerations section of this document. The IANA Functions Operator understands that, upon approval of this document, there are three actions which we must complete. First, in the OC-Feature-Vector AVP Values (code 622) subregistry of the AVP Specific Values registry on the Authentication, Authorization, and Accounting (AAA) Parameters registry page located at: https://www.iana.org/assignments/aaa-parameters/ a single, new value is to be registered as follows: AVP Value: 0x0000000000000010 Attribute Name: OLR_RATE_ALGORITHM Reference: [ RFC-to-be ] Second, in the AVP Codes registry also on the Authentication, Authorization, and Accounting (AAA) Parameters registry page located at: https://www.iana.org/assignments/aaa-parameters/ a single, new value is to be registered as follows: AVP Code: [ TBD-at-Registration ] Attribute Name: OC-Maximum-Rate Reference: [ RFC-to-be ] As this document requests registrations in a Specification Required (see RFC 8126) registry, we will initiate the required Expert Review via a separate request. Expert review will need to be completed before your document can be approved for publication as an RFC. Third, section 6.3 provides AVP Flag Rules. IANA Question --> Is there a request for registration of this information. If so, where should that registration take place; in what registry? If not, could this information be place elsewhere in a revised draft for clarity to the reader? The IANA Functions Operator understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is meant only to confirm the list of actions that will be performed. Thank you, Sabrina Tanamal Senior IANA Services Specialist |
|
2019-01-10
|
10 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Chris Lonvick. |
|
2019-01-07
|
10 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Bob Briscoe |
|
2019-01-07
|
10 | Magnus Westerlund | Request for Last Call review by TSVART is assigned to Bob Briscoe |
|
2018-12-27
|
10 | Jean Mahoney | Request for Last Call review by GENART is assigned to Vijay Gurbani |
|
2018-12-27
|
10 | Jean Mahoney | Request for Last Call review by GENART is assigned to Vijay Gurbani |
|
2018-12-27
|
10 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Chris Lonvick |
|
2018-12-27
|
10 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Chris Lonvick |
|
2018-12-26
|
10 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Susan Hares |
|
2018-12-26
|
10 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Susan Hares |
|
2018-12-21
|
10 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
|
2018-12-21
|
10 | Cindy Morgan | The following Last Call announcement was sent out (ends 2019-01-16):<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: ben@nostrum.com, lionel.morand@orange.com, … The following Last Call announcement was sent out (ends 2019-01-16):<br><br>From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> CC: ben@nostrum.com, lionel.morand@orange.com, dime-chairs@ietf.org, dime@ietf.org, Lionel Morand <lionel.morand@orange.com>, draft-ietf-dime-doic-rate-control@ietf.org Reply-To: ietf@ietf.org Sender: <iesg-secretary@ietf.org> Subject: Last Call: <draft-ietf-dime-doic-rate-control-10.txt> (Diameter Overload Rate Control) to Proposed Standard The IESG has received a request from the Diameter Maintenance and Extensions WG (dime) to consider the following document: - 'Diameter Overload Rate Control' <draft-ietf-dime-doic-rate-control-10.txt> as Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2019-01-16. Exceptionally, comments may be sent to iesg@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract This specification documents an extension to 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 file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-dime-doic-rate-control/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-dime-doic-rate-control/ballot/ No IPR declarations have been submitted directly on this I-D. |
|
2018-12-21
|
10 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
|
2018-12-21
|
10 | Ben Campbell | Last call was requested |
|
2018-12-21
|
10 | Ben Campbell | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
|
2018-12-21
|
10 | Ben Campbell | Last call announcement was changed |
|
2018-12-21
|
10 | Ben Campbell | Last call announcement was generated |
|
2018-12-21
|
10 | Ben Campbell | Ballot writeup was generated |
|
2018-12-21
|
10 | Ben Campbell | Ballot approval text was generated |
|
2018-12-21
|
10 | Ben Campbell | This is my AD evaluation for draft-ietf-dime-doic-rate-control-10. I previously reviewed version 8, however since some time has passed I reviewed this version “from scratch”. In … This is my AD evaluation for draft-ietf-dime-doic-rate-control-10. I previously reviewed version 8, however since some time has passed I reviewed this version “from scratch”. In general the draft is in good shape. I think it’s ready for IETF Last Call, which I will request shortly. Please note the last call window will be extended due to the upcoming holidays. I have a few minor comments that can be resolved along with any last call feedback. ------------------------------------- §4, paragraphs 2 and 3: Am I correct to assume that, as new DOIC algorithms get added, nodes could support both of these and something else? If so, then in paragraph 2 I suggest s/ “ support both the loss and rate based abatement algorithms”/ "support at least the loss and rate based abatement algorithms” ... and in paragraph 3, I suggest adding something to the effect of “... and MAY indicate support for others.” (nit) §5.5, 2nd paragraph: "It is also possible for the reporting node to send overload reports with the rate algorithm indicated when the reporting node is not in an overloaded state.” I suggest s/ “indicated when” / “indicated even when” (nit) §5.6, first paragraph: The algorithm is detailed in 7.3. §7.3.1: "To apply abatement treatment to new Diameter requests at the rate specified in the OC-Maximum-Rate AVP value sent by the reporting node to its reacting nodes, the reacting node MAY use the proposed default algorithm for rate-based control or any other equivalent algorithm that forward messages in conformance with the upper bound of 1/T messages per second.” This is redundant to similar normative text in §5.6. I suggest keeping just one (probably this one since it’s more precise) and use descriptive language for the other. §9: Do the authors think that the rate algorithm might be more effective at DoS mitigation than the loss algorithm? If so, that might be worth a mention in the security considerations. |
|
2018-10-03
|
10 | Steve Donovan | New version available: draft-ietf-dime-doic-rate-control-10.txt |
|
2018-10-03
|
10 | (System) | New version approved |
|
2018-10-03
|
10 | (System) | Request for posting confirmation emailed to previous authors: Steve Donovan <srdonovan@usdonovans.com>, Eric Noel <ecnoel@research.att.com> |
|
2018-10-03
|
10 | Steve Donovan | Uploaded new revision |
|
2018-09-10
|
09 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
|
2018-09-10
|
09 | Steve Donovan | New version available: draft-ietf-dime-doic-rate-control-09.txt |
|
2018-09-10
|
09 | (System) | New version approved |
|
2018-09-10
|
09 | (System) | Request for posting confirmation emailed to previous authors: Steve Donovan <srdonovan@usdonovans.com>, Eric Noel <ecnoel@research.att.com> |
|
2018-09-10
|
09 | Steve Donovan | Uploaded new revision |
|
2018-05-15
|
08 | Ben Campbell | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
|
2018-05-15
|
08 | Ben Campbell | This is my AD Evaluation of draft-ietf-dime-doic-rate-control-08. Thank you for doing the work on this. I think the document is on the right track, but … This is my AD Evaluation of draft-ietf-dime-doic-rate-control-08. Thank you for doing the work on this. I think the document is on the right track, but needs a little work before it will be ready for IETF last call. ———————————————————— Substantive Comments: General: The document seems inconsistent about whether rate limits are only reported during overload conditions, or in advance of overload conditions. I’d like to see the need to allocate the rate limit across all potential sources of traffic given some more emphasis. (Maybe a sub-section of its own?) §1: - “ While this can effectively decrease the load handled by the server, it does not directly address cases where the rate of arrival of service requests increases quickly." I think it fails to address cases where the load changes rapidly in either direction, right? At least, the following text seems to say that. §3: Does the need for future report types to consider the rate algorithm have IANA implications? §5.1: The first paragraph indicates state should be kept for every reacting node to which it sends an OLR. But the 5th paragraph can be interpreted to say it sends an OLR to every reacting node with which it has negotiated use of the rate algorithm. (see general comment). §5.4: The first paragraph seems to suggest the reacting node keeps OCS for every server that has indicated support for the rate algorithm, not just nodes that have sent OLRs. Is that the intent? §5.6, first paragraph: The MAY seems week here. I know and agree that we don’t want to force a particular application. But don’t we need to say that if an implementation uses a different algorithm, it MUST have the same behavior as the algorithm in section 7? §7.2, third and 4th paragraphs: I don’t understand what this is trying to say. Please elaborate. -6th paragraph: “ may receive requests at a rate below its target maximum Diameter request rate while others above that target rate. But the resulting request rate presented to the overloaded reporting node will converge towards the target Diameter request rate.” Why do we expect traffic to converge to the rate limit? It seems like that won't happen if some reporting nodes are not sending at full capacity, unless work can be shifted from the high-rate sources to the slow-rate ones. §7.3.1: paragraph starting with “ In situations where reacting nodes are configured with some knowledge” that requires knowledge of other traffic sources, not just knowledge of the reporting node. The example code says to transmit a message if (Xp <= TAU). But the text said the limit was “T+TAU). §9: I think the security considerations need more thought. What are the security considerations specific to the rate algorithm? If there aren’t any, then please describe the rational behind that. But I suspect there are, for example, can this be used for a DoS? Can it be used to help _mitigate_ a DoS? Could one reacting node cause others to be traffic starved? Editorial Comments: General: IDNits returns several issues. Some of those may be errors on its part, but I’m pretty sure some of them are real. Please resolve these. Requirements: There are instances of lower case “must” and “should”. Please use the new boilerplate from RFC 8174. §1 - “protect the stability” seems awkward. Maybe “ensure the stability”? - Also s/ “subjected with” / “subjected to”. - Please cite the definitions for “reporting node” and “reacting node”. I know they are defined later, but these are somewhat non-intuitive concepts and people will likely stumble over the terms when they are used before they are defined. - Please expand DOIC and SOC on first mention in the body. (Even if they were expanded in the abstract.) §2: - Definitions of “Diameter Node” and “Diameter Endpoint”: Please use proper citations rather than just referring to the RFC in text. For example: “Diameter Node: A Diameter client, server, or agent. [RFC6733]” §4, - first paragraph: — “This extension defines”: I think this should say “This document defines…” — Please consider active voice for the last sentence. - 2nd paragraph: The first sentence seems awkward. Consider something to the effect of “Since all nodes that support DOIC are required to support the loss algorithm…” - 3rd paragraph: This paragraph seems to belong as part of the previous paragraph. - 4th paragraph: “ AVP in the sent to the DOIC reacting nodes”: Missing word(s)? -5th paragraph: “A reporting node MAY select…” : Is that a new permission, or a statement of fact? §5.1, third paragraph: The text is not clear whether this means OCS should be maintained per supported application, etc, or that it should maintain state when the rate algorithm on a per supported application, etc, basis. - 4th paragraph: s/overoload/overload §5.3: 2nd paragraph: This seems like a redundant restatement of the first paragraph. - third paragraph: The first sentence is convoluted; can it be broken into simpler sentences? §6.1.1, definition of " OLR_RATE_ALGORITHM”: Two periods at end of sentence. §7.1, 2nd paragraph: “ signal one another support for rate-based overload control”: This seems awkward; are there missing words? §7.2, last two paragraphs: The MUSTs do not seem necessary. 2119 keywords should be used when there is some sort of choice or room for error. You don’t need them to define the basic operation of the protocol. §7.3.1: I found the text hard to follow. It would help to declare all the identifiers and initialization up front, and to present things in more of a stepwise fashion. - T is effectively a time interval, right? It would help to say that, especially later when you subtract a different time interval from it. - paragraph 9: Should “admit” be “emit”? - the example code has several mentions of SIP requests. §7.3.2: “ Request candidates for reduction, requests not subject to reduction (except under extenuating circumstances when there aren’t any messages in the first category that can be reduced).”: That seems like an awkward way to say that the second category is the set of requests that is only subject to reduction if there are no messages left in the first category. - “ This can be generalized to n priorities using n thresholds for n>2 in the obvious way.”: I suggest you refrain from calling it “obvious". §7.3.3: Paragraph starting with “ Then (only) if the arrival is admitted, increase the bucket by an amount…”: I think you increase the bucket _count_, right? |
|
2018-05-15
|
08 | Ben Campbell | IESG state changed to AD Evaluation from Publication Requested |
|
2018-05-15
|
08 | Ben Campbell | Changed consensus to Yes from Unknown |
|
2018-03-11
|
08 | Ben Campbell | Shepherding AD changed to Ben Campbell |
|
2018-03-06
|
08 | Lionel Morand | 1. Summary The document shepherd is Lionel Morand. The responsible Area Director is Eric Rescorla. This document defines an abatement algorithm that allows Diameter nodes … 1. Summary The document shepherd is Lionel Morand. The responsible Area Director is Eric Rescorla. This document defines an abatement algorithm that allows Diameter nodes to notify the maximum rate at which Diameter requests can be received. This is an extension to the Diameter Overload Indication Conveyance (DOIC) [RFC7683] base solution, in which only the loss algorithm was defined, used to request a percentage reduction in the amount of traffic received. Intended status: Standards Track 2. Review and Consensus 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. 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. The document received a large support for adoption when initiated and it has been reviewed multiple times, with detailed comments and corrections. The version -03 addresses the last comments received after the WGLC process and the shepherd review. There is a strong WG consensus on the content of this document, with a broad range of people, including key experts. 3. Security Considerations There is no specific security concerns highlighted in this document. The Security considerations section outlined in [RFC7683] apply to the rate overload abatement mechanism that is just a new algo defined for the Diameter overload control mechanism. 4. IANA considerations The IANA considerations section is consistent with the body of the document. All protocol extensions are associated with appropriate reservations for IANA. 5. Intellectual Property The author and contributor have confirmed conformance with IETF IPR rules (RFCs 3979, 4879, 3669, and 5378). There are no IPR disclosures on the document. 6. ID Nits Some IDnits that can be handled with a rev of the document when publishing the document; Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 4 characters in excess of 72. ** The abstract seems to contain references ([RFC2119], [RFC7683]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- No issues found here. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '0' on line 758 == Missing Reference: 'T' is mentioned on line 758, but not defined == Unused Reference: 'RFC5226' is defined on line 806, but no explicit reference was found in the text == Unused Reference: 'RFC6733' is defined on line 811, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-dime-agent-overload-00 ** Obsolete normative reference: RFC 5226 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. 7. Other points An errata report on RFC7683 (Errata ID: 5277) has been issued and it is related to IANA policy for the OC-Feature-Vector AVP value allocation. The present document adds a new algo for DOIC and then a new feature flag is needed in the OC-Feature-Vector AVP. During the review, it has been identified that the current text describing the value for OC-Feature-Vector AVP is not correct. While the AVP is defined as a 64-bit mask, in which each bit indicates a supported feature, the initial text was implying that a value needed to assigned per feature, which was wrong. The current version of this document takes into account this errata report. A small error remains in the document that can be covered by a last revision: in the default algo for Rate-based Control shown in section 7.3.1, "SIP" is used instead of "Diameter". For information, the document defines a new algorithm that is referenced as normative reference of draft-ietf-dime-agent-overload-11 (waiting for IESG review), which is itself used as referenced by the draft-ietf-dime-load-09 (already in the RFC Ed Queue). |
|
2018-03-06
|
08 | Lionel Morand | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
|
2018-03-06
|
08 | Lionel Morand | IESG state changed to Publication Requested |
|
2018-03-06
|
08 | Lionel Morand | IESG process started in state Publication Requested |
|
2018-03-06
|
08 | Lionel Morand | Changed document writeup |
|
2018-03-05
|
08 | Steve Donovan | New version available: draft-ietf-dime-doic-rate-control-08.txt |
|
2018-03-05
|
08 | (System) | New version approved |
|
2018-03-05
|
08 | (System) | Request for posting confirmation emailed to previous authors: Steve Donovan <srdonovan@usdonovans.com>, Eric Noel <ecnoel@research.att.com> |
|
2018-03-05
|
08 | Steve Donovan | Uploaded new revision |
|
2017-09-27
|
07 | Steve Donovan | New version available: draft-ietf-dime-doic-rate-control-07.txt |
|
2017-09-27
|
07 | (System) | New version approved |
|
2017-09-27
|
07 | (System) | Request for posting confirmation emailed to previous authors: Steve Donovan <srdonovan@usdonovans.com>, Eric Noel <ecnoel@research.att.com> |
|
2017-09-27
|
07 | Steve Donovan | Uploaded new revision |
|
2017-04-20
|
06 | Jouni Korhonen | Tag Revised I-D Needed - Issue raised by WGLC cleared. |
|
2017-04-20
|
06 | Jouni Korhonen | IETF WG state changed to WG Consensus: Waiting for Write-Up from Waiting for WG Chair Go-Ahead |
|
2017-04-20
|
06 | Jouni Korhonen | Notification list changed to Lionel Morand <lionel.morand@orange.com> |
|
2017-04-20
|
06 | Jouni Korhonen | Document shepherd changed to Lionel Morand |
|
2017-03-29
|
06 | Amy Vezza | Shepherding AD changed to Eric Rescorla |
|
2017-03-27
|
06 | Steve Donovan | New version available: draft-ietf-dime-doic-rate-control-06.txt |
|
2017-03-27
|
06 | (System) | New version approved |
|
2017-03-27
|
06 | (System) | Request for posting confirmation emailed to previous authors: Steve Donovan <srdonovan@usdonovans.com>, Eric Noel <ecnoel@research.att.com> |
|
2017-03-27
|
06 | Steve Donovan | Uploaded new revision |
|
2017-02-16
|
05 | Steve Donovan | New version available: draft-ietf-dime-doic-rate-control-05.txt |
|
2017-02-16
|
05 | (System) | New version approved |
|
2017-02-16
|
05 | (System) | Request for posting confirmation emailed to previous authors: "Eric Noel" <ecnoel@research.att.com>, "Steve Donovan" <srdonovan@usdonovans.com> |
|
2017-02-16
|
05 | Steve Donovan | Uploaded new revision |
|
2017-02-14
|
04 | Jouni Korhonen | Comments mainly received from Misha Zaytsev. These should be addressed before submitting the document to the IESG. See https://www.ietf.org/mail-archive/web/dime/current/msg09118.html Likely no new WGLC is needed … Comments mainly received from Misha Zaytsev. These should be addressed before submitting the document to the IESG. See https://www.ietf.org/mail-archive/web/dime/current/msg09118.html Likely no new WGLC is needed after that. |
|
2017-02-14
|
04 | Jouni Korhonen | Tag Revised I-D Needed - Issue raised by WGLC set. Tag Other - see Comment Log cleared. |
|
2017-02-06
|
04 | Jouni Korhonen | WGLC completed. Got few reviews. Chair needs to check whether the comments require a revised I-D. |
|
2017-02-06
|
04 | Jouni Korhonen | IETF WG state changed to Waiting for WG Chair Go-Ahead from In WG Last Call |
|
2017-01-22
|
04 | Jouni Korhonen | The WGLC#3 starts 1/22/2017 and ends 2/5/2017. |
|
2017-01-22
|
04 | Jouni Korhonen | IETF WG state changed to In WG Last Call from WG Document |
|
2017-01-11
|
04 | Jouni Korhonen | WGLC#2 concluded.. unfortunately not a single review or comment received. |
|
2017-01-11
|
04 | Jouni Korhonen | IETF WG state changed to WG Document from In WG Last Call |
|
2016-12-12
|
04 | Jouni Korhonen | WGLC ends 12/19/2016 EOB. |
|
2016-12-12
|
04 | Jouni Korhonen | IETF WG state changed to In WG Last Call from WG Document |
|
2016-12-12
|
04 | Jouni Korhonen | Going to another WGLC soon. There was really no during WGLC#1 |
|
2016-12-12
|
04 | Jouni Korhonen | IETF WG state changed to WG Document from In WG Last Call |
|
2016-10-04
|
04 | Steve Donovan | New version available: draft-ietf-dime-doic-rate-control-04.txt |
|
2016-10-04
|
04 | (System) | New version approved |
|
2016-10-04
|
03 | (System) | Request for posting confirmation emailed to previous authors: "Eric Noel" <ecnoel@research.att.com>, "Steve Donovan" <srdonovan@usdonovans.com> |
|
2016-10-04
|
03 | Steve Donovan | Uploaded new revision |
|
2016-09-19
|
03 | (System) | Document has expired |
|
2016-05-25
|
03 | Jouni Korhonen | WGLC #1 starts 5/25/16 and ends 6/8/16 |
|
2016-05-25
|
03 | Jouni Korhonen | Tag Other - see Comment Log set. |
|
2016-05-25
|
03 | Jouni Korhonen | IETF WG state changed to In WG Last Call from WG Document |
|
2016-04-04
|
03 | Lionel Morand | Added -03 to session: IETF-95: dime Fri-1000 |
|
2016-03-18
|
03 | Steve Donovan | New version available: draft-ietf-dime-doic-rate-control-03.txt |
|
2015-08-31
|
02 | Steve Donovan | New version available: draft-ietf-dime-doic-rate-control-02.txt |
|
2015-03-06
|
01 | Steve Donovan | New version available: draft-ietf-dime-doic-rate-control-01.txt |
|
2015-01-27
|
00 | Benoît Claise | Shepherding AD changed to Kathleen Moriarty |
|
2014-12-17
|
00 | Jouni Korhonen | Intended Status changed to Proposed Standard from None |
|
2014-12-17
|
00 | Jouni Korhonen | This document now replaces draft-donovan-dime-doc-rate-control instead of None |
|
2014-12-17
|
00 | Steve Donovan | New version available: draft-ietf-dime-doic-rate-control-00.txt |