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

From: "Vijay K. Gurbani" <[email-masked]>
Date: Fri, 22 Jul 2011 15:25:50 -0500

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.

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.

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} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/

---

From: <[email-masked]>
Date: Tue, 26 Jul 2011 11:40:14 +0100

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:  +44 1473 651709 (office: recorded answering facility) 
        +44 1473 250133 (home: no recorded answering facility) 
Email:  [email-masked] 

> -----Original Message-----
> From: [email-masked] [mailto:sip-overload-
> [email-masked]] On Behalf Of Vijay K. Gurbani
> Sent: 22 July 2011 21:26
> To: [email-masked]
> Subject: [sip-overload] So, where are we on multiple 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...
> 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.
> _______________________________________________
> sip-overload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-overload