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

"James M. Polk" <> Tue, 19 April 2011 16:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B3C1FE07D7 for <>; Tue, 19 Apr 2011 09:32:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -111.399
X-Spam-Status: No, score=-111.399 tagged_above=-999 required=5 tests=[AWL=1.200, BAYES_00=-2.599, GB_I_INVITATION=-2, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id bYPNko7vPZpm for <>; Tue, 19 Apr 2011 09:32:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id A632AE07C0 for <>; Tue, 19 Apr 2011 09:32:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=14779; q=dns/txt; s=iport; t=1303230746; x=1304440346; h=message-id:date:to:from:subject:cc:in-reply-to: references:mime-version:content-transfer-encoding; bh=QLvOBqRhR+Rx9SwMmCn2+Lxv6v5wDFZQBkHozuiFyy8=; b=MP74eWX5wx5mHZ5LGGFO0etIe0WOvp/wtfvgIHH5eoLK08rHCPnBdwVX cgyiHxfKpNBiKlxMidoiYpapSOFsL+oBZreWpeiCN2q65zt/bRBbNJjn2 2TvMkstLSj5sF005iQWKH1vuoughmBY9OERB9xzf2meqeBIakwJEbkPrC I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvsEAOa3rU2rRDoI/2dsb2JhbAClLHenfJxnhXEEhWc
X-IronPort-AV: E=Sophos;i="4.64,240,1301875200"; d="scan'208";a="683955335"
Received: from ([]) by with ESMTP; 19 Apr 2011 16:32:25 +0000
Received: from ( []) by (8.14.3/8.14.3) with ESMTP id p3JGWP9d021586; Tue, 19 Apr 2011 16:32:25 GMT
Message-Id: <>
X-Mailer: QUALCOMM Windows Eudora Version
Date: Tue, 19 Apr 2011 11:32:23 -0500
To: "DRAGE, Keith (Keith)" <>, ken carlberg <>
From: "James M. Polk" <>
In-Reply-To: <EDC0A1AE77C57744B664A310A0B23AE21EC517EC@FRMRSSXCHMBSC3.dc>
References: <> <> <> <> <> <> <>
Mime-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"; format=flowed
Content-Transfer-Encoding: quoted-printable
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 16:32:28 -0000

At 08:43 AM 4/19/2011, DRAGE, Keith (Keith) wrote:
>Content-Language: en-US
>Content-Type: multipart/alternative;
>With regard to your comment on 1), I believe 
>nothing extra is required. Anyone setting up 
>multiple namespaces has to define at each entity 
>that is required to understand them how they are 
>treated in relationship to each other. That is 
>part of the implementation. That will define 
>which namespaces exist, and which are used at 
>the receiving entity to give any form of 
>priority handling. There is no reason for SIP 
>overload to alter that relationship in any way, shape, or form.
>On 2), I do not believe your comment is correct. 
>The fact that a namespace is a pre-emption 
>namespace is not an invitation to pre-empt all 
>other calls until you get your call through, 
>even under situations of no overload. It merely 
>states that calls can be pre-empted when this 
>namespace is used. The same applies for 
>priority. Usually the algorithm for handling 
>these DOES NOT SAY – handle all calls with this 
>namespace until there are none left, and then 
>move onto others. It deals with things like 
>percentage of traffic and so on. So what I am 
>saying is that the RPH is not a guarantee to override all other traffic,

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


>whether overload exists or not.
>From: ken carlberg []
>Sent: 19 April 2011 14:23
>To: DRAGE, Keith (Keith)
>Cc: Janet Gunn;
>Subject: Re: [sip-overload] draft-ietf-soc-overload-design-05
>On Apr 19, 2011, at 9:03 AM, DRAGE, Keith (Keith) wrote:
>My confirmation was on what Janet wrote, rather than the original text.
>Two comments.
>1)         Any statement about some specific RPH 
>being taken as a default are inappropriate. If 
>you are using RPH you must handle them in the 
>way you already know. If you do not know about 
>an RPH value, then you have to ignore it (and 
>possibly delete it in the outgoing INVITE 
>depending on your policy). There are certainly 
>use cases where multiple RPH values can exist, 
>covering different aspects of priority on the 
>same request. It may be the second one that is 
>received that defines the priority in regard to 
>the handling in the SIP server itself (as 
>opposed to priority of giving a media stream or whatever).
>or it may be the first, or the last.  I'll 
>concede the difficulty in stating the first 
>"recognized/supported" RPH is the one to be 
>used.  But I think one is deferring the problem 
>that arises with no position taken at all.  The 
>primary point that I wanted to make was that the 
>possibility of multiple RPHs may exist.  I'm 
>fine with removing the text of choosing a default RPH in that instance.
>2)         In a case of load shedding, I suspect 
>that the discussion on whether either priority 
>or pre-emption are relevant depend on whether 
>you are using them to represent the request to 
>the original target server that indicated 
>overload, or to some other server. I believe 
>that in the case of representing to the original 
>targetted server it is inappropriate. It is 
>making the assumption that some of the existing 
>traffic directed from this server to that server 
>is somehow responsible for the overload, and 
>that is an entirely invalid assumption.
>again, the intent of the suggested added text 
>was to point out to the reader that preemption 
>and queuing are *examples* of what has been 
>defined so far with respect to Namespaces.  What 
>you have stated above makes a case that another 
>Namespace should be defined, otherwise, you one 
>is overloading new characteristics from what has already been defined.
>From: ken carlberg []
>Sent: 19 April 2011 13:39
>To: DRAGE, Keith (Keith)
>Cc: Janet Gunn; <>
>Subject: Re: [sip-overload] draft-ietf-soc-overload-design-05
>If your comment is about the original text, then 
>we are in some measure of agreement.  If you 
>agree with a position that its incorrect to 
>point out the characteristics for currently 
>defined Namespaces as stated in rfc4412, then we are in disagreement.
>On Apr 19, 2011, at 6:04 AM, DRAGE, Keith (Keith) wrote:
>Janet’s statements about RPH align with the way I understand RPH works.
>[] On Behalf Of Janet P Gunn
>Sent: 18 April 2011 19:21
>To: ken carlberg
>Subject: Re: [sip-overload] draft-ietf-soc-overload-design-05
>First of all, that text is included in quite a 
>few of the soc documents, so if you change it in 
>the design doc, it will need to be changed in the others too.
>More importantly, I STRONGLY disagree with the 
>statement that  " The action taken is determined 
>by the characteristics defined for the set of 
>priority values of a Namespace (e.g., preemption versus queuing) ".
>  Neither "preemption" nor "queuing" are 
> appropriate responses to a request for load 
> shedding.  Either the request is shed, or it is 
> not.  AFAIK, there is no intention to "preempt" 
> another request, nor to change in the order in 
> which the messages respond to load shedding..
>In particular, in systems already deployed, SIP 
>messages using the ets/wps family of namespaces 
>(which are defined as "queuing based" , and do 
>queue for MEDIA resources) receive exemption 
>from SIP server  overload based shedding.  They 
>do NOT have any special queuing based 
>behavior  for SIP server resources.  Not do they preempt other SIP requests.
>Furthermore, the behavior associated with a 
>particular namespace is highly dependant on the 
>particular network.  dsn.flash-override is not 
>going to elicit any priority behavior in a 
>civilian or public network.  It will certainly 
>not  preempt anything.  Conversely, ets.0, 
>wps.0  is not going to elicit any priority behavior in the DSN network
>The statement "An example local policy may even 
>include exemptions from network management 
>control." introduces a new term - " network 
>management control" which would need to be 
>defined.  I presume that what you really mean in 
>this context is "exemption from load 
>shedding".  This is already covered in i) of the existing text.
>I fail to see the reason for your proposed 
>statement "However, for the sake of simplicity, 
>a default position should be the use of the 
>first RPH entry to   determine the priority of 
>the SIP request. "  AFAIK, the order of the 
>headers is not generally relevant to SIP, and I 
>do not see any particular need to introduce it 
>here.   Furthermore, a given SIP agent only 
>"understands" certain namespaces.  It seems 
>highly  counterproductive to suggest that a SIP 
>server, by default, should "use" a namespace it 
>doesn't understand (just because it is "first") 
>, and ignore the one(s) it does understand (just because not "first").
>Even if you change the statement to read "the 
>first RPH entry it understands", you would need 
>a "default behavior" to go with the "default namespace."
>As far as I am concerned, if a particular SIP 
>server does NOT have a local policy for RPH 
>(both which namespaces are relevant/understood, 
>and the appropriate behavior for each namespace 
>or combination of namespaces), then it should 
>simply ignore the RPH namespaces.  This seems 
>consistent with generic SIP behavior with regard to namespaces in general.
>I fail to see the significance of the statement 
>about B2BUAs.  ALL SIP servers, (not just 
>B2BUAs) can and will insert, delete, or change the RPH.
>  I also fail to see the need to refer 
> explicitly to Namespaces not defined in 
> RFC4412.  There are already a large number of 
> IETF registered RPH namespaces which do not 
> appear in RFC4412 (see RFC 5478 for example) 
> and others have been proposed (for instance 
> draft-ietf-ecrit-local-emergency-rph-namespace). 
>    If you are suggesting that specific networks 
> may be using purely "private" RPH namespaces 
> that have never been subject to IETF review, 
> that may well be true in practice, but I don't 
> think it should be introduced into IETF 
> documents- especially ones that are not primarily about RPH.
>This is a PRIVATE message. If you are not the 
>intended recipient, please delete without 
>copying and kindly advise us by e-mail of the mistake in delivery.
>NOTE: Regardless of content, this e-mail shall 
>not operate to bind CSC to any order or other 
>contract unless pursuant to explicit written 
>agreement or government initiative expressly 
>permitting the use of e-mail for such purpose.
>ken carlberg <<>>
>04/17/2011 03:38 PM
>[sip-overload] draft-ietf-soc-overload-design-05
>in following up on the discussion point I 
>brought up at the Prague-IETF meeting concerning 
>RPH related text, I've added some suggested text 
>to section 12 of 
>draft-ietf-soc-overload-design-05.  The 
>suggested text is bound by the following tags:
><insert text>
></insert text>
>The purpose of the new text is to present a more 
>complete picture and point out aspects that 
>others following this effort should be aware 
>of.  I've kept the rest of the original text for 
>that section as is (ie, I did not remove any 
>original text).  I've also sent the suggested 
>text to Martin and James for a sanity check before posting to the list.
>  12.  Message Prioritization
>   Overload control can require a SIP server to prioritize requests and
>   select requests to be rejected or redirected.  The selection is
>    largely a matter of local policy of the SIP server, the overall
>   network, and the services it provides.  As a general rule, SIP server
>   should prioritize requests for ongoing dialogs over requests that set
>   up a new dialog.  Targeting requests for ongoing dialogs may prevent
>   users from modifying or terminating an ongoing dialog.
>   While there are many factors which can affect the prioritization of
>   SIP requests, the Resource-Priority header field [RFC4412] is a prime
>   candidate for marking the prioritization of SIP requests.  Depending
>   on the particular network and the services it offers, a particular
>   namespace and priority value in the RPH it could indicate i) a high
>   priority request, which should be preserved if possible during
>   overload, ii) a low priority request, which should be dropped during
>   overload, or iii) a label, which has no impact on message
>   prioritization in this network.  <insert text> The action taken is
>    determined by the characteristics defined for the set of priority values
>    of a Namespace (e.g., preemption versus queuing) as well as the
>    local policies defined for the various Namespaces supported by the
>    server.  An example local policy may even include exemptions from
>    network management control.
>   We note that [RFC4412] allows the presence of multiple RPH entries
>    per SIP request.  Local policy would determine which Namespace and
>    Priority tuple are used to prioritize requests.  However, for the sake of
>    simplicity, a default position should be the 
> use of the first RPH entry to
>    determine the priority of the SIP request.
>   Another scenario that should be considered is the presence of Back
>    to Back User Agents (B2BUA) that may strip out the RPH from the
>    upstream SIP request.  Operators or Administrators may choose to
>    insert their own RPH to support downstream prioritization of the SIP
>    request.  This RPH inserted by the B2BUA may conform to a
>    Namespace set defined in [RPH4412], or it may reflect a new
>    Namespace set.
>    </insert text>
>   For a number of reasons, responses should not be targeted in order to
>   reduce SIP server load.  Responses cannot be rejected and would have
>   to be dropped.  This triggers the retransmission of the request plus
>   the response, leading to even more load.  In addition, the request
>   associated with a response has already been processed and dropping
>   the response will waste the efforts that have been spent on the
>   request.  Most importantly, rejecting a request effectively also
>   removes the request and the response.  If no requests are passed
>   along there will be no responses coming back in return.
>   Overload control does not change the retransmission behavior of SIP.
>   Retransmissions are triggered using procedures defined in RFC 3261
>   [RFC3261] and not subject to throttling.
>sip-overload mailing list
>sip-overload mailing list