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

From: "NOEL, ERIC C (ERIC C)" <[email-masked]>
Date: Tue, 3 Jan 2012 13:34:59 -0500

Vijay,

Thanks for your reply and the suggested email threads.

Another way to express my concern is that in reading your client default loss control algorithm, the client normalization of oc-loss seems to imply that the server estimates oc-loss assuming it could equally be rejecting all requests (initial-dialog or out-of-dialog or mid-dialog requests). 

This is in contrast with my simulation implementation of rate and loss controls in support of the SIP overload control working group activities a few years ago.  There, both my simulated servers and clients used the implicit assumption that throttling was limited to the same requests in both the servers and clients (at the time just INVITE messages).

Basically I am concerned that the throttling algorithms may not work properly if the clients normalize oc-loss/oc-rate/oc-other based on a "reduction/no reduction" mix of messages locally created, while the servers estimate optimal oc-loss/oc-rate based on a different mix.  

It seems that in such situation, the client normalization would result in over or under control regardless of the server update frequency (of course I do not have any quantitative results to backup my claims).

Such situation could be avoided by having both clients and servers be pre-provisioned with an identical set of "requests candidate for reduction". 

Note that I certainly do not want to define the actual set of messages that belong to the set "requests candidate for reduction", nor do I want to require clients and servers to establish dropping policies.

What do you think?

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]

-----Original Message-----
From: Vijay K. Gurbani [mailto:[email-masked]] 
Sent: Tuesday, December 27, 2011 11:41 AM
To: NOEL, ERIC C (ERIC C)
Cc: [email-masked]
Subject: Re: [sip-overload] soc-overload-control-05

On 12/19/2011 09:50 AM, NOEL, ERIC C (ERIC C) wrote:
> Vijay,
>
> 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
-- 
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: Salvatore Loreto <[email-masked]>
Date: Mon, 9 Jan 2012 18:28:05 +0100

Hi Noel,

thanks for the new 02 version.

after having read it, I have some questions/comments

- last sentence of Section 3.3

    Support of rate-based control MUST be indicated by clients and
    servers by setting oc-algo to "rate".

however based on overload-control-06

     the "oc-algo" list MUST include "loss" and MAY also include other algorithm names

so I would change that sentence in something like

     Support of rate-based control MUST be indicated by clients 
including in the "oc-algo"
     list the "rate" value. A server supporting and willing to use the 
rate control algorithm
     MUST pare the "oc-algo" list dow to include only the "rate" value.

- in Section 4. Example the answer

             SIP/2.0 100 Trying
             Via: SIP/2.0/TLS p1.example.net;
             branch=z9hG4bK2d4790.1;received=192.0.2.111;
             oc-algo="rate";oc-validity=0;
             oc-seq=1282321615.781

the Via header should also include the "oc" parameter, it should be

             SIP/2.0 100 Trying
             Via: SIP/2.0/TLS p1.example.net;
             branch=z9hG4bK2d4790.1;received=192.0.2.111;
             oc;oc-algo="rate";oc-validity=0;
             oc-seq=1282321615.781

- the draft should also register in the IANA registry the value "rate" 
for the "oc-algo" list.

best regards
Salvatore

-- 
Salvatore Loreto
www.sloreto.com

On 12/15/11 5:23 PM, NOEL, ERIC C (ERIC C) wrote:
> 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
>
> _______________________________________________
> sip-overload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-overload
>

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 13 Jan 2012 17:47:42 -0600

Eric: Closing this loop.  Please see inline.

On 01/03/2012 12:34 PM, NOEL, ERIC C (ERIC C) wrote:
> Another way to express my concern is that in reading your client
> default loss control algorithm, the client normalization of oc-loss
> seems to imply that the server estimates oc-loss assuming it could
> equally be rejecting all requests (initial-dialog or out-of-dialog or
> mid-dialog requests).

Correct.

> This is in contrast with my simulation implementation of rate and
> loss controls in support of the SIP overload control working group
> activities a few years ago.  There, both my simulated servers and
> clients used the implicit assumption that throttling was limited to
> the same requests in both the servers and clients (at the time just
> INVITE messages).
>
> Basically I am concerned that the throttling algorithms may not work
> properly if the clients normalize oc-loss/oc-rate/oc-other based on a
> "reduction/no reduction" mix of messages locally created, while the
> servers estimate optimal oc-loss/oc-rate based on a different mix.

True.  Following the discussion we have had, I will clarify that the
basis for calculating the "oc" parameter value must include all
the messages.  The suggested text is below.

OLD
5.3 Determining the 'oc' Parameter Value
    The value of the "oc" parameter is determined by the overloaded
    server using any pertinent information at its disposal.  The process
    by which an overloaded server determines the value of the "oc"
    parameter is considered out of scope for this document.

NEW
5.3 Determining the 'oc' Parameter Value
     The value of the "oc" parameter is determined by the overloaded
     server using any pertinent information at its disposal.  The only
     constraint imposed by this document is that the server control
     algorithm MUST produce a value for the "oc" parameter
     such that the receiving clients can apply it to all downstream
     messages (dialogue forming as well as in-dialogue).  Beyond this
     stipulation, the process by which an overloaded server determines
     the value of the "oc" parameter is considered out of scope for this
     document.

         Note that this stipulation is required so that both the
         and server have an common view of which messages to include
         in the calculation of the feedback.  With this stipulation
         in place, the client can prioritize messages as discussed
         in Section 5.10.1.

    As an example, a value of "oc=10" when the loss-based algorithm is
    uses implies that 10% of all messages (dialog forming as well as
    in-dialogue) are subject to reduction at the client.  Analogously,
    a value of "oc=10" when the rate-based algorithm is used indicates
    that the client should send SIP requests at a rate no greater than
    or equal to 10 SIP requests per second.

Is that okay?  Please let me know if you or anyone else has any further
issues with this.  If not, I will revise the draft.

Thanks,

- vijay

---

From: Volker Hilt <[email-masked]>
Date: Fri, 13 Jan 2012 18:49:27 -0500

Hi Vijay,

as a nit - I'd suggest to consistently talk about requests (and not 
messages) in the text. Otherwise, I think this looks good.

Thanks,

Volker

---

From: "NOEL, ERIC C (ERIC C)" <[email-masked]>
Date: Fri, 13 Jan 2012 19:26:14 -0500

Vijay,

Everything looks good to me, this is consistent to what we agreed off line.

Thanks,

Eric
________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Volker Hilt [[email-masked]]
Sent: Friday, January 13, 2012 6:49 PM
To: [email-masked]
Subject: Re: [sip-overload] soc-overload-control-05

Hi Vijay,

Thanks,

Volker

---

From: Salvatore Loreto <[email-masked]>
Date: Sat, 14 Jan 2012 14:13:31 +0200

Vijay

it looks good to me too. Thanks.

Eric: btw in rate-control-02 you talks about just limiting the Invite rate.

    This document proposes extensions to [draft-ietf-soc-overload-  <http://tools.ietf.org/html/draft-ietf-soc-overload-control-05>
    control-05  <http://tools.ietf.org/html/draft-ietf-soc-overload-control-05>] so as to support a rate-based control that guarantees
    clients produce a limited upper bound to the Invite rate towards an
    overloaded server, which is constant between server updates.

cheers
Salvatore

-- 
Salvatore Loreto
www.sloreto.com

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Mon, 16 Jan 2012 11:46:21 -0600

> it looks good to me too. Thanks.

Sal: Thanks.  Closing the loop on one of your previous comments
that I have not yet responded to ... see [1].

To fix this, I suggest the following change:

OLD:
9.2 Backwards Compatibility
...
    A SIP server should therefore use 5xx responses towards upstream
    neighbors that do not support overload control. The server should
    reject the same amount of requests with 5xx responses that would be
    otherwise be rejected/redirected by the upstream neighbor if it would
    support overload control. If the load condition on the server does	
    not permit the creation of 5xx responses, the server should drop all
    requests from servers that do not support overload control.

NEW:
9.2 Backwards Compatibility
...
    A SIP server should therefore follow the behaviour outlined in
    Section 5.10.2 to handle clients that do not support overload
    control.

Thanks,

[1] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00704.html

- vijay