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

Volker Hilt <volker.hilt@alcatel-lucent.com> Fri, 13 January 2012 23:49 UTC

Return-Path: <volker.hilt@alcatel-lucent.com>
X-Original-To: sip-overload@ietfa.amsl.com
Delivered-To: sip-overload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 73C2B1F0C3D for <sip-overload@ietfa.amsl.com>; Fri, 13 Jan 2012 15:49:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gGVFL0wIIxxt for <sip-overload@ietfa.amsl.com>; Fri, 13 Jan 2012 15:49:33 -0800 (PST)
Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id C151E1F0C38 for <sip-overload@ietf.org>; Fri, 13 Jan 2012 15:49:33 -0800 (PST)
Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id q0DNnWN4027511 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <sip-overload@ietf.org>; Fri, 13 Jan 2012 17:49:32 -0600 (CST)
Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q0DNnWh2013753 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <sip-overload@ietf.org>; Fri, 13 Jan 2012 17:49:32 -0600
Received: from [135.244.19.232] (135.3.62.245) by USNAVSXCHHUB02.ndc.alcatel-lucent.com (135.3.39.111) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 13 Jan 2012 17:49:32 -0600
Message-ID: <4F10C307.7010507@alcatel-lucent.com>
Date: Fri, 13 Jan 2012 18:49:27 -0500
From: Volker Hilt <volker.hilt@alcatel-lucent.com>
User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:9.0) Gecko/20111222 Thunderbird/9.0.1
MIME-Version: 1.0
To: <sip-overload@ietf.org>
References: <4EEA1BB3.7020509@bell-labs.com> <2F8FB48C17221643AD77FA295756D2A72405E641CE@njfpsrvexg6.research.att.com> <4EF9F50F.0@bell-labs.com> <2F8FB48C17221643AD77FA295756D2A724060158A8@njfpsrvexg6.research.att.com> <4F10C29E.4000009@bell-labs.com>
In-Reply-To: <4F10C29E.4000009@bell-labs.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9
Subject: Re: [sip-overload] soc-overload-control-05
X-BeenThere: sip-overload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Overload <sip-overload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sip-overload>, <mailto:sip-overload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sip-overload>
List-Post: <mailto:sip-overload@ietf.org>
List-Help: <mailto:sip-overload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip-overload>, <mailto:sip-overload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Jan 2012 23:49:34 -0000

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