Re: [sip-overload] AD review: draft-ietf-soc-overload-control-13 (MAJOR ISSUES)

Richard Barnes <rlb@ipv.sx> Wed, 30 October 2013 23:29 UTC

Return-Path: <rlb@ipv.sx>
X-Original-To: sip-overload@ietfa.amsl.com
Delivered-To: sip-overload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B0C5811E8186 for <sip-overload@ietfa.amsl.com>; Wed, 30 Oct 2013 16:29:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.897
X-Spam-Level:
X-Spam-Status: No, score=-2.897 tagged_above=-999 required=5 tests=[AWL=0.079, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WtkRZ5pV3QhW for <sip-overload@ietfa.amsl.com>; Wed, 30 Oct 2013 16:29:17 -0700 (PDT)
Received: from mail-oa0-f47.google.com (mail-oa0-f47.google.com [209.85.219.47]) by ietfa.amsl.com (Postfix) with ESMTP id C6F6511E810C for <sip-overload@ietf.org>; Wed, 30 Oct 2013 16:29:17 -0700 (PDT)
Received: by mail-oa0-f47.google.com with SMTP id i1so2257636oag.6 for <sip-overload@ietf.org>; Wed, 30 Oct 2013 16:29:17 -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:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=Iuc+FBVvSlPzFglvWzOMNb6ZCgdFwZvaWuYAwIY1aTk=; b=NOaGzcWEyaKTAmhdNiWCBUen7qT51Q9ACKYcWwwSBMxhVFkUQKZpPAxb6qP/0Uk+7Q 0eqjZGkLOOU7qyfGQb9K3xMNvM8dmphlJghdNIAYGi18necD+p3agKAycyP7Z7OJagVb TcaNUXdfWPd+lXV9Fl1mIHefV5tumetOL1VpzXWEE8MT6lGNwVXCPmNpTm+9pqSw3Iv6 aoTgKAQFdbXXZOMa+aXjwaaHlDGW9ySOg2p+htF6jfi6ZwqWBBKv8opv01bubiSbonk/ Yl3m0u3ovB8HjkXke9s0YwOx3Q1XAYg74QFcgpfQs/k/VyPohnolpmkHSKtgu33JPqzo +yIQ==
X-Gm-Message-State: ALoCoQkg8H8CuIDo9XxNIolnNWEstgCG3oVdW3qpiHQoemJ6X4iw/RgJjGHpuhSEqO2yWmQ8dE1g
MIME-Version: 1.0
X-Received: by 10.182.101.134 with SMTP id fg6mr201816obb.30.1383175756910; Wed, 30 Oct 2013 16:29:16 -0700 (PDT)
Received: by 10.76.101.10 with HTTP; Wed, 30 Oct 2013 16:29:16 -0700 (PDT)
In-Reply-To: <5271813C.606@bell-labs.com>
References: <520564B6.7040304@bell-labs.com> <CAL02cgSov68ub=Djrst=V+=f0oPHY_HFMEb6jOuerWYAaxtRxQ@mail.gmail.com> <5271813C.606@bell-labs.com>
Date: Wed, 30 Oct 2013 19:29:16 -0400
Message-ID: <CAL02cgTn3jzwf2T2YhWAYg8QmctNaNY2QyNpW=j3W7jV8hjKOw@mail.gmail.com>
From: Richard Barnes <rlb@ipv.sx>
To: "Vijay K. Gurbani" <vkg@bell-labs.com>
Content-Type: multipart/alternative; boundary=e89a8ff250e0a72bba04e9fdb399
Cc: "sip-overload@ietf.org" <sip-overload@ietf.org>
Subject: Re: [sip-overload] AD review: draft-ietf-soc-overload-control-13 (MAJOR ISSUES)
X-BeenThere: sip-overload@ietf.org
X-Mailman-Version: 2.1.12
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, 30 Oct 2013 23:29:21 -0000

All that looks good to me!

On Wednesday, October 30, 2013, Vijay K. Gurbani wrote:

> On 10/29/2013 01:32 PM, Richard Barnes wrote:
>
>> Hey Vijay,
>>
>> Thanks for following up in detail.  Catching up with this now.
>> Responses inline.
>>
>
> Richard: Thank you for your time and a close read.  More inline,
> please.
>
>  In retrospect, I may have been a little persnickety about this.  What I
>> meant was that simply having a timestamp with a value less than a
>> previous one is not sufficient to detect overflow, because messages can
>> arrive out of order (as the document notes).  It seems like for overflow
>> detection, you could just require that the oc-seq value be
>> *significantly* below recent values, or below all values used in a time
>> window.
>>
>> Also, if overflow can be detected, then shouldn't the new message be
>> accepted and used, even though the oc-seq value is lower?
>>
>> It's actually a little more troubling that the field is not actually
>> defined to be an unsigned integer AFAICT.  Could we define this to be a
>> 32-bit or 64-bit unsigned integer?  Otherwise, talking about comparisons
>> is kind of ill-defined.
>>
>> Suggested text:
>> OLD: "This parameter contains a value..."
>> NEW: "This parameter contains a unsigned integer value..."
>>
>
> Sure, I will make that change.
>
>  OLD:
>> """
>> Due to an overflow, client implementations should be prepared to receive
>> an "oc-seq" parameter whose value is less than the previous value.
>> Client implementations can handle this by continuing to perform overload
>> control until the "oc-validity" related to the previous value of
>> "oc-seq" parameter expires.
>> """
>> NEW:
>> """
>> A client implementation can recognize that an overflow has occurred when
>> if it receives an "oc-seq" parameter whose value is significantly less
>> than the last several previous values.  If an overflow is detected, then
>> the client should use the overload parameters in the new message, even
>> though the sequence number is lower.  The client should also reset any
>> internal state to reflect the overflow so that future messages
>> (following the overflow) will be accepted.
>> """
>>
>
> Sure, this is good as well.  One small modification I would suggest is
> to expand on the term "significantly" to provide context to
> implementers.  Absent such a context, the term looses its, well,
> significance, as time passes.
>
> So, I would very slightly modify your proposal above as follows:
>
>    A client implementation can recognize that an overflow has
>    occurred when it receives an "oc-seq" parameter whose value
>    is significantly less than several previous values.  (Note that
>    an "oc-seq" parameter whose value does not deviate significantly
>    from the last several previous values is symptomatic of a tardy
>    packet.  However, overflow will cause "oc-seq" an "oc-seq"
>    parameter value to be significantly less than the last several
>    values.)  If an overflow is detected, then the client should
>    use the overload parameters in the new message, even though the
>    sequence number is lower.  The client should also reset any
>    internal state to reflect the overflow so that future messages
>    (following the overflow) will be accepted.
>
> Let me know if you have any concerns on such an edit.
>
>  We probably don't need to be as specific as my initial suggestion, but I
>> think it would be good to note that liveness checks are a source of
>> load.  Suggested text:
>>
>> OLD:
>> """
>> The SIP client SHOULD periodically probe if the downstream server is
>> alive using any mechanism at its disposal.
>> """
>>
>> NEW:
>> """
>> The SIP client SHOULD periodically probe if the downstream server is
>> alive using any mechanism at its disposal.  Clients should be
>> conservative in their probing (e.g., using an exponential back-off) so
>> that their liveness probes do not exacerbate an overload situation.
>> """
>>
>
> Sure, sounds reasonable.
>
> Regarding the security considerations, you wrote:
>
>  Overall, pretty good.  Couple of minor things inline.
>>
>
> I will circle back on the security considerations with a fresh mind
> sometimes in the morning and get back to you.  Generally, I think what
> you write seems reasonable here, but I will like to look at the changes
> with a fresh set of eyes.
>
> Thank you so much.
>
> - 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/<http://ect.bell-labs.com/who/vkg/> | Calendar:
> http://goo.gl/x3Ogq
>