Re: [sip-overload] draft-ietf-soc-overload-design-05

["James M. Polk" <[e-mail]>]

At 03:10 PM 4/19/2011, James M. Polk wrote:
>At 01:04 PM 4/19/2011, Janet P Gunn wrote:

Janet

in-line


>>[e-mail] wrote on 04/19/2011 12:32:23 PM:
>>
>> > Re: [sip-overload] draft-ietf-soc-overload-design-05
>> >
>> > James M. Polk
>>
>> >
>> > it might not be, but within an RPH namespace that
>> > is understood, there is the explicit ability
>> > (based on whether it is configured to do so or
>> > not) to have the priority-value determine which
>> > SIP requests get processed moved ahead of (or
>> > before) lower priority-value marked requests (or
>> > those without an understandable (or no)
>> > namespace). Janet called this thrashing - and
>> > said it is bad. This is one of the purposes of
>> > 4412, in times of congestion, to elevate certain
>> > marked requests above others in the processing
>> > queue. Section 8 of 4412 has the guidance of
>> > this. I'm not reading in this thread any
>> > consideration of that function - which really
>> > should be included (or explained why it isn't).
>> >
>> > James
>>
>>James,
>>
>>It is "thrashing" because there are two separate servers 
>>involved.  There are SIP messages on server A, which are intended 
>>to go to server B, but server B is in overload, and is asking 
>>server A to reduce the number of messages it is sending to server B.

[the following is assuming 4412 is configured on server A]

ok, so server A should prioritize the SIP requests according to the 
namespace.priority-value that server A lists as highest priority and 
send those requests first - or without delaying, as will happen to 
the less prioritized or non-prioritized SIP requests. That's what 
4412 says to do. If it becomes the case that the overload condition 
exists such that Server B can only receive RPH marked SIP requests, 
then that's how it is to be configured (where Server A processes 
requests according to RPH).


>>I do not think it is practical (from a timing perspective) for an 
>>MLPP-marked

RFC 4412 is written far wider than just for MLPP and ets - for those 
of you that aren't picking that up.

>>SIP message on server A (in the queue for server B) on server A to
>>a) figure out if the message being processed on server B is preemtable
>>and
>>b) send a message to server B to preemept processing of that message
>>before server B finishes processing THAT (preemptable) message.

how does this work in non-MLPP (and non-ets) environments?


>>Furthermore, I don't think that approach helps the MLPP-marked SIP 
>>message on server A as much as just saying "this SIP message is 
>>exempt from being shed".
>>
>>Once the MLPP-marked SIP message has been transmitted to server B, 
>>it can preemept anything it is entitled to, as far as I am concerned.

But that isn't up to server A (by itself) to decide, as you seem to imply.


>>Same with ets and queuing.  You can do all the queue manipulation 
>>you want, once the ets-marked SIP message has been transmitted to 
>>server B (though I personally don't think it is worth the 
>>processing effort, given Server B is already in, or close to, overload).

If server B is an ETS enabled server, and it has not reached overload 
- it should receive ets marked SIP requests before any other 
requests, right? Why wouldn't that be the case?


>>  But as long as the ets-marked SIP message is sitting on server A 
>> (in the queue for server B), it is a lot more beneficial to say 
>> "this ets-marked SIP message will not be shed" than to say "lets 
>> move this ets-marked SIP message to the front of the queue, where 
>> it STILL might be shed".

I don't get where you say "where it STILL might be shed" ? Why would 
it be shed? The most likely (i.e., practical) way of looking at ets 
is that not very many SIP requests will be so marked, therefore there 
shouldn't be very many requests sitting in server B's processing queue.

>>Whether you are dealing with percent based, or rate based load 
>>shedding, there is no particular advantage to being "first in line" 
>>at an arbitrary point in time.

I disagree - especially when the first in line gets processed next.


>>Being "exempt from shedding" is much more valuable.

you're suggesting a second layer of complexity to SOC and reducing 
the behavior of normal 4412 operation in the process by having an 
upstream server hold a SIP request for a downstream server in times 
of near overload where there is a message prioritization mechanism in 
place. Your solution would seem to ignore the prioritization 
mechanism altogether - so why would it be there in the first place?

James


>>Janet