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

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

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.

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.

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

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

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/