From nobody Wed Jun 4 12:08:24 2014 Return-Path: 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 BABA81A02DA for ; Wed, 4 Jun 2014 12:08:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 oNpur7-re2qv for ; Wed, 4 Jun 2014 12:08:20 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 345F71A007B for ; Wed, 4 Jun 2014 12:08:20 -0700 (PDT) Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id s54J8A7p019377 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 4 Jun 2014 14:08:11 -0500 (CDT) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail3.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id s54J8Ado008734 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Jun 2014 14:08:10 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.169]) by umail.lucent.com (8.13.8/TPES) with ESMTP id s54J89Kc027701; Wed, 4 Jun 2014 14:08:10 -0500 (CDT) Message-ID: <538F6F23.90907@bell-labs.com> Date: Wed, 04 Jun 2014 14:10:27 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: draft-ietf-soc-overload-rate-control@tools.ietf.org Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11 Archived-At: http://mailarchive.ietf.org/arch/msg/sip-overload/lUrJNg3hXTTN4opHyr5SiMPR2vo Cc: "sip-overload@ietf.org" Subject: [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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 04 Jun 2014 19:08:22 -0000 Eric, Philip: I was asked by the chairs to review draft-ietf-soc- overload-rate-control-07.txt. 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 ..." - S1, fourth paragraph, last sentence: s/loss approach./loss-based approach./ - 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? - S3.3, first paragraph: s/string "rate"/token "rate"/ (in 2 places) - 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. - 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. 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: ... - S4: In the SIP messages of the example, there appear to be spurious new lines between header elements. Plus, when a continuation appears on a new line in SIP, the first token of the new line has a LWS. Thus, the Via line in the INVITE is best written as: Via: SIP/2.0/TLS p1.example.net; branch=z9hG4bK2d4790.1;received=192.0.2.111; oc;oc-algo="loss,rate" and similarly for the response. - S6: I suspect that this draft can refer to the Security Considerations section of [draft-ietf-soc-overload-control-15] by reference instead of by value (so to speak). Of more interest would be a discussion of threats specific to the rate- based algorithm (if there aren't any, or if all such threats are subsumed by the discussion in [draft-ietf-soc-overload-control-15], then simply say so). 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 From nobody Fri Jun 13 07:09:02 2014 Return-Path: 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 55D551B290F for ; Fri, 13 Jun 2014 07:09:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.252 X-Spam-Level: X-Spam-Status: No, score=-3.252 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 ug-gRk9Hkil8 for ; Fri, 13 Jun 2014 07:08:58 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.137]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 969721B2869 for ; Fri, 13 Jun 2014 07:08:57 -0700 (PDT) Received: from EVMHT01-UKBR.domain1.systemhost.net (193.113.108.42) by EVMED03-UKBR.bt.com (10.216.161.33) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 13 Jun 2014 15:08:52 +0100 Received: from EMV04-UKBR.domain1.systemhost.net ([169.254.2.216]) by EVMHT01-UKBR.domain1.systemhost.net ([193.113.108.42]) with mapi; Fri, 13 Jun 2014 15:08:55 +0100 From: To: Date: Fri, 13 Jun 2014 15:08:54 +0100 Thread-Topic: [sip-overload] Review of draft-ietf-soc-overload-rate-control-07.txt Thread-Index: Ac+AKFv/mTNplpkfSey+LSSEezmShQGFgQiA Message-ID: References: <538F6F23.90907@bell-labs.com> In-Reply-To: <538F6F23.90907@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 Archived-At: http://mailarchive.ietf.org/arch/msg/sip-overload/NG-mTrpW7Ylr2O90VoRnekre0KY 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 X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Jun 2014 14:09:01 -0000 Vijay, Thanks for your comments. My responses embedded below. I think Eric may res= pond next week. I can suggest some more specific suggested wording/revisions for my first s= omewhat lengthy reply, but I was hoping to get some other views about this = first. Regards, Phil > -----Original Message----- > From: sip-overload [mailto:sip-overload-bounces@ietf.org] On Behalf Of > Vijay K. Gurbani > Sent: 04 June 2014 20:10 > To: draft-ietf-soc-overload-rate-control@tools.ietf.org > Cc: sip-overload@ietf.org > Subject: [sip-overload] Review of draft-ietf-soc-overload-rate-control- > 07.txt >=20 > Eric, Philip: I was asked by the chairs to review draft-ietf-soc- > overload-rate-control-07.txt. >=20 > Here are my comments, in document order. Generally, the draft is well > written; some of the comments below may be helpful. >=20 > - 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 k= now that I have been. I suggest that we should be more explicit about how t= hey differ, because the intention is that they are essentially the same (us= ing the same framework) but with a few key differences. E.g. one possible interpretation might be that SIP Rate Control is a 'speci= alisation' (or 'extension'?) of SIP Overload Control. By this I mean that (= logical implication) conformance to SIP Rate Control =3D> conformance to SIP Overload Control However one of the features of SIP Overload Control is that the loss-based = method must be supported by both clients and servers (the latter follows be= cause if a client only specifies "loss" then the server has no other choice= ). Therefore since both client and server must support the rate-based metho= d for SIP Rate Control, the 'specialisation' interpretation would imply tha= t for SIP Rate Control clients and servers would support both methods. Howe= ver there isn't any statement in draft-ietf-soc-overload-rate-control-07 th= at clients must support the loss-based method as well. On the other hand an= 'alternative' interpretation could be that neither the client nor the serv= er are required to support the loss-based method (but may do). This would b= e similar to SIP Overload Control where, in terms of default/mandatory meth= od, the roles of 'loss' and 'rate' are transposed (in fact one can map 5.1-= Determining support for overload control from draft-ietf-soc-overload-contr= ol-15 in this way). I expect that this is the intention. In this case it w= ould be worth stating this explicitly - in addition to the mandatory refere= nces to the rate-based method - just for clarity. A natural place to do thi= s would be in the last paragraph of 3.3. So which is really intended - 'alternative' or 'specialisation'? I have arg= ued in the past that clients should support both and it is the server that = should dictate the method, so I would be happy with 'specialisation', but I= appreciate that others would not be given the outcome of the earlier debat= e about SIP Overload Control, which gave rise to the creation of this SIP R= ate Control draft. In any case if we go for 'alternative' then the two sets= of requirements are compatible, i.e. if it is required to conform to SIP O= verload Control AND SIP Rate Control then it follows that clients and serve= rs should support both algorithms. This gives flexibility for practical imp= lementation [the only issue I have with this is that it is a stronger requi= rement than may be required in many situations - where we want all clients = to support both methods, but servers can support only one of them]. To summarise, if the intention is an 'alternative' set of requirements, whi= ch is the same as SIP Overload Control, but where the default(mandatory) re= striction algorithm is rate-based rather than loss-based (the latter being = optional), then it would be helpful to state this explicitly. > =20 > - S1, fourth paragraph, last sentence: s/loss approach./loss-based > approach./ [PhilW] Agreed. >=20 > - 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 i= s not the desired rate, but the desired maximum rate. I would be happy to m= ove 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 max= imum rate. They are defined in [draft-ietf-soc-overload-control-14] and summarized below... >=20 > - S3.3, first paragraph: s/string "rate"/token "rate"/ > (in 2 places) [PhilW] OK. >=20 > - 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 gramma= r is incorrect - would this do "...at a rate below their target (maximum) = request rate..."? >=20 > - 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 a= lgorithm in 5.10.1 of draft-ietf-soc-overload-control-15, and my interpreta= tion is that this section doesn't necessarily imply just two levels of prio= rity (say normal and 'priority'). In fact since several types of 'high prio= rity' requests are discussed in 5.10.1, one can envisage that they may be c= lassed as different priority levels, although I am not necessarily implying= that is necessarily a good approach from a performance perspective. >=20 > 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: >=20 > 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 le= ast two categories' >=20 > - S4: In the SIP messages of the example, there appear to be spurious > new lines between header elements. Plus, when a continuation appears > on a new line in SIP, the first token of the new line has a LWS. > Thus, the Via line in the INVITE is best written as: >=20 > Via: SIP/2.0/TLS p1.example.net; > branch=3Dz9hG4bK2d4790.1;received=3D192.0.2.111; > oc;oc-algo=3D"loss,rate" >=20 > and similarly for the response. [PhilW] Agreed. >=20 > - S6: I suspect that this draft can refer to the Security Considerations > section of [draft-ietf-soc-overload-control-15] by reference instead > of by value (so to speak). [PhilW] Yes - reference would be better in order to ensure everything is ke= pt up-to-date. >=20 > Of more interest would be a discussion of threats specific to the > rate-based algorithm (if there aren't any, or if all such threats are > subsumed by the discussion in [draft-ietf-soc-overload-control-15], > then simply say so). [PhilW] I think it is covered by draft-ietf-soc-overload-control-15. In fac= t in that discussion it does point out that there is a difference in the ab= ility of the overloaded server to police arriving traffic rates from specif= ic clients, i.e. since it does not know the arrival rate at the client befo= re restriction, for proportional rejection (loss-based) the server does not= know whether the client is conforming, whereas for the rate-based method t= he server will know it isn't if the rate it receives from a client exceeds = the control rate significantly between updates. >=20 > Thanks, >=20 > - 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 >=20 > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload From nobody Wed Jun 25 08:26:21 2014 Return-Path: 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 B90751B2CFF for ; Wed, 25 Jun 2014 08:26:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 l4Al5lyyze7j for ; Wed, 25 Jun 2014 08:26:16 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4A6851B2CB7 for ; Wed, 25 Jun 2014 08:26:15 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id s5PFQB0B025073 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Jun 2014 10:26:11 -0500 (CDT) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id s5PFQB34024718 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Jun 2014 10:26:11 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.169]) by umail.lucent.com (8.13.8/TPES) with ESMTP id s5PFQASI019535; Wed, 25 Jun 2014 10:26:10 -0500 (CDT) Message-ID: <53AAEAAC.3010408@bell-labs.com> Date: Wed, 25 Jun 2014 10:28:44 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: phil.m.williams@bt.com References: <538F6F23.90907@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.64 on 135.3.39.12 Archived-At: http://mailarchive.ietf.org/arch/msg/sip-overload/LgPUZaFNUVu-Ps2RdGukvKXkYmk 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 X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 15:26:19 -0000 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. >> - S1, fourth paragraph, last sentence: s/loss approach./loss-based >> approach./ > [PhilW] 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. >> - 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. >> - 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. 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 From nobody Wed Jun 25 10:24:37 2014 Return-Path: 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 ; 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 ; 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 ; 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 ); 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 ); 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" To: "Vijay K. Gurbani" , "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> <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: X-SOURCE-IP: [144.160.229.24] Archived-At: http://mailarchive.ietf.org/arch/msg/sip-overload/MNAkloFh8djUYGT5WvHGvbg1Fx0 Cc: "sip-overload@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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=20 AT&T Labs, Inc.=20 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 Vija= y 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-contr= ol-15], =20 this document proposes an alternate overload control, the rate-based overl= oad=20 control algorithm. The rate-based control algorithm guarantees an upper bo= und ..." >> - 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 gram= mar > 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],= =20 a client implementing the rate-based algorithm also prioritizes messages into two or more categories of requests: ..." Thanks, - vijay --=20 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 From nobody Wed Jun 25 10:29:00 2014 Return-Path: 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 106A51B2D4B for ; Wed, 25 Jun 2014 10:28:59 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5] 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 PGnnCK2vYfQL for ; Wed, 25 Jun 2014 10:28:55 -0700 (PDT) Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 459351B2AD9 for ; Wed, 25 Jun 2014 10:28:55 -0700 (PDT) Received: from usnavsmail4.ndc.alcatel-lucent.com (usnavsmail4.ndc.alcatel-lucent.com [135.3.39.12]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id s5PHSHUc017379 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 25 Jun 2014 12:28:17 -0500 (CDT) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail4.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id s5PHSGCI028873 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 25 Jun 2014 12:28:17 -0500 Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.169]) by umail.lucent.com (8.13.8/TPES) with ESMTP id s5PHSGRk003177; Wed, 25 Jun 2014 12:28:16 -0500 (CDT) Message-ID: <53AB074A.8050309@bell-labs.com> Date: Wed, 25 Jun 2014 12:30:50 -0500 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: "NOEL, ERIC C" , "phil.m.williams@bt.com" References: <538F6F23.90907@bell-labs.com> <53AAEAAC.3010408@bell-labs.com> <432544DCDB78E046B9E22D0EE8F419030104DEA6@MISOUT7MSGUSRDC.ITServices.sbc.com> In-Reply-To: <432544DCDB78E046B9E22D0EE8F419030104DEA6@MISOUT7MSGUSRDC.ITServices.sbc.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.64 on 135.3.39.12 Archived-At: http://mailarchive.ietf.org/arch/msg/sip-overload/SJ6TbNtYTMzMycMEI1zaT92M344 Cc: "sip-overload@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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 25 Jun 2014 17:28:59 -0000 On 06/25/2014 12:23 PM, NOEL, ERIC C wrote: > Vijay, Phil, thanks for the comments and suggestions. > > I added resolutions in-line below. [...] > 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 ..." Eric: Works for me. The rest of the conversation was mostly in agreement, so I will not quote it here. 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