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

[Hadriel Kaplan <[e-mail]>]

So in summary you're proposing to resolve the issue that having two mechanisms is a bad idea, by specifying the two mechanisms in two separate docs?? 

OK, well if we have to have two ways of doing the same thing, then I suggest we MANDATE BOTH, by putting them in the same document and a "MUST implement both" written right in it. 
Otherwise, if you have RFC A and RFC B, then some devices will do A and others B and there won't be interop.

-hadriel


On Jun 27, 2011, at 5:47 PM, Vijay K. Gurbani wrote:

> 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/
> _______________________________________________
> sip-overload mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sip-overload