Re: [sip-overload] Issue: Multiple algorithms -> Single algorithm for 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