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

Vijay,

Thanks for submitting version 05.

Please find some comments below (nothing major).

Regards,

Phil

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

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...'?

-----------------------------------------------------------------------------------
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".

-----------------------------------------------------------------------------------
There could be some ambiguity in the following:

5.7.  Terminating overload control

   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.

The question is: What should 'termination' refer to? The action in (1.) could be accompanied by a non-zero oc-validity period which is still active. Therefore the server would view control as still being active, although it has (perhaps temporarily) allowed all traffic to be admitted from this client.

A practical realisation would probably leave a client control allocated in case (1.) if the oc-validity period had not expired, and therefore the control would not be regarded as 'terminated'. This is reflected in the use of 'effectively' in the following:

      Note that the loss-based overload control scheme (Section 6) can
      effectively stop overload control by setting the value of the "oc"
      parameter to 0... 

Therefore the following alternative wording for this section would be better:

5.7.  Terminating overload control

   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.

   Note also that messages will not be prevented from being forwarded if
   the "oc" parameter is set to a value that allows the client to forward
   all traffic.

-------------------------------------------------------------------------------------------------

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

-------------------------------------------------------
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]),...

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

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

----------------------------------------------------------
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'.

> -----Original Message-----
> From: sip-overload-bounces@ietf.org [mailto:sip-overload-
> bounces@ietf.org] On Behalf Of Vijay K. Gurbani
> Sent: 15 December 2011 16:09
> To: sip-overload@ietf.org
> Subject: [sip-overload] soc-overload-control-05
> 
> Folks: I realize people are busy with end of the year plans,
> but if you get the chance, please provide input on
> soc-overload-control-05 [1].
> 
> I had posted this updated version back in Oct-28.  The changes
> and diffs are outlined in [2].  It will be nice to move this work
> ahead.
> 
> Thanks,
> 
> [1] http://tools.ietf.org/html/draft-ietf-soc-overload-control-05
> [2] http://www.ietf.org/mail-archive/web/sip-
> overload/current/msg00679.html
> 
> - 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} / 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