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

[ken carlberg <[e-mail]>]

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.