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

Vijay,

Thanks for below. I am ok with your comments.

Thanks, 

Eric Noel 
AT&T Labs, Inc. 
Rethink Possible

Network Design and Performance Analysis
200 South Laurel Avenue, D5-3D19
Middletown, NJ 07748
P: 732.420.4174
ecnoel@att.com

-----Original Message-----
From: sip-overload-bounces@ietf.org [mailto:sip-overload-bounces@ietf.org] On Behalf Of Vijay K. Gurbani
Sent: Monday, March 25, 2013 12:02 PM
To: sip-overload@ietf.org
Subject: Re: [sip-overload] WG Last Call for draft-ietf-soc-overload-control-12

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} / vijay.gurbani@alcatel-lucent.com
Web:   http://ect.bell-labs.com/who/vkg/
_______________________________________________
sip-overload mailing list
sip-overload@ietf.org
https://www.ietf.org/mailman/listinfo/sip-overload