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

From: ken carlberg <[email-masked]>
Date: Mon, 7 Mar 2011 08:53:09 -0500

hi,

I believe some more text is needed for clarification concerning section 12 (Message Prioritization) of the draft.  With respect to the last sentence of the following:

   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 sessions over requests that
   set up a new session.

does this statement only apply to priorities of the same level?  What if the priority in setting up a new session is higher than the existing one?  I know of systems that insist on taking a preemptive action, and others that will never allow this.  In this document, I don't believe one doesn't have to state the action to be taken, but I think it would help to recognize the potential options at hand.

The second paragraph of Section 12 states the following:

  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.

The immediate thought that comes to mind is how do these three options relate to the existing Namespace/Value tuples that have already been defined in rfc-4412?  Also, at the last wg meeting, I believe someone asked if a new Namespace/Value should be defined for the overload condition.  Perhaps a statement should be added to the text that covers this possibility and/or recommendation.

-ken