Re: [sip-overload] FW: New Version Notification fordraft-partha-soc-overload-resource-availability-00

[Volker Hilt <[e-mail]>]

Paul,
>
> In regards to "draft-hilt-sipping-overload" ...
>>> inserting the "oc" values in the Via headers would indicate (to
>> whom?) "the
>>> percentage by which the load forwarded to this SIP server should be
>>> reduced".  This might make sense if there is a single peer device,
>> but what
>>> if there are 100 peers?  How much should any one of those peers
>> reduce load
>>> to the device?
>>
>> The nice thing about percentage numbers is that you can forward them to
>> all neighbors (e.g., 20%) without counting them. Overall you will get a
>> reduction of 20%. An alternative is to forward an absolute rate (say
>> 100cps). In this case, you need to split your overall capacity across
>> all upstream neighbors (i.e, know how many neighbors there are).
>
> I have a third alternative that I'd like to write up, as it requires a bit
> of explanation.
>
> I still don't quite understand how the percentage-based messages will work.
> If a device is sending no traffic, then it's a bit hard to reduce.  If it
> sends 1 call and gets a response that says to reduce traffic by 90%, what
> does that mean?  I understand what the behavior would be when there is an
> established flow of messages, but it's the "edge cases" that I don't fully
> understand how to handle.
>
A simple way of thinking about this is that the percentage value is the 
probability for each message to be rejected. I.e., if a SIP proxy needs 
to reduce load by 10%, it can to use a random process that rejects each 
message with a 10% probability and forwards it with 90% probability. 
Overall, this will lead to the desired reduction.

This is described in more detail in Section 9.2. of 
draft-hilt-soc-overload-design-00.

>>> This seemed a little confusing to me, even if there were
>>> just two peers.  And in the case of a single peer, it seems to only
>> work
>>> with percentages.  So, if a device tells a peer to reduce by 100%,
>> then
>>> traffic stops.  If it says "reduce by 0%", then what would prompt
>> traffic to
>>> flow?
>>
>> Not sure I understand your comment. Reduce by 0% would mean there is no
>> reduction, i.e., the proxy can pass along messages.
>
> There are two points of confusion I have:
> 1) What happens when a device is told to reduce by 100%?  Does that stop all
> messages?

This is a good point that probably needs clarification in the draft. 
Applying the percentage to all messages has the advantage that it works 
independent of the transaction type. I.e., you don't need to know that 
an INVITE transaction actually corresponds to 5 messages whereas a 
MESSAGE only to two. If you use the percentage on all messages, a 
reduction percentage of 100% would be catastrophic and something you 
should not experience if the overload control algorithm works properly. 
For any reduction, it is useful to have priorities, e.g., target new 
INVITEs before messages of existing dialoges are targeted.

> 2) When and how is it able to start message exchanges again?  If a device
> was told to reduce by 100%, but then we tell it to reduce by 0%, would that
> prompt traffic flow?  My point here was that if a device is sending 0
> traffic and is told to reduce by 0 (i.e., increase by 100%), the 0 * 100% =
> 0.
>
There is a discussion of this issue in Section 9.2. of 
draft-hilt-soc-overload-design-00.

Thanks,

Volker