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

"Vijay K. Gurbani" <vkg@bell-labs.com> Wed, 30 October 2013 21:59 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 (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41DFC11E81B4 for <sip-overload@ietfa.amsl.com>; Wed, 30 Oct 2013 14:59:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.519
X-Spam-Level:
X-Spam-Status: No, score=-110.519 tagged_above=-999 required=5 tests=[AWL=0.080, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 iAvPJ9RJTU2x for <sip-overload@ietfa.amsl.com>; Wed, 30 Oct 2013 14:59:40 -0700 (PDT)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfa.amsl.com (Postfix) with ESMTP id 3FECB11E8182 for <sip-overload@ietf.org>; Wed, 30 Oct 2013 14:59:40 -0700 (PDT)
Received: from usnavsmail3.ndc.alcatel-lucent.com (usnavsmail3.ndc.alcatel-lucent.com [135.3.39.11]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id r9ULxda4023574 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Wed, 30 Oct 2013 16:59:39 -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 r9ULxdVs005444 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 30 Oct 2013 16:59:39 -0500
Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.237.229]) by umail.lucent.com (8.13.8/TPES) with ESMTP id r9ULxcPK020012; Wed, 30 Oct 2013 16:59:39 -0500 (CDT)
Message-ID: <5271813C.606@bell-labs.com>
Date: Wed, 30 Oct 2013 16:59:24 -0500
From: "Vijay K. Gurbani" <vkg@bell-labs.com>
Organization: Bell Laboratories, Alcatel-Lucent
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130805 Thunderbird/17.0.8
MIME-Version: 1.0
To: Richard Barnes <rlb@ipv.sx>
References: <520564B6.7040304@bell-labs.com> <CAL02cgSov68ub=Djrst=V+=f0oPHY_HFMEb6jOuerWYAaxtRxQ@mail.gmail.com>
In-Reply-To: <CAL02cgSov68ub=Djrst=V+=f0oPHY_HFMEb6jOuerWYAaxtRxQ@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.11
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 21:59:50 -0000

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/  | Calendar: http://goo.gl/x3Ogq