Re: [sip-overload] soc-overload-control-05

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

On 12/28/2011 03:53 PM, Janet P Gunn wrote:
>
> Finally got a chance to come up for air and take a look at this.
>
> Some comments, mostly nits. The non-nit is the one about setting
> oc-validity.
>
> Comments on draft-ietf-soc-overload-control-05

Janet: Thank you for the comments.  I have incorporated
them as discussed below.

> Sec 4.1
>
> Second paragraph refers to "Section X.X". Probably supposed to be
> 5.1

Already fixed (from a previous comment by Phil).

> Last paragraph - the statement "it SHOULD reduce, by the amount
> indicated, the number of requests going downstream to the SIP server
> from which it received the response ..." is perfectly true for the
> loss based algorithm, but not technically correct

Eric had the same feedback in a private email exchange.  While I
pushed back since I did not believed that the statement was not
loss-centric, I suspect that given a similar comment from you
as well, the passage in question deserves a re-evaluation.

So, I have changed it as you indicate below, and hopefully this will
have solved Eric's concern as well.

> for the rate based algorithm.
>
> Suggest either adding a "Note" as in other cases where you discuss
> differences for rate based, or reword it, possibly "it SHOULD reduce,
> as indicated by the oc and oc-algo parameters, the number of requests
> going downstream to the SIP server from which it received the
> response ..."

Changed as follows:

OLD:
    When a SIP client receives a response with the value in the "oc"
    parameter filled in, it SHOULD reduce, by the amount indicated, the
    number of requests going downstream to the SIP server from which it
    received the response (see Section 5.10 for pertinent discussion on
    traffic reduction).

NEW:
    When a SIP client receives a response with the value in the "oc"
    parameter filled in, it SHOULD reduce, as indicated by the "oc" and
    "oc-algo" parameters, the number of requests going downstream to the
    SIP server from which it received the response (see Section 5.10 for
    pertinent discussion on traffic reduction).


> 4.3
> last sentence
> should "and the oc-algo parameter." be added on to the sentence?

Since oc-validity is tied to the value of oc, I am more likely to
leave it as is (unless you feel strongly about this).

> 5.2 overload stability and the value for oc-validity. (NON-NIT)
>
> In selecting an oc-validity value, you should also consider the time
> interval for requests form EACH upstream SIP client.
>
> As an extreme example, consider a case where you have thousands of
> upstream SIP clients, and each one sends a message, typically, once a
> second. Even if you are adjusting your oc value every 10
> milliseconds, you want an oc-validity of at least a second.
> Otherwise, every time a client gets ready to transmit, it will have
> an expired oc value, and won't throttle.
>
> Something like " A SIP server MAY use a shorter "oc-validity" time if
> each upstream SIP client attempts to send messages at a high rate,
> and SHOULD use a longer "oc- validity" time if each SIP client
> operates at a lower rate."

I think your point is valid, but shouldn't this behaviour be
specified more appropriately in the rate-based draft?  Section 5
in draft-ietf-soc-overload-control-05 outlines general behaviour,
not one specific to either rate- or loss-based.

> 5.5 first paragraph
> "The SIP client
> MUST NOT forward more requests to a SIP server than allowed by the
> current "oc" parameter value from a particular downstream server."
> should probably be
> "The SIP client
> MUST NOT forward more requests to a SIP server than allowed by the
> current "oc" parameter value from that particular downstream server."

Fixed.

> 5.8. This isn't really about "Stabilizing overload control" but about
> "Stabilizing overload algorithm
> selection". Suggest changing section title.

Done.

> 5.10.2 last paragraph says
>
> "A SIP server that is under overload and has started to throttle
> incoming traffic MUST reject this request with a "503 (Service
> Unavailable)" response without Retry-After header to reject a
> fraction of requests from upstream neighbors that do not support
> overload control."
>
> "fraction" is probably the right word if the server is using a loss
> based algorithm, but probably not the
> right word if it is using a rate based algorithm.
>
> Maybe "A SIP server that is under overload and has started to throttle
> incoming traffic MUST reject this request with a "503 (Service
> Unavailable)" response without Retry-After header to reject some
> requests from upstream neighbors that do not support
> overload control."

Fixed as suggested.

I will get the updated draft with these set of changes by tomorrow.

> Thanks
>
> Happy New Year

Thank you, and best wishes for a new year to you as well.

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / [e-mail]
Web:   http://ect.bell-labs.com/who/vkg/