Subject: [Dime] Review of draft-ietf-dime-overload-reqs-02

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 11 Jan 2013 10:11:29 +0200

Hi Eric, Hi Ben, 

I went through the document and here are a few minor comments. 

You write:

"
The existing mechanisms provided by Diameter are not
   sufficient for this purpose.  This document describes the limitations
   of the existing mechanisms, and provides requirements for new
   overload management mechanisms.
"

I suggest to change it to:

"
The existing Diameter mechanisms, listed in Section 4, are not
   sufficient for this purpose. Section 5 describes the limitations
   of the existing mechanisms, and provides requirements for new
   overload management mechanisms in Section 7.
   "

You write: 

   This document draws on [RFC5390] and the work done on SIP overload
   control as well as on overload practices in SS7 networks and studies
   done by 3GPP.
 
My suggestion would be to re-word this sentence to:

   This document draws on the work done on SIP overload
   control [RFC5390, RFC6357, draft-ietf-soc-overload-control], experience gained with overload handling in SS7 networks, and studies done by 3GPP (see Section 6).

You write:
"
   Diameter is not typically an end-user protocol; rather it is   
   generally used as one component in support of some end-user activity.
   For example, a WiFi access point might use Diameter to authenticate
   and authorize user access via 802.11.  Overload in a network that
   uses Diameter applications will likely spill over into the end-user
   application network.  The impact of Diameter overload on the client
   application (a client application may use the Diameter protocol and
   other protocols to do its job) is beyond the scope of this document.
" 

I would change this paragraph to:
" 
   Diameter is not an end-user protocol; rather it is   
   generally used as a backend protocol in support of some application.
   
   For example, a SIP server might use Diameter to authenticate
   and authorize user access.  Overload in the Diameter backend infrastructure
   will likely impact the experience observed by the end user in the SIP 
   application. 
   
   The impact of Diameter overload on the application using the Diameter protocol 
   is beyond the scope of this document.
"

You write:

" 
      Diameter depends heavily on The "Authentication, Authorization,
      and Accounting (AAA) Transport Profile" [RFC3539], which states
      assumptions about the scale of AAA services which may be incorrect
      for current uses of Diameter.  In particular, the document
      suggests that AAA services will typically be low volume and that
      traffic will typically be application-driven.  Section 2.1 of that
      document uses an example of a 48 port NAS.  However, Diameter is
      commonly used in large-scale mobile data environments, where a
      typical client could be a packet gateway that serves millions of
      users, and generates Diameter messages at network-driven rates.
"

I am not sure why the text is indented. I also do not believe that RFC 3539
states incorrect assumption. You reference the same of a 48 port NAS but in the 
same section 10,000 48-ports NASes as well as 2048-port NASes are mentioned as well. 
Even though the examples may not necessarily map to the current deployment the 
point the referenced section makes is a different one, namely "the rate at which 
messages are sent is typically limited by how quickly they are generated by the application, 
rather than by the size of the congestion window." This statement is also applicable 
to the discussion in draft-ietf-dime-overload-reqs.
   
Section 2.3: s/diameter/Diameter
Section 3: s/diameter/Diameter

Regarding extensibility I am wondering whether you are trying to say that the algorithm itself should not be standardized (or should at least be extensible) or that the mechanism to convey overload information should be extensible. 

If it is the former then I would suggest to rename the section to something like "Overload Algorithm Independence"

I would have actually expected the text from Section 4 to appear much earlier in the document, for example, in the introduction RFC 5390 actually does a pretty good job in explaining why the currently specified overload mechanisms in SIP are insufficient and further work is needed. 

Section 5: 

I would shorten the introduction to the sub-sections because the same text is repeated twice. 

Change from:

"
   The currently available Diameter mechanisms for indicating an
   overload condition are not adequate to avoid service outages due to
   overload.  This inadequacy may, in turn, contribute to broader
   congestion collapse due to unresponsive Diameter nodes causing
   application or transport layer retransmissions.  In particular, they
   do not allow a Diameter agent or server to shed load as it approaches
   overload.  At best, a node can only indicate that it needs to
   entirely stop receiving requests, i.e. that it has effectively
   failed.  Even that is problematic due to the inability to indicate
   durational validity on the transient errors available in the base
   Diameter protocol.  Diameter offers no mechanism to allow a node to
   indicate different overload states for different categories of
   messages, for example, if it is overloaded for one Diameter
   application but not another.
"

To:

"
   The currently available Diameter mechanisms for indicating an
   overload condition are not adequate, as described in the sub-sections 
   below. 
"

s/It makes no suggestion that a the
   receipt of a DIAMETER_TOO_BUSY response should affect future Diameter
   messages in any way./It makes no suggestion that the
   receipt of a DIAMETER_TOO_BUSY response should affect future Diameter
   messages in any way.

You should probably expand acronyms on first use. Examples: IMS, GSM, SS7, 3GPP, UMTS, CDMA

You write: 

"
Smartphones contribute much more heavily, relative to non-
   smartphones, to the continuation of a registration surge due to their
   very aggressive registration algorithms.  The aggressive smartphone
   logic is designed to:

   a.  always have voice and data registration, and

   b.  constantly try to be on 3G or LTE data (and thus on 3G voice or
       VoLTE) for their added benefits.

   Non-smartphones typically have logic to wait for a time period after
   registering successfully on voice and data.

   The smartphone aggressive registration is problematic in two ways:

   o  first by generating excessive signaling load towards the HLR that
      is ten times that from a non-smartphone,

   o  and second by causing continual registration attempts when a
      network failure affects registrations through the 3G data network.	   
"

I have to guess what point you are trying to make in the second part of Section 6.1. 

I believe the the issue you want to point out is that applications on smart phones send keep-alive messages peridically to ensure that the applications are always reachable. The Diameter overload handling does not offer a solution in this case since newer phones work (with their applications) work differently than legacy phones and therefore more state is required.

It might help to cite a document that provides further information and to supports the statements you have made. 

Requirements: 

You write:
"
   REQ 11:  The overload control mechanism MUST be scalable.  That is,
            it MUST be able to operate in different sized networks.
" 

I would simplify this statement into:

"
   REQ 11:  The overload control mechanism MUST be able to operate networks of different 
   size. 
" 
			
Just saying it "scales" is not really useful.

REQ 18:  In a mixed environment of nodes that support the overload
            control mechanism and that do not, users and operators of
            nodes that do not support the mechanism MUST NOT unfairly
            benefit from the mechanism.
			
As mentioned on the mailing list this is hard to accomplish. Consider the following case:

           +------------------+     +------------------+
           |                  |     |                  |
           |                  |     |                  |
           |     Client 1     |     |     Client 2     |
           |                  |     |                  |
           +--------+-`.------+     +------.'+---------+
                        `.               .'
                         `.           .'
                            `.       .'
                              `.   .'
                        +-------`.'--------+
                        |                  |
                        |                  |
                        |     Agent        |
                        |                  |
                        +--------+---------+
                                 |
                                 |
                                 |
                        +--------+---------+
                        |                  |
                        |                  |
                        |     Server       |
                        |                  |
                        +------------------+

Imagine that the server is under heavy load and reports this situation. There are two clients who contribute to the overload: client 1 understands the overload feedback signal and client 2 doesn't. So, what's going to happen? client 1 will reduce the sending rate while client 2 will not react. 
						
I am not sure what you are trying to express with REQ 30. Lacking e2e security in Diameter all you can do is to trust your neighboring nodes (which you hopefully have authenticated). 

Replay Attacks

Are you concerned about replay attacks by Diameter nodes, by on-path attackers (who are not Diameter nodes), or by off-path attackers? 

Reading through the entire document there is one aspect unclear to me: How do you want to support the exchange of overload information between non-neighboring nodes (particularly when some intermediate nodes do not support the indicated mechanism)? Or, you could phrase it in a different way: If you are able to exchange overload information how do you expect the approach to work when an unknown number of intermediaries do not understand how to behave differently in case of new requests. Since you scope the document in such a way that the actual initiator of the interactions does not necessarily get informed you leave the decision making pending somewhere but you do not say where. Let me give you an example: Imagine a SIP client that triggers some transactions that require AAA interworking. The AAA client (for example a proxy server) could decide to reject some end user requests when it receives notifications about overload. It could, however, also assume that somewhere further in the AAA network the signaling load will be "re-directed" to some other servers. Lacking any information about what the real reason for the overload is it is hard to make some assumptions. A load balancing node, for example, may not be updated to support the overload features and could therefore not take those into account, the may only be a single server, there may be multiple servers but they are all connected to the same database and the problem is actually with the database, etc. 

Ciao
Hannes

---

From: Eric McMurry <[email-masked]>
Date: Fri, 11 Jan 2013 09:55:55 -0600

Hi Hannes,

thanks for the comments!

responses inline.

Eric

>    overload management mechanisms in Section 7.

okay

>    control [RFC5390, RFC6357, draft-ietf-soc-overload-control], experience gained with overload handling in SS7 networks, and studies done by 3GPP (see Section 6).

okay in general.  I'd rather not reference a draft if it can be avoided.

>    is beyond the scope of this document.

I see two comments here; break up the paragraph, and use a SIP example instead of the 802.11 example.  right?

> to the discussion in draft-ietf-dime-overload-reqs.

I think it was indented because no one noticed that :-).  If there was a reason, I don't remember it.  I will fix that.

I agree with you on the intent of that session in RFC 3539, and I believe that was where the last statement in the paragraph in this draft came from.  Even using the RFC 3539 example of 10,000 NASs, the characteristics and scale are quite different than with current and future Diameter usage.  It is entirely possible for networks, as well as applications, to become congested with Diameter traffic now.

That said, this was in the document to show some history and how the original thinking and planned usages have not matched where things ended up, and is not integral to the document.  If it is causing confusion it should be changed or removed.

> Section 3: s/diameter/Diameter

thanks, I'll fix those

> If it is the former then I would suggest to rename the section to something like "Overload Algorithm Independence"

The intended extensibility was broader.  I recall that this was added to address a question on one of the requirements at some point.  It looks like we should have put a bit more in it.  I'll broaden the language in this section.

> I would have actually expected the text from Section 4 to appear much earlier in the document, for example, in the introduction RFC 5390 actually does a pretty good job in explaining why the curren…

I think swapping that with section 3 would be reasonable.  It was after section 2 so that there was some context to talk about why the existing mechanisms were not sufficient.  Putting it before that might be a bit confusing.  Thoughts?

>    overload condition are not adequate, as described in the sub-sections 

I'm not sure I agree with this.  If I were reading it on a first pass I think I would appreciate the summary.  The same concepts are repeated and expanded in the subsections, but I don't think the text is copied.

>    receipt of a DIAMETER_TOO_BUSY response should affect future Diameter

got it.  thanks.

> You should probably expand acronyms on first use. Examples: IMS, GSM, SS7, 3GPP, UMTS, CDMA

I will scrub for that.  These particular terms though are usually not expanded in documents that I recall.

> It might help to cite a document that provides further information and to supports the statements you have made. 

I'll see what I can find for references.

At a minimum, I agree that some context should be placed there around the growing proportion of smartphones and their impact.  This is expository and is just intended to convey an example cause of overload that is getting worse over time.

> Just saying it "scales" is not really useful.

okay

> As mentioned on the mailing list this is hard to accomplish. Consider the following case:

Perhaps saying that the mechanism must allow elements to ensure fair behavior or provide means to do so would be better.  The mechanism must not preclude fair behavior.  In this case, the server (or the agent) could throttle traffic from client 2.

> I am not sure what you are trying to express with REQ 30. Lacking e2e security in Diameter all you can do is to trust your neighboring nodes (which you hopefully have authenticated). 

yes, lack of e2e security is an issue.  Hop-by-hop authentication helps, but would not protect from a middle box relaying malicious information.  You could also, for example, control what scope of overload is acceptable from any given source, to minimize impacts.  The point of this was to ensure that this was considered for any mechanism.

> Are you concerned about replay attacks by Diameter nodes, by on-path attackers (who are not Diameter nodes), or by off-path attackers? 

is there a reason to be specific here?

> Reading through the entire document there is one aspect unclear to me: How do you want to support the exchange of overload information between non-neighboring nodes (particularly when some intermed…

I'm not sure I fully understand your question, but I'll take a stab.  I think the general point is around middle boxes that do no support the mechanism.  This is tricky, because clients may not be aware of any specifics behind middle boxes.  In the case of a load balancer, for example, a client may be unaware that there are multiple servers.  If it exchanged overload information with one server behind the load balancer, would that information be valid for all of the other servers?  I think the requirement here is that it would be, or that the middle box would be responsible for it.  In general, anything reporting overload information for a particular scope needs to be authoritative for that scope.  We were trying to capture that in the requirements in a way that did not force a particular mechanism.

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 15 Jan 2013 10:46:48 +0200

Hi Eric, 

thanks for your quick response. 

> okay in general.  I'd rather not reference a draft if it can be avoided.

As informative references drafts are unproblematic. 

> I see two comments here; break up the paragraph, and use a SIP example instead of the 802.11 example.  right?

Particularly the reference to 802.11 does not seem too realistic since WLAN deployments mostly use RADIUS. 

> That said, this was in the document to show some history and how the original thinking and planned usages have not matched where things ended up, and is not integral to the document.  If it is caus…
To focus on the specific sentences:

" 
      Diameter depends heavily on the "Authentication, Authorization,
      and Accounting (AAA) Transport Profile" [RFC3539],
"

I would write: "The Transport Profile document [RFC3539] discusses transport layer
   issues that arise with AAA protocols and recommendations on how to
   overcome these issues. "
"
 which states
      assumptions about the scale of AAA services which may be incorrect
      for current uses of Diameter.
"

I don't see those assumptions. The entire document is only focused on discussing different issues. 

"
  In particular, the document
      suggests that AAA services will typically be low volume and that
      traffic will typically be application-driven.
"

I don't see this assumption of low volume. 

"
  Section 2.1 of that

I would write: 

      "Diameter is
      users."
> The intended extensibility was broader.  I recall that this was added to address a question on one of the requirements at some point.  It looks like we should have put a bit more in it.  I'll broad…
Thanks. 

> I think swapping that with section 3 would be reasonable.  It was after section 2 so that there was some context to talk about why the existing mechanisms were not sufficient.  Putting it before th…

I personally think that Section 4 could come after Section 2 since the scenarios just try to illustrate new features that should be supported. 

> I'm not sure I agree with this.  If I were reading it on a first pass I think I would appreciate the summary.  The same concepts are repeated and expanded in the subsections, but I don't think the…

For long and complex text it makes sense to summarize but in this case neither is true. 

> I will scrub for that.  These particular terms though are usually not expanded in documents that I recall.
Here is a list of abbreviations the RFC editor has collected:
http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt

> is there a reason to be specific here?

It depends what your concerns are and how they impact the solution. If there is just some text to say that the authors have addressed security in the document then it does not matter. 

For cases where non-Diameter nodes act as adversaries there is a solution in Diameter. That's good. For those cases where Diameter nodes act maliciously there is a problem (which you will not be able to fix). 

> I'm not sure I fully understand your question, but I'll take a stab.  I think the general point is around middle boxes that do no support the mechanism.  This is tricky, because clients may not be…

I was hoping to read from the requirement whether a hop-by-hop approach or an end-to-end approach is better. 

Ciao
Hannes

---

From: Eric McMurry <[email-masked]>
Date: Tue, 15 Jan 2013 15:00:22 -0600

Hi Hannes,

Thanks for the additional clarification.  Responses inline.

Eric

> As informative references drafts are unproblematic. 

okay.  In this case though, I don't think we referenced that for the requirements.  That one is more useful for drawing from for mechanism.

okay

>      typical client could be a packet gateway that serves millions of

The need for this paragraph has probably passed.  I'm thinking deleting it would be the best course.  I'll remove this from the submission I'm about to make, but I can add it back if folks disagree.

[...]

> http://www.rfc-editor.org/rfc-style-guide/abbrev.expansion.txt

saw that.  I expanded the acronyms.  thanks for catching.

[...]

> For cases where non-Diameter nodes act as adversaries there is a solution in Diameter. That's good. For those cases where Diameter nodes act maliciously there is a problem (which you will not be ab…

I think for the requirements, we're just saying that it should be considered.  I agree that a Diameter node can cause issues that are not fixable, but the scope of potential damage can still be controlled.

> I was hoping to read from the requirement whether a hop-by-hop approach or an end-to-end approach is better. 

We didn't think the requirements should specify that.  Mechanisms could be done either way.