Re: [sip-overload] draft-ietf-soc-overload-control-02 and algorithmagility

[<[e-mail]>]

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 : [e-mail] [mailto:[e-mail]] De la part de Janet P Gunn
Envoyé : mercredi 30 mars 2011 15:30
À : Hadriel Kaplan
Cc : [e-mail]
Objet : Re: [sip-overload] draft-ietf-soc-overload-control-02 and algorithmagility

 

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 <[e-mail]> wrote: -----

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

 

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:





 

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

[e-mail] wrote: -----

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

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



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