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

["Vijay K. Gurbani" <[e-mail]>]

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:
 > http://www.ietf.org/mail-archive/web/sip-overload/current/msg00436.html
[...]
 > 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.  [...]

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