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

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
ecnoel@att.com

-----Original Message-----
From: NOEL, ERIC C (ERIC C) 
Sent: Thursday, April 05, 2012 5:24 PM
To: 'Volker Hilt'; sip-overload@ietf.org
Cc: 'phil.m.williams@bt.com'; jgunn6@csc.com
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
ecnoel@att.com

-----Original Message-----
From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] On Behalf Of Volker Hilt
Sent: Tuesday, March 27, 2012 1:23 PM
To: sip-overload@ietf.org
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.:

    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?

- 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
sip-overload@ietf.org
https://www.ietf.org/mailman/listinfo/sip-overload