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

[Richard Barnes <[e-mail]>]

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