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

[Volker Hilt <[e-mail]>]

On 9/6/2011 10:47 PM, Vijay K. Gurbani wrote:
> On 09/06/2011 07:23 PM, Shida Schubert wrote:
>> 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.
>
I agree.

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.

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.

In the spirit of keeping things simple, I don't think expressing 
preferences adds much value. The client should send a flat list the 
sever can choose from.

The draft should, of course, have a discussion about chosing the 
algorithm in the server (i.e., not changing it often, etc)

Thanks,

Volker [as individual]