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

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

On 12/23/2011 10:00 AM, [e-mail] wrote:
> Vijay,
>
> Thanks for submitting version 05.
>
> Please find some comments below (nothing major).

Phil: Thank you for your comments.  Resolutions inline.

> In a several places the qualification 'conformant to this
> specification' is used, e.g.

I added this phrase following the email discussion that you,
Janet, Eric, and I had on Sept-9-2011.  Janet felt that
adding the prefix "a device that supports this specification"
would aid.  Hence I made the change.

Personally, I think that adding this phrase makes the reading
rather, for the lack of a better word, clunky.  Any implementer
reading this document will understand that the "oc-algo"
parameters, etc. are only supported by implementations that
support overload control.

> 4.2.  The oc-algo parameter
>
> A SIP client conformant to this specification MUST add an "oc-algo"
> Parameter ...
>
> I'm not sure whether this is really necessary, but since it is used
> here then perhaps ought to be included in the following since the
> use of 'When inserted...' makes it appear optional:
>
> 4.1.  The oc parameter ... A SIP client MUST add an "oc" parameter
> ... When inserted into a request by a SIP client to indicate support
> for overload control...
>
> Or alternatively take out the 'When inserted...'?

Modified as follows to make it more conformant to the remaining
sections:

OLD:
4.1. The oc parameter

    This parameter is inserted by the SIP client and updated by the SIP
    server.

    A SIP client MUST add an "oc" parameter to the topmost Via header it
    inserts into the SIP request.  This provides an indication to
    downstream neighbors that the client supports overload control.  When
    inserted into a request by a SIP client to indicate support for
    overload control, there MUST NOT be a value associated with the
    parameter.

NEW:
4.1. The oc parameter

    This parameter is inserted by the SIP client and updated by the SIP
    server.

    A SIP client conformant to this specification MUST add an "oc"
    parameter to the topmost Via header it inserts into the SIP
    request.  This provides an indication to downstream neighbors that
    the client supports overload control.  There MUST NOT be a value
    associated with the parameter (the value will be added by the
    server).

> In the following, I think 'server' should be 'client':
>
> 5.2.  Creating and updating the overload control parameters ...
> Furthermore, when a SIP<client>[server] receives a request with the
> topmost Via header containing only an "oc-validity" parameter
> without the accompanying "oc" parameter, it MUST ignore the
> "oc-validity".

No, it is indeed "server".  That sentence is discussing the corner
case when a SIP server receives a request with the "oc-validity"
parameter specified but no corresponding "oc" parameter.  This
is an error condition.  I should perhaps move the offending
sentence to Section 4.3, where we discuss the parameter itself
(and I have done so in my working copy).

> There could be some ambiguity in the following:
>
> 5.7.  Terminating overload control
[...]
> Therefore the following alternative wording for this section would
> be better:

OK; I have replaced opening paragraph of Section 5.7 as follows:

OLD:

    A SIP client stops applying overload control to the number of
    messages forwarded (i.e., it stops reducing the number of messages
    forwarded) if one of the following events occur:

    1.  The "oc" parameter is set to a value that allows the client to
        forward all traffic;
    2.  The "oc-validity" period negotiated to put the server and client
        in overload state expires;
    3.  The client is explicitly told by the server to stop performing
        overload control using the "oc-validity=0" parameter.

NEW:

    A SIP client removes overload control if one of the following events
    occur:

    1.  The "oc-validity" period negotiated to put the server and client
        in overload state expires;
    2.  The client is explicitly told by the server to stop performing
        overload control using the "oc-validity=0" parameter.

> Minor typos/grammatical =======================
>
> In the following<replacement text>  denotes replacement for
> [original text].
>
> ----------------------------------------------------------------- 4.
> Via header parameters for overload control
>
> The four Via header parameters are introduced below.  Further
> context<about>[in] how to interpret...

Done.

> 4.1.  The oc parameter
>
> Inclusion of a value to the parameter represents two things: one,
> upon an initial handshake (see Section<5.1>[X.X]),...

Done.

> 5.  General behaviour
>
> If the server supports overload control...
>
> A client that supports the rate-based...
>
> is almost a verbatim repeat of
>
> 5.1.  Handshake to determine support for overload control
>
> A server that supports overload control...
>
> Note that the rate-based...
>
> Could this be avoided by some cross-referencing?

Good catch.  I have consolidated the text in Section 5.1.

>  5.2. Creating and updating the overload control parameters ... The
> "oc-validity" parameter MUST NOT be<added to>[used in] a Via header
> that did not originally contain an "oc" parameter when received.

I am unable to find the above phrase in -05, Section 5.2 ...

> 5.5. Using the Overload Control Parameter Values
> ...
> If the SIP client has a non-expired "oc" parameter value for the
> server chosen from the Expected Output,<then>[and] this chosen
> server is operating in overload control mode.
>
> To make sense as a conditional statement, need to replace 'and' with
> 'then'.

Fixed as suggested.  I will release a new version shortly.

Thanks a lot, Phil!

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