Re: [sip-overload] WG Last Call for draft-ietf-soc-overload-control-12

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

On 02/17/2013 04:49 PM, NOEL, ERIC (ERIC C) wrote:
> Salvatore,
>
> I read the document and have a few comments:

Eric: Sorry for the delay; finishing up WGLC comments related to the
draft.  Please see inline.

> - Typos:
> + Section 5.4 page 12, second paragraph "... is larger than the value
>  stored value, ...." --> "... is larger than the stored value, ..."
> + Section 6.2 page 18, 7th paragraph, "20% for 1s." --> "20% for
>  0.5s" or "oc-validity=500"  --> "oc-validity=1000"

Fixed.  Thanks for a close read.

> - Questions:
> + Section 4.1 page 6, 4th paragraph, why using SHOULD and not MUST to
>  describe the client behavior upon receiving a response with the oc
>  parameters filled in. This is in contrast with section 5.5 page 12,
>  first paragraph, where a SIP client MUST honor overload control
>  values it receives from downstream neighbors.

Changed SHOULD to MUST.

> + Section 4.4 page 8, 4th paragraph, following a sequence number
>  overflow, the server must reset the oc-seq parameter. Do we incur the
>  risk of having the client ignore all server requests with the new
>  oc-seq until oc-validity expires? Or does the client need to be able
>  to identify when oc-seq was reset?

That is a good question.  I think that this an exceptional case and
probably best handled by alerting the implementer of this instead of
trying to be prescriptive using rfc-2119 language.

To that extent, I can add some explanatory text as the last paragraph
of S4.4 as follows:

    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.

If someone has a better way to handle this case, please let me know.

> + Section 7, should there be any mention of draft-soc-overload-rate-control?

draft-soc-overload-rate-control is mentioned already as a companion
overload control scheme throughout the document.  Thus I see no specific
reason to mention it in S7.

Thanks,

- 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/