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

[Volker Hilt <[e-mail]>]

Hadriel,

> 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.
>
I agree. An extension mechanism can be added in the future as you point 
out when it becomes necessary for some reason. I.e., the first extension 
would have to define the extension mechanism. This can be done in a 
backwards compatible way the does not break things.

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

The client needs to send the algo parameter in every request, not only 
when it renegotiates. That will keep things fairly simple.

The client sends the algorithms it supports. The server responds with an 
oc value for one of the algorithms and an indication which algorithm it 
is. The server decides which algorithm that was offered by the client it 
wants to use. The response needs to contain a parameter saying with 
algorithm it is. No parameter would mean the default.

With this, reboots of either side will not be a problem. Since we have a 
mandatory to implement default algorithm, interoperability should also 
not be a problem.

Having said that, I believe this extension mechanism can be added when 
the first extension is defined.

Thanks,

Volker

> 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