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