Subject: [sip-overload] draft-ietf-soc-overload-control-02 and algorithm agility

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 29 Mar 2011 12:09:06 -0400

Howdy,
in today's WG session the new oc-algo mechanism was described, and it was stated the WG had agreed to support multiple algorithms, with a pointer to this thread:
http://www.ietf.org/mail-archive/web/sip-overload/current/msg00436.html

I have read that thread, and there were actually few discussions about the need for multiple algorithms (most of it was about 100 response handling or how often algorithms would change, not the need for multiple algorithms).

2 people seemed to want to support multiple algorithms, but did not define what the "other" one would be.

So I'm going to try to argue for NOT doing this (at least not right now).  Here's why:

1) Every time we add something optional, interop issues happen.  The protocol gets more complicated, there's more to test, more to fail, etc.  ISTM that a overload control mechanism should be as simple as possible, with the greatest probability of success and interop.  For me, the bar would have to pretty darn high to add optionality - there would have to be a really good reason.

2) Currently, there is only one algorithm: loss.  Other algorithms were tested (rate and window), but since the results were effectively the same, it would seem rather foolish to add support for those other two.  So this would have to be a 4th, as yet unknown, algorithm.  That's fine, but we don't need to create a param or logic to handle unknown future algorithms *now*. Think about it - nothing prevents a future algorithm from adding this oc-algo param in a backwards-compatible manner.  Ergo, we don't need to do it now.  In fact, since we don't know the future algorithm(s), we have no idea if they could even use the other params we have.

3) Doing this is not as trivial as the draft currently has it.  You cannot just "negotiate" it by having *only* the client-side send the param again in the next request when it wants to re-negotiate it, because the client has no idea when its next-hop server has rebooted, or the next-hop server's had *its* config changed.  If that happens, the server would get a request form the client without the param, and thus think the client is using loss, even if they previously negotiated some new algo.  

4) When you're the server-side, you'll now have to keep a negotiated algorithm setting pre previous hop client.  For some server systems that's easy, but for some servers that's untenable - they don't keep state per previous hop client.  And I believe our charter requires us to support a model of unknown previous-hop clients.

-hadriel

---

From: Janet P Gunn <[email-masked]>
Date: Tue, 29 Mar 2011 13:58:37 -0400

I was one of the people pushing hard for the use of a rate based algorithm, either as well as or instead of a percentage loss based algorithm.

See, for instance, http://www.ietf.org/mail-archive/web/sip-overload/current/msg00403.html

http://www.ietf.org/mail-archive/web/sip-overload/current/msg00411.html

I know I discussed this in much greater detail at some point- but I can't find the specific message. Maybe it is in the minutes of the interim

While both loss based and rate based algorithms work well in a simulated environment, driven by random processes, there are a number  of highly probable real world scenarios (e.g. highly localized source of overload, or rapidly varying overload) in which a loss based algorithm is either ineffective or unfair.

Evidence of the greater robusness, fairness, and effectiveness of rate-based network management controls is found in the circuit switched PSTN where "Call Gapping" (rate based) has made the percentage-dropped network management controls all but obsolete.

There are, of course, many differences between the PSTN and a SIP network.  But this particular case seems to be a place where we can, and should, learn from the lessons learned in the PSTN.

Janet
[email-masked] wrote: -----

To: "[email-masked]" <[email-masked]>
From: Hadriel Kaplan <[email-masked]>
Sent by: [email-masked]
Date: 03/29/2011 12:09PM
Subject: [sip-overload] draft-ietf-soc-overload-control-02 and algorithm agility

Howdy,

-hadriel

_______________________________________________
sip-overload mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/sip-overload

---

From: Hadriel Kaplan <[email-masked]>
Date: Tue, 29 Mar 2011 18:50:46 -0400

But that to me argues we shouldn't pick the loss-based one to begin with.
Either they're all effectively the same, or they're not.  As far as I know, the results of the design-team were they were the same, so the loss based one was picked just because it's the simplest to implement.  If a rate-based is instead more effective, even if it's just for "corner cases", then we should pick that one instead.
No?

-hadriel

On Mar 29, 2011, at 1:58 PM, Janet P Gunn wrote:

Janet
[email-masked]<mailto:[email-masked]> wrote: -----

To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
From: Hadriel Kaplan <[email-masked]<mailto:[email-masked]>>
Sent by: [email-masked]<mailto:[email-masked]>
Date: 03/29/2011 12:09PM
Subject: [sip-overload] draft-ietf-soc-overload-control-02 and algorithm agility

Howdy,

-hadriel

_______________________________________________
sip-overload mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/sip-overload

---

From: Janet P Gunn <[email-masked]>
Date: Wed, 30 Mar 2011 09:30:29 -0400

That would be my preference (use Rate as the only mechanism).  But there was pushback from the supporters of "loss based", so my fallback position was "at least give the provider a way to use Rate based when the provider prefers it."

Janet

This is a PRIVATE message. If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery.
NOTE: Regardless of content, this e-mail shall not operate to bind CSC to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.

-----Hadriel Kaplan <[email-masked]> wrote: -----

To: Janet P Gunn/USA/CSC@CSC
From: Hadriel Kaplan <[email-masked]>
Date: 03/29/2011 06:50PM
cc: "[email-masked]" <[email-masked]>
Subject: Re: [sip-overload] draft-ietf-soc-overload-control-02 and algorithm agility

No?

-hadriel

Janet
[email-masked] wrote: -----

Howdy,

-hadriel

---

From: <[email-masked]>
Date: Thu, 31 Mar 2011 08:03:09 +0200

My understanding is that Rate-based is more efficient for handling mass calling (e.g. televoting) but is a bit more complex to operate than Loss-based. Considering that for Televoting and similar services the filter-based solution (i.e. draft-soc-shen…)  is probably more appropriate anyway, I’m wondering whether Rate-based should really be the “mandatory default” for the feedback-based solution…

Bruno

De : [email-masked] [mailto:[email-masked]] De la part de Janet P Gunn
Envoyé : mercredi 30 mars 2011 15:30
À : Hadriel Kaplan
Cc : [email-masked]
Objet : Re: [sip-overload] draft-ietf-soc-overload-control-02 and algorithmagility

Janet

-----Hadriel Kaplan <[email-masked]> wrote: -----

No?

-hadriel

 

Janet

[email-masked] wrote: -----

Howdy,

-hadriel

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 31 Mar 2011 03:53:47 -0500

Hadriel: Please see inline.

On 03/29/2011 11:09 AM, Hadriel Kaplan wrote:
 > Howdy, in today's WG session the new oc-algo mechanism was described,
 > and it was stated the WG had agreed to support multiple algorithms,
 > with a pointer to this thread:
[...]
 > 1) Every time we add something optional, interop issues happen.  [...]

Hadriel: Indeed, I am sympathetic to that as well.

 > 2) Currently, there is only one algorithm: loss.  Other algorithms
 > were tested (rate and window), but since the results were effectively
 > the same, it would seem rather foolish to add support for those other
 > two.  So this would have to be a 4th, as yet unknown, algorithm.
 > That's fine, but we don't need to create a param or logic to handle
 > unknown future algorithms *now*. Think about it - nothing prevents a
 > future algorithm from adding this oc-algo param in a
 > backwards-compatible manner.  Ergo, we don't need to do it now.  In
 > fact, since we don't know the future algorithm(s), we have no idea if
 > they could even use the other params we have.

Just so that we are all on the same page, Hadriel is arguing that
we do not have the "oc-algo" parameter at all.  We go with the loss-
based algorithm right now, and if that does not work then at some
future time we have an updated RFC that adds the new "oc-algo" Via
parameter.  The backward compatibility will be acheived by older
implementations defaulting to using loss-based because they will
not have the context to understand the new "oc-algo" parameter.

I think this is reasonable, especially since it cuts out the
complexity listed next:

 > 3) Doing this is not as trivial as the draft currently has it.  You
 > cannot just "negotiate" it by having *only* the client-side send the
 > param again in the next request when it wants to re-negotiate it,
 > because the client has no idea when its next-hop server has rebooted,
 > or the next-hop server's had *its* config changed.  If that happens,
 > the server would get a request form the client without the param, and
 > thus think the client is using loss, even if they previously
 > negotiated some new algo.

Yes, I am sympathetic to this as well.  Although the current text
says that the algorithms must not be re-negotiated frequently, it
does not define the interval.  RjS pointed out that this will
create interoperability problems.  And since the renegotiation is
driven by the client, there are the other problems you mention
above.

 > 4) When you're the server-side, you'll now have to keep a negotiated
 > algorithm setting pre previous hop client.  For some server systems
 > that's easy, but for some servers that's untenable - they don't keep
 > state per previous hop client.  And I believe our charter requires us
 > to support a model of unknown previous-hop clients.

Right; btw, keeping less state in the server is an argument to pick
loss-based as the default algorithm instead of rate-based.  The
latter requires the server to assign --- and keep track --- of a
share of its overall capacity with each upstream client.

In summary, I think it is worth debating Hadriel's point 2
above, i.e., should we put algorithm negotiation right
now or do it later in a backwards compatible manner.

Thoughts?

Thanks,

- 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} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Thu, 31 Mar 2011 03:57:00 -0500

On 03/29/2011 05:50 PM, Hadriel Kaplan wrote:
> Either they're all effectively the same, or they're not. As far as I
> know, the results of the design-team were they were the same, so the
> loss based one was picked just because it's the simplest to implement.
> If a rate-based is instead more effective, even if it's just for "corner
> cases", then we should pick that one instead.

The rate-based one requires more state in the server.  Keeping
less state in the server is an argument to pick loss-based as the
default algorithm instead of rate-based.  The latter requires the
server to assign --- and keep track --- of a share of its overall
capacity with each upstream client.  There is a good discussion
of this in the design document [1], Sections 9.1 and 9.2.

[1] http://tools.ietf.org/html/draft-ietf-soc-overload-design-05

Thanks,

- vijay

---

From: Volker Hilt <[email-masked]>
Date: Thu, 31 Mar 2011 11:09:23 +0200

The SIP overload control design team had spent quite some time on 
comparing the different types of algorithms. A summary of the results of 
the simulations that were run was presented in SIPPING at IETF 74:

http://www.ietf.org/proceedings/74/slides/sipping-11/sipping-11.htm

These results indicate that there is little difference between the 
different types of algorithms. The design team had evaluated the 
algorithms under a range of conditions. Details are in the slides above.

More inline.

> While both loss based and rate based algorithms work well in a simulated
> environment, driven by random processes, there are a number of highly
> probable real world scenarios (e.g. highly localized source of overload,
> or rapidly varying overload) in which a loss based algorithm is either
> ineffective or unfair.

Do you have pointers to results that show that the loss based algorithms 
is ineffective or unfair in a SIP network? It would be helpful to back 
these statements up with results otherwise we end up guessing what may 
or may not happen in a network.

The design team has evaluated scenarios with rapidly changing load 
conditions and fairness among sources. The results are in the slides 
above. Both loss and rate-based mechanisms worked well in all the 
scenarios we have evaluated.

> Evidence of the greater robusness, fairness, and effectiveness of
> rate-based network management controls is found in the circuit switched
> PSTN where "Call Gapping" (rate based) has made the percentage-dropped
> network management controls all but obsolete.
> There are, of course, many differences between the PSTN and a SIP
> network. But this particular case seems to be a place where we can, and
> should, learn from the lessons learned in the PSTN.

Again, I'd like to see these claims backed up with results for a SIP 
server. The members of the design team did not find these evidences.

Thanks,

Volker

>     in today's WG session the new oc-algo mechanism was described, and
>     it was stated the WG had agreed to support multiple algorithms, with
>     a pointer to this thread:
>     I have read that thread, and there were actually few discussions
>     about the need for multiple algorithms (most of it was about 100
>     response handling or how often algorithms would change, not the need
>     for multiple algorithms).
>
>     1) Every time we add something optional, interop issues happen. The
>     protocol gets more complicated, there's more to test, more to fail,
>     etc. ISTM that a overload control mechanism should be as simple as
>     possible, with the greatest probability of success and interop. For
>     me, the bar would have to pretty darn high to add optionality -
>     there would have to be a really good reason.
>
>     were tested (rate and window), but since the results were
>     effectively the same, it would seem rather foolish to add support
>     for those other two. So this would have to be a 4th, as yet unknown,
>     algorithm. That's fine, but we don't need to create a param or logic
>     to handle unknown future algorithms *now*. Think about it - nothing
>     prevents a future algorithm from adding this oc-algo param in a
>     fact, since we don't know the future algorithm(s), we have no idea
>     if they could even use the other params we have.
>
>     because the client has no idea when its next-hop server has
>     rebooted, or the next-hop server's had *its* config changed. If that
>     happens, the server would get a request form the client without the
>     param, and thus think the client is using loss, even if they
>     previously negotiated some new algo.
>

---

From: Volker Hilt <[email-masked]>
Date: Thu, 31 Mar 2011 11:25:20 +0200

Hadriel,

> they could even use the other params we have.
I agree. An extension mechanism can be added in the future as you point 
out when it becomes necessary for some reason. I.e., the first extension 
would have to define the extension mechanism. This can be done in a 
backwards compatible way the does not break things.

> negotiated some new algo.

The client needs to send the algo parameter in every request, not only 
when it renegotiates. That will keep things fairly simple.

The client sends the algorithms it supports. The server responds with an 
oc value for one of the algorithms and an indication which algorithm it 
is. The server decides which algorithm that was offered by the client it 
wants to use. The response needs to contain a parameter saying with 
algorithm it is. No parameter would mean the default.

With this, reboots of either side will not be a problem. Since we have a 
mandatory to implement default algorithm, interoperability should also 
not be a problem.

Having said that, I believe this extension mechanism can be added when 
the first extension is defined.

Thanks,

Volker

> _______________________________________________ sip-overload mailing
> list [email-masked]

---

From: Volker Hilt <[email-masked]>
Date: Thu, 31 Mar 2011 11:30:52 +0200

Yes, I'm for leaving the extension mechanism for a future draft. It 
seems that creating such a mechanism at a later point is feasible.

Volker (as individual)