[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 []) 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-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 ([]) by localhost (ietfa.amsl.com []) (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 []) (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 []) 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 []) 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 []) 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
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-

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

- 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

  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;

  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).


- 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