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

Janet P Gunn <jgunn6@csc.com> Tue, 19 April 2011 12:23 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 4CDEDE06A5 for <sip-overload@ietfc.amsl.com>; Tue, 19 Apr 2011 05:23:48 -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 AKhx5Fg+NNGc for <sip-overload@ietfc.amsl.com>; Tue, 19 Apr 2011 05:23:46 -0700 (PDT)
Received: from mail164.messagelabs.com (mail164.messagelabs.com [216.82.253.131]) by ietfc.amsl.com (Postfix) with ESMTP id 58589E00BE for <sip-overload@ietf.org>; Tue, 19 Apr 2011 05:23:46 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: jgunn6@csc.com
X-Msg-Ref: server-4.tower-164.messagelabs.com!1303215821!42911826!1
X-StarScan-Version: 6.2.9; banners=-,-,-
X-Originating-IP: [20.137.2.87]
Received: (qmail 22305 invoked from network); 19 Apr 2011 12:23:42 -0000
Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-4.tower-164.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 19 Apr 2011 12:23:42 -0000
Received: from amer-gw09.amer.csc.com (amer-gw09.amer.csc.com [20.6.39.245]) by amer-mta101.csc.com (Switch-3.4.3/Switch-3.3.3mp) with ESMTP id p3JCNeDe002963 for <sip-overload@ietf.org>; Tue, 19 Apr 2011 08:23:41 -0400
In-Reply-To: <4DACE3ED.4030301@alcatel-lucent.com>
References: <9FEB75F0-712B-4CDE-949D-F3DE4D80BCD7@g11.org.uk> <4DAC7356.9000009@alcatel-lucent.com> <BF40E494-D739-40F0-A425-651FE433E730@g11.org.uk> <4DACE3ED.4030301@alcatel-lucent.com>
To: Volker Hilt <volker.hilt@alcatel-lucent.com>, keith.drage@alcatel-lucent.com
MIME-Version: 1.0
X-KeepSent: B194A97C:8E9F3522-85257877:00430B32; 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: <OFB194A97C.8E9F3522-ON85257877.00430B32-85257877.0044166A@csc.com>
Date: Tue, 19 Apr 2011 08:23:38 -0400
X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.2FP1 HF29|January 09, 2011) at 04/19/2011 08:22:32 AM, Serialize complete at 04/19/2011 08:22:32 AM
Content-Type: multipart/alternative; boundary="=_alternative 0044160085257877_="
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 12:23:48 -0000

Volker, 

I would just as soon stick with the original text. 

I think the new proposed text is misleading.

Both Queuing and Preemption are mechanisms that make sense when the 
"holding time" is several orders of magnitude more that the time to 
manipulate the queue, or organize the preemption.  This makes them useful 
mechanisms for dealing with SIP sessions. 

But when dealing with a SIP server, processing SIP messages, the "holding 
time" is likely to be the same order of magnitude as the time to 
manipulate the queue, or organize the preemption.  In this case 
introducing queue manipulation or preemption is counterproductive, and 
likely to lead to thrashing..

We have been through this discussion many times, going back to the 
development of  Req 13 in 5390, and I see no advantage in re-introducing 
it to this document.

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:
Volker Hilt <volker.hilt@alcatel-lucent.com>
To:
Janet P Gunn/USA/CSC@CSC
Cc:
"sip-overload@ietf.org" <sip-overload@ietf.org>
Date:
04/18/2011 09:23 PM
Subject:
Re: [sip-overload] draft-ietf-soc-overload-design-05



Janet, All,

are you comfortable with the changes for this draft as proposed below? 
The proposal is the add the following sentence at the end of the RPH 
discussion in Sec 12:

     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.

Thanks,

Volker



On 4/18/2011 1:27 PM, ken carlberg wrote:
> Volker,
>
> I leave it in your hands as to what to keep, remove, or simply move to 
another document.
>
> cheers,
>
> -ken
>
>
> On Apr 18, 2011, at 1:22 PM, Volker Hilt wrote:
>
>> 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.
>>>
>> _______________________________________________
>> sip-overload mailing list
>> sip-overload@ietf.org
>> https://www.ietf.org/mailman/listinfo/sip-overload
>