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

[Volker Hilt <[e-mail]>]

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)



On 3/31/2011 10:53 AM, Vijay K. Gurbani wrote:
> 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