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

[Volker Hilt <[e-mail]>]

[as an individual]
I think this path forward make sense and is a good way forward.

[as a chair]
The two proposed drafts (2) and (3) will both address our charter item 
2. A specification for an SIP overload control mechanism based on 
implicit/explicit feedback and should both be covered under this item. 
If there are no concerns from the AD, I believe that we do not need to 
re-charter if we add the draft proposed for (2).

Thanks,

Volker


On 6/27/2011 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