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

[Hadriel Kaplan <[e-mail]>]

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