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

From: ken carlberg <[email-masked]>
Date: Sun, 17 Apr 2011 15:38:46 -0400

Hello,

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.

cheers,

-ken

 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.

---

From: Volker Hilt <[email-masked]>
Date: Mon, 18 Apr 2011 13:22:30 -0400

Ken,

comments inline.
> prioritization in this network.

I've shortened the added text as follows:
> <insert text> The action taken is
> of a Namespace as well as the local policies defined for the various
> Namespaces supported by the server.
>

I would suggest to move this text to the Gurbani draft as it defines the 
specific processing of RPH.
> determine the priority of the SIP request.

I'm not sure how much this is related to the design considerations of an 
overload control mechanism and how much it is related to RPH. I'd 
suggest to keep this text out of the oc design document.
> Namespace set defined in [RPH4412], or it may reflect a new
Generally, at this point I'd like to keep the changes to the document to 
the absolute necessary. It has been discussed for a long time including 
issues related to RPH.

Thanks,

Volker

---

From: ken carlberg <[email-masked]>
Date: Mon, 18 Apr 2011 13:27:53 -0400

Volker,

I leave it in your hands as to what to keep, remove, or simply move to another document.

cheers,

-ken

On Apr 18, 2011, at 1:22 PM, Volker Hilt wrote:

> I would suggest to move this text to the Gurbani draft as it defines the specific processing of RPH.
> I'm not sure how much this is related to the design considerations of an overload control mechanism and how much it is related to RPH. I'd suggest to keep this text out of the oc design document.
> Generally, at this point I'd like to keep the changes to the document to the absolute necessary. It has been discussed for a long time including issues related to RPH.
> 
> Thanks,
> 
> Volker
> 
> _______________________________________________
> sip-overload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-overload

---

From: Janet P Gunn <[email-masked]>
Date: Mon, 18 Apr 2011 14:20:50 -0400

Ken,

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.

Janet

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.

From:
ken carlberg <[email-masked]>
To:
[email-masked]
Date:
04/17/2011 03:38 PM
Subject:
[sip-overload] draft-ietf-soc-overload-design-05

Hello,

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.

cheers,

-ken

   determined by the characteristics defined for the set of priority 
values 
 
   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.

---

From: ken carlberg <[email-masked]>
Date: Mon, 18 Apr 2011 16:39:06 -0400

Janet,

> Ken, 
> 
> 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. 

that would seem to be the consequence.  And simply having text in multiple places does not make it any more or less correct.

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

you've lost me here.  Each Namespace in rfc-4412, with its corresponding set of values, have been defined to "operate" as either a preemption or queuing algorithm.  (see the end of subsections 10.2 to 10.6 of rfc-4412).  I used "e.g." in my suggested text to allow for future Namespaces to exhibit other characteristics.  But as of today, all we have is preemption and queuing.  So I have no idea how can you strongly object to a statement that reflects what is in rfc-4412.

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

...which means you have now discounted all the Namespaces in rfc-4412.  But the more fundamental problem is that you're jumping around in your discussion point.  Lets keep in mind that as the title indicates, section 12 is on "Message Prioritization", and in particular the prioritization of SIP requests through the use of RPH.  The purpose of the suggested new text is to add more context and bring up points that the reader should be aware of with respect to the RPH.  And I'm comfortable with Volker's point of moving some of the suggested text to another draft given its specificity.

> 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 

...see above.

> 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'll leave it up to the co-authors/chairs as to whether they feel the term network management control is not a commonly understood term for the reader(s) of this document -- I thought it was well understood, but I'll defer to others.  The point I was trying to make is that there may be cases where an *exemption* from the RPH is an acceptable action, as your above example points out.

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

On your last point, you are reading way too much into what was written.  There is absolutely no suggestion in the proposed new text that a server should use a Namespace it does not understand, so lets be a bit more reasonable with the points you are trying to make.

As to suggesting using the first (ok, "recognized" Namespace) as the basis for determining which of multiple priority values to choose from, the position is meant to suggest a path forward to deal with a potentially interoperable problem.  Local policy has its strengths, but it also has its weaknesses in terms of helping achieve interoperability.  The fact that no position has been taken about the relative ordering of RPHs doesn't make it something that should continually be maintained.  I'll understand if there a desire to move this statement to another draft, but some position should be taken.

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

no.  the notion of a "default namespace" is too specific.  I took no position about what specific Namespace(s) to use, nor to suggest the requirement that a new Namespace be defined.  I wanted to point out the potential for multiple Namespaces (not mentioned in the previous text), and suggest (in terms of "should") a course of action to be taken in such a scenario.

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

no disagreement here.

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

Will?  Fascinating.  My understanding is different, but I'll not discuss what vendors do (or plan to do) on this open list.

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

I'm not sure where to begin.  You stated above that characteristics of priority and preemption are not appropriate, but these are the only characteristics that have been defined by the Namespaces in rfc-4412.  And again, you are inserting too much into what was written.  I'm not suggesting the use of a "private" Namespace.  I am only suggesting the *possibility* of a new Namespace, period.  This is supposed to be a document that has relevance for some period of time and allow the reader to consider possibilities and additional context.  To suggest that only namespaces in rfc-4412 are to be used is quite short sighted.

I'll repeat what I stated in my original posting on this thread.  "The purpose of the suggested new text is to present a more complete picture and point out aspects that others following this effort should be aware of".  My intention was to work with what was written, and I made it a point not to delete any existing text.

-ken

> Janet
> 
> 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. 
> 
> 
> From:	ken carlberg <[email-masked]>
> To:	[email-masked]
> Date:	04/17/2011 03:38 PM
> Subject:	[sip-overload] draft-ietf-soc-overload-design-05
> 
> 
> 
> 
> Hello, 
>

---

From: Volker Hilt <[email-masked]>
Date: Mon, 18 Apr 2011 21:22:53 -0400

Janet, All,

are you comfortable with the changes for this draft as proposed below? 
The proposal is the add the following sentence at the end of the RPH 
discussion in Sec 12:

     The action taken is determined by the characteristics defined for
     the set of priority values of a Namespace as well as the local
     policies defined for the various Namespaces supported by the server.

Thanks,

Volker

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 19 Apr 2011 12:04:15 +0200

Janet's statements about RPH align with the way I understand RPH works.

Keith

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Janet P Gunn
Sent: 18 April 2011 19:21
To: ken carlberg
Cc: [email-masked]; [email-masked]
Subject: Re: [sip-overload] draft-ietf-soc-overload-design-05

Ken,

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

Janet

From:

To:

[email-masked]

Date:

04/17/2011 03:38 PM

Subject:

________________________________

Hello,

cheers,

-ken

---

From: Janet P Gunn <[email-masked]>
Date: Tue, 19 Apr 2011 08:23:38 -0400

Volker, 

I would just as soon stick with the original text. 

I think the new proposed text is misleading.

Both Queuing and Preemption are mechanisms that make sense when the 
"holding time" is several orders of magnitude more that the time to 
manipulate the queue, or organize the preemption.  This makes them useful 
mechanisms for dealing with SIP sessions. 

But when dealing with a SIP server, processing SIP messages, the "holding 
time" is likely to be the same order of magnitude as the time to 
manipulate the queue, or organize the preemption.  In this case 
introducing queue manipulation or preemption is counterproductive, and 
likely to lead to thrashing..

We have been through this discussion many times, going back to the 
development of  Req 13 in 5390, and I see no advantage in re-introducing 
it to this document.

Janet

From:
Volker Hilt <[email-masked]>
To:
Janet P Gunn/USA/CSC@CSC
Cc:
"[email-masked]" <[email-masked]>
Date:
04/18/2011 09:23 PM
Subject:
Re: [sip-overload] draft-ietf-soc-overload-design-05

Janet, All,

Thanks,

Volker

values
of
>> I'm not sure how much this is related to the design considerations of 
an overload control mechanism and how much it is related to RPH. I'd 
suggest to keep this text out of the oc design document.
>> Generally, at this point I'd like to keep the changes to the document 
to the absolute necessary. It has been discussed for a long time including 
issues related to RPH.

---

From: ken carlberg <[email-masked]>
Date: Tue, 19 Apr 2011 08:34:51 -0400

I can live with that.

-ken

On Apr 18, 2011, at 9:22 PM, Volker Hilt wrote:

> Janet, All,
> 
> are you comfortable with the changes for this draft as proposed below? The proposal is the add the following sentence at the end of the RPH discussion in Sec 12:
>

---

From: ken carlberg <[email-masked]>
Date: Tue, 19 Apr 2011 08:38:40 -0400

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.

-ken

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

---

From: ken carlberg <[email-masked]>
Date: Tue, 19 Apr 2011 08:43:31 -0400

On Apr 19, 2011, at 8:23 AM, Janet P Gunn wrote:

> Both Queuing and Preemption are mechanisms that make sense when the "holding time" is several orders of magnitude more that the time to manipulate the queue, or organize the preemption.  This makes them useful mechanisms for dealing with SIP sessions.   
> 
> But when dealing with a SIP server, processing SIP messages, the "holding time" is likely to be the same order of magnitude as the time to manipulate the queue, or organize the preemption.  In this case introducing queue manipulation or preemption is counterproductive, and likely to lead to thrashing.. 

you can't have it both ways.  you cannot say that the Namespaces in rfc4412 are the ones to be used, but that their defined characteristics (either being queuing or preemption) are inappropriate.

I fail to see how pointing out aspects in rfc4412 is misleading.  Note that my suggested text does not advocate nor dismiss existing Namespaces.  The text is general and it simply points out existing aspects, such as the potential for multiple RPH, which is not mentioned in the original text of soc-overload-design.  How that can be construed as misleading is beyond me.

-ken

> We have been through this discussion many times, going back to the development of  Req 13 in 5390, and I see no advantage in re-introducing it to this document. 
> 
> Janet
> 
> From:	Volker Hilt <[email-masked]>
> To:	Janet P Gunn/USA/CSC@CSC
> Cc:	"[email-masked]" <[email-masked]>
> Date:	04/18/2011 09:23 PM

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 19 Apr 2011 15:03:03 +0200

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

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.

Regards

Keith

________________________________
From: ken carlberg [mailto:[email-masked]]
Sent: 19 April 2011 13:39
To: DRAGE, Keith (Keith)
Cc: Janet Gunn; [email-masked]
Subject: Re: [sip-overload] draft-ietf-soc-overload-design-05

-ken

Keith

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Janet P Gunn
Sent: 18 April 2011 19:21
To: ken carlberg
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [sip-overload] draft-ietf-soc-overload-design-05

Ken,

Janet

From:

ken carlberg <[email-masked]<mailto:[email-masked]>>

To:

[email-masked]<mailto:[email-masked]>

Date:

04/17/2011 03:38 PM

Subject:

Hello,

cheers,

-ken

[email-masked]<mailto:[email-masked]>

---

From: ken carlberg <[email-masked]>
Date: Tue, 19 Apr 2011 09:23:17 -0400

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

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

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.  

-ken

---

From: Janet P Gunn <[email-masked]>
Date: Tue, 19 Apr 2011 09:40:48 -0400

ken carlberg <[email-masked]> wrote on 04/19/2011 08:43:31 AM:

> 
> you can't have it both ways.  you cannot say that the Namespaces in 
> rfc4412 are the ones to be used, but that their defined 
> characteristics (either being queuing or preemption) are inappropriate.
> 
Ken,

Consider the circuit switched models from which the RPH concept was 
derived.

With queueing, we queue for trunks, we queue for radio resources.  But we 
do NOT QUEUE in response to SS7 congestion (just a higher level protection 
from being dropped), nor do we queue in response to call gapping or other 
network management controls (just exempt from them).  That does not in any 
way diminish the nature of the HPC (High Probability of Completion) 
marking as inherently "queuing based".

Similarly, in the circuit switched version, MLPP preempts established 
sessions. But it DOES NOT preempt SS7 processing, or network call gapping. 
 That does not in any way diminish the nature of MLPP as "preemption 
based".

Same here.

Using more appropriate (than queuing or preemption) techniques to address 
priority in response to SIP server overload (e.g., exemption from load 
shedding) in no way diminishes the nature of the Namespace as "queuing 
based" or "preemption based".

Janet

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Tue, 19 Apr 2011 15:43:01 +0200

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, whether overload exists or not.

Regards

Keith

Sent: 19 April 2011 14:23

Two comments.

-ken

Regards

Keith

Cc: Janet Gunn; [email-masked]<mailto:[email-masked]>

-ken

Keith

Ken,

Janet

From:

To:

Date:

04/17/2011 03:38 PM

Subject:

Hello,

cheers,

-ken

---

From: ken carlberg <[email-masked]>
Date: Tue, 19 Apr 2011 10:30:47 -0400

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

this is somewhat scenario dependent.  but I don't think we are gaining any traction, so I'll stop here.

> 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, whether overload exists or not.

the preemption-capable systems I've worked on in the past *must* preempt or tear down state when there are no available resources -- either established calls (or flows) or call/session establishment.  I guess there are various scenarios and variations of implementations that one can consider, but I think that continues down an endless series of possibilities that never lead to a definitive answer.

I think the subject has been beaten to a pulp.  And to a large degree, we have gone much further into topics than perhaps was necessary.  The purpose of the suggested new next was to broaden the picture and bring up topics that are attributed to the RPH.  The only position that was taken in the text was to suggest in the form of a "should" the use of the first RPH (which I meant to be the first "recognized/supported" RPH).  But I conceded that i was fine to remove that position.

I'll stop here and leave it to the co-authors/co-chairs to decide how to proceed.

-ken

---

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 19 Apr 2011 10:02:00 -0500

On 04/19/2011 09:30 AM, ken carlberg wrote:
> I think the subject has been beaten to a pulp. And to a large degree, we
> have gone much further into topics than perhaps was necessary. The
> purpose of the suggested new next was to broaden the picture and bring
> up topics that are attributed to the RPH. The only position that was
> taken in the text was to suggest in the form of a "should" the use of
> the first RPH (which I meant to be the first "recognized/supported"
> RPH). But I conceded that i was fine to remove that position.
[...]

As the editor of draft-ietf-sip-overload-control, I have read this
thread with interest.

So, the question now is: what, if any, from this thread carries over
into the draft-ietf-sip-overload-control draft?  I am certainly not
up to verse with RPH as some of the members of this working group
are, so I will depend on them to point out any text that should be
modified in draft-ietf-sip-overload-control.

For the sake of completeness, here is what
draft-ietf-sip-overload-control has to say about prioritizing
requests containing the RPH header:

    A SIP client SHOULD honor the local policy for prioritizing SIP
    requests such as policies based on the content of the Resource-
    Priority header (RPH, RFC4412 [RFC4412]).  Specific (namespace.value)
    RPH contents may indicate high priority requests that should be
    preserved as much as possible during overload.  The RPH contents can
    also indicate a low-priority request that is eligible to be dropped
    during times of overload.  Other indicators, such as the SOS URN
    [RFC5031] indicating an emergency request, may also be used for
    prioritization.

Do we deem this to be enough?

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / [email-masked]
Web:   http://ect.bell-labs.com/who/vkg/

---

From: Janet P Gunn <[email-masked]>
Date: Tue, 19 Apr 2011 11:24:24 -0400

Vijay,

What is there now is fine with me. I see no need for change.

Janet

[email-masked] wrote on 04/19/2011 11:02:00 AM:

> [image removed] 
> Vijay K. Gurbani 
> to:
> sip-overload
> 04/19/2011 11:00 AM
> Sent by:
> [email-masked]
>

---

From: "James M. Polk" <[email-masked]>
Date: Tue, 19 Apr 2011 11:32:23 -0500

At 08:43 AM 4/19/2011, DRAGE, Keith (Keith) wrote:
>Content-Language: en-US
>Content-Type: multipart/alternative;
> 
>boundary="_000_EDC0A1AE77C57744B664A310A0B23AE21EC517ECFRMRSSXCHMBSC3d_"
>
>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).

James

>whether overload exists or not.
>
>Regards
>
>Keith
>
>
>----------
>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.
>
>-ken
>
>
>
>Regards
>
>Keith
>
>
>----------
>Cc: Janet Gunn; <mailto:[email-masked]>[email-masked]
>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.
>
>-ken
>
>
>
>----------
><mailto:[email-masked]>[email-masked] 
>[mailto:[email-masked]] On Behalf Of Janet P Gunn
><mailto:[email-masked]>[email-masked]; 
><mailto:[email-masked]>[email-masked]
>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 
>  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.
>
>Janet
>
>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.
>
>
>
>From:
>ken carlberg <<mailto:[email-masked]>[email-masked]>
>To:
><mailto:[email-masked]>[email-masked]
>Date:
>04/17/2011 03:38 PM
>Subject:
>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.
>
>cheers,
>
>-ken
>
>
><mailto:[email-masked]>[email-masked]

---

From: Janet P Gunn <[email-masked]>
Date: Tue, 19 Apr 2011 14:04:10 -0400

[email-masked] wrote on 04/19/2011 12:32:23 PM:

> James M. Polk 

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

---

From: ken carlberg <[email-masked]>
Date: Tue, 19 Apr 2011 15:20:35 -0400

Vijay,

from my perspective, what you have concerning draft-ietf-sip-overload-control is a reasonably good start.  

However, given that this thread has required quite a lot of additional points being raised with a fair amount of detail (whether one agrees with a particular position or not), then what you have would seem to be insufficient in terms of an explanation of related issues and possible suggested path(s) forward.

cheers,

-ken

---

From: Volker Hilt <[email-masked]>
Date: Tue, 19 Apr 2011 21:09:48 -0400

Based on the discussion in this thread, I will keep the original text of 
the design draft (i.e., leave the message prioritization section unchanged).

Thanks,

Volker

On 4/19/2011 10:30 AM, ken carlberg wrote:
>> 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, whether overload exists or not.
>
> the preemption-capable systems I've worked on in the past *must* preempt
> or tear down state when there are no available resources -- either
> established calls (or flows) or call/session establishment. I guess
> there are various scenarios and variations of implementations that one
> can consider, but I think that continues down an endless series of
> possibilities that never lead to a definitive answer.
>
>> ------------------------------------------------------------------------
>> *From:*ken carlberg [mailto:[email-masked]]
>> *Sent:*19 April 2011 14:23
>> *To:*DRAGE, Keith (Keith)
>> *Cc:*Janet Gunn;[email-masked] <mailto:[email-masked]>
>> *Subject:*Re: [sip-overload] draft-ietf-soc-overload-design-05
>> 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
>> 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.
>> -ken
>>
>>
>> Regards
>> Keith
>> ------------------------------------------------------------------------
>> *From:*ken carlberg [mailto:[email-masked]]
>> *Sent:*19 April 2011 13:39
>> *To:*DRAGE, Keith (Keith)
>> *Cc:*Janet Gunn;[email-masked] <mailto:[email-masked]>
>> *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.
>> -ken
>> ------------------------------------------------------------------------
>> *From:[email-masked]
>> <mailto:[email-masked]>[mailto:[email-masked]]*On
>> Behalf Of*Janet P Gunn
>> *Sent:*18 April 2011 19:21
>> *To:*ken carlberg
>> *Cc:[email-masked]
>> <mailto:[email-masked]>;[email-masked]
>> <mailto:[email-masked]>
>> *Subject:*Re: [sip-overload] draft-ietf-soc-overload-design-05
>>
>>
>> Ken,
>>
>> 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
>> 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
>> 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").
>>
>> 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 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
>> 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
>> 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.
>>
>>
>>
>> From:
>> 	
>> ken carlberg <[email-masked] <mailto:[email-masked]>>
>> To:
>> 	
>> [email-masked] <mailto:[email-masked]>
>> Date:
>> 	
>> 04/17/2011 03:38 PM
>> Subject:
>> 	
>> ------------------------------------------------------------------------
>>
>>
>>
>>
>> Hello,
>>
>> 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 ofdraft-ietf-soc-overload-design-05. The
>> 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
>> prioritization in this network.<insert text>The action taken is
>> [email-masked] <mailto:[email-masked]>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Wed, 20 Apr 2011 17:17:49 +0200

OK

Keith

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> On Behalf Of Volker Hilt
> Sent: 20 April 2011 02:10
> >> algorithm for handling these DOES NOT SAY - handle all calls with this