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

"Vijay K. Gurbani" <vkg@bell-labs.com> Tue, 19 April 2011 14:59 UTC

Return-Path: <vkg@bell-labs.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 49F13E0691 for <sip-overload@ietfc.amsl.com>; Tue, 19 Apr 2011 07:59:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.676
X-Spam-Level:
X-Spam-Status: No, score=-105.676 tagged_above=-999 required=5 tests=[AWL=0.923, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
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 1KWE7KK9B82H for <sip-overload@ietfc.amsl.com>; Tue, 19 Apr 2011 07:59:55 -0700 (PDT)
Received: from ihemail2.lucent.com (ihemail2.lucent.com [135.245.0.35]) by ietfc.amsl.com (Postfix) with ESMTP id 79323E0664 for <sip-overload@ietf.org>; Tue, 19 Apr 2011 07:59:55 -0700 (PDT)
Received: from usnavsmail2.ndc.alcatel-lucent.com (usnavsmail2.ndc.alcatel-lucent.com [135.3.39.10]) by ihemail2.lucent.com (8.13.8/IER-o) with ESMTP id p3JExsK5004643 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <sip-overload@ietf.org>; Tue, 19 Apr 2011 09:59:55 -0500 (CDT)
Received: from umail.lucent.com (umail-ce2.ndc.lucent.com [135.3.40.63]) by usnavsmail2.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id p3JExs9i017563 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <sip-overload@ietf.org>; Tue, 19 Apr 2011 09:59:54 -0500
Received: from shoonya.ih.lucent.com (shoonya.ih.lucent.com [135.185.238.233]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p3JExsiP008128 for <sip-overload@ietf.org>; Tue, 19 Apr 2011 09:59:54 -0500 (CDT)
Message-ID: <4DADA3E8.6080409@bell-labs.com>
Date: Tue, 19 Apr 2011 10:02:00 -0500
From: "Vijay K. Gurbani" <vkg@bell-labs.com>
Organization: Bell Laboratories, Alcatel-Lucent
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.15) Gecko/20110307 Fedora/3.1.9-0.39.b3pre.fc14 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: 7bit
X-Scanned-By: MIMEDefang 2.57 on 135.245.2.35
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: Tue, 19 Apr 2011 14:59:56 -0000

On 04/19/2011 09:30 AM, ken carlberg wrote:
> 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.
[...]

As the editor of draft-ietf-sip-overload-control, I have read this
thread with interest.

So, the question now is: what, if any, from this thread carries over
into the draft-ietf-sip-overload-control draft?  I am certainly not
up to verse with RPH as some of the members of this working group
are, so I will depend on them to point out any text that should be
modified in draft-ietf-sip-overload-control.

For the sake of completeness, here is what
draft-ietf-sip-overload-control has to say about prioritizing
requests containing the RPH header:

    A SIP client SHOULD honor the local policy for prioritizing SIP
    requests such as policies 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.  Other indicators, such as the SOS URN
    [RFC5031] indicating an emergency request, may also be used for
    prioritization.

Do we deem this to be enough?

Thanks,

- vijay
-- 
Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60566 (USA)
Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com
Web:   http://ect.bell-labs.com/who/vkg/