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

[Volker Hilt <[e-mail]>]

Phil,
>
> I pointed out in [1] that the server needs to determine the algorithm
> to be used, otherwise it has to use an overload control method that
> will support a mix of restriction algorithms on the client, which
> would be significantly more complex for the server than the client
> having to support two restriction algorithms (which I view as
> relatively straightforward to specify and implement).

For a server it is fairly easy to convert a loss value into a rate (or 
vice versa) if it has the data available that is needed for rate-based 
controls (current call rate, number of upstream neighbors,...).

> Because the
> draft spec does not specify the server algorithm, it gives the
> illusion that most complexity is in the client, whereas in reality it
> is most likely to be on the server.
>
With the current proposal it is possible to build a simple client and 
server with effective overload control and to go for a more complex 
mechanism depending on the targeted scenario and use case.

> In [2] I gave an example modification of the draft whereby the client
> algorithms are mandatory, which removes the complexity of the
> negotiation as well.
>
I believe it is fairly simple for client and server to agree. There are 
four cases:
- Client and Server support A and B.
   * Client sends AB to server.
   * Server responds with A or with B (e.g., depending on configuration).
- Client supports A and B. Server supports A.
   * Client sends AB to server
   * Server responds with A.
- Client supports A. Server supports A and B
   * Client sends A to server.
   * Server responds with A.
- Client supports A. Server supports A
   * same as above.

Thanks,

Volker (as individual)







> -----Original Message----- From: [e-mail]
> [mailto:[e-mail]] On Behalf Of Volker Hilt Sent:
> 12 July 2011 15:00 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