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

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

On 03/08/2012 01:12 PM, Adam Roach wrote:
> Because responses that you're *sending* will *not* contain overload
> information that you need to extract. In fact, you'll need to take
> action to *put* overload information in them.

Well ... if you are *sending* a response, you're acting as a proxy
and in fact, will take out oc parameters from a response going upstream.

> Responses that you're *receiving* will potentially contain overload
> information that you need to extract and store.

Right.

> Similarly, requests that you're about to *send* are subject to the
> overload state of their next hop host, and might be dropped accordingly.

Right.

> Requests that you've just *received* aren't (although they might be
> subject to local rejection, per the behavior in 5.10.2).

Right.

> Critically, there are four different behaviors that need to be detailed:
> inbound request, outbound request, inbound response, and outbound
> response. The algorithm in the draft (and the revised one that you
> proposed) seem to mash these all together into two cases (request and
> response), which are then slightly or radically wrong, depending on
> whether they're applied to inbound or outbound messages.

So assume that you are a proxy (the most general of the entities doing
overload control).  And also assume that when you execute

while (true)  {
    sip_msg := get_sip_msg() ... }

that if this is a request, it has been picked up from the network and
put on your processing queue.  If it is a response, then it has been
picked up from the network and put on your processing queue.  From your
viewpoint, requests are now destined downstream subject to overload
control.  Similarly, responses are to be processed to extract overload
control information and proxied upstream.

With this context, see if things make more sense.

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