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

Volker Hilt <volker.hilt@alcatel-lucent.com> Wed, 20 April 2011 01:09 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 154B8E076F for <sip-overload@ietfc.amsl.com>; Tue, 19 Apr 2011 18:09:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level:
X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[AWL=0.400, BAYES_00=-2.599, GB_I_INVITATION=-2, J_CHICKENPOX_25=0.6, J_CHICKENPOX_43=0.6, 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 OjY7y8rY8-sK for <sip-overload@ietfc.amsl.com>; Tue, 19 Apr 2011 18:09:51 -0700 (PDT)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfc.amsl.com (Postfix) with ESMTP id 17619E072C for <sip-overload@ietf.org>; Tue, 19 Apr 2011 18:09:51 -0700 (PDT)
Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p3K19odM017159 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <sip-overload@ietf.org>; Tue, 19 Apr 2011 20:09:50 -0500 (CDT)
Received: from USNAVSXCHHUB02.ndc.alcatel-lucent.com (usnavsxchhub02.ndc.alcatel-lucent.com [135.3.39.111]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3K19oYd016643 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <sip-overload@ietf.org>; Tue, 19 Apr 2011 20:09:50 -0500
Received: from [135.244.35.16] (135.3.63.241) by USNAVSXCHHUB02.ndc.alcatel-lucent.com (135.3.39.111) with Microsoft SMTP Server (TLS) id 8.3.106.1; Tue, 19 Apr 2011 20:09:50 -0500
Message-ID: <4DAE325C.2090308@alcatel-lucent.com>
Date: Tue, 19 Apr 2011 21:09:48 -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> <OF0DF6A035.7421167A-ON85257876.00646380-85257876.0064CA28@csc.com> <EDC0A1AE77C57744B664A310A0B23AE21EC516BD@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <69BD7A69-FF32-4750-A73C-3B28D39FA5BF@g11.org.uk> <EDC0A1AE77C57744B664A310A0B23AE21EC517B7@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <578BF6E7-89CD-4300-AED2-EED8BF6F2547@g11.org.uk> <EDC0A1AE77C57744B664A310A0B23AE21EC517EC@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <847C3FA5-B73C-4BB9-B5BD-253C6DC994A5@g11.org.uk>
In-Reply-To: <847C3FA5-B73C-4BB9-B5BD-253C6DC994A5@g11.org.uk>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9
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: Wed, 20 Apr 2011 01:09:53 -0000

Based on the discussion in this thread, I will keep the original text of 
the design draft (i.e., leave the message prioritization section unchanged).

Thanks,

Volker



On 4/19/2011 10:30 AM, ken carlberg wrote:
>
> On Apr 19, 2011, at 9:43 AM, DRAGE, Keith (Keith) wrote:
>
>> With regard to your comment on 1), I believe nothing extra is
>> required. Anyone setting up multiple namespaces has to define at each
>> entity that is required to understand them how they are treated in
>> relationship to each other. That is part of the implementation. That
>> will define which namespaces exist, and which are used at the
>> receiving entity to give any form of priority handling. There is no
>> reason for SIP overload to alter that relationship in any way, shape,
>> or form.
>
> this is somewhat scenario dependent. but I don't think we are gaining
> any traction, so I'll stop here.
>
>> On 2), I do not believe your comment is correct. The fact that a
>> namespace is a pre-emption namespace is not an invitation to pre-empt
>> all other calls until you get your call through, even under situations
>> of no overload. It merely states that calls can be pre-empted when
>> this namespace is used. The same applies for priority. Usually the
>> algorithm for handling these DOES NOT SAY – handle all calls with this
>> namespace until there are none left, and then move onto others. It
>> deals with things like percentage of traffic and so on. So what I am
>> saying is that the RPH is not a guarantee to override all other
>> traffic, whether overload exists or not.
>
> the preemption-capable systems I've worked on in the past *must* preempt
> or tear down state when there are no available resources -- either
> established calls (or flows) or call/session establishment. I guess
> there are various scenarios and variations of implementations that one
> can consider, but I think that continues down an endless series of
> possibilities that never lead to a definitive answer.
>
> I think the subject has been beaten to a pulp. And to a large degree, we
> have gone much further into topics than perhaps was necessary. The
> purpose of the suggested new next was to broaden the picture and bring
> up topics that are attributed to the RPH. The only position that was
> taken in the text was to suggest in the form of a "should" the use of
> the first RPH (which I meant to be the first "recognized/supported"
> RPH). But I conceded that i was fine to remove that position.
>
> I'll stop here and leave it to the co-authors/co-chairs to decide how to
> proceed.
>
> -ken
>
>
>
>> Regards
>> Keith
>> ------------------------------------------------------------------------
>> *From:*ken carlberg [mailto:carlberg@g11.org.uk]
>> *Sent:*19 April 2011 14:23
>> *To:*DRAGE, Keith (Keith)
>> *Cc:*Janet Gunn;sip-overload@ietf.org <mailto:sip-overload@ietf.org>
>> *Subject:*Re: [sip-overload] draft-ietf-soc-overload-design-05
>> On Apr 19, 2011, at 9:03 AM, DRAGE, Keith (Keith) wrote:
>>
>>
>> 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).
>> or it may be the first, or the last. I'll concede the difficulty in
>> stating the first "recognized/supported" RPH is the one to be used.
>> But I think one is deferring the problem that arises with no position
>> taken at all. The primary point that I wanted to make was that the
>> possibility of multiple RPHs may exist. I'm fine with removing the
>> text of choosing a default RPH in that instance.
>>
>>
>> 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.
>> again, the intent of the suggested added text was to point out to the
>> reader that preemption and queuing are *examples* of what has been
>> defined so far with respect to Namespaces. What you have stated above
>> makes a case that another Namespace should be defined, otherwise, you
>> one is overloading new characteristics from what has already been
>> defined.
>> -ken
>>
>>
>> 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 <mailto: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 ofdraft-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
>>
>>
>>
>