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

[Volker Hilt <[e-mail]>]

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



> [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
>
>