Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt

Volker Hilt <volker.hilt@bell-labs.com> Fri, 11 January 2013 14:07 UTC

Return-Path: <volker.hilt@bell-labs.com>
X-Original-To: sip-overload@ietfa.amsl.com
Delivered-To: sip-overload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2B6BF21F8581 for <sip-overload@ietfa.amsl.com>; Fri, 11 Jan 2013 06:07:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -9.749
X-Spam-Level:
X-Spam-Status: No, score=-9.749 tagged_above=-999 required=5 tests=[AWL=0.500, BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_HI=-8]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z3hGFz1fewvg for <sip-overload@ietfa.amsl.com>; Fri, 11 Jan 2013 06:07:21 -0800 (PST)
Received: from smail3.alcatel.fr (smail3.alcatel.fr [64.208.49.56]) by ietfa.amsl.com (Postfix) with ESMTP id 8D9D021F8570 for <sip-overload@ietf.org>; Fri, 11 Jan 2013 06:07:20 -0800 (PST)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail3.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id r0BE6lV5024816 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for <sip-overload@ietf.org>; Fri, 11 Jan 2013 15:07:18 +0100
Received: from US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 11 Jan 2013 15:07:03 +0100
Received: from [149.204.61.163] (135.5.27.17) by US70TWXCHHUB03.zam.alcatel-lucent.com (135.5.2.35) with Microsoft SMTP Server (TLS) id 14.2.247.3; Fri, 11 Jan 2013 09:07:00 -0500
Message-ID: <50F01C82.9010406@bell-labs.com>
Date: Fri, 11 Jan 2013 15:06:58 +0100
From: Volker Hilt <volker.hilt@bell-labs.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: <sip-overload@ietf.org>
References: <20121022163217.13864.84970.idtracker@ietfa.amsl.com> <CAPSQ9ZU_52XDJGm0AFs6fe0ZkMSiQCwp7kSoQ5nDvxjnJh5McA@mail.gmail.com> <5EBD159DE88147488A3B1590E090018403530A9E6275@njfpsrvexg2.research.att.com> <OF7CCDE698.10939705-ON85257AD4.0072A173-85257AD4.007308A2@csc.com> <CAPSQ9ZVx7K_2_ApjG_sP2uopRLocaasgpJQNUNeh6NmSVAGiyw@mail.gmail.com> <24674_1355758104_50CF3A18_24674_468_1_88CAD1D4E8773F42858B58CAA28272A00E2A2C@PEXCVZYM12.corporate.adroot.infra.ftgroup> <CAPSQ9ZU-9fZRGksgut-UiRmbVfTi9WR9Orn6cockYqgjVjRF7Q@mail.gmail.com> <OF0E1F39E5.19A27B85-ON85257AE5.005E7CF8-85257AE5.005EF464@csc.com> <EDC0A1AE77C57744B664A310A0B23AE20D7456E216@FRMRSSXCHMBSC3.dc-m.alcatel-lucent.com> <CAPSQ9ZV10ShtsZwzA10RfBmjyzmLy7TpxomJW+GfPr08qh5z2g@mail.gmail.com> <50E5B529.2090105@bell-labs.com> <OF0589660E.64BDF257-ON85257AE8.006149FC-85257AE8.0062277C@csc.com>
In-Reply-To: <OF0589660E.64BDF257-ON85257AE8.006149FC-85257AE8.0062277C@csc.com>
Content-Type: text/plain; charset="ISO-8859-1"; format=flowed
Content-Transfer-Encoding: 7bit
X-Originating-IP: [135.5.27.17]
X-Scanned-By: MIMEDefang 2.69 on 155.132.188.83
Subject: Re: [sip-overload] Local Policy Re: I-D Action: draft-ietf-soc-load-control-event-package-05.txt
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: Fri, 11 Jan 2013 14:07:22 -0000

Janet, All,

while this sounds good in most cases, the concern I have is that there 
may be situation where a proxy is forced to violate local policy. E.g., 
a policy "emergency calls can never be dropped" will have to be violated 
eventually if overload reaches levels where only emergency calls are left.

Maybe this boils down to formulating policies in a reasonable way. It 
has to be made clear, however, that not all policies call be kept under 
all circumstances.

A SHOULD would imply this to the developer. With a MUST, I think one 
would have to add explanatory text.

Thanks,

Volker [with individual contributor hat on]



On 03.01.2013 18:52, Janet P Gunn wrote:
> I prefer MUST to SHOULD.
>
> The original wording was based on Req 13 of RFC 5390:
> " REQ 13:  The mechanism must not dictate a specific algorithm for
>        prioritizing the processing of work within a proxy during times of
>        overload*.  It must permit a proxy to prioritize requests based on*
> *      any local policy*, so that certain ones (such as a call for
>        emergency services or a call with a specific value of the
>        Resource-Priority header field [RFC4412]) are given preferential
>        treatment, such as not being dropped, being given additional
>        retransmission, or being processed ahead of others."
>
> which has a lower case "must".
>
> If we are going to say "MUST honor" (rather than "must permit"), I think
> we need to change "any" to "the" . (you can permit many alternatives,
> but you can really only honor one).  I think this also reflects the
> intent of Martin's  comment
>
> So I would prefer
>
>
>    A SIP client MUST honor *the *local policy for prioritizing SIP
>    requests such as policies based on message type, e.g., INVITEs vs.
>    requests associated with existing sessions.
>
>    A SIP client MUST honor *the *local policy for prioritizing SIP
>    requests based on the content of the Resource-Priority header (RPH,
>    RFC4412 [RFC4412]).  Specific (namespace.value) RPH contents may
>    indicate high priority requests that should be preserved as much as
>    possible during overload.  The RPH contents can also indicate a
>    low-priority request that is eligible to be dropped during times of
>    overload.
>
>    A SIP client MUST honor *the *local policy for prioritizing SIP
>    requests relating to emergency calls, as identified by the SOS
>    URN [RFC5031] indicating an emergency request.
>
>
> Thanks
>
> 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: "Vijay K. Gurbani" <vkg@bell-labs.com>
> To: Charles Shen <charles@cs.columbia.edu>
> Cc: "DRAGE, Keith (Keith)" <keith.drage@alcatel-lucent.com>om>, Janet P
> Gunn/USA/CSC@CSC, "sip-overload@ietf.org" <sip-overload@ietf.org>rg>, Arata
> Koike <koike.arata@lab.ntt.co.jp>jp>, "NOEL, ERIC (ERIC C)"
> <ecnoel@att.com>om>, Henning Schulzrinne <hgs@cs.columbia.edu>
> Date: 01/03/2013 11:42 AM
> Subject: Re: [sip-overload] Local Policy Re: I-D Action:
> draft-ietf-soc-load-control-event-package-05.txt
> ------------------------------------------------------------------------
>
>
>
> On 01/03/2013 07:34 AM, Charles Shen wrote:
>  > Sounds good, I can update the wording in the event package draft, if
>  > Vijay is OK with the other one.
>
> I just want to make sure we are all agreeing to the same thing.
>
> It seems to me that the question of using SHOULD versus MUST is being
> decided slightly in favour of a MUST.  Martin and Bruno prefer a MUST,
> Janet is okay with, although her original text used a SHOULD; and Keith
> could go either way.
>
> Is the consensus, then, that the text on honoring local policy contains
> MUST?  If so, the text to be inserted would be the following:
>
>    A SIP client MUST honor any local policy for prioritizing SIP
>    requests such as policies based on message type, e.g., INVITEs vs.
>    requests associated with existing sessions.
>
>    A SIP client MUST honor any local policy for prioritizing SIP
>    requests based on the content of the Resource-Priority header (RPH,
>    RFC4412 [RFC4412]).  Specific (namespace.value) RPH contents may
>    indicate high priority requests that should be preserved as much as
>    possible during overload.  The RPH contents can also indicate a
>    low-priority request that is eligible to be dropped during times of
>    overload.
>
>    A SIP client MUST honor any local policy for prioritizing SIP
>    requests relating to emergency calls, as identified by the SOS
>    URN [RFC5031] indicating an emergency request.
>
> Yes?
>
> Thanks,
>
> - vijay
> --
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA)
> Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com
> Web: http://ect.bell-labs.com/who/vkg/
>
>
>
> _______________________________________________
> sip-overload mailing list
> sip-overload@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-overload
>