Subject: [sip-overload] Updated version (-06) of draft-ietf-soc-overload-control

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 02 Jan 2012 13:06:05 -0600

All: Best wishes for the new year.

I have revised draft-ietf-soc-overload-control to version -06 based
on the list comments that occurred during the last couple of weeks.
The thread of comments and proposed resolutions can be accessed from
http://www.ietf.org/mail-archive/web/sip-overload/current/msg00685.html.

Generally, the comments were mostly editorial and clarifications.
Version -06 is available at [1] and the diffs from -05 at [2].

Please let me know of any concerns or feedback.

[1] http://tools.ietf.org/html/draft-ietf-soc-overload-control-06
[2] 
http://tools.ietf.org/rfcdiff?url2=draft-ietf-soc-overload-control-06.txt

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/

---

From: Salvatore Loreto <[email-masked]>
Date: Wed, 4 Jan 2012 18:33:23 +0100

Hi Vijay,

thanks for the new 06 version, I have just finished to review it
together with the relative mail discussions

below my comments/doubts:

- Section 4.2 The oc-algo parameter

    When more than one class of
    overload control algorithms is present in the "oc-algo" parameter,
    the client may indicate algorithm preference by ordering the list in
    a decreasing order of preference.  However, the client must not
    assume that the server will pick the most preferred algorithm.

It is not completely clear to me the advantage for the client to express 
preferences
ordering the list if the server does not know whether or not the order 
really express a preference.

if we want the list ordered then we need to add some text also in last 
paragraph of Section 5

- Section 5.1 Handshake to determine support for overload control

reading the second paragraph I understood that a server must always 
respond, the first time
it is contacted by a client, with the "oc" parameter set to "0".

    A server that supports overload control MUST set the value of the
    "oc" parameter to be 0.

Is this the real intention? what happen when a client contact for the 
first time a server that is
already overloaded? it will receive a first response with "oc" parameter 
set to "0" and then
only with the answer to the next (second) request it will discover that 
the server is overloaded?

The fact that the first time the "oc" parameter MUST be set to 0 seems 
in contradiction with the
last sentence of the same paragraph.

     A server that supports overload control MAY insert an
    "oc-validity=0" parameter in the response to further qualify the
    value in the "oc" parameter.

- Section 5.9. Self-Limiting  second paragraph states

    In the event of repeated timeouts or fatal transport errors, the SIP
    client MUST stop sending requests to this server.  The SIP client
    SHOULD occasionally forward a single request to probe if the
    downstream server is alive.

we are explicitly suggesting to sacrifice a request to probe if the 
downstream server
is alive.
I would prefer change the last sentence in something like

    The SIP client SHOULD periodically probe if the downstream server is alive.
    How the SIP client will probe the downstream server is out of scope for this document.

best regards
Salvatore

-- 
Salvatore Loreto
www.sloreto.com

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 04 Jan 2012 14:12:01 -0600

> below my comments/doubts:

Sal: Thank you for your comments.  Please see inline for
resolutions.

> It is not completely clear to me the advantage for the client to
> express preferences ordering the list if the server does not know
> whether or not the order really express a preference.

Hmmm ... I had thought that since the third paragraph of Section 4,2,
which discusses server behaviour, appears right underneath the second
paragraph (which discusses client behaviour), the context about the
"oc-algo" parameter containing a sorted listed carried over from the
second paragraph to the third.

> if we want the list ordered then we need to add some text also in last

If you think we still need to add something, I would rather do so in
the third paragraph of S 4.2 (which discusses the server behaviour).
Please let me know.

> respond, the first time it is contacted by a client, with the "oc"
> parameter set to "0".
>
> Is this the real intention? what happen when a client contact for
> the first time a server that is already overloaded? it will receive a
> first response with "oc" parameter set to "0" and then only with the
> answer to the next (second) request it will discover that the server
> is overloaded?

That is a valid point.  I will rewrite that paragraph as follows (let me
know if anyone has concerns with the rewrite):

OLD:

    A server that supports overload control MUST set the value of the
    "oc" parameter to be 0.  In addition, it MUST choose one algorithm
    from the list of algorithms in the "oc-algo" parameter and echo the
    chosen algorithm as the sole parameter value in the "oc-algo"
    parameter.  A server that supports overload control MAY insert an
    "oc-validity=0" parameter in the response to further qualify the
    value in the "oc" parameter.

NEW:

    A server that supports overload control MUST choose one algorithm
    from the list of algorithms in the "oc-algo" parameter and echo the
    chosen algorithm as the sole parameter value in the "oc-algo"
    parameter.  In addition, if the server is currently not in an
    overload condition, it MUST set the value of the "oc" parameter
    to be 0 and MAY insert an "oc-validity=0" parameter in the
    response to further qualify the value in the "oc" parameter. If
    the server is currently overloaded, it MUST follow the procedures
    of Section 5.2.

> in contradiction with the last sentence of the same paragraph.
>

No, there is a subtle interplay between loss-based and rate-based
values going on here.  In loss-based, an "oc=0" implies "do no
overload".  In rate-based schemes, an "oc=0" implies the opposite,
i.e., "do not send me any messages".  Thus, the "oc-validity=0"
parameter is used with rate-based schemes to signify that overload
control is supported, but not turned on.  This was agreed on the list
by Eric Noel, Phil Williams and Janet Gunn.

>   The SIP client SHOULD periodically probe if the downstream server is
>   alive. How the SIP client will probe the downstream server is out of
>   scope for this document.

Works for me.  I can change it to that unless someone has any
objections.

Thanks,

- vijay

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 9 Jan 2012 10:59:25 +0100

Hi Vijay,

my replies in line.

> the third paragraph of S 4.2 (which discusses the server behaviour).

I agree about the position for clarification (S 4.2 instead of 5)

reading once again, more carefully,  the second and third paragraph
I see that in the third paragraph is implicit in the context of the section
that the server can assume
the list is ordered by preference but it is free to choose whatever algo 
works
best for it.
However I would prefer make it explicit in the third paragraph, but this 
is just my preference.

>      the server is currently overloaded, it MUST follow the procedures
the NEW text is much better and is in line with what stated in Section 4.1

> by Eric Noel, Phil Williams and Janet Gunn.
OK got it.
I agree with Eric, Phil and Janet

> - vijay]
best regards
Salvatore

-- 
Salvatore Loreto
www.sloreto.com

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 09 Jan 2012 08:45:00 -0600

Sal: Please see inline.

On 01/09/2012 03:59 AM, Salvatore Loreto wrote:
>>> if we want the list ordered then we need to add some text also in
>>> last paragraph of Section 5
>> If you think we still need to add something, I would rather do so
>> in the third paragraph of S 4.2 (which discusses the server
>> behaviour). Please let me know.
>
> reading once again, more carefully, the second and third paragraph I
> see that in the third paragraph is implicit in the context of the
> section that the server can assume the list is ordered by preference
> but it is free to choose whatever algo works best for it. However I
> would prefer make it explicit in the third paragraph, but this is
> just my preference.

OK.  How about the following suggestion:

OLD:
4.2   The oc-algo parameter
...
    When a downstream SIP server receives a request with a choice of
    overload control algorithms specified in the "oc-algo" parameter
    value, it MUST choose one algorithm from the list and MUST pare the
    list down to include the one chosen algorithm.  The pared down list
    consisting of the chosen algorithm MUST be returned to the upstream
    SIP client in the response.

NEW:
4.2   The oc-algo parameter
...
    When a downstream SIP server receives a request with multiple
    overload control algorithms specified in the "oc-algo"
    parameter (sorted by decreasing order of preference), it MUST
    choose one algorithm from the list and MUST pare the list down
    to include the one chosen algorithm.  The pared down list
    consisting of the chosen algorithm MUST be returned to the upstream
    SIP client in the response.

If you are okay with this, I will make the requisite change in -07.

Thanks,

- vijay

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 9 Jan 2012 16:14:08 +0100

>      SIP client in the response.
I would only change
s/(sorted by decreasing order of preference)/(maybe sorted by decreasing 
order of preference)

thanks
Salvatore

-- 
Salvatore Loreto
www.sloreto.com

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 9 Jan 2012 18:58:05 +0100

Hi Vijay,

one more comment

in Section 9.2 Backward Compatibility
the last paragraph states:

    A SIP server should therefore use 5xx responses towards upstream
    neighbors that do not support overload control.  The server should
    reject the same amount of requests with 5xx responses that would be
    otherwise be rejected/redirected by the upstream neighbor if it would
    support overload control.  If the load condition on the server does
    not permit the creation of 5xx responses, the server should drop all
    requests from servers that do not support overload control.

Shouldn't rather state 503 without Retry-After as indicate in Chapter 5.9.2?

best regards
Salvatore

-- 
Salvatore Loreto
www.sloreto.com