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
- [sip-overload] soc-overload-control-05 Vijay K. Gurbani
- [sip-overload] draft-noel-soc-overload-rate-contr… NOEL, ERIC C (ERIC C)
- Re: [sip-overload] soc-overload-control-05 NOEL, ERIC C (ERIC C)
- Re: [sip-overload] soc-overload-control-05 phil.m.williams
- Re: [sip-overload] soc-overload-control-05 Vijay K. Gurbani
- Re: [sip-overload] soc-overload-control-05 Vijay K. Gurbani
- Re: [sip-overload] soc-overload-control-05 Janet P Gunn
- Re: [sip-overload] soc-overload-control-05 Vijay K. Gurbani
- Re: [sip-overload] soc-overload-control-05 NOEL, ERIC C (ERIC C)
- Re: [sip-overload] draft-noel-soc-overload-rate-c… Salvatore Loreto
- Re: [sip-overload] soc-overload-control-05 Vijay K. Gurbani
- Re: [sip-overload] soc-overload-control-05 Volker Hilt
- Re: [sip-overload] soc-overload-control-05 NOEL, ERIC C (ERIC C)
- Re: [sip-overload] soc-overload-control-05 Salvatore Loreto
- Re: [sip-overload] soc-overload-control-05 Vijay K. Gurbani