Re: [sip-overload] Issue: Multiple algorithms -> Single algorithmfor overload control

Janet:

> Do I understanding that you are expecting an (already overloaded) SIP 
server to recalculate the desired "loss rate" twice a second?

> Is that wise?

I am also am concerned about adding any extra load to the overloaded
server, but that makes me come down on the other side. It would seem
to me that making the overloaded server try to track/compute the
rates distributed to each upstream node would be even more work intensive.

Assuming that the overloaded server is using some dynamic algorithm
to determine the (aggregate) load to let in, I would think that it is
recomputing (aggregate) accept rates at least this granularity anyway.

My vote is for the simplest requirement on the overloaded server with
any bells and whistles (if any) on the upstream (non-overloaded) nodes.

Cheers,
Shaun

-----Original Message-----
From: sip-overload-bounces@ietf.org on behalf of Janet P Gunn
Sent: Fri 6/10/2011 6:03 PM
To: Vijay K. Gurbani
Cc: sip-overload-bounces@ietf.org; sip-overload@ietf.org
Subject: Re: [sip-overload] Issue: Multiple algorithms -> Single algorithmfor	overload control

Do I understanding that you are expecting an (already overloaded) SIP 
server to recalculate the desired "loss rate" twice a second?

Is that wise?

Janet

sip-overload-bounces@ietf.org wrote on 06/10/2011 05:34:27 PM:

> [image removed] 
> 
> [sip-overload] Issue: Multiple algorithms -> Single algorithm for 
> overload control
> 
> Vijay K. Gurbani 
> 
> to:
> 
> sip-overload@ietf.org
> 
> 06/10/2011 05:34 PM
> 
> Sent by:
> 
> sip-overload-bounces@ietf.org
> 
> Folks: During the Prague IETF, Mr. Kaplan reopened the
> case for supporting multiple overload control algorithms [1].
> 
> Summarizing, the basic problems with multiple algorithms are:
> 
> 1) Interoperability suffers as protocol gets complex.
> 2) Get out one algorithm now (loss), and later if there is a need to
>     standardize more add the oc-algo parameter in a backwards
>     compatible manner.
> 3) Re-negotiating the chosen algorithm is not trivial.
> 4) Servers will have to maintain negotiated algorithms as pieces
>     of state for a potentially large set of upstream clients.
> 
> I cannot say that I am unsympathetic to the above list.  If we can
> simplify processing, then we should do so.
> 
> The main reason to support multiple algorithms appear to have been
> the need to not preclude rate-based algorithms [2,3].  However
> subsequent discussions in the thread started off by [3] have
> resulted in the understanding that rate-based algorithms may have
> a slight advantage if the offered load at the client significantly
> surges over a period of time << then the overload server's feedback
> period.  Since the overload server's feedback period is already short
> (500ms by default), the advantage possessed by rate-based algorithms
> may be moot [5].
> 
> Further, minimizing state in the server is an argument to pick
> loss-based as the default algorithm instead of rate-based.  The
> latter requires the server to assign --- and keep track --- of a
> share of its overall capacity with each upstream client.
> 
> So ... given all this, it may be a good idea to go with one
> algorithm, and make that the loss based algorithm.
> 
> I will like have discussion so we can reach consensus on this
> issue and close it for good.
> 
> [1] 
http://www.ietf.org/mail-archive/web/sip-overload/current/msg00564.html
> [2] 
http://www.ietf.org/mail-archive/web/sip-overload/current/msg00565.html
> [3] 
http://www.ietf.org/mail-archive/web/sip-overload/current/msg00600.html
> [4] 
http://www.ietf.org/mail-archive/web/sip-overload/current/msg00606.html
> [5] 
http://www.ietf.org/mail-archive/web/sip-overload/current/msg00606.html
> 
> 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} / 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