From salvatore.loreto@ericsson.com Mon Jan 10 07:16:14 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id E26FB3A69C4 for ; Mon, 10 Jan 2011 07:16:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.551 X-Spam-Level: X-Spam-Status: No, score=-106.551 tagged_above=-999 required=5 tests=[AWL=0.048, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zme+56pHWNDu for ; Mon, 10 Jan 2011 07:16:14 -0800 (PST) Received: from mailgw9.se.ericsson.net (mailgw9.se.ericsson.net [193.180.251.57]) by core3.amsl.com (Postfix) with ESMTP id D5A373A6975 for ; Mon, 10 Jan 2011 07:16:13 -0800 (PST) X-AuditID: c1b4fb39-b7cfbae000005c8e-33-4d2b2342f175 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw9.se.ericsson.net (Symantec Mail Security) with SMTP id D0.84.23694.2432B2D4; Mon, 10 Jan 2011 16:18:27 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.2.234.1; Mon, 10 Jan 2011 16:18:26 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 7B313255D for ; Mon, 10 Jan 2011 17:18:26 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 4456F50343 for ; Mon, 10 Jan 2011 17:18:26 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id C8D3D50320 for ; Mon, 10 Jan 2011 17:18:25 +0200 (EET) Message-ID: <4D2B2341.7090602@ericsson.com> Date: Mon, 10 Jan 2011 16:18:25 +0100 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: sip-overload@ietf.org References: <4D08E3E4.2050002@ericsson.com> In-Reply-To: <4D08E3E4.2050002@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: Re: [sip-overload] Call for Consensus: draft-shen-soc-load-control-event-package as wg item X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 15:16:15 -0000 Hi there, so far we have received just two replies to this call, both in favor to adopt it. To take in consideration the fact that the call was almost in coincidence with the Christmas vacations, we have decided to extend it until this Friday, January 14th. cheers /Sal On 12/15/10 4:51 PM, Salvatore Loreto wrote: > Hi folks, > > during the last Interim (Interim II) on December 1st, > Charles Shen presented the draft-shen-soc-load-control-event-package > and asked about the possibility to adopt it as wg item, > due to the comments received during the presentation we decided to wait > for a new version before to check in the mailing list the consensus to > adopt it. > > Charles has posted a new version of the draft > ( http://www.ietf.org/id/draft-shen-soc-load-control-event-package-02.txt ) > addressing the comments from the Interim > (see in the Interim minutes: > http://trac.tools.ietf.org/wg/soc/trac/attachment/wiki/Interim20101201/notes.txt > ) > and also other previous comments received in the mailing list. > > It is time to check in the ml the consensus to adopt the > draft-shen-soc-load-control-event-package as wg item. > > So, as chairs Volker and I want to check the consensus to adopt it as > baseline for the wg item > addressing the derivable number 3 in the charter: > > Aug 2011 - Specification for a SIP load filtering mechaism to IESG for publication as Proposed Standard > > > This consensus call will end on Friday January 7th, 2010. > > cheers > /Sal From jgunn6@csc.com Mon Jan 10 08:41:46 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id D8AED3A67FA; Mon, 10 Jan 2011 08:41:46 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cn49Dsp9XvUR; Mon, 10 Jan 2011 08:41:45 -0800 (PST) Received: from mail170.messagelabs.com (mail170.messagelabs.com [216.82.253.227]) by core3.amsl.com (Postfix) with ESMTP id 9ACEC3A680D; Mon, 10 Jan 2011 08:41:45 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-7.tower-170.messagelabs.com!1294677836!36085373!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [20.137.2.87] Received: (qmail 31473 invoked from network); 10 Jan 2011 16:43:58 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-7.tower-170.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 10 Jan 2011 16:43:58 -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 p0AGhtPC028713; Mon, 10 Jan 2011 11:43:55 -0500 In-Reply-To: <4D2B2341.7090602@ericsson.com> References: <4D08E3E4.2050002@ericsson.com> <4D2B2341.7090602@ericsson.com> To: Salvatore Loreto MIME-Version: 1.0 X-KeepSent: 7CD235B6:6E7D2FDC-85257814:005BAC5F; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP1 CCH2 April 23, 2009 From: Janet P Gunn Message-ID: Date: Mon, 10 Jan 2011 11:43:53 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.1FP1 HF440|June 18, 2010) at 01/10/2011 11:43:24 AM, Serialize complete at 01/10/2011 11:43:24 AM Content-Type: multipart/alternative; boundary="=_alternative 005BE93585257814_=" Cc: sip-overload-bounces@ietf.org, sip-overload@ietf.org Subject: Re: [sip-overload] Call for Consensus: draft-shen-soc-load-control-event-package as wg item X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 16:41:46 -0000 This is a multipart message in MIME format. --=_alternative 005BE93585257814_= Content-Type: text/plain; charset="US-ASCII" Yes, I am in favor of adopting this as a working group item. I do not necessarily agree with all the text in section 9- but it is there which was my main concern. We can work on refining those details later Janet sip-overload-bounces@ietf.org wrote on 01/10/2011 10:18:25 AM: > Re: [sip-overload] Call for Consensus: draft-shen-soc-load-control- > event-package as wg item > Salvatore Loreto > to: sip-overload > 01/10/2011 10:19 AM > Sent by: sip-overload-bounces@ietf.org > > Hi there, > > so far we have received just two replies to this call, > both in favor to adopt it. > > To take in consideration the fact that the call was almost in coincidence > with the Christmas vacations, > > we have decided to extend it until this Friday, January 14th. > > > cheers > /Sal > > > On 12/15/10 4:51 PM, Salvatore Loreto wrote: > > Hi folks, > > > > during the last Interim (Interim II) on December 1st, > > Charles Shen presented the draft-shen-soc-load-control-event-package > > and asked about the possibility to adopt it as wg item, > > due to the comments received during the presentation we decided to wait > > for a new version before to check in the mailing list the consensus to > > adopt it. > > > > Charles has posted a new version of the draft > > ( http://www.ietf.org/id/draft-shen-soc-load-control-event-package-02.txt ) > > addressing the comments from the Interim > > (see in the Interim minutes: > > http://trac.tools.ietf.org/wg/soc/trac/attachment/wiki/ > Interim20101201/notes.txt > > ) > > and also other previous comments received in the mailing list. > > > > It is time to check in the ml the consensus to adopt the > > draft-shen-soc-load-control-event-package as wg item. > > > > So, as chairs Volker and I want to check the consensus to adopt it as > > baseline for the wg item > > addressing the derivable number 3 in the charter: > > > > Aug 2011 - Specification for a SIP load filtering mechaism to > IESG for publication as Proposed Standard > > > > > > This consensus call will end on Friday January 7th, 2010. > > > > cheers > > /Sal > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload --=_alternative 005BE93585257814_= Content-Type: text/html; charset="US-ASCII"
Yes, I am in favor of adopting this as a working group item.  I do not necessarily agree with all the text in section 9- but it is there which was my main concern.  We can work on refining those details later

Janet
sip-overload-bounces@ietf.org wrote on 01/10/2011 10:18:25 AM:

> Re: [sip-overload] Call for Consensus: draft-shen-soc-load-control-
> event-package as wg item
> Salvatore Loreto
> to: sip-overload
> 01/10/2011 10:19 AM
> Sent by: sip-overload-bounces@ietf.org
>
> Hi there,
>
> so far we have received just two replies to this call,
> both in favor to adopt it.
>
> To take in consideration the fact that the call was almost in coincidence
> with the Christmas vacations,
>
> we have decided to extend it until this Friday, January 14th.
>
>
> cheers
> /Sal
>
>
> On 12/15/10 4:51 PM, Salvatore Loreto wrote:
> > Hi folks,
> >
> > during the last Interim (Interim II) on December 1st,
> > Charles Shen presented the draft-shen-soc-load-control-event-package
> > and asked about the possibility to adopt it as wg item,
> > due to the comments received during the presentation we decided to wait
> > for a new version before to check in the mailing list the consensus to
> > adopt it.
> >
> > Charles has posted a new version of the draft
> > ( http://www.ietf.org/id/draft-shen-soc-load-control-event-package-02.txt )
> > addressing the comments from the Interim
> > (see in the Interim minutes:
> > http://trac.tools.ietf.org/wg/soc/trac/attachment/wiki/
> Interim20101201/notes.txt
> > )
> > and also other previous comments received in the mailing list.
> >
> > It is time to check in the ml the consensus to adopt the
> > draft-shen-soc-load-control-event-package as wg item.
> >
> > So, as chairs Volker and I want to check the consensus to adopt it as
> > baseline for the wg item
> > addressing the derivable number 3 in the charter:
> >
> >     Aug 2011 - Specification for a SIP load filtering mechaism to
> IESG for publication as Proposed Standard
> >
> >
> > This consensus call will end on Friday January 7th, 2010.
> >
> > cheers
> > /Sal
> _______________________________________________
> sip-overload mailing list
> sip-overload@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-overload
 --=_alternative 005BE93585257814_=-- From vkg@bell-labs.com Mon Jan 10 11:07:00 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 3769A3A6B0E for ; Mon, 10 Jan 2011 11:07:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.387 X-Spam-Level: X-Spam-Status: No, score=-106.387 tagged_above=-999 required=5 tests=[AWL=0.212, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5U0VUUCv8YF for ; Mon, 10 Jan 2011 11:06:59 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id B52C63A69C5 for ; Mon, 10 Jan 2011 11:06:58 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p0AJ8et3010330 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 10 Jan 2011 13:08:40 -0600 (CST) Received: from shoonya.ih.lucent.com (Knoppix-135185238233.ih.lucent.com [135.185.238.233]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p0AJ8dSx026360; Mon, 10 Jan 2011 13:08:39 -0600 (CST) Message-ID: <4D2B59C5.6040400@bell-labs.com> Date: Mon, 10 Jan 2011 13:11:01 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: Salvatore Loreto , Charles Shen References: <4D08E3E4.2050002@ericsson.com> <4D2B2341.7090602@ericsson.com> In-Reply-To: <4D2B2341.7090602@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Cc: sip-overload@ietf.org Subject: Re: [sip-overload] Call for Consensus: draft-shen-soc-load-control-event-package as wg item X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 19:07:00 -0000 On 01/10/2011 09:18 AM, Salvatore Loreto wrote: > Hi there, > > so far we have received just two replies to this call, > both in favor to adopt it. > > To take in consideration the fact that the call was almost in coincidence > with the Christmas vacations, > > we have decided to extend it until this Friday, January 14th. Sal, Charles: I support the adoption of this work as a WG item for "A specification for a SIP load filtering mechanism." I do have one observation, the importance of which did not quite strike me until I read the draft: it appears that the filtering mechanism will also impact a core proxy. Thus, the core proxy must be prepared to handle the explicit overload control mechanism as well as the filtering mechanism. Is it the intent to mandate the support of both algorithms? Are we going to put tacit support for one algorithm in the other? In other words, consider CPa1 and CPb1 in Figure 1 of the draft. Can CPb1 ask CPa1 to perform overload control based on [1] and later upload a filter criteria based on [2]? I suspect from S8.2 of [2] that the answer is yes ... however, right now, [1] is silent on [2]. [1] http://tools.ietf.org/html/draft-ietf-soc-overload-control-00 [2] http://tools.ietf.org/html/draft-shen-soc-load-control-event-package-02 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/ From charles.newyork@gmail.com Mon Jan 10 12:21:38 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A7F5C28C0E5; Mon, 10 Jan 2011 12:21:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gR8NQghIkFmo; Mon, 10 Jan 2011 12:21:37 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id 4EE1228C125; Mon, 10 Jan 2011 12:21:37 -0800 (PST) Received: by eyd10 with SMTP id 10so8718636eyd.31 for ; Mon, 10 Jan 2011 12:23:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=35cZJTIQ0BH7pnSZEa12YwCeXOxdES3icEY09Yidxi0=; b=JJN0eh5yX+OkD9dROntGSJLFdCKtXkAeIZccKqPCl5sKOkBuQ7row0kNjRK7CwDgGg RQSJOFFuNuOkNbNTBx74HrFm3lbjAEGH32bZtWXyF8WmIlovqe9ipwn9+o3h5brJ10Oi Xc4E6Kphvhr39f60/BQ2DZxw1RhRdoVKbTU4E= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=nKG8VVelFpAZzvWufC0j20o4NbOgHnSrHx8U1R2KfIG1jXZpWgWAN1G+2PD8nj7w91 k+wf/TibCGzQei8qVzqtfR5Gw418dhPdNAA+Oy17XEHKNLpcb63Vct+iD1CqGqpyQ3vP 8H0xEXDX1ZHirzUqajUwmS6vzPUG4acWnngXs= MIME-Version: 1.0 Received: by 10.213.112.131 with SMTP id w3mr5087380ebp.42.1294691031071; Mon, 10 Jan 2011 12:23:51 -0800 (PST) Sender: charles.newyork@gmail.com Received: by 10.213.33.205 with HTTP; Mon, 10 Jan 2011 12:23:50 -0800 (PST) In-Reply-To: References: <4D08E3E4.2050002@ericsson.com> <4D2B2341.7090602@ericsson.com> Date: Mon, 10 Jan 2011 15:23:50 -0500 X-Google-Sender-Auth: QU4FOZ4ZaCmxUWmSRaHQG0MXQKc Message-ID: From: Charles Shen To: Janet P Gunn Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: sip-overload-bounces@ietf.org, sip-overload@ietf.org Subject: Re: [sip-overload] Call for Consensus: draft-shen-soc-load-control-event-package as wg item X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 20:21:38 -0000 Thanks Janet. Will be happy to work together on more details of your concer= n. Charles On Mon, Jan 10, 2011 at 11:43 AM, Janet P Gunn wrote: > > Yes, I am in favor of adopting this as a working group item. =C2=A0I do n= ot > necessarily agree with all the text in section 9- but it is there which w= as > my main concern. =C2=A0We can work on refining those details later > > Janet > > sip-overload-bounces@ietf.org wrote on 01/10/2011 10:18:25 AM: > >> Re: [sip-overload] Call for Consensus: draft-shen-soc-load-control- >> event-package as wg item >> Salvatore Loreto >> to: sip-overload >> 01/10/2011 10:19 AM >> Sent by: sip-overload-bounces@ietf.org >> >> Hi there, >> >> so far we have received just two replies to this call, >> both in favor to adopt it. >> >> To take in consideration the fact that the call was almost in coincidenc= e >> with the Christmas vacations, >> >> we have decided to extend it until this Friday, January 14th. >> >> >> cheers >> /Sal >> >> >> On 12/15/10 4:51 PM, Salvatore Loreto wrote: >> > Hi folks, >> > >> > during the last Interim (Interim II) on December 1st, >> > Charles Shen presented the draft-shen-soc-load-control-event-package >> > and asked about the possibility to adopt it as wg item, >> > due to the comments received during the presentation we decided to wai= t >> > for a new version before to check in the mailing list the consensus to >> > adopt it. >> > >> > Charles has posted a new version of the draft >> > ( >> > http://www.ietf.org/id/draft-shen-soc-load-control-event-package-02.tx= t ) >> > addressing the comments from the Interim >> > (see in the Interim minutes: >> > http://trac.tools.ietf.org/wg/soc/trac/attachment/wiki/ >> Interim20101201/notes.txt >> > ) >> > and also other previous comments received in the mailing list. >> > >> > It is time to check in the ml the consensus to adopt the >> > draft-shen-soc-load-control-event-package as wg item. >> > >> > So, as chairs Volker and I want to check the consensus to adopt it as >> > baseline for the wg item >> > addressing the derivable number 3 in the charter: >> > >> > =C2=A0 =C2=A0 Aug 2011 - Specification for a SIP load filtering mechai= sm to >> IESG for publication as Proposed Standard >> > >> > >> > This consensus call will end on Friday January 7th, 2010. >> > >> > cheers >> > /Sal >> _______________________________________________ >> 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 > > From charles.newyork@gmail.com Mon Jan 10 12:27:09 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A5C2128C12F for ; Mon, 10 Jan 2011 12:27:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z4wBohSAmf1k for ; Mon, 10 Jan 2011 12:27:07 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 1F7C828C0E5 for ; Mon, 10 Jan 2011 12:27:06 -0800 (PST) Received: by ewy8 with SMTP id 8so9152575ewy.31 for ; Mon, 10 Jan 2011 12:29:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:sender:received :in-reply-to:references:date:x-google-sender-auth:message-id:subject :from:to:cc:content-type:content-transfer-encoding; bh=R2euYZdTnX4ZdCVilfmFb/5mxC5nUY7QVGtlWBJqwsM=; b=a5M887Xu4ElQX6VZ3PBbJinyj5z5BlgfIqkHq7a4iav29ilMY2fqwGjjDIvZ1fSeFr dBnVTSksj03EAhI6+at/e7/EyWRgW6uYH6JmV6+YRde6uW5iEErhD7BSCrfnZ3+LlfJx ULJOdeHBewgN0gu3nSCoVN4HukEULOW7ntBhw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=I/G859v5uAsJhy+wyO/IZdyNmXPiRVsjtsYmWI+AaHkUi+MCSyw8ALMro9vpH2mcNI 3UQ1lld+HeXfVfx6NOEsd2ZicaLLRmiFJoAoXfbzALW2jkpSp5lQDynxVKx17oEVro/V 6Ydr9gV8A4o8aSOdkUPjodSwnLutfpSF2CzyY= MIME-Version: 1.0 Received: by 10.213.112.131 with SMTP id w3mr5091261ebp.42.1294691360515; Mon, 10 Jan 2011 12:29:20 -0800 (PST) Sender: charles.newyork@gmail.com Received: by 10.213.33.205 with HTTP; Mon, 10 Jan 2011 12:29:20 -0800 (PST) In-Reply-To: <4D2B59C5.6040400@bell-labs.com> References: <4D08E3E4.2050002@ericsson.com> <4D2B2341.7090602@ericsson.com> <4D2B59C5.6040400@bell-labs.com> Date: Mon, 10 Jan 2011 15:29:20 -0500 X-Google-Sender-Auth: 2mCM7KF1_o_I3dto5p_k2O2mto0 Message-ID: From: Charles Shen To: "Vijay K. Gurbani" Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: sip-overload@ietf.org Subject: Re: [sip-overload] Call for Consensus: draft-shen-soc-load-control-event-package as wg item X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jan 2011 20:27:09 -0000 Hi Vijay, I agree with you and I think it will be beneficial that the possible interaction between [1] and [2] is explicitly laid out in both documents. Thanks Charles On Mon, Jan 10, 2011 at 2:11 PM, Vijay K. Gurbani wrote= : > On 01/10/2011 09:18 AM, Salvatore Loreto wrote: >> >> Hi there, >> >> so far we have received just two replies to this call, >> both in favor to adopt it. >> >> To take in consideration the fact that the call was almost in coincidenc= e >> with the Christmas vacations, >> >> we have decided to extend it until this Friday, January 14th. > > Sal, Charles: I support the adoption of this work as a WG item for > "A specification for a SIP load filtering mechanism." > > I do have one observation, the importance of which did not > quite strike me until I read the draft: it appears that the > filtering mechanism will also impact a core proxy. =C2=A0Thus, the > core proxy must be prepared to handle the explicit overload > control mechanism as well as the filtering mechanism. > > Is it the intent to mandate the support of both algorithms? > Are we going to put tacit support for one algorithm in the > other? =C2=A0In other words, consider CPa1 and CPb1 in Figure > 1 of the draft. Can CPb1 ask CPa1 to perform overload > control based on [1] and later upload a filter criteria > based on [2]? =C2=A0I suspect from S8.2 of [2] that the answer > is yes ... however, right now, [1] is silent on [2]. > > [1] http://tools.ietf.org/html/draft-ietf-soc-overload-control-00 > [2] http://tools.ietf.org/html/draft-shen-soc-load-control-event-package-= 02 > > 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: =C2=A0 http://ect.bell-labs.com/who/vkg/ > From jgunn6@csc.com Tue Jan 11 14:28:12 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 430E23A6AB5; Tue, 11 Jan 2011 14:28:12 -0800 (PST) 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 ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sEOfsesh-Vh3; Tue, 11 Jan 2011 14:28:09 -0800 (PST) Received: from mail86.messagelabs.com (mail86.messagelabs.com [216.82.242.179]) by core3.amsl.com (Postfix) with ESMTP id B7BF73A6AAB; Tue, 11 Jan 2011 14:28:08 -0800 (PST) X-VirusChecked: Checked X-Env-Sender: jgunn6@csc.com X-Msg-Ref: server-7.tower-86.messagelabs.com!1294785023!25657954!1 X-StarScan-Version: 6.2.9; banners=-,-,- X-Originating-IP: [20.137.2.87] Received: (qmail 19680 invoked from network); 11 Jan 2011 22:30:24 -0000 Received: from amer-mta101.csc.com (HELO amer-mta101.csc.com) (20.137.2.87) by server-7.tower-86.messagelabs.com with DHE-RSA-AES256-SHA encrypted SMTP; 11 Jan 2011 22:30:24 -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 p0BMUNGi030583; Tue, 11 Jan 2011 17:30:23 -0500 In-Reply-To: References: <4D08E3E4.2050002@ericsson.com> <4D2B2341.7090602@ericsson.com> To: Charles Shen MIME-Version: 1.0 X-KeepSent: 75DF8D4C:18D559AA-85257815:007919CC; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.0.2FP1 CCH2 April 23, 2009 From: Janet P Gunn Message-ID: Date: Tue, 11 Jan 2011 17:30:21 -0500 X-MIMETrack: Serialize by Router on AMER-GW09/SRV/CSC(Release 8.5.1FP1 HF440|June 18, 2010) at 01/11/2011 05:29:51 PM, Serialize complete at 01/11/2011 05:29:51 PM Content-Type: multipart/alternative; boundary="=_alternative 007BA48385257815_=" Cc: sip-overload-bounces@ietf.org, sip-overload@ietf.org Subject: [sip-overload] Section 9 Re: Call for Consensus: draft-shen-soc-load-control-event-package as wg item X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Jan 2011 22:28:12 -0000 This is a multipart message in MIME format. --=_alternative 007BA48385257815_= Content-Type: text/plain; charset="US-ASCII" OK, here are my comments on sec 9. My proposed new text in italics inside [ ] As far as I am concerned, there is nothing fatally wrong with saying "No" when it doesn't meet a specific requirement. It just means that it must or should be used in conjunction with other mechanisms that DO meet that requirement. Here is my first cut at it. ... Therefore, we categorize the assessment results into Yes (meet the requirement), P/A (partially applicable),[ No (must be used in conjunction with another mechanism to meet this requirement)], and N/A (not applicable) ... REQ 1: The overload mechanism shall strive to maintain the overall useful throughput (taking into consideration the quality-of- service needs of the using applications) of a SIP server at reasonable levels, even when the incoming load on the network is far in excess of its capacity. The overall throughput under load is the ultimate measure of the value of an overload control mechanism. JPG - delete this - Yes. The goal of the load filtering control is to prevent overload or maintain overall goodput during the time of overload, especially when the overload contexts (e.g., time, scope) are known in advance. JPG add this instead [P/A. The goal of the load filtering control is to prevent overload or maintain overall goodput during the time of overload, but it is dependent on the advance predictions of the load. If the predictions are incorrect, in either direction, the mechanism will throttle too much or too little.] REQ 2 OK REQ 3: The mechanism should seek to minimize the amount of configuration required in order to work. For example, it is better to avoid needing to configure a server with its SIP message throughput, as these kinds of quantities are hard to determine. JPG - delete this - P/A. Since a main purpose of the load filtering control approach is to provision the appropriate capacity with advanced knowledge, configuration cannot be entirely avoided, although minimizing the configuration efforts is still desired. JPG add this instead [ No. This mechanism is entirely dependent on advance configuration, based on advance knowledge. In order to satisfy Req 3, it should be used in conjunction with other mechanisms which are not based on advance configuration. ] REQ 4: The mechanism must be capable of dealing with elements that do not support it, so that a network can consist of a mix of elements that do and don't support it. In other words, the mechanism should not work only in environments where all elements support it. It is reasonable to assume that it works better in such environments, of course. Ideally, there should be incremental improvements in overall network throughput as increasing numbers of elements in the network support the mechanism. JPG - delete this - Yes. Servers need to be prepared to work in environments where not all the upstream neighbors support this load control event package as discussed in Section 4.4. JPG add this instead [ No. This mechanism is entirely dependent on the participation of all possible neighbors. In order to satisfy Req 4, it should be used in conjunction with other mechanisms, some of which are described in section 4.4. ] REQ 5: The mechanism should not assume that it will only be deployed in environments with completely trusted elements. It should seek to operate as effectively as possible in environments where other elements are malicious; this includes preventing malicious elements from obtaining more than a fair share of service. JPG - delete this - Yes. Servers need to be prepared to work in environments where not all the upstream neighbors conform to this load control event package as discussed in Section 4.4. JPG add this instead [No. This mechanism is entirely dependent on the non-malicious participation of all possible neighbors. In order to satisfy Req 5, it should be used in conjunction with other mechanisms, some of which are described in section 4.4.] REQ 6: When overload is signaled by means of a specific message, the message must clearly indicate that it is being sent because of overload, as opposed to other, non overload-based failure conditions. This requirement is meant to avoid some of the problems that have arisen from the reuse of the 503 response code for multiple purposes. Of course, overload is also signaled by lack of response to requests. This requirement applies only to explicit overload signals. JPG - delete this - Yes. The event package defined in this document is specifically for filter-based overload control. JPG add this instead [ N/A. This mechanism signals anticipated overload, not actual overload. However the signals in this mechanism are not used for any other purpose. ] REQ 7 OK REQ 8 OK REQ 9 OK REQ 10: The mechanism should support servers that receive requests from a large number of different upstream elements, where the set of upstream elements is not enumerable. JPG - delete this - P/A: the load filtering control is mainly for cases with advanced overload contexts and for scenarios with a relatively good knowledge of the upstream entities (e.g., core proxy and edge proxy servers) where the filters can be installed. When the set of upstream elements is not enumerable, it is expected that the mechanism may be more difficult to apply. JPG add this instead [ No. Because this mechanism requires advance configuration of specific identified neighbors, it does not support environments where the number and identity of the upstream neighbors are not known in advance. In order to satisfy Req 10, it should be used in conjunction with other mechanisms.] REQ 11 OK REQ 12 OK 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. JPG - delete this - Yes. Local policies such as honoring RPH are specified. JPG add this instead [ P/A. This mechanism does not specifically address the prioritizing of work during times of overload. But is does not preclude any particular local policy.] REQ 14 OK REQ 15: In cases where a network element fails, is so overloaded that it cannot process messages, or cannot communicate due to a network failure or network partition, it will not be able to provide explicit indications of the nature of the failure or its levels of congestion. The mechanism must properly function in these cases. JPG - delete this - Yes. When the filters are provisioned in advance, they do not rely on explicit overload feedback indication. JPG add this instead [ P/A Because the filters are provisioned in advance, they are not affected by the overload or failure of other nodes. But, on the other hand, they may not, in those cases, be able to protect the overloaded node (see Req 1) ] REQ 16 OK REQ 17: The overload mechanism must not provide an avenue for malicious attack, including DoS and DDoS attacks. JPG - delete this - Yes. Security considerations are discussed, in particular, accepted filters must be authenticated and authorized. JPG add this instead [ P/A. This mechanism does provide a potential avenue for malicious attacks, Therefore the security mechanisms for SIP event packages in general [RFC3265] and of section 10 of this document SHOULD be used. ] REQ 18 OK REQ 19 OK REQ 20: In a mixed environment of elements that do and do not implement the overload mechanism, no disproportionate benefit shall accrue to the users or operators of the elements that do not implement the mechanism. JPG - delete this - Yes. For example, an example approach to ensure fair server resource allocation in an environment with both conforming and non-conforming entities is discussed in Section 4.4. JPG add this instead [ No. This mechanism is entirely dependent on the participation of all possible neighbors. In order to satisfy Req 20, it should be used in conjunction with other mechanisms, some of which are described in section 4.4. ] REQ 21 OK REQ 22 OK REQ 23 OK 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: Charles Shen To: Janet P Gunn/USA/CSC@CSC Cc: Salvatore Loreto , sip-overload-bounces@ietf.org, sip-overload@ietf.org Date: 01/10/2011 03:23 PM Subject: Re: [sip-overload] Call for Consensus: draft-shen-soc-load-control-event-package as wg item Thanks Janet. Will be happy to work together on more details of your concern. Charles On Mon, Jan 10, 2011 at 11:43 AM, Janet P Gunn wrote: > > Yes, I am in favor of adopting this as a working group item. I do not > necessarily agree with all the text in section 9- but it is there which was > my main concern. We can work on refining those details later > > Janet > > sip-overload-bounces@ietf.org wrote on 01/10/2011 10:18:25 AM: > >> Re: [sip-overload] Call for Consensus: draft-shen-soc-load-control- >> event-package as wg item >> Salvatore Loreto >> to: sip-overload >> 01/10/2011 10:19 AM >> Sent by: sip-overload-bounces@ietf.org >> >> Hi there, >> >> so far we have received just two replies to this call, >> both in favor to adopt it. >> >> To take in consideration the fact that the call was almost in coincidence >> with the Christmas vacations, >> >> we have decided to extend it until this Friday, January 14th. >> >> >> cheers >> /Sal >> >> >> On 12/15/10 4:51 PM, Salvatore Loreto wrote: >> > Hi folks, >> > >> > during the last Interim (Interim II) on December 1st, >> > Charles Shen presented the draft-shen-soc-load-control-event-package >> > and asked about the possibility to adopt it as wg item, >> > due to the comments received during the presentation we decided to wait >> > for a new version before to check in the mailing list the consensus to >> > adopt it. >> > >> > Charles has posted a new version of the draft >> > ( >> > http://www.ietf.org/id/draft-shen-soc-load-control-event-package-02.txt ) >> > addressing the comments from the Interim >> > (see in the Interim minutes: >> > http://trac.tools.ietf.org/wg/soc/trac/attachment/wiki/ >> Interim20101201/notes.txt >> > ) >> > and also other previous comments received in the mailing list. >> > >> > It is time to check in the ml the consensus to adopt the >> > draft-shen-soc-load-control-event-package as wg item. >> > >> > So, as chairs Volker and I want to check the consensus to adopt it as >> > baseline for the wg item >> > addressing the derivable number 3 in the charter: >> > >> > Aug 2011 - Specification for a SIP load filtering mechaism to >> IESG for publication as Proposed Standard >> > >> > >> > This consensus call will end on Friday January 7th, 2010. >> > >> > cheers >> > /Sal >> _______________________________________________ >> 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 > > --=_alternative 007BA48385257815_= Content-Type: text/html; charset="US-ASCII"
OK, here are my comments on sec 9.  My proposed new text  in italics inside [  ]
As far as I am concerned, there is nothing fatally wrong with saying "No" when it doesn't meet a specific requirement.  It just means that it must or should be used in conjunction with other mechanisms that DO meet that requirement.

Here is my first cut at it.


...
Therefore, we categorize the assessment    results into Yes (meet the requirement), P/A (partially applicable),[ No (must be used in conjunction with another mechanism to meet this requirement)],   and N/A (not applicable)
...
REQ 1: The overload mechanism shall strive to maintain the overall
      useful throughput (taking into consideration the quality-of-
      service needs of the using applications) of a SIP server at
      reasonable levels, even when the incoming load on the network is
      far in excess of its capacity.  The overall throughput under load
      is the ultimate measure of the value of an overload control
      mechanism.

  JPG - delete this - Yes. The goal of the load filtering control is to prevent overload or
   maintain overall goodput during the time of overload, especially when
   the overload contexts (e.g., time, scope) are known in advance.

JPG add this instead [P/A. The goal of the load filtering control is to prevent overload or  maintain overall goodput during the time of overload, but it is dependent on the advance predictions of the load. If the predictions are incorrect, in either direction, the mechanism will throttle too much or too little.]

REQ 2 OK

      REQ 3: The mechanism should seek to minimize the amount of
      configuration required in order to work.  For example, it is
      better to avoid needing to configure a server with its SIP message
      throughput, as these kinds of quantities are hard to determine.

    JPG - delete this - P/A. Since a main purpose of the load filtering control approach is
   to provision the appropriate capacity with advanced knowledge,
   configuration cannot be entirely avoided, although minimizing the
   configuration efforts is still desired.

JPG add this instead [ No.  This mechanism is entirely dependent on advance configuration, based on advance knowledge.  In order to satisfy  Req 3, it should be used in conjunction with other mechanisms which are not based on advance configuration. ]

      REQ 4: The mechanism must be capable of dealing with elements that
      do not support it, so that a network can consist of a mix of
      elements that do and don't support it.  In other words, the
      mechanism should not work only in environments where all elements
      support it.  It is reasonable to assume that it works better in
      such environments, of course.  Ideally, there should be
      incremental improvements in overall network throughput as
      increasing numbers of elements in the network support the
      mechanism.

  JPG - delete this -  Yes. Servers need to be prepared to work in environments where not
   all the upstream neighbors support this load control event package as
   discussed in Section 4.4.

 JPG add this instead [ No. This mechanism is entirely dependent on the participation of all possible neighbors.  In order to satisfy Req 4, it should be used in conjunction with other mechanisms, some of which are described in section 4.4. ]

      REQ 5: The mechanism should not assume that it will only be
      deployed in environments with completely trusted elements.  It
      should seek to operate as effectively as possible in environments
      where other elements are malicious; this includes preventing
      malicious elements from obtaining more than a fair share of
      service.

    JPG - delete this -   Yes. Servers need to be prepared to work in environments where not
   all the upstream neighbors conform to this load control event package
   as discussed in Section 4.4.

 JPG add this instead [No. This  mechanism is entirely dependent on the non-malicious  participation of all possible neighbors.  In order to satisfy Req 5, it should be used in conjunction with other mechanisms, some of which are described in section 4.4.]

      REQ 6: When overload is signaled by means of a specific message,
      the message must clearly indicate that it is being sent because of
      overload, as opposed to other, non overload-based failure
      conditions.  This requirement is meant to avoid some of the
      problems that have arisen from the reuse of the 503 response code
      for multiple purposes.  Of course, overload is also signaled by
      lack of response to requests.  This requirement applies only to
      explicit overload signals.

    JPG - delete this -     Yes. The event package defined in this document is specifically for
   filter-based overload control.

 JPG add this instead [ N/A.  This mechanism signals anticipated overload, not actual overload.  However the signals in this mechanism are not used for any other purpose. ]

REQ 7 OK
REQ 8 OK
REQ 9 OK

      REQ 10: The mechanism should support servers that receive requests
      from a large number of different upstream elements, where the set
      of upstream elements is not enumerable.

 JPG - delete this -      P/A: the load filtering control is mainly for cases with advanced
   overload contexts and for scenarios with a relatively good knowledge
   of the upstream entities (e.g., core proxy and edge proxy servers)
   where the filters can be installed.  When the set of upstream
   elements is not enumerable, it is expected that the mechanism may be
   more difficult to apply.

 JPG add this instead  [ No.  Because this mechanism requires advance configuration of  specific identified neighbors, it does not support environments where the number and identity of the upstream neighbors are not known in advance.  In order to satisfy Req 10, it should be used in conjunction with other mechanisms.]

REQ 11 OK
REQ 12 OK

      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.

   JPG - delete this -    Yes. Local policies such as honoring RPH are specified.

 JPG add this instead [ P/A.  This mechanism does not specifically address the prioritizing of work during times of overload.  But is does not preclude any particular local policy.]

REQ 14 OK

      REQ 15: In cases where a network element fails, is so overloaded
      that it cannot process messages, or cannot communicate due to a
      network failure or network partition, it will not be able to
      provide explicit indications of the nature of the failure or its
      levels of congestion.  The mechanism must properly function in
      these cases.

     JPG - delete this -    Yes. When the filters are provisioned in advance, they do not rely on
   explicit overload feedback indication.

 JPG add this instead [ P/A  Because the filters are provisioned in advance, they are not affected by the overload or failure of other nodes.  But, on the other hand, they may not, in those cases, be able to protect the overloaded node (see Req 1) ]

REQ 16 OK

      REQ 17: The overload mechanism must not provide an avenue for
      malicious attack, including DoS and DDoS attacks.

    JPG - delete this -      Yes. Security considerations are discussed, in particular, accepted
   filters must be authenticated and authorized.

 JPG add this instead [ P/A. This mechanism does provide a potential avenue for malicious attacks, Therefore the security mechanisms for SIP event packages in general [RFC3265] and of section 10 of this document SHOULD be used.  ]

REQ 18 OK
REQ 19 OK

      REQ 20: In a mixed environment of elements that do and do not
      implement the overload mechanism, no disproportionate benefit
      shall accrue to the users or operators of the elements that do not
      implement the mechanism.

  JPG - delete this -       Yes. For example, an example approach to ensure fair server resource
   allocation in an environment with both conforming and non-conforming
   entities is discussed in Section 4.4.

 JPG add this instead [ No. This mechanism is entirely dependent on the participation of all possible neighbors.  In order to satisfy Req 20, it should be used in conjunction with other mechanisms, some of which are described in section 4.4. ]

REQ 21 OK
REQ 22 OK
REQ 23 OK

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: Charles Shen <charles@cs.columbia.edu>
To: Janet P Gunn/USA/CSC@CSC
Cc: Salvatore Loreto <salvatore.loreto@ericsson.com>, sip-overload-bounces@ietf.org, sip-overload@ietf.org
Date: 01/10/2011 03:23 PM
Subject: Re: [sip-overload] Call for Consensus: draft-shen-soc-load-control-event-package as wg item




Thanks Janet. Will be happy to work together on more details of your concern.

Charles




On Mon, Jan 10, 2011 at 11:43 AM, Janet P Gunn <jgunn6@csc.com> wrote:
>
> Yes, I am in favor of adopting this as a working group item.  I do not
> necessarily agree with all the text in section 9- but it is there which was
> my main concern.  We can work on refining those details later
>
> Janet
>
> sip-overload-bounces@ietf.org wrote on 01/10/2011 10:18:25 AM:
>
>> Re: [sip-overload] Call for Consensus: draft-shen-soc-load-control-
>> event-package as wg item
>> Salvatore Loreto
>> to: sip-overload
>> 01/10/2011 10:19 AM
>> Sent by: sip-overload-bounces@ietf.org
>>
>> Hi there,
>>
>> so far we have received just two replies to this call,
>> both in favor to adopt it.
>>
>> To take in consideration the fact that the call was almost in coincidence
>> with the Christmas vacations,
>>
>> we have decided to extend it until this Friday, January 14th.
>>
>>
>> cheers
>> /Sal
>>
>>
>> On 12/15/10 4:51 PM, Salvatore Loreto wrote:
>> > Hi folks,
>> >
>> > during the last Interim (Interim II) on December 1st,
>> > Charles Shen presented the draft-shen-soc-load-control-event-package
>> > and asked about the possibility to adopt it as wg item,
>> > due to the comments received during the presentation we decided to wait
>> > for a new version before to check in the mailing list the consensus to
>> > adopt it.
>> >
>> > Charles has posted a new version of the draft
>> > (
>> > http://www.ietf.org/id/draft-shen-soc-load-control-event-package-02.txt )
>> > addressing the comments from the Interim
>> > (see in the Interim minutes:
>> > http://trac.tools.ietf.org/wg/soc/trac/attachment/wiki/
>> Interim20101201/notes.txt
>> > )
>> > and also other previous comments received in the mailing list.
>> >
>> > It is time to check in the ml the consensus to adopt the
>> > draft-shen-soc-load-control-event-package as wg item.
>> >
>> > So, as chairs Volker and I want to check the consensus to adopt it as
>> > baseline for the wg item
>> > addressing the derivable number 3 in the charter:
>> >
>> >     Aug 2011 - Specification for a SIP load filtering mechaism to
>> IESG for publication as Proposed Standard
>> >
>> >
>> > This consensus call will end on Friday January 7th, 2010.
>> >
>> > cheers
>> > /Sal
>> _______________________________________________
>> 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
>
>

--=_alternative 007BA48385257815_=-- From charles.newyork@gmail.com Thu Jan 13 06:44:27 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id A91E928B23E; Thu, 13 Jan 2011 06:44:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P3aLNO8DSiMz; Thu, 13 Jan 2011 06:44:25 -0800 (PST) Received: from mail-ew0-f44.google.com (mail-ew0-f44.google.com [209.85.215.44]) by core3.amsl.com (Postfix) with ESMTP id 1A99D3A6B32; Thu, 13 Jan 2011 06:44:23 -0800 (PST) Received: by ewy8 with SMTP id 8so876511ewy.31 for ; Thu, 13 Jan 2011 06:46:46 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; bh=H14YTjBQ6ReYI7pZRYL/Zak/VvSbJNnMxxZ4fCdtV5c=; b=ApzYVH4PD7acEGWW9aGdyVkLDwI5AnZglzgwxx6K3d8BcxjPJw4Kf03Kh9HUterxNm aVl6LngM3lu4qOV9hXut1Ct6CRGWHqnlWe2ZBMynx12CES7ogSyq2uAmi6bsCDSt36KO 8vRFpSJFWWK8dLfRnuEgCCeBcfnVpyh24nY7w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=rdBljllwLeedY9sp7fpR3PwrRjBdK0WmG+xx8j593Hs+JEZ+w5ySGcxbKqxhd5oBLP V31Wt4NRTqfAYXT7QPg/9MVs8wxlGxupUd6XErUPZdBCUr9RmRvkdKAQCzAtDL99ePo0 etES0eu/mEHWVaHMyOhTAbU37nncZNh8xJfcA= MIME-Version: 1.0 Received: by 10.213.114.82 with SMTP id d18mr631481ebq.29.1294930005711; Thu, 13 Jan 2011 06:46:45 -0800 (PST) Sender: charles.newyork@gmail.com Received: by 10.213.33.205 with HTTP; Thu, 13 Jan 2011 06:46:45 -0800 (PST) In-Reply-To: References: <4D08E3E4.2050002@ericsson.com> <4D2B2341.7090602@ericsson.com> Date: Thu, 13 Jan 2011 09:46:45 -0500 X-Google-Sender-Auth: wItUF_ogbdEore3HNvqKCK0vOY8 Message-ID: From: Charles Shen To: Janet P Gunn Content-Type: multipart/alternative; boundary=0015174bde28ffdcf20499bb62bc Cc: sip-overload-bounces@ietf.org, sip-overload@ietf.org Subject: Re: [sip-overload] Section 9 Re: Call for Consensus: draft-shen-soc-load-control-event-package as wg item X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jan 2011 14:44:27 -0000 --0015174bde28ffdcf20499bb62bc Content-Type: text/plain; charset=UTF-8 Hi Janet, Thanks for your comments! I have absolutely no problem adding "No" as one of the assessment results to the requirements that are not met. I will incorporate your suggested revision in the next update. Thanks Charles On Tue, Jan 11, 2011 at 5:30 PM, Janet P Gunn wrote: > > OK, here are my comments on sec 9. My proposed new text in italics inside > [ ] > As far as I am concerned, there is nothing fatally wrong with saying "No" > when it doesn't meet a specific requirement. It just means that it must or > should be used in conjunction with other mechanisms that DO meet that > requirement. > > Here is my first cut at it. > > > ... > Therefore, we categorize the assessment results into Yes (meet the > requirement), P/A (partially applicable),[ *No (must be used in > conjunction with another mechanism to meet this requirement)*], and N/A > (not applicable) > ... > REQ 1: The overload mechanism shall strive to maintain the overall > useful throughput (taking into consideration the quality-of- > service needs of the using applications) of a SIP server at > reasonable levels, even when the incoming load on the network is > far in excess of its capacity. The overall throughput under load > is the ultimate measure of the value of an overload control > mechanism. > > JPG - delete this - Yes. The goal of the load filtering control is to > prevent overload or > maintain overall goodput during the time of overload, especially when > the overload contexts (e.g., time, scope) are known in advance. > > JPG add this instead [*P/A. The goal of the load filtering control is to > prevent overload or maintain overall goodput during the time of overload, > but it is dependent on the advance predictions of the load. If the > predictions are incorrect, in either direction, the mechanism will throttle > too much or too little.*] > > REQ 2 OK > > REQ 3: The mechanism should seek to minimize the amount of > configuration required in order to work. For example, it is > better to avoid needing to configure a server with its SIP message > throughput, as these kinds of quantities are hard to determine. > > JPG - delete this - P/A. Since a main purpose of the load filtering > control approach is > to provision the appropriate capacity with advanced knowledge, > configuration cannot be entirely avoided, although minimizing the > configuration efforts is still desired. > > JPG add this instead [ *No. This mechanism is entirely dependent on > advance configuration, based on advance knowledge. In order to satisfy Req > 3, it should be used in conjunction with other mechanisms which are not > based on advance configuration.* ] > > REQ 4: The mechanism must be capable of dealing with elements that > do not support it, so that a network can consist of a mix of > elements that do and don't support it. In other words, the > mechanism should not work only in environments where all elements > support it. It is reasonable to assume that it works better in > such environments, of course. Ideally, there should be > incremental improvements in overall network throughput as > increasing numbers of elements in the network support the > mechanism. > > JPG - delete this - Yes. Servers need to be prepared to work in > environments where not > all the upstream neighbors support this load control event package as > discussed in Section 4.4. > > JPG add this instead [ *No. This mechanism is entirely dependent on the > participation of all possible neighbors. In order to satisfy Req 4, it > should be used in conjunction with other mechanisms, some of which are > described in section 4.4.* ] > > REQ 5: The mechanism should not assume that it will only be > deployed in environments with completely trusted elements. It > should seek to operate as effectively as possible in environments > where other elements are malicious; this includes preventing > malicious elements from obtaining more than a fair share of > service. > > JPG - delete this - Yes. Servers need to be prepared to work in > environments where not > all the upstream neighbors conform to this load control event package > as discussed in Section 4.4. > > JPG add this instead [*No. This mechanism is entirely dependent on the > non-malicious participation of all possible neighbors. In order to satisfy > Req 5, it should be used in conjunction with other mechanisms, some of which > are described in section 4.4.*] > > REQ 6: When overload is signaled by means of a specific message, > the message must clearly indicate that it is being sent because of > overload, as opposed to other, non overload-based failure > conditions. This requirement is meant to avoid some of the > problems that have arisen from the reuse of the 503 response code > for multiple purposes. Of course, overload is also signaled by > lack of response to requests. This requirement applies only to > explicit overload signals. > > JPG - delete this - Yes. The event package defined in this document > is specifically for > filter-based overload control. > > JPG add this instead [* N/A. This mechanism signals anticipated > overload, not actual overload. However the signals in this mechanism are > not used for any other purpose. *] > > REQ 7 OK > REQ 8 OK > REQ 9 OK > > REQ 10: The mechanism should support servers that receive requests > from a large number of different upstream elements, where the set > of upstream elements is not enumerable. > > JPG - delete this - P/A: the load filtering control is mainly for > cases with advanced > overload contexts and for scenarios with a relatively good knowledge > of the upstream entities (e.g., core proxy and edge proxy servers) > where the filters can be installed. When the set of upstream > elements is not enumerable, it is expected that the mechanism may be > more difficult to apply. > > JPG add this instead [ *No. Because this mechanism requires advance > configuration of specific identified neighbors, it does not support > environments where the number and identity of the upstream neighbors are not > known in advance. In order to satisfy Req 10, it should be used in > conjunction with other mechanisms.*] > > REQ 11 OK > REQ 12 OK > > 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. > > JPG - delete this - Yes. Local policies such as honoring RPH are > specified. > > JPG add this instead [ *P/A. This mechanism does not specifically > address the prioritizing of work during times of overload. But is does not > preclude any particular local policy.*] > > REQ 14 OK > > REQ 15: In cases where a network element fails, is so overloaded > that it cannot process messages, or cannot communicate due to a > network failure or network partition, it will not be able to > provide explicit indications of the nature of the failure or its > levels of congestion. The mechanism must properly function in > these cases. > > JPG - delete this - Yes. When the filters are provisioned in > advance, they do not rely on > explicit overload feedback indication. > > JPG add this instead [ *P/A Because the filters are provisioned in > advance, they are not affected by the overload or failure of other nodes. > But, on the other hand, they may not, in those cases, be able to protect > the overloaded node (see Req 1)* ] > > REQ 16 OK > > REQ 17: The overload mechanism must not provide an avenue for > malicious attack, including DoS and DDoS attacks. > > JPG - delete this - Yes. Security considerations are discussed, in > particular, accepted > filters must be authenticated and authorized. > > JPG add this instead [* P/A. This mechanism does provide a potential > avenue for malicious attacks, Therefore the security mechanisms for SIP > event packages in general [RFC3265] and of section 10 of this document > SHOULD be used.* ] > > REQ 18 OK > REQ 19 OK > > REQ 20: In a mixed environment of elements that do and do not > implement the overload mechanism, no disproportionate benefit > shall accrue to the users or operators of the elements that do not > implement the mechanism. > > JPG - delete this - Yes. For example, an example approach to ensure > fair server resource > allocation in an environment with both conforming and non-conforming > entities is discussed in Section 4.4. > > JPG add this instead [ *No. This mechanism is entirely dependent on the > participation of all possible neighbors. In order to satisfy Req 20, it > should be used in conjunction with other mechanisms, some of which are > described in section 4.4. *] > > REQ 21 OK > REQ 22 OK > REQ 23 OK > > 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: Charles Shen To: Janet P Gunn/USA/CSC@CSC > Cc: Salvatore Loreto , > sip-overload-bounces@ietf.org, sip-overload@ietf.org Date: 01/10/2011 > 03:23 PM Subject: Re: [sip-overload] Call for Consensus: > draft-shen-soc-load-control-event-package as wg item > ------------------------------ > > > > Thanks Janet. Will be happy to work together on more details of your > concern. > > Charles > > > > > On Mon, Jan 10, 2011 at 11:43 AM, Janet P Gunn wrote: > > > > Yes, I am in favor of adopting this as a working group item. I do not > > necessarily agree with all the text in section 9- but it is there which > was > > my main concern. We can work on refining those details later > > > > Janet > > > > sip-overload-bounces@ietf.org wrote on 01/10/2011 10:18:25 AM: > > > >> Re: [sip-overload] Call for Consensus: draft-shen-soc-load-control- > >> event-package as wg item > >> Salvatore Loreto > >> to: sip-overload > >> 01/10/2011 10:19 AM > >> Sent by: sip-overload-bounces@ietf.org > >> > >> Hi there, > >> > >> so far we have received just two replies to this call, > >> both in favor to adopt it. > >> > >> To take in consideration the fact that the call was almost in > coincidence > >> with the Christmas vacations, > >> > >> we have decided to extend it until this Friday, January 14th. > >> > >> > >> cheers > >> /Sal > >> > >> > >> On 12/15/10 4:51 PM, Salvatore Loreto wrote: > >> > Hi folks, > >> > > >> > during the last Interim (Interim II) on December 1st, > >> > Charles Shen presented the draft-shen-soc-load-control-event-package > >> > and asked about the possibility to adopt it as wg item, > >> > due to the comments received during the presentation we decided to > wait > >> > for a new version before to check in the mailing list the consensus to > >> > adopt it. > >> > > >> > Charles has posted a new version of the draft > >> > ( > >> > > http://www.ietf.org/id/draft-shen-soc-load-control-event-package-02.txt ) > >> > addressing the comments from the Interim > >> > (see in the Interim minutes: > >> > http://trac.tools.ietf.org/wg/soc/trac/attachment/wiki/ > >> Interim20101201/notes.txt > >> > ) > >> > and also other previous comments received in the mailing list. > >> > > >> > It is time to check in the ml the consensus to adopt the > >> > draft-shen-soc-load-control-event-package as wg item. > >> > > >> > So, as chairs Volker and I want to check the consensus to adopt it as > >> > baseline for the wg item > >> > addressing the derivable number 3 in the charter: > >> > > >> > Aug 2011 - Specification for a SIP load filtering mechaism to > >> IESG for publication as Proposed Standard > >> > > >> > > >> > This consensus call will end on Friday January 7th, 2010. > >> > > >> > cheers > >> > /Sal > >> _______________________________________________ > >> 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 > > > > > > > --0015174bde28ffdcf20499bb62bc Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Janet,

Thanks for your comments! I have absolutely no problem ad= ding "No" as one of the assessment results to the requirements th= at are not met. I will incorporate your suggested revision in the next upda= te.=C2=A0

Thanks

Charles



On Tue, Jan 11, 2011 at 5:30 PM, Janet P= Gunn <jgunn6@csc.co= m> wrote:

OK, here are my comments on sec 9. = =C2=A0My proposed new text =C2=A0in italics inside [ =C2=A0]
As far as I am concerned, there is n= othing fatally wrong with saying "No" when it doesn't meet a specifi= c requirement. =C2=A0It just means that it must or should be used in conjunct= ion with other mechanisms that DO meet that requirement.

Here is my first cut at it.


...
Therefore, we categorize the assessm= ent =C2=A0 =C2=A0results into Yes (meet the requirement), P/A (partially applic= able),[ No (must be used in conjunction with another mechanism to meet this requirement)], =C2=A0 and N/A (not applicable)
...
REQ 1: The overload mechanism shall = strive to maintain the overall
=C2=A0 =C2=A0 =C2=A0 useful throughp= ut (taking into consideration the quality-of-
=C2=A0 =C2=A0 =C2=A0 service needs o= f the using applications) of a SIP server at
=C2=A0 =C2=A0 =C2=A0 reasonable leve= ls, even when the incoming load on the network is
=C2=A0 =C2=A0 =C2=A0 far in excess o= f its capacity. =C2=A0The overall throughput under load
=C2=A0 =C2=A0 =C2=A0 is the ultimate= measure of the value of an overload control
=C2=A0 =C2=A0 =C2=A0 mechanism.

=C2=A0 JPG - delete this - Yes. The = goal of the load filtering control is to prevent overload or
=C2=A0 =C2=A0maintain overall goodpu= t during the time of overload, especially when
=C2=A0 =C2=A0the overload contexts (= e.g., time, scope) are known in advance.

JPG add this instead [P/A. The go= al of the load filtering control is to prevent overload or =C2=A0maintain overall goodput during the time of overload, but it is dependent on the advance predictions of the load. If the predictions are incorrect, in eithe= r direction, the mechanism will throttle too much or too little.]

REQ 2 OK

=C2=A0 =C2=A0 =C2=A0 REQ 3: The mech= anism should seek to minimize the amount of
=C2=A0 =C2=A0 =C2=A0 configuration r= equired in order to work. =C2=A0For example, it is
=C2=A0 =C2=A0 =C2=A0 better to avoid= needing to configure a server with its SIP message
=C2=A0 =C2=A0 =C2=A0 throughput, as = these kinds of quantities are hard to determine.

=C2=A0 =C2=A0 JPG - delete this - P/= A. Since a main purpose of the load filtering control approach is
=C2=A0 =C2=A0to provision the approp= riate capacity with advanced knowledge,
=C2=A0 =C2=A0configuration cannot be= entirely avoided, although minimizing the
=C2=A0 =C2=A0configuration efforts i= s still desired.

JPG add this instead [ No. =C2=A0= This mechanism is entirely dependent on advance configuration, based on advance knowledge. =C2=A0In order to satisfy =C2=A0Req 3, it should be used in conjunction with other mechanisms which are not based on advance configurat= ion. ]

=C2=A0 =C2=A0 =C2=A0 REQ 4: The mech= anism must be capable of dealing with elements that
=C2=A0 =C2=A0 =C2=A0 do not support = it, so that a network can consist of a mix of
=C2=A0 =C2=A0 =C2=A0 elements that d= o and don't support it. =C2=A0In other words, the
=C2=A0 =C2=A0 =C2=A0 mechanism shoul= d not work only in environments where all elements
=C2=A0 =C2=A0 =C2=A0 support it. =C2= =A0It is reasonable to assume that it works better in
=C2=A0 =C2=A0 =C2=A0 such environmen= ts, of course. =C2=A0Ideally, there should be
=C2=A0 =C2=A0 =C2=A0 incremental imp= rovements in overall network throughput as
=C2=A0 =C2=A0 =C2=A0 increasing numb= ers of elements in the network support the
=C2=A0 =C2=A0 =C2=A0 mechanism.

=C2=A0 JPG - delete this - =C2=A0Yes= . Servers need to be prepared to work in environments where not
=C2=A0 =C2=A0all the upstream neighb= ors support this load control event package as
=C2=A0 =C2=A0discussed in Section 4.= 4.

=C2=A0JPG add this instead [ No. = This mechanism is entirely dependent on the participation of all possible neighb= ors. =C2=A0In order to satisfy Req 4, it should be used in conjunction with other mechanisms, some of which are described in section 4.4. ]

=C2=A0 =C2=A0 =C2=A0 REQ 5: The mech= anism should not assume that it will only be
=C2=A0 =C2=A0 =C2=A0 deployed in env= ironments with completely trusted elements. =C2=A0It
=C2=A0 =C2=A0 =C2=A0 should seek to = operate as effectively as possible in environments
=C2=A0 =C2=A0 =C2=A0 where other ele= ments are malicious; this includes preventing
=C2=A0 =C2=A0 =C2=A0 malicious eleme= nts from obtaining more than a fair share of
=C2=A0 =C2=A0 =C2=A0 service.

=C2=A0 =C2=A0 JPG - delete this - = =C2=A0 Yes. Servers need to be prepared to work in environments where not
=C2=A0 =C2=A0all the upstream neighb= ors conform to this load control event package
=C2=A0 =C2=A0as discussed in Section= 4.4.

=C2=A0JPG add this instead [No. T= his =C2=A0mechanism is entirely dependent on the non-malicious =C2=A0participat= ion of all possible neighbors. =C2=A0In order to satisfy Req 5, it should be used in conjunction with other mechanisms, some of which are described in section 4.4.]

=C2=A0 =C2=A0 =C2=A0 REQ 6: When ove= rload is signaled by means of a specific message,
=C2=A0 =C2=A0 =C2=A0 the message mus= t clearly indicate that it is being sent because of
=C2=A0 =C2=A0 =C2=A0 overload, as op= posed to other, non overload-based failure
=C2=A0 =C2=A0 =C2=A0 conditions. =C2= =A0This requirement is meant to avoid some of the
=C2=A0 =C2=A0 =C2=A0 problems that h= ave arisen from the reuse of the 503 response code
=C2=A0 =C2=A0 =C2=A0 for multiple pu= rposes. =C2=A0Of course, overload is also signaled by
=C2=A0 =C2=A0 =C2=A0 lack of respons= e to requests. =C2=A0This requirement applies only to
=C2=A0 =C2=A0 =C2=A0 explicit overlo= ad signals.

=C2=A0 =C2=A0 JPG - delete this - = =C2=A0 =C2=A0 Yes. The event package defined in this document is specifically for
=C2=A0 =C2=A0filter-based overload c= ontrol.

=C2=A0JPG add this instead [ N/A.= =C2=A0This mechanism signals anticipated overload, not actual overload. =C2=A0However the signals in this mechanism are not used for any other purpose. ]

REQ 7 OK
REQ 8 OK
REQ 9 OK

=C2=A0 =C2=A0 =C2=A0 REQ 10: The mec= hanism should support servers that receive requests
=C2=A0 =C2=A0 =C2=A0 from a large nu= mber of different upstream elements, where the set
=C2=A0 =C2=A0 =C2=A0 of upstream ele= ments is not enumerable.

=C2=A0JPG - delete this - =C2=A0 =C2= =A0 =C2=A0P/A: the load filtering control is mainly for cases with advanced
=C2=A0 =C2=A0overload contexts and f= or scenarios with a relatively good knowledge
=C2=A0 =C2=A0of the upstream entitie= s (e.g., core proxy and edge proxy servers)
=C2=A0 =C2=A0where the filters can b= e installed. =C2=A0When the set of upstream
=C2=A0 =C2=A0elements is not enumera= ble, it is expected that the mechanism may be
=C2=A0 =C2=A0more difficult to apply= .

=C2=A0JPG add this instead =C2=A0[ <= i>No. =C2=A0Because this mechanism requires advance configuration of =C2=A0specif= ic identified neighbors, it does not support environments where the number and identity of the upstream neighbors are not known in advance. =C2=A0In order to satisfy Req 10, it should be used in conjunction with other mechan= isms.]

REQ 11 OK
REQ 12 OK

=C2=A0 =C2=A0 =C2=A0 REQ 13: The mec= hanism must not dictate a specific algorithm for
=C2=A0 =C2=A0 =C2=A0 prioritizing th= e processing of work within a proxy during times of
=C2=A0 =C2=A0 =C2=A0 overload. =C2= =A0It must permit a proxy to prioritize requests based on
=C2=A0 =C2=A0 =C2=A0 any local polic= y, so that certain ones (such as a call for
=C2=A0 =C2=A0 =C2=A0 emergency servi= ces or a call with a specific value of the
=C2=A0 =C2=A0 =C2=A0 Resource-Priori= ty header field [RFC4412]) are given preferential
=C2=A0 =C2=A0 =C2=A0 treatment, such= as not being dropped, being given additional
=C2=A0 =C2=A0 =C2=A0 retransmission,= or being processed ahead of others.

=C2=A0 =C2=A0JPG - delete this - =C2= =A0 =C2=A0Yes. Local policies such as honoring RPH are specified.

=C2=A0JPG add this instead [ P/A.= =C2=A0This mechanism does not specifically address the prioritizing of work during times of overload. =C2=A0But is does not preclude any particular local policy.]

REQ 14 OK

=C2=A0 =C2=A0 =C2=A0 REQ 15: In case= s where a network element fails, is so overloaded
=C2=A0 =C2=A0 =C2=A0 that it cannot = process messages, or cannot communicate due to a
=C2=A0 =C2=A0 =C2=A0 network failure= or network partition, it will not be able to
=C2=A0 =C2=A0 =C2=A0 provide explici= t indications of the nature of the failure or its
=C2=A0 =C2=A0 =C2=A0 levels of conge= stion. =C2=A0The mechanism must properly function in
=C2=A0 =C2=A0 =C2=A0 these cases.

=C2=A0 =C2=A0 =C2=A0JPG - delete thi= s - =C2=A0 =C2=A0Yes. When the filters are provisioned in advance, they do not rely on
=C2=A0 =C2=A0explicit overload feedb= ack indication.

=C2=A0JPG add this instead [ P/A = =C2=A0Because the filters are provisioned in advance, they are not affected by the overlo= ad or failure of other nodes. =C2=A0But, on the other hand, they may not, in those cases, be able to protect the overloaded node (see Req 1) ]

REQ 16 OK

=C2=A0 =C2=A0 =C2=A0 REQ 17: The ove= rload mechanism must not provide an avenue for
=C2=A0 =C2=A0 =C2=A0 malicious attac= k, including DoS and DDoS attacks.

=C2=A0 =C2=A0 JPG - delete this - = =C2=A0 =C2=A0 =C2=A0Yes. Security considerations are discussed, in particular, accepted
=C2=A0 =C2=A0filters must be authent= icated and authorized.

=C2=A0JPG add this instead [ P/A.= This mechanism does provide a potential avenue for malicious attacks, Therefore the security mechanisms for SIP event packages in general [RFC3265] and of section 10 of this document SHOULD be used. =C2=A0]

REQ 18 OK
REQ 19 OK

=C2=A0 =C2=A0 =C2=A0 REQ 20: In a mi= xed environment of elements that do and do not
=C2=A0 =C2=A0 =C2=A0 implement the o= verload mechanism, no disproportionate benefit
=C2=A0 =C2=A0 =C2=A0 shall accrue to= the users or operators of the elements that do not
=C2=A0 =C2=A0 =C2=A0 implement the m= echanism.

=C2=A0 JPG - delete this - =C2=A0 = =C2=A0 =C2=A0 Yes. For example, an example approach to ensure fair server resource=
=C2=A0 =C2=A0allocation in an enviro= nment with both conforming and non-conforming
=C2=A0 =C2=A0entities is discussed i= n Section 4.4.

=C2=A0JPG add this instead [ No. = This mechanism is entirely dependent on the participation of all possible neighb= ors. =C2=A0In order to satisfy Req 20, it should be used in conjunction with other mechanisms, some of which are described in section 4.4. ]

REQ 21 OK
REQ 22 OK
REQ 23 OK

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 agreemen= t or government initiative expressly permitting the use of e-mail for such purpose.


From: Charles Shen <charles@cs.columbia.edu>
To: Janet P Gunn/USA/CSC@CSC
C= c: Salvatore Loreto <salvatore.loret= o@ericsson.com>, sip-over= load-bounces@ietf.org, sip-overload@ietf.org
Date: 01/10/2011 03:23 PM
Subject: Re: [sip-overload] Call for C= onsensus: draft-shen-soc-load-control-event-package as wg item




Thanks Janet. Will be happy to work together on mo= re details of your concern.

Charles




On Mon, Jan 10, 2011 at 11:43 AM, Janet P Gunn <jgunn6@csc.com> wrote:
>
> Yes, I am in favor of adopting this as a working group item. =C2=A0I do not
> necessarily agree with all the text in section 9- but it is there which was
> my main concern. =C2=A0We can work on refining those details later
>
> Janet
>
> sip= -overload-bounces@ietf.org wrote on 01/10/2011 10:18:25 AM:
>
>> Re: [sip-overload] Call for Consensus: draft-shen-soc-load-control= -
>> event-package as wg item
>> Salvatore Loreto
>> to: sip-overload
>> 01/10/2011 10:19 AM
>> Sent by: sip-overload-bounces@ietf.org
>>
>> Hi there,
>>
>> so far we have received just two replies to this call,
>> both in favor to adopt it.
>>
>> To take in consideration the fact that the call was almost in coincidence
>> with the Christmas vacations,
>>
>> we have decided to extend it until this Friday, January 14th.
>>
>>
>> cheers
>> /Sal
>>
>>
>> On 12/15/10 4:51 PM, Salvatore Loreto wrote:
>> > Hi folks,
>> >
>> > during the last Interim (Interim II) on December 1st,
>> > Charles Shen presented the draft-shen-soc-load-control-event-= package
>> > and asked about the possibility to adopt it as wg item,
>> > due to the comments received during the presentation we decid= ed to wait
>> > for a new version before to check in the mailing list the consensus to
>> > adopt it.
>> >
>> > Charles has posted a new version of the draft
>> > (
>> > h= ttp://www.ietf.org/id/draft-shen-soc-load-control-event-package-02.txt )
>> > addressing the comments from the Interim
>> > (see in the Interim minutes:
>> > http://trac.tools= .ietf.org/wg/soc/trac/attachment/wiki/=
>> Interim20101201/notes.txt
>> > )
>> > and also other previous comments received in the mailing list.
>> >
>> > It is time to check in the ml the consensus to adopt the
>> > draft-shen-soc-load-control-event-package as wg item.
>> >
>> > So, as chairs Volker and I want to check the consensus to adopt it as
>> > baseline for the wg item
>> > addressing the derivable number 3 in the charter:
>> >
>> > =C2=A0 =C2=A0 Aug 2011 - Specification for a SIP load filteri= ng mechaism to
>> IESG for publication as Proposed Standard
>> >
>> >
>> > This consensus call will end on Friday January 7th, 2010.
>> >
>> > cheers
>> > /Sal
>> _______________________________________________
>> sip-overload mailing list
>> sip-ove= rload@ietf.org
>> https://www.ietf.org/mailma= n/listinfo/sip-overload
>
> _______________________________________________
> sip-overload mailing list
> sip-overloa= d@ietf.org
> https://www.ietf.org/mailman/li= stinfo/sip-overload
>
>


--0015174bde28ffdcf20499bb62bc-- From salvatore.loreto@ericsson.com Sat Jan 15 09:34:38 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id B56F73A6DCA for ; Sat, 15 Jan 2011 09:34:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.541 X-Spam-Level: X-Spam-Status: No, score=-106.541 tagged_above=-999 required=5 tests=[AWL=0.058, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sgmATdWf5gLV for ; Sat, 15 Jan 2011 09:34:37 -0800 (PST) Received: from mailgw10.se.ericsson.net (mailgw10.se.ericsson.net [193.180.251.61]) by core3.amsl.com (Postfix) with ESMTP id 4D77D3A6DC7 for ; Sat, 15 Jan 2011 09:34:36 -0800 (PST) X-AuditID: c1b4fb3d-b7b89ae0000036a3-3c-4d31db40790a Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw10.se.ericsson.net (Symantec Mail Security) with SMTP id 02.C4.13987.04BD13D4; Sat, 15 Jan 2011 18:37:05 +0100 (CET) Received: from mail.lmf.ericsson.se (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.2.234.1; Sat, 15 Jan 2011 18:37:04 +0100 Received: from nomadiclab.lmf.ericsson.se (nomadiclab.lmf.ericsson.se [131.160.33.3]) by mail.lmf.ericsson.se (Postfix) with ESMTP id 456A62595 for ; Sat, 15 Jan 2011 19:37:04 +0200 (EET) Received: from nomadiclab.lmf.ericsson.se (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 0B9CD50454 for ; Sat, 15 Jan 2011 19:37:04 +0200 (EET) Received: from Salvatore-Loretos-MacBook-Pro.local (localhost [127.0.0.1]) by nomadiclab.lmf.ericsson.se (Postfix) with ESMTP id 8B44C4FEBC for ; Sat, 15 Jan 2011 19:37:03 +0200 (EET) Message-ID: <4D31DB3E.9040609@ericsson.com> Date: Sat, 15 Jan 2011 18:37:02 +0100 From: Salvatore Loreto User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv:1.9.2.13) Gecko/20101207 Thunderbird/3.1.7 MIME-Version: 1.0 To: sip-overload@ietf.org References: <4D08E3E4.2050002@ericsson.com> <4D2B2341.7090602@ericsson.com> In-Reply-To: <4D2B2341.7090602@ericsson.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP X-Brightmail-Tracker: AAAAAA== Subject: [sip-overload] Consensus on draft-shen-soc-load-control-event-package as wg item X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2011 17:34:38 -0000 Hi there, this call for consensus that has been extended until January 14th is now over. Based on the fact that nobody objected, Volker and I, as chairs, declare consensus on the adoption of the draft-shen-soc-load-control-event-package as wg item (baseline for the third item we have in the SoC charter). So I would ask the authors to submit a new version as wg item, (and of course updating it to take in considerations all the comments that have been sent out). we have experienced a very small numbers of responses/feedback. Once again, we want encourage everyone who cares to progress the wg's related issues to become more active in providing technical feedback as well as on providing opinions on calls. Ciao Sal & Volker -- Salvatore Loreto www.sloreto.com On 1/10/11 4:18 PM, Salvatore Loreto wrote: > Hi there, > > so far we have received just two replies to this call, > both in favor to adopt it. > > To take in consideration the fact that the call was almost in coincidence > with the Christmas vacations, > > we have decided to extend it until this Friday, January 14th. > > > cheers > /Sal > > > On 12/15/10 4:51 PM, Salvatore Loreto wrote: >> Hi folks, >> >> during the last Interim (Interim II) on December 1st, >> Charles Shen presented the draft-shen-soc-load-control-event-package >> and asked about the possibility to adopt it as wg item, >> due to the comments received during the presentation we decided to wait >> for a new version before to check in the mailing list the consensus to >> adopt it. >> >> Charles has posted a new version of the draft >> ( http://www.ietf.org/id/draft-shen-soc-load-control-event-package-02.txt ) >> addressing the comments from the Interim >> (see in the Interim minutes: >> http://trac.tools.ietf.org/wg/soc/trac/attachment/wiki/Interim20101201/notes.txt >> ) >> and also other previous comments received in the mailing list. >> >> It is time to check in the ml the consensus to adopt the >> draft-shen-soc-load-control-event-package as wg item. >> >> So, as chairs Volker and I want to check the consensus to adopt it as >> baseline for the wg item >> addressing the derivable number 3 in the charter: >> >> Aug 2011 - Specification for a SIP load filtering mechaism to IESG for publication as Proposed Standard >> >> >> This consensus call will end on Friday January 7th, 2010. >> >> cheers >> /Sal > _______________________________________________ > sip-overload mailing list > sip-overload@ietf.org > https://www.ietf.org/mailman/listinfo/sip-overload > From charles.newyork@gmail.com Sun Jan 16 20:34:55 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6656A28C0EC for ; Sun, 16 Jan 2011 20:34:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.977 X-Spam-Level: X-Spam-Status: No, score=-2.977 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qDryIm6IpiZw for ; Sun, 16 Jan 2011 20:34:54 -0800 (PST) Received: from mail-ey0-f172.google.com (mail-ey0-f172.google.com [209.85.215.172]) by core3.amsl.com (Postfix) with ESMTP id F0BC828C0E3 for ; Sun, 16 Jan 2011 20:34:53 -0800 (PST) Received: by eyd10 with SMTP id 10so2460529eyd.31 for ; Sun, 16 Jan 2011 20:37:26 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=2fnW/tAAFuE/gA0NKmWdHTfZilIIhx/COmMknH0Rrz4=; b=NhiiXeG1wGnwKkXfmHmVg67wucOUWhDTY/oRr4gmKlUFQ7AkVVAz65SV8gLyxb1hSw ahpC+h4kWu5YzvgT9dXdz4YjQ+2dU1BK7U+off6KTvVqq8t3iRtzmrPHzm3bVf46rH+u RsY6QUOor4wywIopMSml6rSfd2H4rbdGQULBE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type :content-transfer-encoding; b=PaJW7z/lrmgvc+b8QSD2V+2OkGmFeeZQ+re88hSlxaGO5cQ4N183vNpUEByS+64Huk 9s1zWL3+UYhIekNZHdO4qNdlWZfr2WRbncQKDb8njm2WjvuqflvGrD+npZgreojP5lN/ 8NkAtSCzpvPgAlVZBHsvxe9+Hq7Lr5qI8508c= MIME-Version: 1.0 Received: by 10.213.114.82 with SMTP id d18mr2089080ebq.29.1295239046210; Sun, 16 Jan 2011 20:37:26 -0800 (PST) Sender: charles.newyork@gmail.com Received: by 10.213.33.205 with HTTP; Sun, 16 Jan 2011 20:37:26 -0800 (PST) In-Reply-To: <4D31DB3E.9040609@ericsson.com> References: <4D08E3E4.2050002@ericsson.com> <4D2B2341.7090602@ericsson.com> <4D31DB3E.9040609@ericsson.com> Date: Sun, 16 Jan 2011 23:37:26 -0500 X-Google-Sender-Auth: ujrdH9MsW-yZM2fMo8bD2NhYhxE Message-ID: From: Charles Shen To: Salvatore Loreto Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Cc: sip-overload@ietf.org Subject: Re: [sip-overload] Consensus on draft-shen-soc-load-control-event-package as wg item X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 04:34:55 -0000 Thank you Chairs and all, An updated version incorporating the comments from the consensus call has been submitted as draft-ietf-soc-load-control-event-package. Thanks Charles On Sat, Jan 15, 2011 at 12:37 PM, Salvatore Loreto wrote: > Hi there, > > this call for consensus that has been extended until January 14th is now > over. > Based on the fact that nobody objected, > Volker and I, as chairs, declare consensus on the adoption of the > draft-shen-soc-load-control-event-package as wg item > (baseline for the third item we have in the SoC charter). > > So I would ask the authors to submit a new version as wg item, > (and of course updating it to take in considerations all the comments tha= t > have > been sent out). > > > we have experienced a very small numbers of responses/feedback. > Once again, we want encourage everyone who cares to progress the wg's > related issues > to become more active in providing technical feedback as well as on > providing opinions > on calls. > > Ciao > Sal & Volker > > -- > Salvatore Loreto > www.sloreto.com > > > > > > On 1/10/11 4:18 PM, Salvatore Loreto wrote: >> >> Hi there, >> >> so far we have received just two replies to this call, >> both in favor to adopt it. >> >> To take in consideration the fact that the call was almost in coincidenc= e >> with the Christmas vacations, >> >> we have decided to extend it until this Friday, January 14th. >> >> >> cheers >> /Sal >> >> >> On 12/15/10 4:51 PM, Salvatore Loreto wrote: >>> >>> Hi folks, >>> >>> during the last Interim (Interim II) on December 1st, >>> Charles Shen presented the draft-shen-soc-load-control-event-package >>> and asked about the possibility to adopt it as wg item, >>> due to the comments received during the presentation we decided to wait >>> for a new version before to check in the mailing list the consensus to >>> adopt it. >>> >>> Charles has posted a new version of the draft >>> ( http://www.ietf.org/id/draft-shen-soc-load-control-event-package-02.t= xt >>> ) >>> addressing the comments from the Interim >>> (see in the Interim minutes: >>> >>> http://trac.tools.ietf.org/wg/soc/trac/attachment/wiki/Interim20101201/= notes.txt >>> ) >>> and also other previous comments received in the mailing list. >>> >>> It is time to check in the ml the consensus to adopt the >>> draft-shen-soc-load-control-event-package as wg item. >>> >>> So, as chairs Volker and I want to check the consensus to adopt it as >>> baseline for the wg item >>> addressing the derivable number 3 in the charter: >>> >>> =C2=A0 =C2=A0 Aug 2011 - Specification for a SIP load filtering mechais= m to IESG >>> for publication as Proposed Standard >>> >>> >>> This consensus call will end on Friday January 7th, 2010. >>> >>> cheers >>> /Sal >> >> _______________________________________________ >> 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 > From Internet-Drafts@ietf.org Sun Jan 16 23:30:03 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 4066B3A6E84; Sun, 16 Jan 2011 23:30:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.505 X-Spam-Level: X-Spam-Status: No, score=-102.505 tagged_above=-999 required=5 tests=[AWL=0.094, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XYUvKHiAOaj; Sun, 16 Jan 2011 23:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 5D5F03A6DBB; Sun, 16 Jan 2011 23:30:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110117073002.1487.70661.idtracker@localhost> Date: Sun, 16 Jan 2011 23:30:02 -0800 Cc: sip-overload@ietf.org Subject: [sip-overload] I-D Action:draft-ietf-soc-load-control-event-package-00.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jan 2011 07:30:03 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP Overload Control Working Group of the IETF. Title : A Session Initiation Protocol (SIP) Load Control Event Package Author(s) : C. Shen, et al. Filename : draft-ietf-soc-load-control-event-package-00.txt Pages : 32 Date : 2011-01-16 This document defines a load control event package for the Session Initiation Protocol (SIP). It allows SIP servers to distribute user load control information to other SIP servers in the network. The load control can throttle calls based on their source or destination domain, telephone number prefix or for a specific user. The mechanism helps to prevent signaling overload and complements feedback-based SIP overload control efforts. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-soc-load-control-event-package-00.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-soc-load-control-event-package-00.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-16232831.I-D@ietf.org> --NextPart-- From Internet-Drafts@ietf.org Thu Jan 20 09:30:04 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 804BE3A717A; Thu, 20 Jan 2011 09:30:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.57 X-Spam-Level: X-Spam-Status: No, score=-102.57 tagged_above=-999 required=5 tests=[AWL=0.029, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71uF3wXbdBgj; Thu, 20 Jan 2011 09:30:02 -0800 (PST) Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 6D5ED3A7171; Thu, 20 Jan 2011 09:30:02 -0800 (PST) MIME-Version: 1.0 Content-Type: Multipart/Mixed; Boundary="NextPart" From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.10 Message-ID: <20110120173002.21474.56589.idtracker@localhost> Date: Thu, 20 Jan 2011 09:30:02 -0800 Cc: sip-overload@ietf.org Subject: [sip-overload] I-D Action:draft-ietf-soc-overload-control-01.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 17:30:04 -0000 --NextPart A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the SIP Overload Control Working Group of the IETF. Title : Session Initiation Protocol (SIP) Overload Control Author(s) : V. Gurbani, et al. Filename : draft-ietf-soc-overload-control-01.txt Pages : 26 Date : 2011-01-20 Overload occurs in Session Initiation Protocol (SIP) networks when SIP servers have insufficient resources to handle all SIP messages they receive. Even though the SIP protocol provides a limited overload control mechanism through its 503 (Service Unavailable) response code, SIP servers are still vulnerable to overload. This document defines an overload control mechanism for SIP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-soc-overload-control-01.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ Below is the data which will enable a MIME compliant mail reader implementation to automatically retrieve the ASCII version of the Internet-Draft. --NextPart Content-Type: Message/External-body; name="draft-ietf-soc-overload-control-01.txt"; site="ftp.ietf.org"; access-type="anon-ftp"; directory="internet-drafts" Content-Type: text/plain Content-ID: <2011-01-20092458.I-D@ietf.org> --NextPart-- From vkg@bell-labs.com Thu Jan 20 09:48:58 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C3E8328C0EE for ; Thu, 20 Jan 2011 09:48:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.4 X-Spam-Level: X-Spam-Status: No, score=-106.4 tagged_above=-999 required=5 tests=[AWL=0.199, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XA63xymNHOQs for ; Thu, 20 Jan 2011 09:48:57 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by core3.amsl.com (Postfix) with ESMTP id 8590F28C0D9 for ; Thu, 20 Jan 2011 09:48:57 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id p0KHpeCq017206 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 20 Jan 2011 11:51:40 -0600 (CST) Received: from shoonya.ih.lucent.com (Knoppix-135185238233.ih.lucent.com [135.185.238.233]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p0KHpeA2026812 for ; Thu, 20 Jan 2011 11:51:40 -0600 (CST) Message-ID: <4D3876BF.9050009@bell-labs.com> Date: Thu, 20 Jan 2011 11:54:07 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: "sip-overload@ietf.org" Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 Subject: [sip-overload] draft-ietf-soc-overload-control-01 submitted X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 20 Jan 2011 17:48:58 -0000 Folks: Pursuant to our virtual meeting in December-1-2010 [1], an update to draft-ietf-soc-overload-control has been submitted [2]. There are some substantive changes that have been discussed on the mailing list. These are: 1) The need to support algorithm agility (i.e., negotiate different overload control algorithms). This discussion resulted in the addition of the "oc-algo" parameter and is discussed in Sections 4.2 and 5 of the -01 draft. [2] 2) The caveats of sending overload control parameters in a 100- Trying. This discussion is captured in Section 12 of [2]. 3) The relationship of SIP overload control mechanism with other overload control mechanisms. This discussion is captured in Section 13. 4) A new appendix (Appendix B) has been added that tracks the requirements of RFC5390 and how they apply to this draft. 5) Miscellaneous changes to aid in readability. The diff between -00 and -01 is available in [3]. Please take a look at the new revision and provide comments on the mailing list. [1] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00498.html [2] http://www.ietf.org/internet-drafts/draft-ietf-soc-overload-control-01.txt [3] http://tools.ietf.org/rfcdiff?url1=http://www.ietf.org/id/draft-ietf-soc-overload-control-00.txt&url2=http://www.ietf.org/id/draft-ietf-soc-overload-control-01.txt Thank you, - 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/ From antoine.roly@gmail.com Tue Jan 25 00:05:37 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id C1E793A6964 for ; Tue, 25 Jan 2011 00:05:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.599 X-Spam-Level: X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NPAKTF41QDcq for ; Tue, 25 Jan 2011 00:05:36 -0800 (PST) Received: from mail-wy0-f172.google.com (mail-wy0-f172.google.com [74.125.82.172]) by core3.amsl.com (Postfix) with ESMTP id 9A12B3A6A7C for ; Tue, 25 Jan 2011 00:05:36 -0800 (PST) Received: by wyf23 with SMTP id 23so5379096wyf.31 for ; Tue, 25 Jan 2011 00:08:33 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:message-id:date:from:user-agent:mime-version:to :subject:references:in-reply-to:content-type :content-transfer-encoding; bh=8TpWfw8u8j/s0q1cFuI4cm/eNFiqB8kI81V3CdUypYw=; b=AyksRBYWPcjXc2Os2uXgBsvJ2/7cJOfJ9KXTkyNKrqPCRVUNXIXE+Z0XBY34SRZwrv i4KpHeBZhkPljbQjMpiJbZcInurSCQGK9Bl4/RbiMzoQBDiWloicqJ/CJebJPhDIe7hz 2tx+707xhuGSfxDwfeFkbTnVGrBEvyANc2azw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=R1otym5mVW1cxnKPmmjGgBAnvVkcrRxkYSZNmTt9I3M/bXjEdD1jj4uv95rFYcuuss Zwocf1xXyxgUyxmBVMKZHtRKorpUY9bpjlMNJ9K8vCgcmbC4MkUGB9TW2WEV405AwvxB uAJ1swxQxdIjMdc3m7FyGIS9Hoqstk6DFy5Ho= Received: by 10.216.72.201 with SMTP id t51mr3429958wed.6.1295942912748; Tue, 25 Jan 2011 00:08:32 -0800 (PST) Received: from [138.48.32.233] (phoos.info.fundp.ac.be [138.48.32.233]) by mx.google.com with ESMTPS id a50sm5486790wer.42.2011.01.25.00.08.30 (version=SSLv3 cipher=RC4-MD5); Tue, 25 Jan 2011 00:08:31 -0800 (PST) Message-ID: <4D3E84FE.2020407@gmail.com> Date: Tue, 25 Jan 2011 09:08:30 +0100 From: Antoine Roly User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.16) Gecko/20101227 Lightning/1.0b1 Icedove/3.0.11 MIME-Version: 1.0 To: sip-overload@ietf.org References: <4D3876BF.9050009@bell-labs.com> In-Reply-To: <4D3876BF.9050009@bell-labs.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [sip-overload] draft-ietf-soc-overload-control-01 submitted X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 08:05:37 -0000 Hi, There are some small differences between the example in section 3 and the syntax definition in section 14. It could be a good thing to correct them for readability. - In section 14, it is: oc-validity = "oc_validity" [EQUAL delta-ms] but in section 3, in the response ...;oc-validity=500;... Which one is correct? With "-" or "_" ? - In section 14 it is: oc-seq = (1*12DIGIT "." 1*5DIGIT) but in the example it is ;oc-seq=1282321615.781;... IIUC the definition and the example does not match. I think it should be something like : oc-seq = "oc-seq" EQUAL 1*12DIGIT "." 1*5DIGIT Antoine On 20/01/11 18:54, Vijay K. Gurbani wrote: > Folks: Pursuant to our virtual meeting in December-1-2010 [1], > an update to draft-ietf-soc-overload-control has been submitted > [2]. > > There are some substantive changes that have been discussed on > the mailing list. These are: > > 1) The need to support algorithm agility (i.e., negotiate different > overload control algorithms). This discussion resulted in the > addition of the "oc-algo" parameter and is discussed in Sections 4.2 > and 5 of the -01 draft. [2] > > 2) The caveats of sending overload control parameters in a 100- > Trying. This discussion is captured in Section 12 of [2]. > > 3) The relationship of SIP overload control mechanism with other > overload control mechanisms. This discussion is captured in > Section 13. > > 4) A new appendix (Appendix B) has been added that tracks the > requirements of RFC5390 and how they apply to this draft. > > 5) Miscellaneous changes to aid in readability. > > The diff between -00 and -01 is available in [3]. > > Please take a look at the new revision and provide comments on > the mailing list. > > [1] http://www.ietf.org/mail-archive/web/sip-overload/current/msg00498.html > [2] > http://www.ietf.org/internet-drafts/draft-ietf-soc-overload-control-01.txt > [3] > http://tools.ietf.org/rfcdiff?url1=http://www.ietf.org/id/draft-ietf-soc-overload-control-00.txt&url2=http://www.ietf.org/id/draft-ietf-soc-overload-control-01.txt > > > Thank you, > > - vijay From vkg@bell-labs.com Tue Jan 25 06:50:56 2011 Return-Path: X-Original-To: sip-overload@core3.amsl.com Delivered-To: sip-overload@core3.amsl.com Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 31AC23A67EA for ; Tue, 25 Jan 2011 06:50:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.403 X-Spam-Level: X-Spam-Status: No, score=-106.403 tagged_above=-999 required=5 tests=[AWL=0.196, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iZ37DgaK8jbJ for ; Tue, 25 Jan 2011 06:50:55 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by core3.amsl.com (Postfix) with ESMTP id E6E1D3A67E2 for ; Tue, 25 Jan 2011 06:50:54 -0800 (PST) Received: from umail.lucent.com (h135-3-40-63.lucent.com [135.3.40.63]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id p0PErp2j010428 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 25 Jan 2011 08:53:52 -0600 (CST) Received: from shoonya.ih.lucent.com (Knoppix-135185238233.ih.lucent.com [135.185.238.233]) by umail.lucent.com (8.13.8/TPES) with ESMTP id p0PErpIv018002 for ; Tue, 25 Jan 2011 08:53:51 -0600 (CST) Message-ID: <4D3EE495.9000003@bell-labs.com> Date: Tue, 25 Jan 2011 08:56:21 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7 MIME-Version: 1.0 To: sip-overload@ietf.org References: <4D3876BF.9050009@bell-labs.com> <4D3E84FE.2020407@gmail.com> In-Reply-To: <4D3E84FE.2020407@gmail.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Scanned-By: MIMEDefang 2.57 on 135.245.2.33 Subject: Re: [sip-overload] draft-ietf-soc-overload-control-01 submitted X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 25 Jan 2011 14:50:56 -0000 On 01/25/2011 02:08 AM, Antoine Roly wrote: > Hi, > > There are some small differences between the example in section 3 and > the syntax definition in section 14. It could be a good thing to correct > them for readability. Antoine: Thanks for a close read. More inline. > - In section 14, it is: > oc-validity = "oc_validity" [EQUAL delta-ms] > but in section 3, in the response > ...;oc-validity=500;... > > Which one is correct? With "-" or "_" ? Good catch; the one with a "-" is correct. I have modified this in my working copy and the modification will show up in the next revision. > - In section 14 it is: > oc-seq = (1*12DIGIT "." 1*5DIGIT) > but in the example it is > ;oc-seq=1282321615.781;... > > IIUC the definition and the example does not match. > I think it should be something like : > oc-seq = "oc-seq" EQUAL 1*12DIGIT "." 1*5DIGIT Right. I have changed it as such. The "oc-algo" production rule suffered from the same fate; I have fixed that as well. All these changes will show up in the next revision. Thanks again. - 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/