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

 I think the general approach is fine.

 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. 

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

 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. 

    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.

    No "oc-algo" shows up until the next negotiation phase.  

 Should we say anything about when timer runs out?

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

 Regards
  Shida

On Sep 3, 2011, at 4:41 AM, Vijay K. Gurbani wrote:

> Folks: One of the issues that was left rather underspecified
> in draft-ietf-soc-overload-control-02 was how often should
> the overload algorithms be re-negotiated.
> 
> The -02 version took a rather liberal view and simply said that
> implementations must not do it too often, i.e., "... the adjacent
> peers MUST NOT renegotiate the overload control algorithm class
> per transaction, or per request-response message exchange."
> 
> In -03, the text around this is far more conservative and
> disallows renegotiations until at least 3600s have elapsed since
> the last agreement.  See the newly added Section 5.7 in -03 [1].
> 
> Please do read Section 5.7, and if there is a better way to
> accomplish renegotiation, please let me know.
> 
> [1] http://tools.ietf.org/html/draft-ietf-soc-overload-control-03#section-5.7
> 
> 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} / vijay.gurbani@alcatel-lucent.com
> Web:   http://ect.bell-labs.com/who/vkg/
> _______________________________________________
> sip-overload mailing list
> sip-overload@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-overload