Re: [sip-overload] soc-overload-control-05
"NOEL, ERIC C (ERIC C)" <ecnoel@research.att.com> Mon, 19 December 2011 15:46 UTC
Return-Path: <ecnoel@research.att.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 EAAA221F8B8B for <sip-overload@ietfa.amsl.com>;
Mon, 19 Dec 2011 07:46:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.999
X-Spam-Level:
X-Spam-Status: No, score=-103.999 tagged_above=-999 required=5
tests=[BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 DJr0iFJmLoNY for
<sip-overload@ietfa.amsl.com>; Mon, 19 Dec 2011 07:46:53 -0800 (PST)
Received: from mail-pink.research.att.com (mail-pink.research.att.com
[192.20.225.111]) by ietfa.amsl.com (Postfix) with ESMTP id 1BE5521F8B88 for
<sip-overload@ietf.org>; Mon, 19 Dec 2011 07:46:53 -0800 (PST)
Received: from mail-green.research.att.com (unknown [135.207.178.10]) by
mail-pink.research.att.com (Postfix) with ESMTP id BDCB7120741;
Mon, 19 Dec 2011 10:46:52 -0500 (EST)
Received: from njfpsrvexg5.research.att.com (njfpsrvexg5.research.att.com
[135.207.177.27]) by mail-green.research.att.com (Postfix) with ESMTP id
A46F88410; Mon, 19 Dec 2011 10:46:52 -0500 (EST)
Received: from njfpsrvexg6.research.att.com ([fe80::a8f7:a94a:d5bd:fe0b]) by
njfpsrvexg5.research.att.com ([fe80::a501:da3:2345:4587%10]) with mapi;
Mon, 19 Dec 2011 10:45:52 -0500
From: "NOEL, ERIC C (ERIC C)" <ecnoel@research.att.com>
To: "Vijay K. Gurbani" <vkg@bell-labs.com>,
"sip-overload@ietf.org" <sip-overload@ietf.org>
Date: Mon, 19 Dec 2011 10:50:17 -0500
Thread-Topic: [sip-overload] soc-overload-control-05
Thread-Index: Acy7Q8dAOw6SAJCpTv6p7bPupCUdKgDEf0fg
Message-ID: <2F8FB48C17221643AD77FA295756D2A72405E641CE@njfpsrvexg6.research.att.com>
References: <4EEA1BB3.7020509@bell-labs.com>
In-Reply-To: <4EEA1BB3.7020509@bell-labs.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
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: Mon, 19 Dec 2011 15:46:54 -0000
Vijay, I sent you a few editorial/minor comments off-line. In addition, reading section 6.3 (default algorithm for loss-based overload control) lead me to the following comment. Since different request types likely will produce different processing costs at the server, to prevent a mismatch between the servers "control commands" (oc parameter) and clients execution of the "control commands" (percent loss, rate limit...), an agreement between clients and servers on the type of requests that can be discarded seems to be required. Unless I missed that point in your document, could not you explicitly require that servers estimate for oc parameter be based on requests belonging to the set "requests candidate for reduction"? So both clients and servers work from the same set and the mentioned mismatch is prevented. That way in section 6.3, you no longer need to have the client adjusts the oc parameter (percent loss) by the proportion of requests in the set "requests candidate for reduction". And you no longer imply that the server estimates the oc parameter for loss-control based on all requests (initial dialog requests, mid-dialog requests....). What do you think? Thanks, Eric Noel AT&T Labs, Inc. Rethink Possible Network Design and Performance Analysis 200 South Laurel Avenue, D5-3D19 Middletown, NJ 07748 P: 732.420.4174 ecnoel@att.com -----Original Message----- From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] On Behalf Of Vijay K. Gurbani Sent: Thursday, December 15, 2011 11:09 AM To: sip-overload@ietf.org Subject: [sip-overload] soc-overload-control-05 Folks: I realize people are busy with end of the year plans, but if you get the chance, please provide input on soc-overload-control-05 [1]. I had posted this updated version back in Oct-28. The changes and diffs are outlined in [2]. It will be nice to move this work ahead. Thanks, [1] http://tools.ietf.org/html/draft-ietf-soc-overload-control-05 [2] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00679.html - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ _______________________________________________ sip-overload mailing list sip-overload@ietf.org https://www.ietf.org/mailman/listinfo/sip-overload
- [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