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

[<[e-mail]>]

Vijay,

Thanks for the advice. I was indeed intending it to be an independent document, but a copy incorporating revisions to the original so that the differences would be made as clear. Given that the intention is for both proposals to support multiple restriction algorithms at clients I suggest that it would help to compare them.

Although in principle both approaches would support (or evolve to support) the same capability, I am concerned (if not convinced) that proceeding with a single mandated algorithm would result in non-adoption of the other algorithms by suppliers and in effect the alternatives would become redundant (rather like a piece of DNA with redundant sequences?). This particular issue is not really a technical one. But I see this as a critical decision for the evolution of SIP.

I see that contributors like yourself have done much valuable work before me. Like you I have been tied up with other work, but for rather longer! Please bear with me,

Regards,

Phil

-----Original Message-----
From: Vijay K. Gurbani [mailto:[e-mail]] 
Sent: 16 June 2011 14:36
To: Williams,PM,Phil,DEV6 R
Cc: [e-mail]
Subject: Re: [sip-overload] Issue: Multiple algorithms -> Single algorithm for overload control

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/