Re: [sip-overload] The frequency of re-negotiating overload control schemes

["Vijay K. Gurbani" <[e-mail]>]

On 09/06/2011 06:32 AM, Shida Schubert wrote:
>
>   I think the general approach is fine.

Shida: Thank you for your comments.  More inline.

>   Client sends the list and server picks one is the current
> approach, so client has no way to present preference,
> and as far as I can tell the server has no way to change
> the algorithm unless client initiates the re-negotiation. I
> don't have any problem with that as we want to keep it
> as simple as possible  but I thought I would share my
> observation.
> *As far as I can read from the text, there was no text
>   saying that server can include "oc-algo" with list of
>   algorithm it supports in a response to negotiate the
>   algorithm with the client.

Right; the server simply gets to choose one from the list
provided by the client.

>   - If we want to allow client to show preference, we can
>     say that the list is composed in a order that it prefers.
>     Whether server honor that or not is a different story.

That is fine with me, and more preferable than adding additional
parameters showing preference (a q-value).

>   It's also not clear to me the expected normative behavior
> surrounding "oc-algo", I am assuming that  "oc-algo" only
> shows up when negotiating but it is currently not clear. So
> we should probably be clear with when "oc-algo" shows
> up so client/server both know when to set it and what it means.
>
>   Below are my interpretation.
>
>      Client sets "oc-algo" in request only when it wants to
>      negotiate the algorithm to be used.

I agree this part is unclear.  Here is my view, and if you
and the list agrees, I can update the draft.

For the normal sake of fault-tolerance, robustness, and
carrying as much state in the message itself, the
oc-algo appears in every request, with one important difference.
When the client first contacts the server, and thereupon every
time the timer fires, the oc-algo list will contain all
schemes supported by the client.  Once an algorithm has been agreed
to, it becomes the sole value that goes into the oc-algo parameter
until re-negotiation.  Sending it as the sole value allows for
an backup server to continue using the same algorithm agreed
to by its predecessor.

>      Server knows that the negotiation is requested
>      due to the fact that "oc-algo" is present in the via.
>      It selects the algorithm and sends that in the response.

Yes, the above works in both cases.  That is, when there is a list
of algorithms and when one has been chosen and the client/server
pair is in between the timer for the next negotiation going off.
In the latter case, the server does not have too much latitude at
choosing, but the former case (list of algorithms), the server
can choose afresh.

>      No "oc-algo" shows up until the next negotiation phase.
>
>   Should we say anything about when timer runs out?

I believe this is present in Section 5.7:

    Once the client and server agree on an overload control
    algorithm, it MUST remain in effect for at least 3600 seconds
    (1 hour) before renegotiation occurs.

>   Should we have a text mandating that if the timer runs out,
> client negotiates the algorithm on the next request it sends
> to the server??

I believe it is already there in Section 5.7:

    Renegotiation, when desired, is simply accomplished by the
    SIP client sending a complete list of overload control
    algorithms it supports in a "oc-algo" parameter in a
    request going downstream.  The downstream server, as before, 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 and stays in effect until the next renegotiation.

If the last two points you make are not clear in Section 5.7, please
let me know and I can see if I can highlight these in some fashion.

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} / [e-mail]
Web:   http://ect.bell-labs.com/who/vkg/