[sip-overload] Review of draft-ietf-soc-overload-rate-control-07.txt
"Vijay K. Gurbani" <vkg@bell-labs.com> Wed, 04 June 2014 19:08 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 BABA81A02DA for <sip-overload@ietfa.amsl.com>; 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 <sip-overload@ietfa.amsl.com>; 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 <sip-overload@ietf.org>; 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" <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: 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" <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 <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, 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
- [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