Re: [sip-overload] Issue: Multiple algorithms -> Single algorithm for overload control

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

On 06/16/2011 08:01 AM, [e-mail] wrote:
> To follow up on my e-mail below, I am producing a proposed revision
> of draft-ietf-soc-overload-control-02 for comment, and I expect to
> send this out for consideration early next week.
>
> So far it looks like there will be a considerable simplification,
> since essentially the overloaded SIP server is now master and there
> is no longer any need for negotiation of the restriction algorithm at
> the SIP client. It should also make future evolution more
> straightforward both for the spec and for deployments.
>
> There may some additional complexity to specify the algorithms
> themselves, but it is not clear to me to what extent the spec is
> expected to nail them down.

Phil: I believe that modifying a working group document without
a consensus is probably not appropriate.

Certainly, the same set of folks who have been arguing for the
rate have expressed interest in it again, but I do not sense
that a larger discussion has taken place to develop a consensus
to support *all overload algorithms* at the same time.

As such, it may be best to issue an independent document of how
you see such a solution proceeding, and in such a document,
feel free to use the terminology and parameters established
in draft-ietf-soc-overload-control.  Subsequent to that, we
can debate the merits of supporting all algorithms and incorporate
the consensus into the working group document
(draft-ietf-soc-overload-control).

I am sorry, but I have been tied up and need to catch
up with list email.

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/