Shepherd writeup
rfc8582-11

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).
 
Back