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

[Shida Schubert <[e-mail]>]

 I support the path forward.

 I am glad to see that (2) will be progressed along with 
(3). 

 Regards
  Shida 

On Jul 1, 2011, at 6:46 AM, Volker Hilt wrote:

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