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

Janet P Gunn <jgunn6@csc.com> Mon, 18 April 2011 18:21 UTC

Return-Path: <jgunn6@csc.com>
X-Original-To: sip-overload@ietfc.amsl.com
Delivered-To: sip-overload@ietfc.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfc.amsl.com (Postfix) with ESMTP id 5BB6EE0849; Mon, 18 Apr 2011 11:21:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Level:
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([208.66.40.236]) by localhost (ietfc.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cG+NG+obA03H; Mon, 18 Apr 2011 11:21:00 -0700 (PDT)
Received: from mail164.messagelabs.com (mail164.messagelabs.com [216.82.253.131]) by ietfc.amsl.com (Postfix) with ESMTP id E53B3E0856; Mon, 18 Apr 2011 11:20:59 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: jgunn6@csc.com
X-Msg-Ref: server-12.tower-164.messagelabs.com!1303150853!39860349!1
X-StarScan-Version: 6.2.9; banners=-,-,-
X-Originating-IP: [20.137.2.88]
Received: (qmail 4604 invoked from network); 18 Apr 2011 18:20:54 -0000
Received: from amer-mta102.csc.com (HELO amer-mta102.csc.com) (20.137.2.88) by server-12.tower-164.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 18 Apr 2011 18:20:54 -0000
Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta102.csc.com (Switch-3.4.3/Switch-3.3.3mp) with ESMTP id p3IIKquO022157; Mon, 18 Apr 2011 14:20:53 -0400
In-Reply-To: <9FEB75F0-712B-4CDE-949D-F3DE4D80BCD7@g11.org.uk>
References: <9FEB75F0-712B-4CDE-949D-F3DE4D80BCD7@g11.org.uk>
To: ken carlberg <carlberg@g11.org.uk>
MIME-Version: 1.0
X-KeepSent: 0DF6A035:7421167A-85257876:00646380; type=4; name=$KeepSent
X-Mailer: Lotus Notes Release 8.0.2FP1 CCH2 April 23, 2009
From: Janet P Gunn <jgunn6@csc.com>
Message-ID: <OF0DF6A035.7421167A-ON85257876.00646380-85257876.0064CA28@csc.com>
Date: Mon, 18 Apr 2011 14:20:50 -0400
X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP1 HF29|January 09, 2011) at 04/18/2011 02:19:45 PM, Serialize complete at 04/18/2011 02:19:45 PM
Content-Type: multipart/alternative; boundary="=_alternative 0064B84085257876_="
Cc: sip-overload-bounces@ietf.org, sip-overload@ietf.org
Subject: Re: [sip-overload] draft-ietf-soc-overload-design-05
X-BeenThere: sip-overload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Overload <sip-overload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sip-overload>, <mailto:sip-overload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sip-overload>
List-Post: <mailto:sip-overload@ietf.org>
List-Help: <mailto:sip-overload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip-overload>, <mailto:sip-overload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 Apr 2011 18:21:02 -0000

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 <carlberg@g11.org.uk>
To:
sip-overload@ietf.org
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
sip-overload@ietf.org
https://www.ietf.org/mailman/listinfo/sip-overload