Subject: [Dime] New Version Notification for draft-roach-dime-overload-ctrl-01.txt

From: Adam Roach <[email-masked]>
Date: Mon, 22 Oct 2012 16:52:28 -0500

DIME working group:

I have submitted a new version of the Diameter Overload document, based 
on early feedback on the -00 version. Please use the "Diff" link, below, 
for a comprehensive accounting of differences. At a high level, the main 
changes are:

- Only one scope (Host) is mandatory any longer. Others are "SHOULD-level."
- Scope negotiation has been replaced by supported scope announcement. 
This allows for asymmetric scopes in a connection.
- "Host" scope has been renamed "Destination Host" scope to clarify that 
it does not refer to the sending host.
- A new "Appendix D" has been added to discuss some of the design 
tradeoffs currently present in the document.

I plan to discuss this -01 version during the upcoming meeting in Atlanta.

Thanks!

/a

-------- Original Message --------
Subject: 	New Version Notification for 
draft-roach-dime-overload-ctrl-01.txt
Date: 	Mon, 22 Oct 2012 14:42:56 -0700
From: 	[email-masked]
To: 	[email-masked]

A new version of I-D, draft-roach-dime-overload-ctrl-01.txt
has been successfully submitted by Adam Roach and posted to the
IETF repository.

Filename:	 draft-roach-dime-overload-ctrl
Revision:	 01
Title:		 A Mechanism for Diameter Overload Control
Creation date:	 2012-10-22
WG ID:		 Individual Submission
Number of pages: 38
URL:             http://www.ietf.org/internet-drafts/draft-roach-dime-overload-ctrl-01.txt
Status:          http://datatracker.ietf.org/doc/draft-roach-dime-overload-ctrl
Htmlized:        http://tools.ietf.org/html/draft-roach-dime-overload-ctrl-01
Diff:            http://www.ietf.org/rfcdiff?url2=draft-roach-dime-overload-ctrl-01

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 or stop sending traffic for some period of time.  Otherwise,
    it must continue to expend resources parsing and responding to
    Diameter messages.

    This document proposes a concrete, application-independent mechanism
    to address the challenge of communicating load and overload state
    among Diameter peers, and specifies an algorithm for load abatement
    to address such overload conditions as they occur.  The load
    abatement algorithm is extensible, allowing for future documents to
    define additional load abatement approaches.

The IETF Secretariat

---

From: "NOEL, ERIC C (ERIC C)" <[email-masked]>
Date: Fri, 26 Oct 2012 09:47:28 -0400

Adam,

Please find below a few comments on draft-roach-dime-overload-ctrl-01.txt:

- Section 3.2.1, 4th paragraph:
“The sending node then sends, drops, queues, or otherwise…”  Queueing of requests by clients while a server is in overload is probably not a good option as it could likely result in oscillations and/or staled requests.  I would recommend excluding the queueing option.

- Section 3.2.3:
For the case a client is never expected to receive requests from its server, including Load-Info AVP in the outgoing request does not seem to have any value. Moreover, in situations where a server is in overload, clients should not include Load-Info AVP in their requests so as to minimize overhead on the overloaded server.

- Section 3.6.1:
“…which does not correspond to an existing Diameter construct…” How does a Diameter construct differ from the overload scope defined in section 2? Is that identical?

- Section 4.2, pseudo-code, case outbound request:
“Determine if server wants to enter in overload or is in overload” How would a request sender determine whether or not a server wants to enter in overload? From the Load-Info AVPs sent by servers, the request sender can only determine whether or not the server is in overload, not the server overload intent. Please clarify.

- Section 4.2, pseudo-code, case inbound request:
When a server in overload receives requests from compliant clients, it is possible that the server still needs to reject some of these requests based its internal protective mechanisms.  This could correspond to the situation where a sudden increase in offered load, filtered by clients at the current Overload-Metric AVP (loss), exceeds the server internal protective mechanisms until the server refreshes the Overload-Metric AVP.
I assume this case is accounted for in the function “process_msg”. Should this be mentioned anywhere in the contribution or is that too obvious?

- Section 8.2:
In the references, please add “draft-ietf-soc-overload-rate-control-03.txt”. That contribution proposes a rate control algorithm as an alternative to the loss control algorithm within SIP context.

Typos:

-  Section 3.2.1, 5th paragraph:
“The authors….” since only one author, probably better to be singular.

- Section 3.2.4:
“A node that receives a answer…” replace “a “with “an”

- Section 3.3, 2nd paragraph:
“…reflecting the a Agent’s overload…” replace “a” with “an”

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Network Design and Performance Analysis
200 South Laurel Avenue, D5-3D19
Middletown, NJ 07748
P: 732.420.4174
[email-masked]<mailto:[email-masked]>

From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Roach
Sent: Monday, October 22, 2012 5:52 PM
To: DIME (Diameter Maintenance and Extensions) WG
Subject: [Dime] New Version Notification for draft-roach-dime-overload-ctrl-01.txt

DIME working group:

I have submitted a new version of the Diameter Overload document, based on early feedback on the -00 version. Please use the "Diff" link, below, for a comprehensive accounting of differences. At a high level, the main changes are:

- Only one scope (Host) is mandatory any longer. Others are "SHOULD-level."
- Scope negotiation has been replaced by supported scope announcement. This allows for asymmetric scopes in a connection.
- "Host" scope has been renamed "Destination Host" scope to clarify that it does not refer to the sending host.
- A new "Appendix D" has been added to discuss some of the design tradeoffs currently present in the document.

Thanks!

/a

-------- Original Message --------
Subject:

New Version Notification for draft-roach-dime-overload-ctrl-01.txt

Date:

Mon, 22 Oct 2012 14:42:56 -0700

From:

[email-masked]<mailto:[email-masked]>

To:

[email-masked]<mailto:[email-masked]>

IETF repository.

Revision:       01

Number of pages: 38

Abstract:

   Diameter messages.

The IETF Secretariat

---

From: Adam Roach <[email-masked]>
Date: Mon, 29 Oct 2012 17:27:57 -0500

> Please find below a few comments on draft-roach-dime-overload-ctrl-01.txt:

Thanks for the review!

> “The sending node then sends, drops, queues, or otherwise…”  Queueing 
> of requests by clients while a server is in overload is probably not a 
> good option as it could likely result in oscillations and/or staled 
> requests.  I would recommend excluding the queueing option.
>

That sounds reasonable; I've removed it from my -02 draft.

> - Section 3.2.3:
>
> For the case a client is never expected to receive requests from its 
> server, including Load-Info AVP in the outgoing request does not seem 
> to have any value.
>

That does seem reasonable. I'll put it on the slides for Atlanta to see 
if anyone objects to removing the requirement in such a case.

> Moreover, in situations where a server is in overload, clients should 
> not include Load-Info AVP in their requests so as to minimize overhead 
> on the overloaded server.
>

I'm not sure I agree -- in high traffic situations, it doesn't seem 
unreasonable that you would have multiple nodes getting busy 
simultaneously. It would seem dangerous to disable the client's ability 
to signal overload in the case that the server it is communicating with 
is overloaded.

Keep in mind that the server doesn't actually need to process each and 
every Load-Info AVP it receives, as long as the 'O'verload bit is clear 
-- which means that the overhead you're talking about is extremely 
minimal (limited to stripping off an AVP when messages arrive).

> - Section 3.6.1:
>
> “…which does not correspond to an existing Diameter construct…” How 
> does a Diameter construct differ from the overload scope defined in 
> section 2? Is that identical?
>

I meant "construct" as in the plain English meaning of that noun. You 
can substitute "thing" if you'd like, but that didn't seem appropriate 
for the tone of the document.

Each of the scopes is a Diameter thing: a thing defined within the 
Diameter specification itself. There might be some things that we've 
missed, or that will be defined in the future, that are candidates for 
becoming scopes in future overload-related specifications. So, to answer 
your question directly: each of the overload scopes in section 2 
corresponds to a Diameter thing (construct), but there might be things 
-- either now or at some point in the future -- that are not covered by 
those scopes.

> “Determine if server wants to enter in overload or is in overload” How 
> would a request sender determine whether or not a server wants to 
> enter in overload? From the Load-Info AVPs sent by servers, the 
> request sender can only determine whether or not the server is in 
> overload, not the server overload intent. Please clarify.
>

The comment comes directly from the SOC document, so I'd have to check 
with Vijay to be certain; however, my interpretation is "check the 
context, which will contain overload information gleaned from the 
immediately preceding message (server wants to enter overload) or a 
prior message for which the period of validity is still in effect 
(server is in overload)." If you think there is a clearer way to say 
this, I'd be happy to see a concrete proposal.

> When a server in overload receives requests from compliant clients, it 
> is possible that the server still needs to reject some of these 
> requests based its internal protective mechanisms.  This could 
> correspond to the situation where a sudden increase in offered load, 
> filtered by clients at the current Overload-Metric AVP (loss), exceeds 
> the server internal protective mechanisms until the server refreshes 
> the Overload-Metric AVP.
>
> I assume this case is accounted for in the function “process_msg”. 
> Should this be mentioned anywhere in the contribution or is that too 
> obvious?
>

I believe that such rejections would generally be encompassed in 
"process_msg." I'm not sure the pseudocode needs to change, but it's 
probably worthwhile to add text to add text to 3.2.2.1 indicating that 
message recipients might need to reject messages from compliant hosts in 
the case that their load it too high despite use of the mechanism:

               In some circumstances, request recipients can
               become sufficiently overloaded that even those
               messages received from complaint clients can
               overwhelm its processing capabilities. Under
               such circumstances, nodes MAY begin treating
               a subset of such requests as if they were
               received from noncompliant peers (as explained
               in the following section).

> - Section 8.2:
>
> In the references, please add 
> “draft-ietf-soc-overload-rate-control-03.txt”. That contribution 
> proposes a rate control algorithm as an alternative to the loss 
> control algorithm within SIP context.
>

Sure.

> “The authors….” since only one author, probably better to be singular.

This was just a bit of forward-leaning on my part, as I expect to have 
one or more co-authors prior to the document being final.

> “A node that receives a answer…” replace “a “with “an”

Thanks.

> “…reflecting the a Agent’s overload…” replace “a” with “an”

Fixed. Thank you.

/a

---

From: Janet P Gunn <[email-masked]>
Date: Tue, 30 Oct 2012 11:32:39 -0400

First, I have to say that, while I am very familiar with the SIP Overload 
Control work, I am not as familiar with Diameter, so forgive me if some of 
my comments are simply reflections of that ignorance.

You say here
 "- Only one scope (Host) is mandatory any longer. Others are 
"SHOULD-level."
...
- "Host" scope has been renamed "Destination Host" scope to clarify that 
it does not refer to the sending host."

But the text of  draft-roach-dime-overload-ctrl-01 says
"
   Destination-Host:  This scope, which nodes SHOULD implement, pertains
         to all transactions that have a Destination-Host AVP matching
         the indicated value.
 Host: This scope, which nodes SHOULD implement, pertains to all
         transactions sent directly to the host matching the indicated
         value.
   Connection:  This scope, which nodes MUST implement, pertains to all
         transactions sent on the same TCP connection or SCTP
         association.  This scope has no details indicating which
         connection or association it applies to; instead, the recipient
         of an indication of "Connection" scope is to use the connection
         or association on which the message was received as the
         indicated connection or association.  In other words, any use
         of Connection scope applies to "this connection." "

I read that as "Connection" scope is mandatory and both "Destination-Host" 
and  "Host" are at the "SHOULD-level"

I don't have a preference, I am just confused.

Second comment, in 2.2 on combining Scopes, you say
"   o  If a transaction falls within more than one scope, the "most
      overloaded" scope is used for traffic shaping."

If one scope is using the loss algorithm and is asking for a 10% 
reduction, and the other scope uses the rate algorithm, and is asking for 
a max of 100 messages per second, which is "more overloaded"?

Even if one is asking for 10% reduction and the other is asking for 15% 
reduction, the one asking for 15% isn't necessarily "more overloaded", it 
may just have a more aggressive  approach to overload control.

It seems to me it makes more sense to say something like
   o  If a transaction falls within more than one scope, the scope which 
will result in the greatest traffic reduction  is used for traffic 
shaping.

Janet

From:   Adam Roach <[email-masked]>
To:     "DIME (Diameter Maintenance and Extensions) WG" <[email-masked]>
Date:   10/22/2012 05:52 PM
Subject:        [Dime] New Version Notification for 
draft-roach-dime-overload-ctrl-01.txt
Sent by:        [email-masked]

DIME working group:

I have submitted a new version of the Diameter Overload document, based on 
early feedback on the -00 version. Please use the "Diff" link, below, for 
a comprehensive accounting of differences. At a high level, the main 
changes are:

- Only one scope (Host) is mandatory any longer. Others are 
"SHOULD-level."

Thanks!

/a

-------- Original Message -------- 
Subject: 
[email-masked]
To: 
[email-masked]

Filename:                 draft-roach-dime-overload-ctrl
Revision:                 01
Title:                            A Mechanism for Diameter Overload 
Control
Creation date:            2012-10-22
WG ID:                            Individual Submission
Number of pages: 38
URL:             
http://www.ietf.org/internet-drafts/draft-roach-dime-overload-ctrl-01.txt
Status:          
http://datatracker.ietf.org/doc/draft-roach-dime-overload-ctrl
Htmlized:        
http://tools.ietf.org/html/draft-roach-dime-overload-ctrl-01
Diff:            
http://www.ietf.org/rfcdiff?url2=draft-roach-dime-overload-ctrl-01

Abstract:

The IETF Secretariat

_______________________________________________
DiME mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dime