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