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

From: Shida Schubert <[email-masked]>
Date: Sun, 10 Jul 2011 16:09:17 +0900

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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-overload

---

From: Salvatore Loreto <[email-masked]>
Date: Mon, 11 Jul 2011 14:14:09 +0300

> 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

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 12 Jul 2011 09:09:48 -0400

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:

> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
> Email: vkg@{bell-labs.com,acm.org} / [email-masked]
> Web:   http://ect.bell-labs.com/who/vkg/

---

From: Volker Hilt <[email-masked]>
Date: Tue, 12 Jul 2011 10:00:06 -0400

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)

---

From: <[email-masked]>
Date: Tue, 12 Jul 2011 16:59:37 +0100

Volker,

I concur with Hadriel. It wasn't clear to me what was being proposed, but I don't see how what you are suggesting is workable.

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

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.

Regards,

Phil

[1] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00632.html
[2] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00629.html

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Volker Hilt
Sent: 12 July 2011 15:00
To: [email-masked]
Subject: Re: [sip-overload] A modest (and new) proposal on multiple algorithms for overload control

Hadriel,

Thanks,

Volker (as individual)

---

From: "NOEL, ERIC C (ERIC C)" <[email-masked]>
Date: Tue, 12 Jul 2011 17:41:22 -0400

Volker, Vijay,

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?

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? 

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
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Volker Hilt
Sent: Tuesday, July 12, 2011 10:00 AM
To: [email-masked]
Subject: Re: [sip-overload] A modest (and new) proposal on multiple algorithms for overload control

Hadriel,

Thanks,

Volker (as individual)

---

From: Volker Hilt <[email-masked]>
Date: Tue, 12 Jul 2011 19:59:23 -0400

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: [email-masked]
> [mailto:[email-masked]] On Behalf Of Volker Hilt Sent:
> Tuesday, July 12, 2011 10:00 AM To: [email-masked] 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)
>
>
>
>
>
>> 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
>>
>>
>>> 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
>>> 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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> 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.
>>>
>>> [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
>>>
>>>
>>>
>>> - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
>>> Email: vkg@{bell-labs.com,acm.org} /
>>> [email-masked] Web:
>>> http://ect.bell-labs.com/who/vkg/
>>> _______________________________________________ sip-overload
>>> mailing list [email-masked]
>> _______________________________________________ sip-overload
>> mailing list [email-masked]
> _______________________________________________ sip-overload mailing
> list [email-masked]

---

From: Volker Hilt <[email-masked]>
Date: Tue, 12 Jul 2011 20:14:46 -0400

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)

> 12 July 2011 15:00 To: [email-masked] Subject: Re:
> [sip-overload] A modest (and new) proposal on multiple algorithms for
> overload control
>
> Hadriel,
>

---

From: "NOEL, ERIC C (ERIC C)" <[email-masked]>
Date: Wed, 13 Jul 2011 09:56:01 -0400

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

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

Eric,

Thanks,

Volker (as individual)

---

From: <[email-masked]>
Date: Fri, 22 Jul 2011 11:44:03 +0100

Thanks Volker,

Comment below. I aim to try and attend the Quebec meeting remotely,

Regards,

Phil 

> Sent: 13 July 2011 01:15
> To: Williams,PM,Phil,DEV6 R

[PhilW] Whilst it is possible to map between loss based and rate-based per client-server stream by measuring the applied parameter and the arrival rate at the server, this requires measuring the arrival rate from each client individually, and there will be implications for update frequency and control stability because some of these traffic streams will be relatively small, particularly if the number of upstream neighbours is large. With a pure loss-based or pure rate-based schemes it is possible to design the server algorithm to have some nice/useful properties whilst only measuring the total arrival rate and not that from each upstream client. For example with loss-based method one can use the same loss proportion for every source, which makes both adaptation simple and will satisfy one interpretation of fairness. On the other hand for rate-based restriction one can get some nice behaviours (and satisfying another interpretation of fairness) with clients derived from minimum guarantees plus use of unused rate in a precise way, again by only measuring the total arrival rate (some clients may send at below the max control rate received).

To re-iterate my concern: if the two restriction algorithms are not made mandatory for the clients, my suggestion is that it puts a greater burden on the design of the server algorithm than that of the clients.
> - Client supports A. Server supports A

[PhilW] OK, but not if the server wants B but the client only supports A!