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

Volker Hilt <volker.hilt@alcatel-lucent.com> Mon, 18 April 2011 17:22 UTC

Return-Path: <volker.hilt@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 31370E06E5 for <sip-overload@ietfc.amsl.com>; Mon, 18 Apr 2011 10:22:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 k-l8hjnbQvce for <sip-overload@ietfc.amsl.com>; Mon, 18 Apr 2011 10:22:03 -0700 (PDT)
Received: from ihemail4.lucent.com (ihemail4.lucent.com [135.245.0.39]) by ietfc.amsl.com (Postfix) with ESMTP id 44E89E06E4 for <sip-overload@ietf.org>; Mon, 18 Apr 2011 10:22:03 -0700 (PDT)
Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail4.lucent.com (8.13.8/IER-o) with ESMTP id p3IHM0BQ021077 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <sip-overload@ietf.org>; Mon, 18 Apr 2011 12:22:00 -0500 (CDT)
Received: from USNAVSXCHHUB01.ndc.alcatel-lucent.com (usnavsxchhub01.ndc.alcatel-lucent.com [135.3.39.110]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3IHM0iD013916 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <sip-overload@ietf.org>; Mon, 18 Apr 2011 12:22:00 -0500
Received: from [135.222.104.119] (135.3.63.242) by USNAVSXCHHUB01.ndc.alcatel-lucent.com (135.3.39.110) with Microsoft SMTP Server (TLS) id 8.3.106.1; Mon, 18 Apr 2011 12:22:00 -0500
Message-ID: <4DAC7356.9000009@alcatel-lucent.com>
Date: Mon, 18 Apr 2011 13:22:30 -0400
From: Volker Hilt <volker.hilt@alcatel-lucent.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2.15) Gecko/20110303 Thunderbird/3.1.9
MIME-Version: 1.0
To: <sip-overload@ietf.org>
References: <9FEB75F0-712B-4CDE-949D-F3DE4D80BCD7@g11.org.uk>
In-Reply-To: <9FEB75F0-712B-4CDE-949D-F3DE4D80BCD7@g11.org.uk>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.39
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.10
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 17:22:04 -0000

Ken,

comments inline.
> 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.

I've shortened the added text as follows:
> <insert text> The action taken is
> determined by the characteristics defined for the set of priority values
> of a Namespace as well as the local policies defined for the various
> Namespaces supported by the server.
>

I would suggest to move this text to the Gurbani draft as it defines the 
specific processing of RPH.
> 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.

I'm not sure how much this is related to the design considerations of an 
overload control mechanism and how much it is related to RPH. I'd 
suggest to keep this text out of the oc design document.
> 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>
>
Generally, at this point I'd like to keep the changes to the document to 
the absolute necessary. It has been discussed for a long time including 
issues related to RPH.

Thanks,

Volker

> 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.
>