Re: [sip-overload] So, where are we on multiple algorithms...?

[<[e-mail]>]

Vijay,

Conscious that I may be seen as a spanner in the works...

I like Eric's suggestion to separate the protocol support from the specific restriction algorithm.

But I still have reservations about the idea of a default algorithm. My guess is that is that the likely consequences of this are some combination of:

* Being difficult to deploy a non-default algorithm;
* Force latent complexity on the server, which isn't within scope of the RFC;
* Suppliers having to give support two restriction algorithms on the client anyway in order to interwork with different deployments, one where the default is used, and another where it isn't (obviating the need for the algorithm negotiation part of the protocol).

I would like to see the server as master over the clients, i.e. it would be up to the server to dictate which restriction algorithm to use, or indeed to use more than one for some network architectures (see some further ramblings below).

Some further responses below.

Regards,

Phil

Dr Philip M Williams 
Performance Analyst
BT Innovate & Design 
Floor 3,
Orion Building (B62-MH) 
Adastral Park 
Martlesham Heath 
IPSWICH 
IP5 3RE 
Phone:  [phone] (office: recorded answering facility) 
        [phone] (home: no recorded answering facility) 
Email:  [e-mail] 


> -----Original Message-----
> From: [e-mail] [mailto:sip-overload-
> [e-mail]] On Behalf Of Vijay K. Gurbani
> Sent: 22 July 2011 21:26
> To: [e-mail]
> Subject: [sip-overload] So, where are we on multiple algorithms...?
> 
> Folks: Sorry for the silence.  I was on vacation, blissfully
> unaware of all things SOC ;-)
> 
> I have caught up on the mailing list on the thread I opened [1]
> before I left for vacation.
> 
> By and large, I note that most people think that this is a
> reasonable way to proceed.  I think that Eric's follow-up
> email [2] in the thread nicely summarizes next steps.  I am
> fine with this approach.
> 
> This, then leaves us with Phil's objection outlined in
> [3], and summarized in the following sentence from his
> email:
> 
>     I believe that it would add considerable
>     complexity to design an algorithm on the (overloaded)
>     server that gives acceptable/desirable results when
>     clients are operating a mix of algorithms.
> 
> It would be nice if we could run simulations showing the
> effect on the overloaded server when the clients are running
> a mix of algorithms, but maybe the effects are not too
> onerous ...?  After all, we have jettisoned windows-based
> one so we are now talking about clients supporting at most
> two algorithms.

[PhilW] It depends on what you mean by onerous. In terms of processing load, it may be more, but I don't see this as the main issue. It is the additional complexity of designing the server control, and subtleties concerning monitoring traffic from each client. Whilst a simulation may be useful for trickier aspects of transient and stochastic effects, results about convergence and steady-state are usually not difficult to prove assuming simple properties of a known  adaptation algorithm at the server. A basic requirement of any server algorithm is that it converges to a unique solution for a constant offered traffic load. But you also want to know how the server's capacity is distributed amongst the clients, and that's where you get into questions about fairness and guarantees. There is an architecture I can envisage where a mix of restriction algorithms could be deployed, which I raise below...
> 
> In the end, I go back to my contention that we have to
> be realistic here in recognizing that the relative performance
> of all the algorithms is about the same.  So therefore, if the
> relative performance is the same then there may be certain network
> deployments where the choice of one algorithm seems better than
> the other.
> 
> Rate-based one will work well in managed networks where the set of
> upstream clients sending requests is bounded and rather static; this
> also makes it easier to apply capacity guarantees.  Loss-based one
> works well where the set of upstream clients sending traffic is
> unbounded and frequently changing.
> 
> Are there deployments where a SIP server is running in a managed
> network and serving N upstream clients, N/2 of which are in managed
> networks and N/2 in unmanaged networks?  If not, maybe we should
> proceed as outlined in [1] and finish this work.

[PhilW] A factor here is that we are in relatively early days with respect to the deployment of SIP. However I can envisage an architecture where one want to use a mix of restriction algorithms (N may not be partitioned into two equal sizes, but rather as N+M). E.g. one might have a server at network (operator) boundary using guarantees where one wants to use rate-based restriction (N clients), and a fully meshed internal architecture (M clients) where one might use loss-based (and perhaps M >> N?). Partitioning the incoming load on the server between the two network sides may be easier in this case, where the interior load can be treated as one rate and then mapped to proportional (loss-based) for interior control.
> 
> Thoughts?  Can we proceed as outlined in [1, 2]?
> 
> Thanks,
> 
> [1]
> http://www.ietf.org/mail-archive/web/sip-
> overload/current/threads.html#00631
> [2] http://www.ietf.org/mail-archive/web/sip-
> overload/current/msg00646.html
> [3] http://www.ietf.org/mail-archive/web/sip-
> overload/current/msg00632.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} / [e-mail]
> Web:   http://ect.bell-labs.com/who/vkg/
> _______________________________________________
> sip-overload mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sip-overload