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

ken carlberg <carlberg@g11.org.uk> Mon, 07 March 2011 13:52 UTC

Return-Path: <carlberg@g11.org.uk>
X-Original-To: sip-overload@core3.amsl.com
Delivered-To: sip-overload@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 9C3613A6962 for <sip-overload@core3.amsl.com>; Mon, 7 Mar 2011 05:52:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.399
X-Spam-Level:
X-Spam-Status: No, score=-2.399 tagged_above=-999 required=5 tests=[AWL=0.200, BAYES_00=-2.599]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GEeaWEz-lMZE for <sip-overload@core3.amsl.com>; Mon, 7 Mar 2011 05:51:59 -0800 (PST)
Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by core3.amsl.com (Postfix) with ESMTP id 696FD3A6967 for <sip-overload@ietf.org>; Mon, 7 Mar 2011 05:51:59 -0800 (PST)
Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:56709 helo=[192.168.0.20]) by portland.eukhosting.net with esmtpa (Exim 4.69) (envelope-from <carlberg@g11.org.uk>) id 1Pwarv-0003u6-1t; Mon, 07 Mar 2011 13:53:03 +0000
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Apple Message framework v1082)
From: ken carlberg <carlberg@g11.org.uk>
Date: Mon, 07 Mar 2011 08:53:09 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <CB26CA77-27DC-4F88-87F9-0066C0BFE619@g11.org.uk>
To: sip-overload@ietf.org
X-Mailer: Apple Mail (2.1082)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - portland.eukhosting.net
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - g11.org.uk
X-Source:
X-Source-Args:
X-Source-Dir:
Subject: [sip-overload] draft-ietf-soc-overload-design-04
X-BeenThere: sip-overload@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: SIP Overload <sip-overload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/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, 07 Mar 2011 13:52:00 -0000

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