Diameter Overload Control Requirements
draft-ietf-dime-overload-reqs-13

[Ballot comment]

Good document, thanks.

My only question was what the wg are going to do if they
need to choose between two solutions, neither of which
meets all the MUST conditions. You don't say here, and
maybe that's for the best, but that is a long list of
requirements.

[Ballot comment]
I have no objection to the publication of this document.

If I was to be picky I would say that the use of "route" (as in "route a
request to a server") has the potential to cause some confusion. As far
as I can see there isn't any network-wide routing going on here and what
happens is that an Agent selects a Server to consume a request and
dispatches the request to that Server. I suppose that is a form of
routing, but unless the Agents can be arranged hierarchically towards
the Server, and unless there is some sort of mesh connectivity between
Agents, this is not really worthy of the term "routing". "Switch" or
"Dispatch" or even "Forward" may be better terms.

But this is a trivial point and you can completely ignore it if you
like.

[Ballot comment]
I will attempt to finish my review before the telechat, but I wanted to send these out just in case I don't. Editorial silliness follows:

Section 1.1: I quixotically suggest the following as a replacement for the first paragraph:

  The uppercased keywords "MUST", "MUST NOT", and "SHOULD" in this
  document are NOT used as defined in [RFC2119]. Instead, they are to
  be interpreted as follows:

  - "MUST" means that the item is an absolute requirement for a
  solution proposed for addressing the problem described in this
  document.
  - "MUST NOT" means that the item is an absolute prohibition for a
  solution proposed for addressing the problem described in this
  document.
  - "SHOULD" means that there may exist valid reasons in particular
  circumstances for the solution not to address the particular item,
  but the full implications must be understood and carefully weighed
  before choosing a different course.
 
Section 1.4 and Section 2: Replace "the authors" with "this document", 3 occurrences total. This is a WG document; referring to "the authors" sounds weird.

[Ballot comment]
I found this to be a good read, and I learned some things from it.

On seeing Spencer's comments about "overload" vs "congestion", I looked for that, specifically.  To me, it seems that you are using the two as you mean to, and you are making a clean distinction, while recognizing that they relate to each other.  In particular, when you say that server overload can lead to congestion collapse, I think you mean exactly that, and are showing how the layers can interact.  Of course, if I'm reading that wrong, then take this as support for Spencer's comments.  :-)

In Section 1.3, a tiny micronit, but this nit is a pet peeve of mine, so:

  Modern Diameter networks, comprised of application layer multi-node
  deployments of Diameter elements

Correctly used, the whole comprises the parts (it's not "comprised of" them).  Please change "comprised of" to "comprising".

Hey, it shows that I really *read* it, yeh?

In the first sentence of Section 7, I would say "with the goals of addressing the issues described in Section 5"; "improving the issues" sounds odd to this native-English ear.

The requirements appear to be well thought out, and they fit together well.  There's often a gap in that regard in requirements documents, so good work there.

[Ballot comment]
I found this draft to be clear and well-written.

I have some comments that you might wish to consider, along with any other comments you receive during the approval process.

This draft is distinguishing between overload and network congestion, but I'm seeing the word "congestion" in places that seem to be talking about overload, beginning in the Abstract (where the following text appears), and in the Introduction:

  When a Diameter server or agent becomes overloaded, it needs to be
  able to gracefully reduce its load, typically by informing clients to
  reduce sending traffic for some period of time.  Otherwise, it must
  continue to expend resources parsing and responding to Diameter
  messages, possibly resulting in congestion collapse.  The existing
                                  ^^^^^^^^^^
  Diameter mechanisms are not sufficient for this purpose.  This
  document describes the limitations of the existing mechanisms.
  Requirements for new overload management mechanisms are also
  provided.

Given the distinction this draft is making between overload and network congestion, is using "congestion" in this way helpful?

I'm not smart enough to suggest which term is appropriate in each case, but it might be helpful to do a quick scan and make sure each usage of "congest" has the intended meaning ...

In 1.2.  Causes of Overload

  External resources can include upstream Diameter nodes; for example,
  a Diameter agent can become effectively overloaded if one or more
  upstream nodes are overloaded.  While overload is not the same thing
  as network congestion, network congestion can reduce a Diameter nodes
  ability to process and respond to requests, thus contributing to
  overload.

Section 1.4.  Overload vs. Network Congestion explains the difference, but that's later in the document. Perhaps a forward reference here would be helpful?

In 7.2.  Performance

  REQ 11:  The solution MUST be able to operate in networks of
            different sizes.

it might be helpful to give some orders-of-magnitude clue on what this requirement means at the high end (recognizing that all these networks are growing).

In 7.3.  Heterogeneous Support for Solution

  REQ 17:  In a mixed environment with nodes that support the solution
            and that do not, the solution MUST NOT result in materially
            less useful throughput as would have resulted if the
            solution were not present.  It SHOULD result in less severe
            congestion in this environment.

it wasn't clear to me whether this requirement was talking about materially less throughput during periods of overload, or at any time. REQ 21 is clearly talking about periods of overload, but on REQ 17, I'm guessing.

Should "congestion" be "overload" in the last sentence?

Ignoring the part where we're talking about RFC 2119 language in a requirements document, in 7.4.  Granular Control

  REQ 22:  The solution MUST provide a way for a node to throttle the
            amount of traffic it receives from a peer node.  This
            throttling SHOULD be graded so that it can be applied
            gradually as offered load increases.  Overload is not a
            binary state; there may be degrees of overload.

I'm reading this as saying that a solution that cannot be applied gradually is still acceptable (SHOULDs aren't MUSTs). Is that right?

In 7.6.  Security

  REQ 27:  The solution MUST NOT provide new vulnerabilities to
            malicious attack, or increase the severity of any existing
            vulnerabilities.  This includes vulnerabilities to DoS and
            DDoS attacks as well as replay and man-in-the middle
            attacks.  Note that the Diameter base specification
                      ^^^^
            [RFC6733] lacks end to end security and this must be
            considered.  Note that this requirement was expressed at a
            ^^^^^^^^^^
            high level so as to not preclude any particular solution.
            Is is expected that the solution will address this in more
            detail.

The point between "^"s is explained more clearly in the Security Considerations section. I'd suggest either replacing this sentence with a pointer to Section 9 or (perhaps better) pulling the third paragraph from the Security Considerations section into this requirement.

In 9.5.  Compromised Hosts

  A compromised host that supports the Diameter overload control
  mechanism could be used for information gathering as well as for
  sending malicious information to any Diameter node that would
  normally accept information from it.  While is is beyond the scope of
                                              ^^^^^ perhaps "it is"?

[Ballot comment]
I found this draft to be clear and well-written.

I have some comments that you might wish to consider, along with any other comments you receive during the approval process.

In several places this draft is distinguishing between overload and network congestion, but I'm seeing the word "congestion" in several places that seem to be talking about overload, beginning in the Abstract (where the following text appears), and in the Introduction:

  When a Diameter server or agent becomes overloaded, it needs to be
  able to gracefully reduce its load, typically by informing clients to
  reduce sending traffic for some period of time.  Otherwise, it must
  continue to expend resources parsing and responding to Diameter
  messages, possibly resulting in congestion collapse.  The existing
                                  ^^^^^^^^^^
  Diameter mechanisms are not sufficient for this purpose.  This
  document describes the limitations of the existing mechanisms.
  Requirements for new overload management mechanisms are also
  provided.

Given the distinction this draft is making between overload and network congestion, is using "congestion" in this way helpful?

I'm not smart enough to suggest which term is appropriate in each case, but it might be helpful to do a quick scan and make sure each usage of "congest" has the intended meaning ...

In 1.2.  Causes of Overload

  External resources can include upstream Diameter nodes; for example,
  a Diameter agent can become effectively overloaded if one or more
  upstream nodes are overloaded.  While overload is not the same thing
  as network congestion, network congestion can reduce a Diameter nodes
  ability to process and respond to requests, thus contributing to
  overload.

Section 1.4.  Overload vs. Network Congestion explains the difference, but that's later in the document. Perhaps a forward reference here would be helpful?

In 7.2.  Performance

  REQ 11:  The solution MUST be able to operate in networks of
            different sizes.

it might be helpful to give some orders-of-magnitude clue on what this requirement means at the high end (recognizing that all these networks are growing).

In 7.3.  Heterogeneous Support for Solution

  REQ 17:  In a mixed environment with nodes that support the solution
            and that do not, the solution MUST NOT result in materially
            less useful throughput as would have resulted if the
            solution were not present.  It SHOULD result in less severe
            congestion in this environment.

it wasn't clear to me whether this requirement was talking about materially less throughput during periods of overload, or at any time. REQ 21 is clearly talking about periods of overload, but on REQ 17, I'm guessing.

Should "congestion" be "overload" in the last sentence?

Ignoring the part where we're talking about RFC 2119 language in a requirements document, in 7.4.  Granular Control

  REQ 22:  The solution MUST provide a way for a node to throttle the
            amount of traffic it receives from a peer node.  This
            throttling SHOULD be graded so that it can be applied
            gradually as offered load increases.  Overload is not a
            binary state; there may be degrees of overload.

I'm reading this as saying that a solution that cannot be applied gradually is still acceptable (SHOULDs aren't MUSTs). Is that right?

In 7.6.  Security

  REQ 27:  The solution MUST NOT provide new vulnerabilities to
            malicious attack, or increase the severity of any existing
            vulnerabilities.  This includes vulnerabilities to DoS and
            DDoS attacks as well as replay and man-in-the middle
            attacks.  Note that the Diameter base specification
                      ^^^^
            [RFC6733] lacks end to end security and this must be
            considered.  Note that this requirement was expressed at a
            ^^^^^^^^^^
            high level so as to not preclude any particular solution.
            Is is expected that the solution will address this in more
            detail.

The point between "^"s is explained more clearly in the Security Considerations section. I'd suggest either replacing this sentence with a pointer to Section 9 or (perhaps better) pulling the third paragraph from the Security Considerations section into this requirement.

In 9.5.  Compromised Hosts

  A compromised host that supports the Diameter overload control
  mechanism could be used for information gathering as well as for
  sending malicious information to any Diameter node that would
  normally accept information from it.  While is is beyond the scope of
                                              ^^^^^ perhaps "it is"?

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-dime-overload-reqs-10, which is currently
in Last Call, and has the following comments:

We understand that, upon approval of this document, there are no
IANA Actions that need completion.

If this assessment is not accurate, please respond as soon as possible.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Diameter Overload Control Requirements) to Informational RFC


The IESG has received a request from the Diameter Maintenance and
Extensions WG (dime) to consider the following document:
- 'Diameter Overload Control Requirements'
  as Informational RFC

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 2013-08-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


  When a Diameter server or agent becomes overloaded, it needs to be
  able to gracefully reduce its load, typically by informing clients to
  reduce sending traffic for some period of time.  Otherwise, it must
  continue to expend resources parsing and responding to Diameter
  messages, possibly resulting in congestion collapse.  The existing
  Diameter mechanisms, listed in Section 4 are not sufficient for this
  purpose.  This document describes the limitations of the existing
  mechanisms in Section 5.  Requirements for new overload management
  mechanisms are provided in Section 7.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dime-overload-reqs/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dime-overload-reqs/ballot/


No IPR declarations have been submitted directly on this I-D.

(1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard,
Informational, Experimental, or Historic)? Why is this the proper type of RFC? Is this
type of RFC indicated in the title page header?

The document aims for Informational. This is also indicated in
the title page.

(2) The IESG approval announcement includes a Document Announcement Write-Up. Please
provide such a Document Announcement Write-Up. Recent examples can be found in the
"Action" announcements for approved documents. The approval announcement contains the
following sections:

Technical Summary:

The document sets normative requirements for Diameter overload control
solutions. The existing Diameter mechanisms for an overload control are
not sufficient for a practical solution. The document also goes into
lengths explaining why Diameter overload control functionality is needed
and describes the limitations of the existing mechanisms in the Diameter
Base Protocol.

Working Group Summary:

The working group reached a consensus on the document. The discussion
was extensive. Since this document is a requirements document, possible
technical solution space issues are left for future documents and
discussions.

There is an obvious decision point ahead that got quite a bit of attention,
which relates to the dissemination of the overload control information:
whether an explicit overload application is needed for proper end-to-end
signaling semantics or whether everything is piggybacked on top of existing
signaling between adjacent peers in hop-by-hop fashion. However, this is
for the solution space and the requirements document currently allows both
approaches.

Document Quality:

The document has greater industry interest behind, specifically from the
cellular industry. Since the document is a requirement document there are
no standardised solutions available yet due to the absence of the protocol
specification. There is definitive interest from both operators and vendors
to have a standard solution for Diameter overload control.

The requirements document has been extensively reviewed by the 3GPP CT4
working group, which is the main AAA protocol group in 3GPP.

Personnel:

Who is the Document Shepherd? Who is the Responsible Area Director?

Jouni Korhonen is the document shepherd. The responsible
area director is Benoit Claise.

(3) Briefly describe the review of this document that was performed by the Document
Shepherd. If this version of the document is not ready for publication, please explain
why the document is being forwarded to the IESG.

The shepherd has reviewed the document and did not find issues that
would prohibit forwarding the document to the IESG. The remaining
editorial nature concerns can be addressed during the IETF LC.

(4) Does the document Shepherd have any concerns about the depth or breadth of the
reviews that have been performed?

The shepherd has no concern on the depth of the reviews so far.
The document has already been reviewed thoroughly by external parties.

(5) Do portions of the document need review from a particular or from broader perspective,
e.g., security, operational complexity, AAA, DNS, DHCP, XML, or internationalization?
If so, describe the review that took place.

The document needs to be reviewed by OPS-DIR, SecDir and AAA-Doctors.
None of these have not been initiated yet. The reviews should specifically
be done from Diameter deployments point of view and keeping the existing
Diameter security constraints in mind.

(6) Describe any specific concerns or issues that the Document Shepherd has with this
document that the Responsible Area Director and/or the IESG should be aware of? For
example, perhaps he or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any event, if the WG has
discussed those issues and has indicated that it still wishes to advance the
document, detail those concerns here.

No concerns.

(7) Has each author confirmed that any and all appropriate IPR disclosures required for
full conformance with the provisions of BCP 78 and BCP 79 have already been filed.
If not, explain why?

There are no filed IPRs. Also the shepherd has confirmed from each authors
that they are not aware of any IPR claims to the document.

(8) Has an IPR disclosure been filed that references this document? If so, summarize any
WG discussion and conclusion regarding the IPR disclosures.

There are no filed IPRs.

(9) How solid is the WG consensus behind this document? Does it represent the strong
concurrence of a few individuals, with others being silent, or does the WG as a
whole understand and agree with it?

There is a WG level consensus behind the document.

(10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so,
please summarise the areas of conflict in separate email messages to the Responsible
Area Director. (It should be in a separate email because this questionnaire is
publicly available.)

No.

(11) Identify any ID nits the Document Shepherd has found in this document.
(See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist).
Boilerplate checks are not enough; this check needs to be thorough.

The document passes the automated IDnits check.

(12) Describe how the document meets any required formal review criteria, such as the
MIB Doctor, media type, and URI type reviews.

This is a requirements document and as such has not need for
MIB Doctor, media type, and URI type reviews.

(13) Have all references within this document been identified as either normative or
informative?

Yes.

(14) Are there normative references to documents that are not ready for advancement or
are otherwise in an unclear state? If such normative references exist, what is the
plan for their completion?

No.

(15) Are there downward normative references references (see RFC 3967)? If so, list these
downward references to support the Area Director in the Last Call procedure.

No.

(16) Will publication of this document change the status of any existing RFCs? Are those
RFCs listed on the title page header, listed in the abstract, and discussed in the
introduction? If the RFCs are not listed in the Abstract and Introduction, explain
why, and point to the part of the document where the relationship of this document
to the other RFCs is discussed. If this information is not in the document, explain
why the WG considers it unnecessary.

No.

(17) Describe the Document Shepherd's review of the IANA considerations section,
especially with regard to its consistency with the body of the document. Confirm
that all protocol extensions that the document makes are associated with the
appropriate reservations in IANA registries. Confirm that any referenced IANA
registries have been clearly identified. Confirm that newly created IANA registries
include a detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a reasonable name
for the new registry has been suggested (see RFC 5226).

There are no requirements to IANA.

(18) List any new IANA registries that require Expert Review for future allocations.
Provide any public guidance that the IESG would find useful in selecting the IANA
Experts for these new registries.

None.

(19) Describe reviews and automated checks performed by the Document Shepherd to validate
sections of the document written in a formal language, such as XML code, BNF rules,
MIB definitions, etc.

None needed.

On 28-May-2013 @ dime mailing list:

Folks,

We seem to have reached consensus on this document and can conclude it have passed its WGLC. So, the next step is chairs doing yet another review while writing the proto write-up, and then eventually move the document into IESG process.

- Jouni & Lionel

Folks,

The authors of draft-ietf-dime-overload-reqs have requested for a WGLC and I think the document is stable enough for it.

This email starts a two week WGLC for draft-ietf-dime-overload-reqs-03. The WGLC ends Tuesday 5th February 2013. Post your comments to the mailing list and if you think something needs to be changed, put that also into the Issue Tracker. Please pay a specific attention to the actual requirements.

- Jouni & Lionel