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

["NOEL, ERIC C (ERIC C)" <[e-mail]>]

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
[e-mail]


-----Original Message-----
From: Vijay K. Gurbani [mailto:[e-mail]] 
Sent: Tuesday, December 27, 2011 11:41 AM
To: NOEL, ERIC C (ERIC C)
Cc: [e-mail]
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} / [e-mail]
Web:   http://ect.bell-labs.com/who/vkg/