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

[Salvatore Loreto <[e-mail]>]

Vijay

it looks good to me too. Thanks.


Eric: btw in rate-control-02 you talks about just limiting the Invite rate.

    This document proposes extensions to [draft-ietf-soc-overload-  <http://tools.ietf.org/html/draft-ietf-soc-overload-control-05>
    control-05  <http://tools.ietf.org/html/draft-ietf-soc-overload-control-05>] so as to support a rate-based control that guarantees
    clients produce a limited upper bound to the Invite rate towards an
    overloaded server, which is constant between server updates.



cheers
Salvatore


On 1/14/12 2:26 AM, NOEL, ERIC C (ERIC C) wrote:
> Vijay,
>
> Everything looks good to me, this is consistent to what we agreed off line.
>
> Thanks,
>
> Eric
> ________________________________________
> From: [e-mail] [[e-mail]] On Behalf Of Volker Hilt [[e-mail]]
> Sent: Friday, January 13, 2012 6:49 PM
> To: [e-mail]
> 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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sip-overload
> _______________________________________________
> sip-overload mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sip-overload


-- 
Salvatore Loreto
www.sloreto.com