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

[Eric McMurry <[e-mail]>]

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.

(btw, there is a grammar issue in the first sentence)

taken as a client algorithm, it only made sense to me if it described the clients *sending* behavior, which is what I was trying to call out in my first message.  As you and Adam have pointed out, there are different behaviors for different elements in the network.  The UAC and UAS can not necessarily be described with the same algorithm (at least not clearly).  Proxies are another mater also as their behavior is potentially more complex.

So let's consider what the interesting cases are that warrant putting ink to the algorithm.  There are several cases to look at:

* sending from an client endpoint
* receiving at an client endpoint

* receiving at a server endpoint
* sending from a server endpoint

* receiving from a client endpoint at an intermediary
* sending to a client endpoint at an intermediary
* receiving from a server endpoint at an intermediary
* sending to a server endpoint at an intermediary

Since this is only for hop-by-hop, I have not listed all possibilities.  I am also limiting the scope of this discussion to the loss-based default algorithm, and not including others or anything else such as algorithm negotiation.  Working our way down the list:

* sending from an client endpoint
The behavior here is more complex than can be described in a couple of sentences and would be made more clear with an algorithmic description.  The modifications to the algorithm in 6.3 from Adam fit the bill here.

* receiving at an client endpoint
I think this can be described clearly in natural language.

* receiving at a server endpoint
I think this can be described clearly in natural language.

* sending from a server endpoint
I think this can be described clearly in natural language.

* receiving from a client endpoint at an intermediary
I think this can be described clearly in natural language.

* sending to a client endpoint at an intermediary
When the intermediary is a proxy, the behavior here is potentially complex.  I think this would be made more clear with an algorithmic description.

* receiving from a server endpoint at an intermediary
When the intermediary is a proxy, the behavior here is potentially complex.  I think this would be made more clear with an algorithmic description.  It may make sense to cover this in conjunction with the algorithm for sending to a client endpoint from a proxy.

* sending to a server endpoint at an intermediary
I think this can be described clearly in natural language.


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.

On Mar 8, 2012, at 14:04 , Adam Roach wrote:

> On 3/8/12 1:30 PM, Vijay K. Gurbani wrote:
>> 
>> 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.
> 
> No, because there's a lot of processing that needs to take place between receipt of a message and sending that same message. This is complicated by the fact that proxies can, for example, fork requests.
> 
> I think what we really want here is to show one loop that demonstrates how the entity (proxy or user agent) handles messages that are going to the network. Then, separately, we should show a different loop that handles messages coming from the network.
> 
> I suspect we're not going to get untangled from the axle otherwise.
> 
> /a
> _______________________________________________
> sip-overload mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sip-overload