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

[Adam Roach <[e-mail]>]

On 3/8/12 1:04 PM, Vijay K. Gurbani wrote:
> On 03/08/2012 12:30 PM, Adam Roach wrote:
>> No, now I'm even more confused. I have a rather long list of things I
>> think need to change here, but I don't want to throw them all out for
>> fear of them being confused with each other.
>>
>> Let's start simple, with the most fundamentally important question:
>> where is "get_sip_msg()" getting a message from?
>>
>> (a) Some internal queue of outgoing SIP messages to be sent to the 
>> network
>> (b) A network interface (or some abstraction thereof) representing
>> incoming SIP messages
>> (c) Somewhere else
>
> So I fail to see the need to pin down exactly where it is getting
> these messages from?

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.

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

Similarly, requests that you're about to *send* are subject to the 
overload state of their next hop host, and might be dropped accordingly. 
Requests that you've just *received* aren't (although they might be 
subject to local rejection, per the behavior in 5.10.2).

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.

/a