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

["Vijay K. Gurbani" <[e-mail]>]

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} / [e-mail]
Web: http://ect.bell-labs.com/who/vkg/  | Calendar: http://goo.gl/x3Ogq