Subject: [sip-overload] comments on draft-ietf-soc-overload-rate-control-01

From: Janet P Gunn <[email-masked]>
Date: Tue, 1 May 2012 16:02:02 -0400

These are largely editorial comments.

Sec 1
Change
  More importantly, a loss-based control cannot guarantee clients to
   produce a bounded offered load towards an overloaded server and
   requires frequent updates which may have implications for stability.
To
  More importantly, a loss-based control cannot guarantee an upper 
  bound on the offered load  from the clients towards an overloaded 
  server. It also requires frequent updates which may have implications 
  for stability.

Change 
   This document proposes extensions to [draft-ietf-soc-overload-
   control-07] so as to support a rate-based control that guarantees
   clients produce a limited upper bound to the Invite rate towards an
   overloaded server, which is constant between server updates.
To
   This document proposes extensions to [draft-ietf-soc-overload-
   control-07] to support a rate-based control that guarantees
  an upper bound on the rate, constant between server updates, of Invites 
 sent by clients towards an  overloaded server.

Also, do you really mean “Invite”, as opposed to “request”?

Change
  The  penalty for such a benefit is in terms of algorithmic complexity,
   since the overloaded server must estimate a target offered load and
   allocate a portion to each conversing client.
To
  The  tradeoff is in terms of algorithmic complexity,   since the 
overloaded 
  server must estimate a separate target for each client, rather 
  than an overall loss percentage, equally applicable to all clients.

Change
The proposed rate-based overload control algorithm mitigates
   congestion in SIP networks while adhering to the overload signaling
   scheme in [draft-ietf-soc-overload-control-07] and proposing a rate
   control in addition to the default loss-based control in [draft-
   ietf-soc-overload-control-07].
To
The proposed rate-based overload control algorithm mitigates
   congestion in SIP networks while adhering to the overload signaling
   scheme in [draft-ietf-soc-overload-control-07] and presenting a rate 
based
   control as an optional alternative  to the default loss-based control 
in [draft-
   ietf-soc-overload-control-07].

Sec 2

If, for instance, only a SIP
   client supports this specification and not the SIP server,

This doesn’t seem to be a very useful “for instance”, since the  non- 
supporting server won’t be sending any oc parameters to the supporting 
client.

The more interesting “for instance” is when the SIP server supports it and 
the SIP client doesn’t.

Sec 3.2 still needs to be fleshed out

Sec 3.3 
Suggest changing 
Per [draft-ietf-soc-overload-control-07], new clients indicate
   supported overload control algorithms to servers by inserting oc and
   oc-algo in Via header of SIP requests destined to servers.  While
   servers notify clients of selected overload control algorithm
   through the oc-algo parameter in the Via header of SIP responses to
   clients

   Support of rate-based control MUST be indicated by clients and
   servers by setting oc-algo to "rate".

To
   Per [draft-ietf-soc-overload-control-07], new clients indicate
   supported overload control algorithms to servers by inserting oc and
   oc-alg, with the names of the supported algorithms,  in Via header of 
SIP requests destined to servers. 
   The inclusion by the client of the string “rate” indicates that the 
client supports  a rate based algorithm
  Conversely,
   servers notify clients of selected overload control algorithm
   through the oc-algo parameter in the Via header of SIP responses to
   clients.  The inclusion by the server of the string “rate” indicates 
that the rate based algorithm has 
   been selected by the server.

   Support of rate-based control MUST be indicated by clients  setting 
oc-algo to "rate". Selection of  rate-based control MUST be indicated by 
servers setting oc-algo to "rate".

Sec 3.4
Add to second paragraph
The server may set the same rate for every  client, or may set a different 
rates for different clients

Third paragraph, first sentence
Change
… even though it  may only affect a particular subset … 
to 
… even though throttling   may only affect a particular subset …

Change
…since as per [draft-ietf-soc-
   overload-control-07], request prioritization is the client
   responsibility.
To
… since as per [draft-ietf-soc-
   overload-control-07],  and REQ 13 of RFC 5390, request prioritization 
is the client
   responsibility.
And add RFC  5390 to the normative references.

Last sentence of third para
Change
But when deriving this rate the server may need to
   take into account the effect of the client prioritization on the
   load it receives, e.g. CPU utilization will depend upon the
   characteristics of the requests.
To
But when deriving this rate the server may need to
   take into account  characteristics of the requests, and 
the effect of the client prioritization on the
   load it receives, e.g. the average CPU utilization  per request  under 
overload
 control may be different from the average CPU utilization under 
non-overloaded conditions

4th para
Note that the target SIP request rate is a max rate that may not be
   attained by the arrival rate at the client, and the server cannot
   assume that it will.
To
Note that the target SIP request rate is an upper bound on the rate the 
client may send requests to the server.  In many cases, the client will 
send messages at a lower rate.

5th para
Upon detection of overload, the server MUST follow the
   specifications in [draft-ietf-soc-overload-control-07] to notify its
   clients of its overload state and of the allocated target SIP
   request rate.
To
Upon detection of overload, the server MUST follow the
   specifications in [draft-ietf-soc-overload-control-07] to notify its
   clients of the allocated target SIP   request rate.

5th para
Change
   The server MUST use [draft-ietf-soc-overload-control-07] oc
   Parameter … to each of its client.
To
   The server MUST use the [draft-ietf-soc-overload-control-07] oc
   Parameter … to each of its clients. (or “to each client”)

Sec 3.5.1, 3.5.2 -  no comments because I know you are rewriting that to 
include pseudocode.

Janet

---

From: "NOEL, ERIC C (ERIC C)" <[email-masked]>
Date: Wed, 2 May 2012 09:39:30 -0400

Volker,

Phil, Janet and I worked out the following response to provide better clarification on the meaning of Tau, Tau1 and Tau2:

The tolerance parameter Tau determines how close the long-term admitted rate is to an ideal control that would admit all SIP requests for arrival rates less than 1/T and then admit SIP requests precisely rate at 1/T for arrival rates above 1/T. In particular at mean arrival rates close to 1/T, it determines the tolerance to deviation of the inter-arrival time from T (the larger Tau the more tolerance to deviations from the inter-departure interval T).  

This deviation from the inter-departure interval influences the admitted rate burstyness, or the number consecutive SIP requests forwarded to the SIP server (burst size proportional to Tau over the difference between 1/T and the arrival rate).

SIP servers with a very large number of clients, each with a relatively small arrival rate, will generally benefit from a smaller value for Tau in order to limit queuing (and hence response times) at the server when subjected to a sudden surge of traffic from all clients.  Conversely, a SIP server with a relatively small number of clients, each with proportionally larger arrival rate, will benefit from a larger value of Tau.

With a priority scheme that relies on two tolerance parameters (Tau2 influences the priority traffic, Tau1 influences the non-priority traffic), always set Tau1 <= Tau2 (Tau is replaced by Tau1 and Tau2).  Setting both tolerance parameters to the same value is equivalent to having no priority. Tau1 influences the admitted rate the same way as Tau does when no priority are set. And the larger the difference between Tau1 and Tau2, the closer to the control is to strict priority.

Tau (or Tau1 and Tau2) can assume any positive real number value and is not necessarily bounded by T.   
  
Then for the pseudo code (C-like syntax):

Pseudo code (no priority case): 
    
    // T: emission interval, set to 1 / TargetRate 
    // tau:  tolerance parameter 
    // t_a: arrival time of last arrival 
   // LCT:  arrival time of last conforming SIP request (initialized to the first arrival time) 
   // X: current value of leaky bucket counter (initialized to 0) 
   
   // After first arrival, calculate auxiliary variable Xp 
    Xp = X - (t_a - LCT); 
     
    if (Xp <= tau) {   
      // Accept SIP request 
     // Update X and LCT       
      X = max(0,Xp) + T;       
      LCT = t_a; 
    } else { 
      // Reject SIP request 
      // Do not update X and LCT     
    } 
     
Pseudo code (priority case): 
   
    // T: emission interval, set to 1 / TargetRate 
    // tau1:  tolerance parameter of no priority SIP requests 
    // tau2:  tolerance parameter of priority SIP requests 
    // t_a: arrival time of last arrival 
   // LCT:  arrival time of last conforming SIP request (initialized to the first arrival time) 
   // X: current value of leaky bucket counter (initialized to 0) 
   
   // After first arrival, calculate auxiliary variable Xp 
    Xp = X - (t_a - LCT); 
     
  if (AnyRequestReceived && Xp <= tau1 || PriorityRequestReceived && Xp <= tau2 && Xp > tau1) { 
      // Accept SIP request 
     // Update X and LCT       
      X = max(0,Xp) + T; 
      LCT = t_a; 
    } else { 
      // Reject SIP request 
      // Do not update X and LCT     
    }

Note that we intend to update our contribution with the above text.

Additional comments and/or suggestions are welcome.

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]

-----Original Message-----
From: NOEL, ERIC C (ERIC C) 
Sent: Thursday, April 05, 2012 5:24 PM
To: 'Volker Hilt'; [email-masked]
Cc: [email-masked]'; [email-masked]
Subject: RE: [sip-overload] comments on draft-ietf-soc-overload-rate-control-01

Volker,

Apologies for the delayed response.  Phil is away and could not provide input to below, and I am about to go away as well. So I am giving you partial responses which I will complete upon my return. Janet also provided some input in below.

- Section 3.4.:
   But when deriving this rate the server may need to
   take into account the effect of the client prioritization on the
   load it receives, e.g. CPU utilization will depend upon the
   characteristics of the requests.
How should the server take the client prioritization into account? Does the server need to know the prioritization made by the client?
[EN/JG] The server does not know the client(s) prioritization rules, but it could account for it implicitly  by relying on a resource measure such as the average CPU load per request due to the particular request stream mix resulting from the client's admission control.  Using this measure would allow the server to take into account the client prioritization.  

- Section 3.5.:
What is the adjusted-oc-value? Is this the value received in the oc parameter? How will it be adjusted?
[EN/JG] The parameter "adjusted-oc-value" is a typo, should be "oc-value". Will be changed in the next version.

How should the values TAU1 and TAU2 be set with respect to the overall TAU? Can you give guidance on how they should be chosen? What will they depend on?
[EN/JG] Putting together a small model to produce guidance on parameter selection. 

It would be very helpful to have a pseudo-code algorithm for rate based controls. This will make the description in this section easier to understand.
[EN/JG] Will be added in next version.

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]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Volker Hilt
Sent: Tuesday, March 27, 2012 1:23 PM
To: [email-masked]
Subject: [sip-overload] comments on draft-ietf-soc-overload-rate-control-01

Eric, Phil,

here are a few comments on draft-ietf-soc-overload-rate-control-01:

- Section 3.4.:

How should the server take the client prioritization into account? Does the server need to know the prioritization made by the client?

- Section 3.5.:

What is the adjusted-oc-value? Is this the value received in the oc parameter? How will it be adjusted?

How should the values TAU1 and TAU2 be set with respect to the overall TAU? Can you give guidance on how they should be chosen? What will they depend on?

It would be very helpful to have a pseudo-code algorithm for rate based controls. This will make the description in this section easier to understand.

Thanks,

Volker

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

---

From: "NOEL, ERIC C (ERIC C)" <[email-masked]>
Date: Mon, 7 May 2012 10:00:38 -0400

Janet,

Thanks for your comments. Please see below our response.

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 Janet P Gunn
Sent: Tuesday, May 01, 2012 4:02 PM
To: [email-masked]
Subject: [sip-overload] comments on draft-ietf-soc-overload-rate-control-01

Sec 1
Change
> OK

Change

>OK, will also change “Invites” to “requests”.

Change
  The  tradeoff is in terms of algorithmic complexity,   since the overloaded
>OK

Change
The proposed rate-based overload control algorithm mitigates
   congestion in SIP networks while adhering to the overload signaling
   scheme in [draft-ietf-soc-overload-control-07] and proposing a rate
   control in addition to the default loss-based control in [draft-
   ietf-soc-overload-control-07].
To
The proposed rate-based overload control algorithm mitigates
   congestion in SIP networks while adhering to the overload signaling
   scheme in [draft-ietf-soc-overload-control-07] and presenting a rate based
   control as an optional alternative  to the default loss-based control in [draft-
   ietf-soc-overload-control-07].
>OK

Sec 2

This doesn’t seem to be a very useful “for instance”, since the  non- supporting server won’t be sending any oc parameters to the supporting client.

The more interesting “for instance” is when the SIP server supports it and the SIP client doesn’t.
>Please note this paragraph is identical to that in draft-ietf-soc-overload-control-08. We rather keep as is until draft-ietf-soc-overload-control-08 gets modified.

>Will be addressed in next version.

Sec 3.3
Suggest changing

To
   Per [draft-ietf-soc-overload-control-07], new clients indicate
   supported overload control algorithms to servers by inserting oc and
   oc-alg, with the names of the supported algorithms,  in Via header of SIP requests destined to servers.
   The inclusion by the client of the string “rate” indicates that the client supports  a rate based algorithm
  Conversely,
   servers notify clients of selected overload control algorithm
   through the oc-algo parameter in the Via header of SIP responses to
   clients.  The inclusion by the server of the string “rate” indicates that the rate based algorithm has
   been selected by the server.

   Support of rate-based control MUST be indicated by clients  setting oc-algo to "rate". Selection of  rate-based control MUST be indicated by servers setting oc-algo to "rate".
>OK

Sec 3.4
Add to second paragraph
The server may set the same rate for every  client, or may set a different rates for different clients
>OK

>OK

Change
   overload-control-07],  and REQ 13 of RFC 5390, request prioritization is the client
>OK

Last sentence of third para
Change
But when deriving this rate the server may need to
   take into account the effect of the client prioritization on the
   load it receives, e.g. CPU utilization will depend upon the
   characteristics of the requests.
To
But when deriving this rate the server may need to
   take into account  characteristics of the requests, and
the effect of the client prioritization on the
   load it receives, e.g. the average CPU utilization  per request  under overload
 control may be different from the average CPU utilization under non-overloaded conditions
>OK

4th para
Note that the target SIP request rate is a max rate that may not be
   attained by the arrival rate at the client, and the server cannot
   assume that it will.
To
Note that the target SIP request rate is an upper bound on the rate the client may send requests to the server.  In many cases, the client will send messages at a lower rate.
> Suggested writing is different than original paragraph meaning. Originally that paragraph stated the server should not assume the arrival rate at client will exceed the server target rate. Your suggested change does away with the observation on the arrival rate at client and focuses on the arrival rate presented by the client to the server.
Was that the intent?

5th para
>OK

5th para
Change
>OK

Sec 3.5.1, 3.5.2 -  no comments because I know you are rewriting that to include pseudocode.
>OK. Pseudo code will be added in next version.

Janet

From: [email-masked] [mailto:[email-masked]] On Behalf Of Janet P Gunn
Sent: Tuesday, May 01, 2012 4:02 PM
To: [email-masked]
Subject: [sip-overload] comments on draft-ietf-soc-overload-rate-control-01

Sec 1
Change

Change

Change
  The  tradeoff is in terms of algorithmic complexity,   since the overloaded

Change
The proposed rate-based overload control algorithm mitigates
   congestion in SIP networks while adhering to the overload signaling
   scheme in [draft-ietf-soc-overload-control-07] and proposing a rate
   control in addition to the default loss-based control in [draft-
   ietf-soc-overload-control-07].
To
The proposed rate-based overload control algorithm mitigates
   congestion in SIP networks while adhering to the overload signaling
   scheme in [draft-ietf-soc-overload-control-07] and presenting a rate based
   control as an optional alternative  to the default loss-based control in [draft-
   ietf-soc-overload-control-07].

Sec 2

This doesn’t seem to be a very useful “for instance”, since the  non- supporting server won’t be sending any oc parameters to the supporting client.

The more interesting “for instance” is when the SIP server supports it and the SIP client doesn’t.

Sec 3.3
Suggest changing

To
   Per [draft-ietf-soc-overload-control-07], new clients indicate
   supported overload control algorithms to servers by inserting oc and
   oc-alg, with the names of the supported algorithms,  in Via header of SIP requests destined to servers.
   The inclusion by the client of the string “rate” indicates that the client supports  a rate based algorithm
  Conversely,
   servers notify clients of selected overload control algorithm
   through the oc-algo parameter in the Via header of SIP responses to
   clients.  The inclusion by the server of the string “rate” indicates that the rate based algorithm has
   been selected by the server.

   Support of rate-based control MUST be indicated by clients  setting oc-algo to "rate". Selection of  rate-based control MUST be indicated by servers setting oc-algo to "rate".

Sec 3.4
Add to second paragraph
The server may set the same rate for every  client, or may set a different rates for different clients

Change
   overload-control-07],  and REQ 13 of RFC 5390, request prioritization is the client

Last sentence of third para
Change
But when deriving this rate the server may need to
   take into account the effect of the client prioritization on the
   load it receives, e.g. CPU utilization will depend upon the
   characteristics of the requests.
To
But when deriving this rate the server may need to
   take into account  characteristics of the requests, and
the effect of the client prioritization on the
   load it receives, e.g. the average CPU utilization  per request  under overload
 control may be different from the average CPU utilization under non-overloaded conditions

4th para
Note that the target SIP request rate is a max rate that may not be
   attained by the arrival rate at the client, and the server cannot
   assume that it will.
To
Note that the target SIP request rate is an upper bound on the rate the client may send requests to the server.  In many cases, the client will send messages at a lower rate.

5th para

5th para
Change

Sec 3.5.1, 3.5.2 -  no comments because I know you are rewriting that to include pseudocode.

Janet

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 7 May 2012 11:06:00 -0400

From:   "NOEL, ERIC C (ERIC C)" <[email-masked]>
To:     Janet P Gunn/USA/CSC@CSC, "[email-masked]" 
<[email-masked]>
Date:   05/07/2012 10:01 AM
Subject:        RE: [sip-overload] comments on 
draft-ietf-soc-overload-rate-control-01

Janet,

Thanks,
 
Eric Noel 
AT&T Labs, Inc. 
Rethink Possible

...

Sec 3.4 
...
 
4th para 
> Suggested writing is different than original paragraph meaning. 
Originally that paragraph stated the server should not assume the arrival 
rate at client will exceed the server target rate. Your suggested change 
does away with the observation on the arrival rate at client and focuses 
on the arrival rate presented by the client to the server. 
Was that the intent?

[JPG] I guess I am confused.  Why would the server care what  the arrival 
rate at the client is?  Why would the server assume that the arrival rate 
at the client ( which may be distributed among many different servers) 
would, or would not, be bigger that the server target rate?

Janet

---

From: "NOEL, ERIC C (ERIC C)" <[email-masked]>
Date: Tue, 22 May 2012 09:25:34 -0400

Janet,

Thanks for your follow-up comment.

==================
4th para
Was that the intent?

[JPG] I guess I am confused.  Why would the server care what  the arrival rate at the client is?  Why would the server assume that the arrival rate at the client ( which may be distributed among many different servers) would, or would not, be bigger that the server target rate?
===================

Another interpretation of the contentious paragraph is that because the client Leaky Bucket will not throttle offered load below the target SIP request rate, the server does not need to make any immediate adjustments for such situations. This is in contrast with percent blocking where blocking is applied by clients whether or not the offered load presented to clients is below the server overload limit.

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

From: Janet P Gunn [mailto:[email-masked]]
Sent: Monday, May 07, 2012 11:06 AM
To: NOEL, ERIC C (ERIC C)
Cc: [email-masked]
Subject: RE: [sip-overload] comments on draft-ietf-soc-overload-rate-control-01

From:        "NOEL, ERIC C (ERIC C)" <[email-masked]<mailto:[email-masked]>>
To:        Janet P Gunn/USA/CSC@CSC, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date:        05/07/2012 10:01 AM
Subject:        RE: [sip-overload] comments on draft-ietf-soc-overload-rate-control-01
________________________________

Janet,

Thanks,

Eric Noel
AT&T Labs, Inc.
Rethink Possible

Sec 3.4
...

4th para
Was that the intent?

[JPG] I guess I am confused.  Why would the server care what  the arrival rate at the client is?  Why would the server assume that the arrival rate at the client ( which may be distributed among many different servers) would, or would not, be bigger that the server target rate?

Janet