From vkg@bell-labs.com Thu Dec 15 08:05:53 2011 Return-Path: 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 60A4921F86FF for ; Thu, 15 Dec 2011 08:05:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.497 X-Spam-Level: X-Spam-Status: No, score=-106.497 tagged_above=-999 required=5 tests=[AWL=0.102, BAYES_00=-2.599, 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 T81MsD8r3MSE for ; Thu, 15 Dec 2011 08:05:52 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 5848C21F8513 for ; Thu, 15 Dec 2011 08:05:52 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id pBFG5nsT017237 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 15 Dec 2011 10:05:50 -0600 (CST) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pBFG5mBs013771 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Thu, 15 Dec 2011 10:05:49 -0600 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id pBFG5m3F013438 for ; Thu, 15 Dec 2011 10:05:48 -0600 (CST) Message-ID: <4EEA1BB3.7020509@bell-labs.com> Date: Thu, 15 Dec 2011 10:09:23 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111115 Thunderbird/8.0 MIME-Version: 1.0 To: "sip-overload@ietf.org" 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.11 Subject: [sip-overload] soc-overload-control-05 X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2011 16:05:53 -0000 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/ From ecnoel@research.att.com Thu Dec 15 08:19:49 2011 Return-Path: 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 681CF21F84B8 for ; Thu, 15 Dec 2011 08:19:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.599 X-Spam-Level: X-Spam-Status: No, score=-106.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 qldObfgGFhyQ for ; Thu, 15 Dec 2011 08:19:49 -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 EBF7F21F84B7 for ; Thu, 15 Dec 2011 08:19:48 -0800 (PST) Received: from mail-blue.research.att.com (unknown [135.207.178.11]) by mail-pink.research.att.com (Postfix) with ESMTP id 998FA1205AB for ; Thu, 15 Dec 2011 11:19:48 -0500 (EST) Received: from njfpsrvexg2.research.att.com (njfpsrvexg2.research.att.com [135.207.177.29]) by mail-blue.research.att.com (Postfix) with ESMTP id 4B144EF6C9 for ; Thu, 15 Dec 2011 11:19:47 -0500 (EST) Received: from njfpsrvexg6.research.att.com ([fe80::a8f7:a94a:d5bd:fe0b]) by njfpsrvexg2.research.att.com ([fe80::a158:97ea:81b0:43d9%15]) with mapi; Thu, 15 Dec 2011 11:15:04 -0500 From: "NOEL, ERIC C (ERIC C)" To: "sip-overload@ietf.org" Date: Thu, 15 Dec 2011 11:23:01 -0500 Thread-Topic: draft-noel-soc-overload-rate-control-02 Thread-Index: Acy7Q8dAOw6SAJCpTv6p7bPupCUdKgAAe5Mg Message-ID: <2F8FB48C17221643AD77FA295756D2A72405E63EA5@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: [sip-overload] draft-noel-soc-overload-rate-control-02 X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 15 Dec 2011 16:19:49 -0000 Folks, Please make a note we have updated draft-noel-soc-overload-rate-control and= posted the latest version at http://datatracker.ietf.org/doc/draft-noel-soc-overload-rate-control/ Comments and/or suggestions are always appreciated. Thanks! Eric Noel=20 AT&T Labs, Inc.=20 Rethink Possible Network Design and Performance Analysis 200 South Laurel Avenue, D5-3D19 Middletown, NJ 07748 P: 732.420.4174 ecnoel@att.com From ecnoel@research.att.com Mon Dec 19 07:46:53 2011 Return-Path: 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 ; 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 ; 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 ; 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)" To: "Vijay K. Gurbani" , "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 19 Dec 2011 15:46:54 -0000 Vijay, I sent you a few editorial/minor comments off-line.=20 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 cost= s at the server, to prevent a mismatch between the servers "control command= s" (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 requi= re that servers estimate for oc parameter be based on requests belonging to= the set "requests candidate for reduction"? So both clients and servers wo= rk from the same set and the mentioned mismatch is prevented.=20 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 "reque= sts candidate for reduction". And you no longer imply that the server estim= ates the oc parameter for loss-control based on all requests (initial dialo= g requests, mid-dialog requests....). What do you think? Thanks, Eric Noel=20 AT&T Labs, Inc.=20 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 --=20 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 From phil.m.williams@bt.com Fri Dec 23 08:00:37 2011 Return-Path: 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 5D1A121F8B16 for ; Fri, 23 Dec 2011 08:00:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] 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 m4Fz6vWVSbBL for ; Fri, 23 Dec 2011 08:00:36 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 200CF21F8B15 for ; Fri, 23 Dec 2011 08:00:35 -0800 (PST) Received: from EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 23 Dec 2011 16:00:35 +0000 Received: from E07HT01-UKBR.domain1.systemhost.net (193.113.197.94) by EVMHT66-UKRD.domain1.systemhost.net (10.36.3.103) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 23 Dec 2011 16:00:34 +0000 Received: from EMV04-UKBR.domain1.systemhost.net ([169.254.1.212]) by E07HT01-UKBR.domain1.systemhost.net ([193.113.197.94]) with mapi; Fri, 23 Dec 2011 16:00:34 +0000 From: To: Date: Fri, 23 Dec 2011 16:00:32 +0000 Thread-Topic: [sip-overload] soc-overload-control-05 Thread-Index: Acy7Q28zId0gGkeZToCJfah7PmxPeAGOabog Message-ID: References: <4EEA1BB3.7020509@bell-labs.com> In-Reply-To: <4EEA1BB3.7020509@bell-labs.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: sip-overload@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 23 Dec 2011 16:00:37 -0000 Vijay, Thanks for submitting version 05. Please find some comments below (nothing major). Regards, Phil ---------------------------------------------------------------------------= ------ In a several places the qualification 'conformant to this specification' is= used, e.g. 4.2. The oc-algo parameter A SIP client conformant to this specification MUST add an "oc-algo" Para= meter ... I'm not sure whether this is really necessary, but since it is used here th= en perhaps ought to be included in the following since the use of 'When ins= erted...' makes it appear optional: 4.1. The oc parameter ... A SIP client MUST add an "oc" parameter ... When inserted into a request= by a SIP client to indicate support for overload control... Or alternatively take out the 'When inserted...'? ---------------------------------------------------------------------------= -------- In the following, I think 'server' should be 'client': 5.2. Creating and updating the overload control parameters ... Furthermore, when a SIP [server] receives a request with the topmos= t Via header containing only an "oc-validity" parameter without the accompa= nying "oc" parameter, it MUST ignore the "oc-validity". ---------------------------------------------------------------------------= -------- There could be some ambiguity in the following: 5.7. Terminating overload control A SIP client stops applying overload control to the number of messages forwarded (i.e., it stops reducing the number of messages forwarded) if one of the following events occur: 1. The "oc" parameter is set to a value that allows the client to forward all traffic; 2. The "oc-validity" period negotiated to put the server and client in overload state expires; 3. The client is explicitly told by the server to stop performing overload control using the "oc-validity=3D0" parameter. The question is: What should 'termination' refer to? The action in (1.) cou= ld be accompanied by a non-zero oc-validity period which is still active. T= herefore the server would view control as still being active, although it h= as (perhaps temporarily) allowed all traffic to be admitted from this clien= t. A practical realisation would probably leave a client control allocated in = case (1.) if the oc-validity period had not expired, and therefore the cont= rol would not be regarded as 'terminated'. This is reflected in the use of = 'effectively' in the following: Note that the loss-based overload control scheme (Section 6) can effectively stop overload control by setting the value of the "oc" parameter to 0...=20 Therefore the following alternative wording for this section would be bette= r: 5.7. Terminating overload control A SIP client removes overload control if one of the following events occur: 1. The "oc-validity" period negotiated to put the server and client in overload state expires; 2. The client is explicitly told by the server to stop performing overload control using the "oc-validity=3D0" parameter. Note also that messages will not be prevented from being forwarded if the "oc" parameter is set to a value that allows the client to forward all traffic. ---------------------------------------------------------------------------= ---------------------- Minor typos/grammatical =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D In the following denotes replacement for [original text]= . ----------------------------------------------------------------- 4. Via header parameters for overload control The four Via header parameters are introduced below. Further context [in] how to interpret... ------------------------------------------------------- 4.1. The oc parameter Inclusion of a value to the parameter represents two things: one, upon an i= nitial handshake (see Section <5.1>[X.X]),... ------------------------------------------------------- 5. General behaviour If the server supports overload control... A client that supports the rate-based... is almost a verbatim repeat of=20 5.1. Handshake to determine support for overload control A server that supports overload control... Note that the rate-based... Could this be avoided by some cross-referencing? ---------------------------------------------------------- 5.2. Creating and updating the overload control parameters ... The "oc-validity" parameter MUST NOT be [used in] a Via header th= at did not originally contain an "oc" parameter when received. ---------------------------------------------------------- 5.5. Using the Overload Control Parameter Values ... If the SIP client has a non-expired "oc" parameter value for the server cho= sen from the Expected Output, [and] this chosen server is operating i= n overload control mode. To make sense as a conditional statement, need to replace 'and' with 'then'= . > -----Original Message----- > From: sip-overload-bounces@ietf.org [mailto:sip-overload- > bounces@ietf.org] On Behalf Of Vijay K. Gurbani > Sent: 15 December 2011 16:09 > To: sip-overload@ietf.org > Subject: [sip-overload] soc-overload-control-05 >=20 > 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]. >=20 > 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. >=20 > Thanks, >=20 > [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 >=20 > - 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 From vkg@bell-labs.com Tue Dec 27 08:37:05 2011 Return-Path: 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 0625A21F84A3 for ; Tue, 27 Dec 2011 08:37:05 -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 CE1VfmtNzVXe for ; Tue, 27 Dec 2011 08:37:04 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2CF3421F849C for ; Tue, 27 Dec 2011 08:37:04 -0800 (PST) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id pBRGb3MO013884 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Dec 2011 10:37:03 -0600 (CST) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pBRGb2ED007953 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Dec 2011 10:37:03 -0600 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id pBRGb2e4021567; Tue, 27 Dec 2011 10:37:02 -0600 (CST) Message-ID: <4EF9F50F.0@bell-labs.com> Date: Tue, 27 Dec 2011 10:40:47 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111115 Thunderbird/8.0 MIME-Version: 1.0 To: "NOEL, ERIC C (ERIC C)" References: <4EEA1BB3.7020509@bell-labs.com> <2F8FB48C17221643AD77FA295756D2A72405E641CE@njfpsrvexg6.research.att.com> In-Reply-To: <2F8FB48C17221643AD77FA295756D2A72405E641CE@njfpsrvexg6.research.att.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.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Cc: "sip-overload@ietf.org" 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 16:37:05 -0000 On 12/19/2011 09:50 AM, NOEL, ERIC C (ERIC C) wrote: > Vijay, > > I sent you a few editorial/minor comments off-line. Eric: Thanks for the off-line comments. I have incorporated them. More inline (at end). > 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? We have been through this exercise before; i.e., trying to figure out what kinds of requests (SUBS, NOT, INV) a server can discard versus ones it can forward. In the end, we agreed that the ends do not justify the means and best to leave things as they are. Here is a list of messages in the archive that you can peruse to see the discussions on this topic (best to go in order): http://www.ietf.org/mail-archive/web/sip-overload/current/msg00320.html http://www.ietf.org/mail-archive/web/sip-overload/current/msg00321.html http://www.ietf.org/mail-archive/web/sip-overload/current/msg00324.html http://www.ietf.org/mail-archive/web/sip-overload/current/msg00326.html http://www.ietf.org/mail-archive/web/sip-overload/current/msg00339.html http://www.ietf.org/mail-archive/web/sip-overload/current/msg00341.html Furthermore, after the Maastricht IETF, it was decided to provide more guidance by defining a "local policy" (as is done in Section 5.10.1) for which messages should be forwarded is at: www.ietf.org/mail-archive/web/sip-overload/current/msg00366.html Thus in summary, while we can re-open the particular discussion on how we can reach an agreement between client and server on which type of requests should be discarded, I am afraid that we may not get too far. Thanks, - 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/ From vkg@bell-labs.com Tue Dec 27 09:40:30 2011 Return-Path: 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 3A47621F84FB for ; Tue, 27 Dec 2011 09:40:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.999 X-Spam-Level: X-Spam-Status: No, score=-104.999 tagged_above=-999 required=5 tests=[AWL=1.000, BAYES_00=-2.599, J_CHICKENPOX_25=0.6, 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 EMPSb+uG7+m7 for ; Tue, 27 Dec 2011 09:40:29 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3E88221F8508 for ; Tue, 27 Dec 2011 09:40:29 -0800 (PST) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id pBRHeQF6018747 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 27 Dec 2011 11:40:27 -0600 (CST) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pBRHeQrK009121 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 27 Dec 2011 11:40:26 -0600 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id pBRHeQ7n027564; Tue, 27 Dec 2011 11:40:26 -0600 (CST) Message-ID: <4EFA03EB.3050902@bell-labs.com> Date: Tue, 27 Dec 2011 11:44:11 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111115 Thunderbird/8.0 MIME-Version: 1.0 To: phil.m.williams@bt.com References: <4EEA1BB3.7020509@bell-labs.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Cc: sip-overload@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Dec 2011 17:40:30 -0000 On 12/23/2011 10:00 AM, phil.m.williams@bt.com wrote: > Vijay, > > Thanks for submitting version 05. > > Please find some comments below (nothing major). Phil: Thank you for your comments. Resolutions inline. > In a several places the qualification 'conformant to this > specification' is used, e.g. I added this phrase following the email discussion that you, Janet, Eric, and I had on Sept-9-2011. Janet felt that adding the prefix "a device that supports this specification" would aid. Hence I made the change. Personally, I think that adding this phrase makes the reading rather, for the lack of a better word, clunky. Any implementer reading this document will understand that the "oc-algo" parameters, etc. are only supported by implementations that support overload control. > 4.2. The oc-algo parameter > > A SIP client conformant to this specification MUST add an "oc-algo" > Parameter ... > > I'm not sure whether this is really necessary, but since it is used > here then perhaps ought to be included in the following since the > use of 'When inserted...' makes it appear optional: > > 4.1. The oc parameter ... A SIP client MUST add an "oc" parameter > ... When inserted into a request by a SIP client to indicate support > for overload control... > > Or alternatively take out the 'When inserted...'? Modified as follows to make it more conformant to the remaining sections: OLD: 4.1. The oc parameter This parameter is inserted by the SIP client and updated by the SIP server. A SIP client MUST add an "oc" parameter to the topmost Via header it inserts into the SIP request. This provides an indication to downstream neighbors that the client supports overload control. When inserted into a request by a SIP client to indicate support for overload control, there MUST NOT be a value associated with the parameter. NEW: 4.1. The oc parameter This parameter is inserted by the SIP client and updated by the SIP server. A SIP client conformant to this specification MUST add an "oc" parameter to the topmost Via header it inserts into the SIP request. This provides an indication to downstream neighbors that the client supports overload control. There MUST NOT be a value associated with the parameter (the value will be added by the server). > In the following, I think 'server' should be 'client': > > 5.2. Creating and updating the overload control parameters ... > Furthermore, when a SIP[server] receives a request with the > topmost Via header containing only an "oc-validity" parameter > without the accompanying "oc" parameter, it MUST ignore the > "oc-validity". No, it is indeed "server". That sentence is discussing the corner case when a SIP server receives a request with the "oc-validity" parameter specified but no corresponding "oc" parameter. This is an error condition. I should perhaps move the offending sentence to Section 4.3, where we discuss the parameter itself (and I have done so in my working copy). > There could be some ambiguity in the following: > > 5.7. Terminating overload control [...] > Therefore the following alternative wording for this section would > be better: OK; I have replaced opening paragraph of Section 5.7 as follows: OLD: A SIP client stops applying overload control to the number of messages forwarded (i.e., it stops reducing the number of messages forwarded) if one of the following events occur: 1. The "oc" parameter is set to a value that allows the client to forward all traffic; 2. The "oc-validity" period negotiated to put the server and client in overload state expires; 3. The client is explicitly told by the server to stop performing overload control using the "oc-validity=0" parameter. NEW: A SIP client removes overload control if one of the following events occur: 1. The "oc-validity" period negotiated to put the server and client in overload state expires; 2. The client is explicitly told by the server to stop performing overload control using the "oc-validity=0" parameter. > Minor typos/grammatical ======================= > > In the following denotes replacement for > [original text]. > > ----------------------------------------------------------------- 4. > Via header parameters for overload control > > The four Via header parameters are introduced below. Further > context[in] how to interpret... Done. > 4.1. The oc parameter > > Inclusion of a value to the parameter represents two things: one, > upon an initial handshake (see Section<5.1>[X.X]),... Done. > 5. General behaviour > > If the server supports overload control... > > A client that supports the rate-based... > > is almost a verbatim repeat of > > 5.1. Handshake to determine support for overload control > > A server that supports overload control... > > Note that the rate-based... > > Could this be avoided by some cross-referencing? Good catch. I have consolidated the text in Section 5.1. > 5.2. Creating and updating the overload control parameters ... The > "oc-validity" parameter MUST NOT be[used in] a Via header > that did not originally contain an "oc" parameter when received. I am unable to find the above phrase in -05, Section 5.2 ... > 5.5. Using the Overload Control Parameter Values > ... > If the SIP client has a non-expired "oc" parameter value for the > server chosen from the Expected Output,[and] this chosen > server is operating in overload control mode. > > To make sense as a conditional statement, need to replace 'and' with > 'then'. Fixed as suggested. I will release a new version shortly. Thanks a lot, Phil! - 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/ From jgunn6@csc.com Wed Dec 28 13:53:58 2011 Return-Path: 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 A1BAE21F846A; Wed, 28 Dec 2011 13:53:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.598 X-Spam-Level: X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 MPXpDiuD6mRD; Wed, 28 Dec 2011 13:53:57 -0800 (PST) Received: from mail87.messagelabs.com (mail87.messagelabs.com [216.82.250.19]) by ietfa.amsl.com (Postfix) with ESMTP id 98E4521F84B0; Wed, 28 Dec 2011 13:53:57 -0800 (PST) X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-10.tower-87.messagelabs.com!1325109234!52853056!1 X-Originating-IP: [20.137.2.87] X-StarScan-Version: 6.4.3; banners=-,-,- X-VirusChecked: Checked Received: (qmail 23479 invoked from network); 28 Dec 2011 21:53:55 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-10.tower-87.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 28 Dec 2011 21:53:55 -0000 Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.4.3/Switch-3.4.3) with ESMTP id pBSLrqJT003056; Wed, 28 Dec 2011 16:53:54 -0500 In-Reply-To: <4EFA03EB.3050902@bell-labs.com> References: <4EEA1BB3.7020509@bell-labs.com> <4EFA03EB.3050902@bell-labs.com> To: "Vijay K. Gurbani" MIME-Version: 1.0 X-KeepSent: 1D8CB133:DBC9D2FE-85257974:0077AF56; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.2FP1 SHF139 March 01, 2011 From: Janet P Gunn Message-ID: Date: Wed, 28 Dec 2011 16:53:51 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP1 HF29|January 09, 2011) at 12/28/2011 04:51:18 PM, Serialize complete at 12/28/2011 04:51:18 PM Content-Type: multipart/alternative; boundary="=_alternative 0078498485257974_=" Cc: sip-overload-bounces@ietf.org, sip-overload@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 28 Dec 2011 21:53:58 -0000 This is a multipart message in MIME format. --=_alternative 0078498485257974_= Content-Type: text/plain; charset="US-ASCII" Finally got a chance to come up for air and take a look at this. Some comments, mostly nits. The non-nit is the one about setting oc-validity. Comments on draft-ietf-soc-overload-control-05 Sec 4.1 Second paragraph refers to "Section X.X". Probably supposed to be 5.1 Last paragraph - the statement "it SHOULD reduce, by the amount indicated, the number of requests going downstream to the SIP server from which it received the response ..." is perfectly true for the loss based algorithm, but not technically correct for the rate based algorithm. Suggest either adding a "Note" as in other cases where you discuss differences for rate based, or reword it, possibly "it SHOULD reduce, as indicated by the oc and oc-algo parameters, the number of requests going downstream to the SIP server from which it received the response ..." 4.3 last sentence should "and the oc-algo parameter." be added on to the sentence? 5.2 overload stability and the value for oc-validity. (NON-NIT) In selecting an oc-validity value, you should also consider the time interval for requests form EACH upstream SIP client. As an extreme example, consider a case where you have thousands of upstream SIP clients, and each one sends a message, typically, once a second. Even if you are adjusting your oc value every 10 milliseconds, you want an oc-validity of at least a second. Otherwise, every time a client gets ready to transmit, it will have an expired oc value, and won't throttle. Something like " A SIP server MAY use a shorter "oc-validity" time if each upstream SIP client attempts to send messages at a high rate, and SHOULD use a longer "oc- validity" time if each SIP client operates at a lower rate." 5.5 first paragraph "The SIP client MUST NOT forward more requests to a SIP server than allowed by the current "oc" parameter value from a particular downstream server." should probably be "The SIP client MUST NOT forward more requests to a SIP server than allowed by the current "oc" parameter value from that particular downstream server." 5.8. This isn't really about "Stabilizing overload control" but about "Stabilizing overload algorithm selection". Suggest changing section title. 5.10.2 last paragraph says "A SIP server that is under overload and has started to throttle incoming traffic MUST reject this request with a "503 (Service Unavailable)" response without Retry-After header to reject a fraction of requests from upstream neighbors that do not support overload control." "fraction" is probably the right word if the server is using a loss based algorithm, but probably not the right word if it is using a rate based algorithm. Maybe "A SIP server that is under overload and has started to throttle incoming traffic MUST reject this request with a "503 (Service Unavailable)" response without Retry-After header to reject some requests from upstream neighbors that do not support overload control." Thanks Happy New Year Janet --=_alternative 0078498485257974_= Content-Type: text/html; charset="US-ASCII"
Finally got a chance to come up for air and take a look at this.

Some comments, mostly nits.  The non-nit is the one about setting oc-validity.

Comments on draft-ietf-soc-overload-control-05

Sec 4.1

Second paragraph refers to "Section X.X".  Probably supposed to be 5.1

Last paragraph - the statement "it SHOULD reduce, by the amount indicated, the
   number of requests going downstream to the SIP server from which it
   received the response ..." is perfectly true for the loss based algorithm, but not technically correct

for the rate based algorithm.

Suggest either adding a "Note" as in other cases where you discuss differences for rate based, or reword
it, possibly
"it SHOULD reduce, as indicated by the oc and oc-algo parameters, the
   number of requests going downstream to the SIP server from which it
   received the response ..."

4.3
last sentence
 should "and the oc-algo parameter." be added on to the sentence?

5.2 overload stability and the value for oc-validity. (NON-NIT)

In selecting an oc-validity value, you should also consider the time interval for requests form EACH
upstream SIP client.

As an extreme example, consider a case where you have thousands of upstream SIP clients, and each one
sends a message, typically, once a second.  Even if you are adjusting your oc value every 10
milliseconds, you want an oc-validity of at least a second.  Otherwise, every time a client gets ready to
transmit, it will have an expired oc value, and won't throttle.

Something like " A SIP server MAY use a shorter "oc-validity" time
   if each upstream SIP client attempts to send messages at a  high rate,  and SHOULD use a longer "oc-
   validity" time if each SIP client  operates at a lower rate."

5.5 first paragraph
"The SIP client
   MUST NOT forward more requests to a SIP server than allowed by the
   current "oc" parameter value from a particular downstream server."
should probably be
"The SIP client
   MUST NOT forward more requests to a SIP server than allowed by the
   current "oc" parameter value from that particular downstream server."

5.8.  This isn't really about "Stabilizing overload control" but about "Stabilizing overload algorithm
selection".  Suggest changing section title.


5.10.2 last paragraph says

"A SIP server that is under overload and has started to throttle
   incoming traffic MUST reject this request with a "503 (Service
   Unavailable)" response without Retry-After header to reject a
   fraction of requests from upstream neighbors that do not support
   overload control."

"fraction" is probably the right word if the server is using a loss based algorithm, but probably not the
right word if it is using a rate based algorithm.

Maybe "A SIP server that is under overload and has started to throttle
   incoming traffic MUST reject this request with a "503 (Service
   Unavailable)" response without Retry-After header to reject some
   requests from upstream neighbors that do not support
   overload control."

Thanks

Happy New Year

Janet
--=_alternative 0078498485257974_=-- From vkg@bell-labs.com Thu Dec 29 08:01:12 2011 Return-Path: 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 515A621F891D for ; Thu, 29 Dec 2011 08:01:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.799 X-Spam-Level: X-Spam-Status: No, score=-105.799 tagged_above=-999 required=5 tests=[AWL=0.800, BAYES_00=-2.599, 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 5w+es-WLU5al for ; Thu, 29 Dec 2011 08:01:11 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id 8934A21F88B7 for ; Thu, 29 Dec 2011 08:01:11 -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 pBTG17U0005278 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 29 Dec 2011 10:01:08 -0600 (CST) Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id pBTG17aV030304 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 29 Dec 2011 10:01:07 -0600 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.235]) by umail.lucent.com (8.13.8/TPES) with ESMTP id pBTG16v5007900; Thu, 29 Dec 2011 10:01:06 -0600 (CST) Message-ID: <4EFC8FA5.6020901@bell-labs.com> Date: Thu, 29 Dec 2011 10:04:53 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111115 Thunderbird/8.0 MIME-Version: 1.0 To: Janet P Gunn References: <4EEA1BB3.7020509@bell-labs.com> <4EFA03EB.3050902@bell-labs.com> In-Reply-To: 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 Cc: sip-overload@ietf.org 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 29 Dec 2011 16:01:12 -0000 On 12/28/2011 03:53 PM, Janet P Gunn wrote: > > Finally got a chance to come up for air and take a look at this. > > Some comments, mostly nits. The non-nit is the one about setting > oc-validity. > > Comments on draft-ietf-soc-overload-control-05 Janet: Thank you for the comments. I have incorporated them as discussed below. > Sec 4.1 > > Second paragraph refers to "Section X.X". Probably supposed to be > 5.1 Already fixed (from a previous comment by Phil). > Last paragraph - the statement "it SHOULD reduce, by the amount > indicated, the number of requests going downstream to the SIP server > from which it received the response ..." is perfectly true for the > loss based algorithm, but not technically correct Eric had the same feedback in a private email exchange. While I pushed back since I did not believed that the statement was not loss-centric, I suspect that given a similar comment from you as well, the passage in question deserves a re-evaluation. So, I have changed it as you indicate below, and hopefully this will have solved Eric's concern as well. > for the rate based algorithm. > > Suggest either adding a "Note" as in other cases where you discuss > differences for rate based, or reword it, possibly "it SHOULD reduce, > as indicated by the oc and oc-algo parameters, the number of requests > going downstream to the SIP server from which it received the > response ..." Changed as follows: OLD: When a SIP client receives a response with the value in the "oc" parameter filled in, it SHOULD reduce, by the amount indicated, the number of requests going downstream to the SIP server from which it received the response (see Section 5.10 for pertinent discussion on traffic reduction). NEW: When a SIP client receives a response with the value in the "oc" parameter filled in, it SHOULD reduce, as indicated by the "oc" and "oc-algo" parameters, the number of requests going downstream to the SIP server from which it received the response (see Section 5.10 for pertinent discussion on traffic reduction). > 4.3 > last sentence > should "and the oc-algo parameter." be added on to the sentence? Since oc-validity is tied to the value of oc, I am more likely to leave it as is (unless you feel strongly about this). > 5.2 overload stability and the value for oc-validity. (NON-NIT) > > In selecting an oc-validity value, you should also consider the time > interval for requests form EACH upstream SIP client. > > As an extreme example, consider a case where you have thousands of > upstream SIP clients, and each one sends a message, typically, once a > second. Even if you are adjusting your oc value every 10 > milliseconds, you want an oc-validity of at least a second. > Otherwise, every time a client gets ready to transmit, it will have > an expired oc value, and won't throttle. > > Something like " A SIP server MAY use a shorter "oc-validity" time if > each upstream SIP client attempts to send messages at a high rate, > and SHOULD use a longer "oc- validity" time if each SIP client > operates at a lower rate." I think your point is valid, but shouldn't this behaviour be specified more appropriately in the rate-based draft? Section 5 in draft-ietf-soc-overload-control-05 outlines general behaviour, not one specific to either rate- or loss-based. > 5.5 first paragraph > "The SIP client > MUST NOT forward more requests to a SIP server than allowed by the > current "oc" parameter value from a particular downstream server." > should probably be > "The SIP client > MUST NOT forward more requests to a SIP server than allowed by the > current "oc" parameter value from that particular downstream server." Fixed. > 5.8. This isn't really about "Stabilizing overload control" but about > "Stabilizing overload algorithm > selection". Suggest changing section title. Done. > 5.10.2 last paragraph says > > "A SIP server that is under overload and has started to throttle > incoming traffic MUST reject this request with a "503 (Service > Unavailable)" response without Retry-After header to reject a > fraction of requests from upstream neighbors that do not support > overload control." > > "fraction" is probably the right word if the server is using a loss > based algorithm, but probably not the > right word if it is using a rate based algorithm. > > Maybe "A SIP server that is under overload and has started to throttle > incoming traffic MUST reject this request with a "503 (Service > Unavailable)" response without Retry-After header to reject some > requests from upstream neighbors that do not support > overload control." Fixed as suggested. I will get the updated draft with these set of changes by tomorrow. > Thanks > > Happy New Year Thank you, and best wishes for a new year to you as well. - 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/