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

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"?