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

"DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com> Tue, 19 April 2011 13:04 UTC

Return-Path: <keith.drage@alcatel-lucent.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 F1F78E0663 for <sip-overload@ietfc.amsl.com>; Tue, 19 Apr 2011 06:04:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.849
X-Spam-Level:
X-Spam-Status: No, score=-105.849 tagged_above=-999 required=5 tests=[AWL=0.399, BAYES_00=-2.599, HELO_EQ_FR=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 GHnW4LSvjh14 for <sip-overload@ietfc.amsl.com>; Tue, 19 Apr 2011 06:03:54 -0700 (PDT)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfc.amsl.com (Postfix) with ESMTP id CBBE3E065A for <sip-overload@ietf.org>; Tue, 19 Apr 2011 06:03:53 -0700 (PDT)
Received: from FRMRSSXCHHUB04.dc-m.alcatel-lucent.com (FRMRSSXCHHUB04.dc-m.alcatel-lucent.com [135.120.45.64]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id p3JD3D1Y002305 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Tue, 19 Apr 2011 15:03:41 +0200
Received: from FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com ([135.120.45.46]) by FRMRSSXCHHUB04.dc-m.alcatel-lucent.com ([135.120.45.64]) with mapi; Tue, 19 Apr 2011 15:03:04 +0200
From: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>
To: ken carlberg <carlberg@g11.org.uk>
Date: Tue, 19 Apr 2011 15:03:03 +0200
Thread-Topic: [sip-overload] draft-ietf-soc-overload-design-05
Thread-Index: Acv+jsF3s8sG4xGrQCGJsYydTr7qlwAAejlg
Message-ID: <EDC0A1AE77C57744B664A310A0B23AE21EC517B7@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com>
References: <9FEB75F0-712B-4CDE-949D-F3DE4D80BCD7@g11.org.uk> <OF0DF6A035.7421167A-ON85257876.00646380-85257876.0064CA28@csc.com> <EDC0A1AE77C57744B664A310A0B23AE21EC516BD@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <69BD7A69-FF32-4750-A73C-3B28D39FA5BF@g11.org.uk>
In-Reply-To: <69BD7A69-FF32-4750-A73C-3B28D39FA5BF@g11.org.uk>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_EDC0A1AE77C57744B664A310A0B23AE21EC517B7FRMRSSXCHMBSC3d_"
MIME-Version: 1.0
X-Scanned-By: MIMEDefang 2.64 on 155.132.188.83
Cc: "sip-overload@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: Tue, 19 Apr 2011 13:04:03 -0000

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:carlberg@g11.org.uk]
Sent: 19 April 2011 13:39
To: DRAGE, Keith (Keith)
Cc: Janet Gunn; sip-overload@ietf.org
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



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: sip-overload-bounces@ietf.org<mailto:sip-overload-bounces@ietf.org> [mailto:sip-overload-bounces@ietf.org] On Behalf Of Janet P Gunn
Sent: 18 April 2011 19:21
To: ken carlberg
Cc: sip-overload-bounces@ietf.org<mailto:sip-overload-bounces@ietf.org>; sip-overload@ietf.org<mailto:sip-overload@ietf.org>
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 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<mailto:carlberg@g11.org.uk>>

To:

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