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

[Janet P Gunn <[e-mail]>]

[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.

I do not think it is practical (from a timing perspective) for an 
MLPP-marked 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.

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.

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). 

 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".  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. 

Being "exempt from shedding" is much more valuable.

Janet