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

From: Volker Hilt <[email-masked]>
Date: Tue, 27 Mar 2012 17:37:06 +0200

Vijay, All,

here are a few comments on draft-ietf-soc-overload-control-08 Most of 
them are for clarification purposes:

- Section 4.2, second paragraph: the default value of the "oc-algo" 
parameter should be "loss". The draft currently specifies that that 
"loss" must be included but doesn't specify a default value for the 
parameter.

- Section 4.3: suggest to change the following paragraph:

    A SIP client MUST discard the "oc-validity" parameter if the client
    receives it in a response without the corresponding "oc" parameter
    being present as well.  A non-zero value for the "oc-validity"
    parameter MUST only be present in conjunction with an "oc" parameter.

to:

    A non-zero value for the "oc-validity"
    parameter MUST only be present in conjunction with an "oc"
    parameter.  A SIP client MUST discard a non-zero value of the
    "oc-validity" parameter if the client
    receives it in a response without the corresponding "oc" parameter
    being present as well.

-> clarifies the use of oc-validity

- Section 4.4: suggest to change the second paragraph:

    This parameter contains a value that indicates the sequence number
    associated with the "oc" parameter.  Some implementations may be
    capable of updating the overload control information before the
    validity period specified by the "oc-validity" parameter expires.
    Such implementations MUST have an increasing value in the "oc-seq"
    parameter for each response sent to the upstream SIP client.  This is
    to allow the upstream SIP client to properly collate out-of-order
    responses.

to:

    This parameter contains a value that indicates the sequence number
    associated with the "oc" parameter.  This sequence number is used to 
differentiate two "oc" parameter values generated by an overload control 
algorithm at two different instants in time. "oc" parameter values 
generated by an overload control algorithms at time t and t+1 MUST have 
an increasing value in the "oc-seq"
    parameter. This is
    to allow the upstream SIP client to properly collate out-of-order
    responses.

-> clarifies the use of the oc-seq parameter

- Section 5.2: suggest to change the fourth paragraph:

    A SIP server that has updated the "oc" parameter to Via header SHOULD
    also add a "oc-validity" parameter to the same Via header.  The "oc-
    validity" parameter defines the time in milliseconds during which the
    content (i.e., the overload control feedback) of the "oc" parameter
    is valid.  The default value of the "oc-validity" parameter is 500
    (millisecond).  A SIP server SHOULD specify an oc-validity time that
    is responsive to changing client originated traffic rates, but not
    too short as to introduce instability.  This is a complex subject and
    outside the scope of this specification.  If the "oc-validity"
    parameter is not present, its default value is used.  The "oc-
    validity" parameter MUST NOT be used in a Via header that did not
    originally contain an "oc" parameter when received.

to:

    A SIP server that has updated the "oc" parameter to Via header SHOULD
    also add a "oc-validity" parameter to the same Via header.  The "oc-
    validity" parameter defines the time in milliseconds during which the
    content (i.e., the overload control feedback) of the "oc" parameter
    is valid.  The default value of the "oc-validity" parameter is 500
    (millisecond).  A SIP server SHOULD specify an oc-validity time that
    prevents the "oc" value from timing out before the next response is 
received and allows clients to discard stale "oc" values if they have 
not communicated with a server for some time. If the "oc-validity"
    parameter is not present, its default value is used.  The "oc-
    validity" parameter MUST NOT be used in a Via header that did not
    originally contain an "oc" parameter when received.

-> I think this gives better guidance for selecting oc-validity values.

- Section 5.4: first paragraph:

Via headers that are forwarded by a client can contain empty "oc" 
parameters. In fact, this is needed for the negotiation and the "oc" 
parameter should not be removed by the client. If there is a parameter 
value, that value should be removed.

- Section 5.4: second paragraph:

The client also needs to maintain the oc-algo parameter value in the 
overload context for a downstream server. If the oc-algo changes, it 
will need to reset the client algorithm and start using the new algorithm.

- Section 6.2:

            SIP/2.0 100 Trying
            Via: SIP/2.0/TLS p1.example.net;
              branch=z9hG4bK2d4790.1;received=192.0.2.111;
              oc=0;oc-algo="loss";
            ...

This message should also include a validity parameter.

- Section 6.2: suggest to change the following paragraph:

          SIP/2.0 180 Ringing
           Via: SIP/2.0/TLS p1.example.net;
             branch=z9hG4bK2d4790.3;received=192.0.2.111;
             oc=20;oc-algo="loss";oc-validity=1000;
             oc-seq=1282321615.782
           ...

    After 500ms, the overload condition at P2 subsides.  It then sends
    out the message below to allow P1 to send all messages destined to
    P2.

           SIP/2.0 183 Queued
           Via: SIP/2.0/TLS p1.example.net;
             branch=z9hG4bK2d4790.4;received=192.0.2.111;
             oc=0;oc-algo="loss";oc-validity=0;oc-seq=1282321887.783
           ...

to:

          SIP/2.0 180 Ringing
           Via: SIP/2.0/TLS p1.example.net;
             branch=z9hG4bK2d4790.3;received=192.0.2.111;
|           oc=20;oc-algo="loss";oc-validity=500;
             oc-seq=1282321615.782
           ...

|   After some time, the overload condition at P2 subsides.  It then 
creates the via headers below to allow P1 to send all messages destined to
    P2.

           SIP/2.0 183 Queued
           Via: SIP/2.0/TLS p1.example.net;
             branch=z9hG4bK2d4790.4;received=192.0.2.111;
|           oc=0;oc-algo="loss";oc-validity=0;oc-seq=1282321892.439
           ...

-> this clarifies that validity is independent of changes in the oc value.

- Section 6.3: pseudo-code algorithm:

There are two local policies one for the client and one for the server. 
I'd suggest to name them differently, e.g., local_policy_client and 
local_policy_server to disambiguate their use.

- Section 6.3: pseudo-code algorithm: case outbound request and server 
is in overload:

The percentage to reduce (pct_to_reduce) should only be applied to 
category 1 messages. If the client is in a state where it needs to 
reduce more message than it has messages in category 1, it needs to 
calculate the required additional loss percentage for category 2 
messages. Right now, the code would apply the loss percentage for 
category 1 messages also to category 2 messages, which will lead to the 
wrong result.

After the following two statements:

             category := assign_msg_to_category(sip_msg)
             drop_msg := false

the client should check if the message is category 1 and apply the loss 
percentage.

If the message is category 2 and the pct_to_reduce is 100 (i.e., all 
messages in category 1 get dropped) it needs to compute the additional 
loss percentage for category 2 and apply it to the message. Code for 
this case is still missing in the algorithm.

- Section 6.3: Note on the local_policy() function

I don't think there should be a heuristic that includes the frequency 
with which this function is called. When a client needs to discard more 
messages than it has in category 1 it should start to target category 2 
messages. This should be independent from the number of times this 
function has been called. I'd suggest to remove the four cases.

Thanks,

Volker