Re: [sip-overload] Review of draft-ietf-soc-overload-rate-control-07.txt
"Vijay K. Gurbani" <vkg@bell-labs.com> Wed, 25 June 2014 15:26 UTC
Return-Path: <vkg@bell-labs.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 B90751B2CFF for <sip-overload@ietfa.amsl.com>; 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 <sip-overload@ietfa.amsl.com>; 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 <sip-overload@ietf.org>; 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" <vkg@bell-labs.com>
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> <E4B3F0DC6D953D4EBEC223BC86FE322C4BCF46E1D6@EMV04-UKBR.domain1.systemhost.net>
In-Reply-To: <E4B3F0DC6D953D4EBEC223BC86FE322C4BCF46E1D6@EMV04-UKBR.domain1.systemhost.net>
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 <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 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
- [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