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

[ken carlberg <[e-mail]>]

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 <[e-mail]>
> To:	[e-mail]
> 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 
> 
> 
>  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
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sip-overload
> 
>