[sip-overload] AD review of draft-ietf-soc-overload-rate-control

Richard Barnes <rlb@ipv.sx> Fri, 08 August 2014 20:55 UTC

Return-Path: <rlb@ipv.sx>
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 2C6361A0197 for <sip-overload@ietfa.amsl.com>; Fri, 8 Aug 2014 13:55:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.976
X-Spam-Status: No, score=-1.976 tagged_above=-999 required=5 tests=[AC_DIV_BONANZA=0.001, BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id EYdtYr223L83 for <sip-overload@ietfa.amsl.com>; Fri, 8 Aug 2014 13:55:21 -0700 (PDT)
Received: from mail-oi0-f47.google.com (mail-oi0-f47.google.com []) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3F5261A0158 for <sip-overload@ietf.org>; Fri, 8 Aug 2014 13:55:21 -0700 (PDT)
Received: by mail-oi0-f47.google.com with SMTP id x69so4016917oia.34 for <sip-overload@ietf.org>; Fri, 08 Aug 2014 13:55:20 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:date:message-id:subject:from:to :content-type; bh=cgDTjU9JEGjc6Wy1xX2kQPguZ55CrceiSlULxvWdrSA=; b=CO71b1MDoeitPW1sQa3zuizrrtujkVHaiTfpbCnIVOOo7Ec0C3OCILhTyQs3TQOoJx lTdaAnKeJcmAA5p9eLl5Q8FzulwKsPrhtMuN8zM7q8yhM31sEBq8IAr8Ja+KgaxtqHQN PuiuJa0/wRmeLlUXG6J7Rl+EylYftQjubpeTtd9vDHihHSDEfiK6CibFgX8MRRGw/VkJ KfbO/K0zn2VVooNB/gbsiZiqleR3h1pX+sqFgqNQXSb6HoyASuJIDYd8giInKeYb1qDh jfQSh86MapWCHfVZTzt6xVYVp9slICnSZeSWkzn0YYiE0eHl2rontaszX3J7cv+Z0Dc7 TYdg==
X-Gm-Message-State: ALoCoQmYXy3/C8V5ipfc3OWfLqysInwT6QNoHTmjpyuOLzJk1d+gVOwna2VzrzsNAGJQeYFUH0XN
MIME-Version: 1.0
X-Received: by with SMTP id wd6mr5307494obc.87.1407531320578; Fri, 08 Aug 2014 13:55:20 -0700 (PDT)
Received: by with HTTP; Fri, 8 Aug 2014 13:55:20 -0700 (PDT)
Date: Fri, 8 Aug 2014 16:55:20 -0400
Message-ID: <CAL02cgTnFYK-69RTjebqwVABwp8T8a2rOBcFzYWtQnfgqBVK8A@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: "sip-overload@ietf.org" <sip-overload@ietf.org>, draft-ietf-soc-overload-rate-control@tools.ietf.org
Content-Type: multipart/alternative; boundary=089e01634d745faf040500246c9d
Archived-At: http://mailarchive.ietf.org/arch/msg/sip-overload/o3GZ9gfMdycXJCeFFkf946guzCE
Subject: [sip-overload] AD review of draft-ietf-soc-overload-rate-control
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: Fri, 08 Aug 2014 20:55:23 -0000

I have reviewed this document in preparation for IETF LC.  Overall, it's a
nice read, thanks!  I have requested LC, and there are a few comments below
that I would like you to address along with any LC comments.


Section 2. "The normative statements in this specification ... that does
not support this specification."
This paragraph seems tautological to me.  "An implementation must support
this protocol only if it supports this protocol."  Are you trying to say
something different, maybe clarifying that requirements apply to the client
and the server separately?  Or can this paragraph be deleted?

Section 3.4. "server must allocate"
This isn't actually true, is it?  The server could set oc=0, in which case
the client would send no messages.  This seems more like a suggestion,

Section 3.5. "1/T"
The paramter T is not defined before this.  Suggest adding a paragraph to
the beginning of this section of the form
The "oc" parameter defines the maximum number of messages per second that
the client may send to the server.  In the below discussion, we will
instead refer to the arrival rate T = 1/oc-value.

Section 6.
I expect that this section is a little too minimal to get past the Security
ADs.  I would suggest a few more words, of the form:
Aside from the resonance concerns discussed in Section 3.5.3, this
mechanism does not introduce any security concerns beyond the general
overload-control security issues discussed in
[draft-ietf-soc-overload-control-15].  Methods to mitigate the risk of
resonance are discussed in Section 3.5.3.


Section 3.2.
It would be very helpful if you could include a brief example Via header at
the end of this section, showing how the oc-algo and oc parameters are set
to indicate a particular level of rate control.

Section 3.4. "is the client responsibility" -> "is the client's

Section 3.5.1. "negotiated independently" -> "negotiated out of band"
"Independently" suggests (to me) that the client and and server do it
independently of one another.

Section 3.5.1. "any other equivalent algorithm" -> "any other algorithm
meeting the upper bound of 1/T messages per second"
Also, this seems redundant with the previous paragraph.  Can one of them be

Section 3.5.1. "Servers with a very large number of clients..."
It seems odd for this paragraph to be written in terms of server benefit,
since clients are the ones that choose TAU values.  Rephrase as guidance to
clients, or optionally what the server might tell clients if there's an
out-of-band way for them to configure this?