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

[Salvatore Loreto <[e-mail]>]

On 7/1/11 12:46 AM, Volker Hilt wrote:
> [as an individual]
> I think this path forward make sense and is a good way forward.
+1

> [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).

I concur, however we have at least change the Milestone for the 
deliverable 2
from the already passed May to what we think it will be a realistic one


cheers
/Sal


-- 
Salvatore Loreto
www.sloreto.com



> 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