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

ken carlberg <carlberg@g11.org.uk> Tue, 19 April 2011 19:20 UTC

Return-Path: <carlberg@g11.org.uk>
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 9B701E07D2 for <sip-overload@ietfc.amsl.com>; Tue, 19 Apr 2011 12:20:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.689
X-Spam-Level:
X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[AWL=-0.091, BAYES_00=-2.599, HTML_MESSAGE=0.001]
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 mcjKvd+kDuqx for <sip-overload@ietfc.amsl.com>; Tue, 19 Apr 2011 12:20:41 -0700 (PDT)
Received: from portland.eukhosting.net (portland.eukhosting.net [92.48.97.5]) by ietfc.amsl.com (Postfix) with ESMTP id 51770E0675 for <sip-overload@ietf.org>; Tue, 19 Apr 2011 12:20:41 -0700 (PDT)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=g11.org.uk; h=Received:Subject:Mime-Version:Content-Type:From:In-Reply-To:Date:Cc:Message-Id:References:To:X-Mailer:X-Source:X-Source-Args:X-Source-Dir; b=WqugQbsw3E8Z6LffwujcvKeCkxSSNuDPzYBz8AxORKLGDD5r38a0PzmW1Ua/XUWyOV2ExcIkVOjV4aee5hLTtbITJTn0iE47zLLo3eqF8pXEgSf+nRKWM6/iUk5SW68h;
Received: from c-76-111-69-4.hsd1.va.comcast.net ([76.111.69.4]:49858 helo=[192.168.0.20]) by portland.eukhosting.net with esmtpa (Exim 4.69) (envelope-from <carlberg@g11.org.uk>) id 1QCGTL-0003kw-IC; Tue, 19 Apr 2011 19:20:28 +0000
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: multipart/alternative; boundary=Apple-Mail-78-663604564
From: ken carlberg <carlberg@g11.org.uk>
In-Reply-To: <OF90D7BCEF.193A9527-ON85257877.0054915A-85257877.0054A334@csc.com>
Date: Tue, 19 Apr 2011 15:20:35 -0400
Message-Id: <16AE0F76-193C-45B1-AC98-D9624EC8B0B6@g11.org.uk>
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> <4DADA3E8.6080409@bell-labs.com> <OF90D7BCEF.193A9527-ON85257877.0054915A-85257877.0054A334@csc.com>
To: Janet P Gunn <jgunn6@csc.com>
X-Mailer: Apple Mail (2.1082)
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - portland.eukhosting.net
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - g11.org.uk
X-Source:
X-Source-Args:
X-Source-Dir:
Cc: 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 19:20:42 -0000

Vijay,

from my perspective, what you have concerning draft-ietf-sip-overload-control is a reasonably good start.  

However, given that this thread has required quite a lot of additional points being raised with a fair amount of detail (whether one agrees with a particular position or not), then what you have would seem to be insufficient in terms of an explanation of related issues and possible suggested path(s) forward.

cheers,

-ken


On Apr 19, 2011, at 11:24 AM, Janet P Gunn wrote:

> 
> Vijay, 
> 
> What is there now is fine with me. I see no need for change. 
> 
> Janet 
> 
> sip-overload-bounces@ietf.org wrote on 04/19/2011 11:02:00 AM:
> 
> > [image removed] 
> > 
> > Re: [sip-overload] draft-ietf-soc-overload-design-05 
> > 
> > Vijay K. Gurbani 
> > 
> > to: 
> > 
> > sip-overload 
> > 
> > 04/19/2011 11:00 AM 
> > 
> > Sent by: 
> > 
> > sip-overload-bounces@ietf.org 
> > 
> > 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/
> > _______________________________________________
> > sip-overload mailing list
> > sip-overload@ietf.org
> > https://www.ietf.org/mailman/listinfo/sip-overload
> _______________________________________________
> sip-overload mailing list
> sip-overload@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-overload