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

[Shida Schubert <[e-mail]>]

Hi Vijay;

 My comments inline..

On Sep 6, 2011, at 10:11 PM, Vijay K. Gurbani wrote:

> 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.

 Okay, fair enough. 

 I guess we should probably mandate the inclusion of "oc-algo" 
in that case. It is currently stated on 4.1 as "MAY" add an "oc-algo"..

 One can assume that not having "oc-algo" indicates that the client 
only supports or wants to use the default "loss" based algorithm but 
if that is the case we should probably have a statement saying that 
too. 

 I prefer mandating the inclusion of "oc-algo" so it is always clear 
what the client/server means/wants. 

> 
>>     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.

 I must have misread it, it looks good. 

 Regards
  Shida

> 
> 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/