Re: [sip-overload] soc-overload-control-05

Vijay,

Everything looks good to me, this is consistent to what we agreed off line.

Thanks,

Eric
________________________________________
From: sip-overload-bounces@ietf.org [sip-overload-bounces@ietf.org] On Behalf Of Volker Hilt [volker.hilt@alcatel-lucent.com]
Sent: Friday, January 13, 2012 6:49 PM
To: sip-overload@ietf.org
Subject: Re: [sip-overload] soc-overload-control-05

Hi Vijay,

as a nit - I'd suggest to consistently talk about requests (and not
messages) in the text. Otherwise, I think this looks good.

Thanks,

Volker

On 1/13/2012 6:47 PM, Vijay K. Gurbani wrote:
> Eric: Closing this loop.  Please see inline.
>
> On 01/03/2012 12:34 PM, NOEL, ERIC C (ERIC C) wrote:
>> Vijay,
>>
>> Thanks for your reply and the suggested email threads.
>>
>> Another way to express my concern is that in reading your client
>> default loss control algorithm, the client normalization of oc-loss
>> seems to imply that the server estimates oc-loss assuming it could
>> equally be rejecting all requests (initial-dialog or out-of-dialog or
>> mid-dialog requests).
>
> Correct.
>
>> This is in contrast with my simulation implementation of rate and
>> loss controls in support of the SIP overload control working group
>> activities a few years ago.  There, both my simulated servers and
>> clients used the implicit assumption that throttling was limited to
>> the same requests in both the servers and clients (at the time just
>> INVITE messages).
>>
>> Basically I am concerned that the throttling algorithms may not work
>> properly if the clients normalize oc-loss/oc-rate/oc-other based on a
>> "reduction/no reduction" mix of messages locally created, while the
>> servers estimate optimal oc-loss/oc-rate based on a different mix.
>
> True.  Following the discussion we have had, I will clarify that the
> basis for calculating the "oc" parameter value must include all
> the messages.  The suggested text is below.
>
> OLD
> 5.3 Determining the 'oc' Parameter Value
>      The value of the "oc" parameter is determined by the overloaded
>      server using any pertinent information at its disposal.  The process
>      by which an overloaded server determines the value of the "oc"
>      parameter is considered out of scope for this document.
>
> NEW
> 5.3 Determining the 'oc' Parameter Value
>       The value of the "oc" parameter is determined by the overloaded
>       server using any pertinent information at its disposal.  The only
>       constraint imposed by this document is that the server control
>       algorithm MUST produce a value for the "oc" parameter
>       such that the receiving clients can apply it to all downstream
>       messages (dialogue forming as well as in-dialogue).  Beyond this
>       stipulation, the process by which an overloaded server determines
>       the value of the "oc" parameter is considered out of scope for this
>       document.
>
>           Note that this stipulation is required so that both the
>           and server have an common view of which messages to include
>           in the calculation of the feedback.  With this stipulation
>           in place, the client can prioritize messages as discussed
>           in Section 5.10.1.
>
>      As an example, a value of "oc=10" when the loss-based algorithm is
>      uses implies that 10% of all messages (dialog forming as well as
>      in-dialogue) are subject to reduction at the client.  Analogously,
>      a value of "oc=10" when the rate-based algorithm is used indicates
>      that the client should send SIP requests at a rate no greater than
>      or equal to 10 SIP requests per second.
>
> Is that okay?  Please let me know if you or anyone else has any further
> issues with this.  If not, I will revise the draft.
>
> Thanks,
>
> - vijay
_______________________________________________
sip-overload mailing list
sip-overload@ietf.org
https://www.ietf.org/mailman/listinfo/sip-overload