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

[Volker Hilt <[e-mail]>]

On 9/7/2011 10:27 AM, Vijay K. Gurbani wrote:
> On 09/07/2011 07:36 AM, Volker Hilt wrote:
>> Following up on the previous discussion of having the client include
>> only the current algorithm. I think the selection of the algorithm is
>> essentially a server issue. Once the server knows which algorithms
>> the client supports it can pick one. I'm not sure what the value is
>> of having the client include only the currently selected algorithm
>> and trigger a renegotiation once in a while.
>
> Volker: Three reasons.
>
> Consider a case where a client/server pair has agreed on an
> algorithm.  Shortly after agreement, and before the re-negotiation
> timer expires, the server crashes.  A backup server takes its
> place.  The client continues to operate on the previously chosen
> algorithm, even if the new server supports schemes that the old
> server did not.  The alternative is that if we send the complete
> algorithm list, the new server may choose a different scheme
> than its predecessor did, causing the client some mild discomfort.
>
I think this is a good case in which the server can switch. Otherwise 
the client forces the server into using a specific algorithm, which it 
may not even support.

> Second, it seems more explicit for the client to send only the
> algorithm agreed upon.  Sending the entire list every time forces the
> server to always parse the list.
>
Once everything is up and running all the server needs to do is look for 
the algorithm it is currently using. But I agree that may be slightly 
more work.

> Finally, given that the Via header line length is constantly increasing,
> it is advantageous not to  insert an entire list, however small it may
> be.
>
I think we are talking about a very small list. If you are concerned 
about the Via header length, we can make the identifiers very small.

>> I think the client should always include all supported algorithms.
>> The server gets to choose since it needs to shoulder the burden of
>> generating the feedback for each client.
>
> If the working group wants to go with the alternative of sending
> an entire list on each request, I am perfectly happy to do so; but I did
> want to at least provide a justification for not doing so.
>
Fully understood!

>> The draft should, of course, have a discussion about chosing the
>> algorithm in the server (i.e., not changing it often, etc)
>
> The feedback we got the previous time is that we have to do a better
> job of simply saying that the algorithm should not change too often
> ("how long is too often?  Once a transaction?  Once a dialogue?
> Once every 5 minutes?  Once every 10 requests?").  Hence the addition
> of the timer with a default value of 3600s to handle the renegotiation.
> If you have any alternative means to affect the same outcome
> deterministically, please do let me know.
>
I think it makes sense to specify this for the server side. I.e., give 
recommendations of when the server may consider to change an algorithm.

Thanks,

Volker