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

["NOEL, ERIC C (ERIC C)" <[e-mail]>]

Volker, Vijay,

It seems that a compromise would be to maintain the original objective, namely have draft-ietf-soc-overload-control-02 specify:

(1) the signaling mechanism by which servers and clients exchange overload control messages,
(2) a default overload control algorithm that uses the proposed signaling mechanism.

That means draft-ietf-soc-overload-control-02 needs to be adjusted so as to make it clear that the main goal for that document is to define a signaling mechanism to support overload control for SIP.  (In my opinion, the current version of draft-ietf-soc-overload-control-02 is too loss rate control centric.)

In particular, draft-ietf-soc-overload-control-02 needs to have one section to define the signaling mechanism, independently of any overload control algorithms. And another section to define a default control algorithm that utilizes the proposed signaling mechanism.  

Finally, separate specifications that define other overload control algorithms based on the signaling mechanism defined in draft-ietf-soc-overload-control-02 could be proposed. For instance, a rate control algorithm co-authored by Phil Williams, Eric Noel, and Janet Gunn (and/or others).

Thanks,

Eric Noel 
LMTS
AT&T Labs, Inc. 
Rethink Possible

Network Design and Performance Analysis
200 South Laurel Avenue, D5-3D19
Middletown, NJ 07748
P: 732.420.4174
[e-mail]

-----Original Message-----
From: Volker Hilt [mailto:[e-mail]] 
Sent: Tuesday, July 12, 2011 7:59 PM
To: NOEL, ERIC C (ERIC C)
Cc: [e-mail]
Subject: Re: [sip-overload] A modest (and new) proposal on multiple algorithms for overload control

Eric,
>
> I understand the need to have a simple default algorithm in this RFC
> and I also agree it should not preclude extension to other
> algorithms.
>
> However, my interpretation of draft-ietf-soc-overload-control-02 is
> that on one hand it allows for different class of algorithms to be
> used through the oc-algo parameter, and on the other hand it excludes
> other algorithms by limiting the oc parameter value to a loss rate
> percentage (MUST be a number between 0 and 100) irrespective of the
> selected oc-algo parameter.
>
> Provided my interpretation is correct, could
> draft-ietf-soc-overload-control-02 be modified so that the oc
> parameter is a loss rate percentage only when used with the default
> algorithm?
>
Yes! If, for example, a rate-based is used then the feedback needs to be 
a rate. There is no need to transmit loss value in this case.

> If there is a push for multiple simultaneous RFCs, then should not
> draft-ietf-soc-overload-control-02 require oc-algo to be set to the
> value "loss-control" with no mentioning of other controls?
>
Yes, that would make sense. A separate draft can then define other 
values and the corresponding feedback transmission.

Thanks,

Volker (as individual)

>
>
> -----Original Message----- From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Volker Hilt Sent:
> Tuesday, July 12, 2011 10:00 AM To: [e-mail] Subject:
> Re: [sip-overload] A modest (and new) proposal on multiple algorithms
> for overload control
>
> Hadriel,
>
> the idea is to have a mandatory algorithm in the base draft and, at
> the same time, to leave the draft open for extensions to other
> algorithms. The second draft will then specify such an algorithm.
>
> That way RFC A is the common denominator supported by all devices
> and advanced devices can implement RFC A and B.
>
> Thanks,
>
> Volker (as individual)
>
>
>
>
>
> On 7/12/2011 9:09 AM, Hadriel Kaplan wrote:
>>
>> 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
>>
>> _______________________________________________ sip-overload
>> mailing list [e-mail]
>> https://www.ietf.org/mailman/listinfo/sip-overload
> _______________________________________________ sip-overload mailing
> list [e-mail]
> https://www.ietf.org/mailman/listinfo/sip-overload