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

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 15 Dec 2011 10:09:23 -0600

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} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/

---

From: "NOEL, ERIC C (ERIC C)" <[email-masked]>
Date: Thu, 15 Dec 2011 11:23:01 -0500

Folks,

Please make a note we have updated draft-noel-soc-overload-rate-control and posted the latest version at

http://datatracker.ietf.org/doc/draft-noel-soc-overload-rate-control/

Comments and/or suggestions are always appreciated.

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
[email-masked]

---

From: "NOEL, ERIC C (ERIC C)" <[email-masked]>
Date: Mon, 19 Dec 2011 10:50:17 -0500

Vijay,

I sent you a few editorial/minor comments off-line. 

In addition, reading section 6.3 (default algorithm for loss-based overload control) lead me to the following comment.

Since different request types likely will produce different processing costs at the server, to prevent a mismatch between the servers "control commands" (oc parameter) and clients execution of the "control commands" (percent loss, rate limit...), an agreement between clients and servers on the type of requests that can be discarded seems to be required.

Unless I missed that point in your document, could not you explicitly require that servers estimate for oc parameter be based on requests belonging to the set "requests candidate for reduction"? So both clients and servers work from the same set and the mentioned mismatch is prevented. 

That way in section 6.3, you no longer need to have the client adjusts the oc parameter (percent loss) by the proportion of requests in the set "requests candidate for reduction". And you no longer imply that the server estimates the oc parameter for loss-control based on all requests (initial dialog requests, mid-dialog requests....).

What do you think?

Thanks,

Eric Noel 
AT&T Labs, Inc. 
Rethink Possible

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Vijay K. Gurbani
Sent: Thursday, December 15, 2011 11:09 AM
To: [email-masked]
Subject: [sip-overload] soc-overload-control-05

Thanks,

- 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} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/
_______________________________________________
sip-overload mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sip-overload

---

From: <[email-masked]>
Date: Fri, 23 Dec 2011 16:00:32 +0000

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

> From: [email-masked] [mailto:sip-overload-
> [email-masked]] On Behalf Of Vijay K. Gurbani
> Sent: 15 December 2011 16:09

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 27 Dec 2011 10:40:47 -0600

> I sent you a few editorial/minor comments off-line.

Eric: Thanks for the off-line comments.  I have incorporated
them.  More inline (at end).

> In addition, reading section 6.3 (default algorithm for loss-based
> overload control) lead me to the following comment.
>
> Since different request types likely will produce different
> processing costs at the server, to prevent a mismatch between the
> servers "control commands" (oc parameter) and clients execution of
> the "control commands" (percent loss, rate limit...), an agreement
> between clients and servers on the type of requests that can be
> discarded seems to be required.
>
> Unless I missed that point in your document, could not you explicitly
> require that servers estimate for oc parameter be based on requests
> belonging to the set "requests candidate for reduction"? So both
> clients and servers work from the same set and the mentioned mismatch
> is prevented.
>
> That way in section 6.3, you no longer need to have the client
> adjusts the oc parameter (percent loss) by the proportion of requests
> in the set "requests candidate for reduction". And you no longer
> imply that the server estimates the oc parameter for loss-control
> based on all requests (initial dialog requests, mid-dialog
> requests....).
>
> What do you think?

We have been through this exercise before; i.e., trying to figure out
what kinds of requests (SUBS, NOT, INV) a server can discard versus
ones it can forward.  In the end, we agreed that the ends do not justify
the means and best to leave things as they are.

Here is a list of messages in the archive that you can peruse to see
the discussions on this topic (best to go in order):

http://www.ietf.org/mail-archive/web/sip-overload/current/msg00320.html
http://www.ietf.org/mail-archive/web/sip-overload/current/msg00321.html
http://www.ietf.org/mail-archive/web/sip-overload/current/msg00324.html
http://www.ietf.org/mail-archive/web/sip-overload/current/msg00326.html
http://www.ietf.org/mail-archive/web/sip-overload/current/msg00339.html
http://www.ietf.org/mail-archive/web/sip-overload/current/msg00341.html

Furthermore, after the Maastricht IETF, it was decided to provide more
guidance by defining a "local policy" (as is done in Section 5.10.1)
for which messages should be forwarded is at:

www.ietf.org/mail-archive/web/sip-overload/current/msg00366.html

Thus in summary, while we can re-open the particular discussion on how
we can reach an agreement between client and server on which type of
requests should be discarded, I am afraid that we may not get too far.

Thanks,

- vijay

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 27 Dec 2011 11:44:11 -0600

> Please find some comments below (nothing major).

Phil: Thank you for your comments.  Resolutions inline.

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

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

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

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

> 5.7.  Terminating overload control
[...]
> Therefore the following alternative wording for this section would

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

OLD:

NEW:

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

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

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

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

Thanks a lot, Phil!

- vijay

---

From: Janet P Gunn <[email-masked]>
Date: Wed, 28 Dec 2011 16:53:51 -0500

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

Sec 4.1 

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

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 

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

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

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

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

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

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

Thanks

Happy New Year

Janet

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 29 Dec 2011 10:04:53 -0600

> Comments on draft-ietf-soc-overload-control-05

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

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

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.

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

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

> interval for requests form EACH upstream SIP client.
>
> 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.

> current "oc" parameter value from that particular downstream server."

Fixed.

Done.

> "fraction" is probably the right word if the server is using a loss
> based algorithm, but probably not the

Fixed as suggested.

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

> Happy New Year

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

- vijay