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

[Volker Hilt <[e-mail]>]

Phil,

a discussion of some of the differences between loss- and rate-based 
mechanisms is in Section 9 of draft-ietf-soc-overload-design-05

Thanks,

Volker



On 6/30/2011 4:59 PM, [e-mail] wrote:
> Vijay,
>
> Thanks for making suggestions to overcome the impasse and move forward.
>
> I aim to consider the implications of your proposal in more depth next week. In the meantime it would be helpful to clarify what exception 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') would really mean. As I see it the server needs to dictate which algorithm to use and be sure that clients will support it (if overload control is supported at all). 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. Whilst it may be  straightforward to design one such that convergence to a unique solution can be proved - because the admission rate from each source is a monotonically decreasing/increasing function of the restriction parameter value (depending on whether you go for % rejected/admitted (loss-based), or rate reciprocal / rate (rate-bas
ed)
>   , resp.) - designing the server control so that capacity (of the overloaded server) is allocated to each client in the desired way becomes more difficult, whatever your definition of 'fairness', or how you want to meet any 'guarantees'. I expect that it would at least require monitoring the traffic from each client separately, which is not necessary when you are purely using one algorithm or the other.
>
> Viewed another way, taking away the burden on the clients could add a greater burden on the server (ok, this is not directly an issue for IETF because it is not within scope, but it still remains for suppliers and operators).
>
> I would be happy to contribute with the others to the description of a rate-based algorithm. Actually I don't consider that one algorithm is really more complex than another - there are subtleties with both loss-based and rate-based. Are there already more detailed recommendations already for the former?
>
> Regards,
>
> Phil
>
>
> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Vijay K. Gurbani
> Sent: 27 June 2011 22:47
> To: [e-mail]
> Subject: [sip-overload] A modest (and new) proposal on multiple algorithms for overload control
>
> 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