Re: [sip-overload] draft-ietf-soc-overload-control-07 section 6.3 algorithm

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

On 03/08/2012 02:31 PM, Eric McMurry wrote:
> I agree with this sentiment.  I think I (and probably Adam) were
> coming from the assumption that the algorithm described in 6.3 was
> for clients, based on the start of the section:
>
> This section describes a default algorithm that a SIP client can to
> throttle SIP traffic going downstream by the percentage loss value
> specified in the "oc" parameter.

Eric: Understood.  However, because SIP is so rich, a SIP client
could be part of the proxy as well.  When I was doing work in the
sipclf specification, I was told to simply call it a SIP client
instead of "the SIP client part of a proxy..."

Of course, I can make it clear in the overload draft that wherever
"SIP client" is mentioned, it could mean a SIP UAC or proxy.

[...]
> So, I think a couple of algorithms are in order.  The first provided
> by the doc along with Adam's modifications, and a second describing
> proxy behavior.

My contention is that the algorithm in the document and the one I
modified based on your and Adam's input is the most general algorithm;
i.e., one corresponding to the proxy processing (I can add more
background text saying that get_sip_msg() gets a SIP message from the
proxy's processing queue, etc.)  If we do a decent job at specifying
the most complex of the algorithms, implementers will know what to
do for the simpler cases.

Now the question is, did we (or I) do a decent job of specifying the
most complex of the algorithms?  I think I did, but it is clear that
there is still some work to be done.

I fear that providing multiple algorithms or descriptions will simply
create more questions and problems.  The focus should be on the
overload control behaviour vis-a-vis percentage of messages to drop and
what to do when there aren't enough of category 1 messages, etc.  The
redone algorithm I posted that includes your and Adam's comments
improves on the one in the document, I believe.  But clearly, we all
have to consent that it is good enough so we can get the work finished.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
Email: vkg@{bell-labs.com,acm.org} / [e-mail]
Web:   http://ect.bell-labs.com/who/vkg/