Re: [sip-overload] Review of draft-ietf-soc-overload-rate-control-07.txt
"NOEL, ERIC C" <en5192@att.com> Wed, 25 June 2014 17:24 UTC
Return-Path: <en5192@att.com>
X-Original-To: sip-overload@ietfa.amsl.com
Delivered-To: sip-overload@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71EC21B2D84 for <sip-overload@ietfa.amsl.com>; Wed, 25 Jun 2014 10:24:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.851
X-Spam-Level:
X-Spam-Status: No, score=-4.851 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KSROGASvL4kt for <sip-overload@ietfa.amsl.com>; Wed, 25 Jun 2014 10:24:30 -0700 (PDT)
Received: from nbfkord-smmo05.seg.att.com (nbfkord-smmo05.seg.att.com [209.65.160.92]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6851E1B2D87 for <sip-overload@ietf.org>; Wed, 25 Jun 2014 10:24:30 -0700 (PDT)
Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) with ESMTP id ec50ba35.2b22ece9a940.1105690.00-2426.3030377.nbfkord-smmo05.seg.att.com (envelope-from <en5192@att.com>); Wed, 25 Jun 2014 17:24:30 +0000 (UTC)
X-MXL-Hash: 53ab05ce46311062-35d5022ee5326a3893d3be03c875c50464bedd9e
Received: from unknown [144.160.229.24] (EHLO alpi155.enaf.aldc.att.com) by nbfkord-smmo05.seg.att.com(mxl_mta-7.2.1-0) over TLS secured channel with ESMTP id 9b50ba35.0.1105444.00-1899.3029688.nbfkord-smmo05.seg.att.com (envelope-from <en5192@att.com>); Wed, 25 Jun 2014 17:24:13 +0000 (UTC)
X-MXL-Hash: 53ab05bd2470f7ac-7aa9bd0a05174e52972a59bea7a9b617383da799
Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s5PHO9bE003151; Wed, 25 Jun 2014 13:24:09 -0400
Received: from mlpi407.sfdc.sbc.com (mlpi407.sfdc.sbc.com [130.9.128.239]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id s5PHO01I003024 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 25 Jun 2014 13:24:01 -0400
Received: from MISOUT7MSGHUBAE.ITServices.sbc.com (MISOUT7MSGHUBAE.itservices.sbc.com [130.9.129.149]) by mlpi407.sfdc.sbc.com (RSA Interceptor); Wed, 25 Jun 2014 17:23:43 GMT
Received: from MISOUT7MSGUSRDC.ITServices.sbc.com ([169.254.3.141]) by MISOUT7MSGHUBAE.ITServices.sbc.com ([130.9.129.149]) with mapi id 14.03.0174.001; Wed, 25 Jun 2014 13:23:43 -0400
From: "NOEL, ERIC C" <en5192@att.com>
To: "Vijay K. Gurbani" <vkg@bell-labs.com>, "phil.m.williams@bt.com" <phil.m.williams@bt.com>
Thread-Topic: [sip-overload] Review of draft-ietf-soc-overload-rate-control-07.txt
Thread-Index: AQHPgChj2wFDhq/GbEusmX+lpS30fZtvZMEAgBLySQD//9ImAA==
Date: Wed, 25 Jun 2014 17:23:41 +0000
Message-ID: <432544DCDB78E046B9E22D0EE8F419030104DEA6@MISOUT7MSGUSRDC.ITServices.sbc.com>
References: <538F6F23.90907@bell-labs.com> <E4B3F0DC6D953D4EBEC223BC86FE322C4BCF46E1D6@EMV04-UKBR.domain1.systemhost.net> <53AAEAAC.3010408@bell-labs.com>
In-Reply-To: <53AAEAAC.3010408@bell-labs.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [135.91.97.249]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-RSA-Inspected: yes
X-RSA-Classifications: public
X-AnalysisOut: [v=2.0 cv=OJ6QK1mB c=1 sm=1 a=dhB6nF3YHL5t/Ixux6cINA==:17 a]
X-AnalysisOut: [=IpeXJiYOrl0A:10 a=ofMgfj31e3cA:10 a=T371OWOketIA:10 a=BLc]
X-AnalysisOut: [eEmwcHowA:10 a=kj9zAlcOel0A:10 a=zQP7CpKOAAAA:8 a=XIqpo32R]
X-AnalysisOut: [AAAA:8 a=48vgC7mUAAAA:8 a=e9qsufxtAAAA:8 a=N54-gffFAAAA:8 ]
X-AnalysisOut: [a=gxZvrgisAAAA:8 a=C3I3ZF1iAAAA:8 a=_b_RclnsAAAA:20 a=9tQV]
X-AnalysisOut: [VCdFAAAA:20 a=HtYIgt-ClAZp3w7tKh0A:9 a=CjuIK1q_8ugA:10 a=Q]
X-AnalysisOut: [YbaF5LxmtMA:10 a=V4Yg_9LqF70A:10 a=jd7AbVFD4xwA:10 a=Hz7Ir]
X-AnalysisOut: [DYlS0cA:10 a=lZB815dzVvQA:10 a=W1qU_X6G3J8A:10 a=sK9FX98U6]
X-AnalysisOut: [w4A:10 a=nAPXUAfsBmEA:10 a=3FZX-ydVlcEA:10]
X-Spam: [F=0.2000000000; CM=0.500; S=0.200(2014051901)]
X-MAIL-FROM: <en5192@att.com>
X-SOURCE-IP: [144.160.229.24]
Archived-At: http://mailarchive.ietf.org/arch/msg/sip-overload/MNAkloFh8djUYGT5WvHGvbg1Fx0
Cc: "sip-overload@ietf.org" <sip-overload@ietf.org>, "draft-ietf-soc-overload-rate-control@tools.ietf.org" <draft-ietf-soc-overload-rate-control@tools.ietf.org>
Subject: Re: [sip-overload] Review of draft-ietf-soc-overload-rate-control-07.txt
X-BeenThere: sip-overload@ietf.org
X-Mailman-Version: 2.1.15
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: Wed, 25 Jun 2014 17:24:34 -0000
Vijay, Phil, thanks for the comments and suggestions. I added resolutions in-line below. Thanks, Eric Noel AT&T Labs, Inc. Rethink Possible Optimization, Reliability and Customer Analytics 200 South Laurel Avenue, D5-3D19 Middletown, NJ 07748 P: 732.420.4174 ecnoel@att.com -----Original Message----- From: sip-overload [mailto:sip-overload-bounces@ietf.org] On Behalf Of Vijay K. Gurbani Sent: Wednesday, June 25, 2014 11:29 AM To: phil.m.williams@bt.com Cc: draft-ietf-soc-overload-rate-control@tools.ietf.org; sip-overload@ietf.org Subject: Re: [sip-overload] Review of draft-ietf-soc-overload-rate-control-07.txt On 06/13/2014 09:08 AM, phil.m.williams@bt.com wrote: > Vijay, > > Thanks for your comments. My responses embedded below. I think > Eric may respond next week. > > I can suggest some more specific suggested wording/revisions for > my first somewhat lengthy reply, but I was hoping to get some > other views about this first. Phil: Please see inline. Issues that we agreed on are removed from inlining below. >> Here are my comments, in document order. Generally, the draft is well >> written; some of the comments below may be helpful. >> >> - S1, fourth paragraph: The rate-control draft is not as much an >> extension to draft-ietf-soc-overload-control as much as it is >> a specification for an alternative overload control mechanism. >> As such, probably best to state that "This document proposes an >> alternative, rate-based overload control algorithm within the >> framework defined in [draft-ietf-soc-overload-control-15]. The >> rate-based control algorithm guarantees an upper bound ..." > > [PhilW] Please excuse me for a bit of semantic ramble: I suspect that > some readers may get confused about how the two specs relate to each > other - I know that I have been. I suggest that we should be more > explicit about how they differ, because the intention is that they > are essentially the same (using the same framework) but with a few > key differences. [...] > To summarise, if the intention is an 'alternative' set of > requirements, which is the same as SIP Overload Control, but where > the default(mandatory) restriction algorithm is rate-based rather > than loss-based (the latter being optional), then it would be > helpful to state this explicitly. The intention of the WG was that the rate-control draft contain a overload based scheme that is not loss-based, the tautological impact of the first half of this sentence notwithstanding. The only default and m-t-i algorithm that the WG decided to go with is loss-based. However, the framework makes provisions to plug in other algorithms. And rate-based is one of them. Insofar as requirements are concerned, I don't see that the rate-control draft imposes an "alternative set of requirements" as stated above. The requirements of overload are satisfied by the overload-control draft, so I am at a loss to see why rate-control is deriving new requirements when we consider it as an alternative overload scheme. Supporting rate-control implies supporting overload-control. An implementation cannot say it supports overload control if it only implements the rate-control scheme and nothing else. EN> Suggest: "In accordance with the framework defined in [draft-ietf-soc-overload-control-15], this document proposes an alternate overload control, the rate-based overload control algorithm. The rate-based control algorithm guarantees an upper bound ..." >> - S1, fourth paragraph, last sentence: s/loss approach./loss-based >> approach./ > [PhilW] Agreed. EN> Agreed >> >> - S3.2: I am not sure what is the implication of the last paragraph. >> I suspect a value in the oc parameter that triggers overload control >> at the client informs the client of "overload state". Why this >> overload state occurred (i.e., what resources are being exhausted by >> the server) is rather immaterial at the client, no? > > [PhilW] I'm not sure of the intended meaning here either - furthermore it > is not the desired rate, but the desired maximum rate. I would be happy > to move it to the start of the section (or delete it altogether), i.e. > 3.2. Via header field parameters for overload control > The use of the via header oc parameter(s) inform clients of the > desired maximum rate. They are defined in > [draft-ietf-soc-overload-control-14] and summarized below... Either of these actions is fine. I have no preference. EN> Adopting Phil's edit >> - S3.4, sixth paragraph: "... at a rate below its target SIP request >> rate..." Here, "its" refers to client? or server? I think it is the >> client, but some clarification would be good. > [PhilW] Yes it is a little ambiguous but I think this is because the grammar > is incorrect - would this do "...at a rate below their target (maximum) > request rate..."? Yes. EN> Agreed >> - S3.5.2: the fact that the client maintains two categories of requests, >> one subject to reduction and the other not, is an artifact of the >> loss-based algorithm in [draft-ietf-soc-overload-control-15]. Thus, I >> don't think that this is a requirement of [draft-ietf-soc-overload- >> control-15] as much as an artifact of how the loss-based algorithm >> works. > [PhilW] I don't think that there is such a dependence upon the loss-based > algorithm in 5.10.1 of draft-ietf-soc-overload-control-15, and my > interpretation is that this section doesn't necessarily imply just > two levels of priority (say normal and 'priority'). In fact since several > types of 'high priority' requests are discussed in 5.10.1, one can > envisage that they may be classed as different priority levels, although > I am not necessarily implying that is necessarily a good approach from > a performance perspective. Sure ... >> That said, almost any client will automatically gravitate towards two >> similar categories. Thus it is best to specify the opening sentence >> of S3.5.2 as follows: >> >> As with the loss-based algorithm of [draft-ietf-soc-overload- >> control-15], a client implementing the rate-based algorithm also >> prioritizes messages into two categories of requests: ... > [PhilW] I suggest that this should read 'two or more categories', > or 'at least two categories' ... works for me. EN>Suggest: "As with the loss-based algorithm of [draft-ietf-soc-overload-control-15], a client implementing the rate-based algorithm also prioritizes messages into two or more categories of requests: ..." Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq _______________________________________________ sip-overload mailing list sip-overload@ietf.org https://www.ietf.org/mailman/listinfo/sip-overload
- [sip-overload] Review of draft-ietf-soc-overload-… Vijay K. Gurbani
- Re: [sip-overload] Review of draft-ietf-soc-overl… phil.m.williams
- Re: [sip-overload] Review of draft-ietf-soc-overl… Vijay K. Gurbani
- Re: [sip-overload] Review of draft-ietf-soc-overl… NOEL, ERIC C
- Re: [sip-overload] Review of draft-ietf-soc-overl… Vijay K. Gurbani