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

["Vijay K. Gurbani" <[e-mail]>]

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