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

Janet P Gunn <> Tue, 19 April 2011 18:04 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id C1700E0832; Tue, 19 Apr 2011 11:04:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id WirWBff0GyfR; Tue, 19 Apr 2011 11:04:09 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 7A196E0702; Tue, 19 Apr 2011 11:04:09 -0700 (PDT)
X-VirusChecked: Checked
X-StarScan-Version: 6.2.9; banners=-,-,-
X-Originating-IP: []
Received: (qmail 13522 invoked from network); 19 Apr 2011 18:04:08 -0000
Received: from (HELO ( by with DHE-RSA-AES256-SHA encrypted SMTP; 19 Apr 2011 18:04:08 -0000
Received: from ( []) by (Switch-3.4.3/Switch-3.3.3mp) with ESMTP id p3JI47cY026322; Tue, 19 Apr 2011 14:04:07 -0400
In-Reply-To: <>
References: <> <> <> <> <> <> <> <>
To: "James M. Polk" <>
MIME-Version: 1.0
X-KeepSent: 44845051:E121E247-85257877:00619C7C; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.0.2FP1 CCH2 April 23, 2009
From: Janet P Gunn <>
Message-ID: <>
Date: Tue, 19 Apr 2011 14:04:10 -0400
X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP1 HF29|January 09, 2011) at 04/19/2011 02:02:58 PM, Serialize complete at 04/19/2011 02:02:58 PM
Content-Type: multipart/alternative; boundary="=_alternative 0063434585257877_="
Cc:, "" <>
Subject: Re: [sip-overload] draft-ietf-soc-overload-design-05
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Overload <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 19 Apr 2011 18:04:10 -0000 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


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

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 

Being "exempt from shedding" is much more valuable.