[sip-overload] A modest (and new) proposal on multiple algorithms for overload control

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

Folks: I am trying to close the conversation on SIP overload
control algorithms.

To recap, we had a decision on making loss-based as the default
mandatory-to-implement algorithm and had agreed to allow the
choice of rate- and windows-based algorithms.

This is what's currently reflected in the protocol draft [1].

During the Prague IETF, it was suggested that we revisit this
decision and use only one algorithm.  This suggestion lead to
a subsequent thread [2] about which algorithm should be
chosen --- loss-, rate- or windows-based one.

I think 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.

The loss-based algorithm is less complex than the rate-based one
or the windows-based one.

Phil Williams has put out a proposal [3] to support all three
algorithms simultaneously, thereby eliminating the need for protocol
machinations to choose one.  However, issues still remain: first,
this will force implementations to implement all of the algorithms,
and this I believe is a heavy burden.

Second, it does not eliminate the need or the desire to change
algorithms mid stream, and finally, this decision forces an overloaded
server to maintain considerable state as to which particular
algorithm has been chosen with the paired upstream client.

It seems that we are at an impasse.

So, let me suggest another concrete proposal, which will help move
the work forward expeditiously if all agree.

I propose that draft-ietf-soc-overload-control continue as it
is now with the following exception:

    1) Take window class out of the mix, leaving rate and
       loss.  No one is explicitly championing the windows-based
       one; it could be added later if desired.

    2) Invite Phil Williams, Eric Noel, or Janet Gunn to start
       working on a rate-based draft that uses the agreement
       mechanisms defined in draft-ietf-soc-overload-control
       and fleshes out how rate-based mechanism will function.

    3) Move draft-ietf-soc-overload-control and the new draft
       in (2) as a bundle so that no one algorithm gets an
       undue advantage of being specified first.

Note that (2) and (3) effectively mitigate Phil's concern that
"proceeding with a single mandated algorithm would result in
non-adoption of the other algorithms by suppliers and in effect the
alternatives would become redundant."

Personally I do not think that the market will favour a sub-optimal
algorithm and if loss-based does not work I am sure it will
be replaced in short order.  But I do empathize with the perceived
advantage that loss-based one seems to benefit from if it is made the
only mandatory-to-implement algorithm in [1].  Therefore, (2) and
(3) above should mitigate this particular concern.

I suspect what will end up happening is that implementations geared
to managed network providers will end up supporting both loss-
and rate-based algorithms while other implementations can support
only the loss-based one.

Do folks think that this is an agreeable compromise?  It is no
worse off than what we had agreed to before, and in fact it is
much better since we have eliminated windows-based one and are
moving loss-based and rate-based ahead at the same time.

I do note that the chairs may have to re-negotiate the charter
deliverables with the ADs, but modifying the charter or deciding
to make the rate-based draft as an extension to the second
deliverable ("2. A specification for an SIP overload control
mechanism based on implicit/explicit feedback.") is a minor
detail once everyone agrees to this proposal.

Please comment.  Thank you.

[1] http://tools.ietf.org/html/draft-ietf-soc-overload-control-02
[2] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00616.html
[3] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00629.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/