From nobody Mon Mar 3 04:18:05 2014 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97D3F1A00A6; Mon, 3 Mar 2014 04:18:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B3f5qNnPKVqC; Mon, 3 Mar 2014 04:18:01 -0800 (PST) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E93D21A008D; Mon, 3 Mar 2014 04:18:00 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 5.0.2 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20140303121800.25413.69688.idtracker@ietfa.amsl.com> Date: Mon, 03 Mar 2014 04:18:00 -0800 Archived-At: http://mailarchive.ietf.org/arch/msg/sip-overload/m47Mcpfg4JMYBF9fAQjCK7cDLbw Cc: sip-overload@ietf.org Subject: [sip-overload] I-D Action: draft-ietf-soc-overload-control-15.txt X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.15 List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 12:18:02 -0000 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 Authors : Vijay K. Gurbani Volker Hilt Henning Schulzrinne Filename : draft-ietf-soc-overload-control-15.txt Pages : 37 Date : 2014-03-03 Abstract: 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 the behaviour of SIP servers involved in overload control, and in addition, it specifies a loss-based overload scheme for SIP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-soc-overload-control/ There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-soc-overload-control-15 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=draft-ietf-soc-overload-control-15 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Mar 3 04:21:12 2014 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 776AB1A00AB for ; Mon, 3 Mar 2014 04:21:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.2 X-Spam-Level: X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_HI=-5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fIGAzAY_xpQH for ; Mon, 3 Mar 2014 04:20:59 -0800 (PST) Received: from ihemail1.lucent.com (ihemail1.lucent.com [135.245.0.33]) by ietfa.amsl.com (Postfix) with ESMTP id CDE711A00A8 for ; Mon, 3 Mar 2014 04:20:59 -0800 (PST) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail1.lucent.com (8.13.8/IER-o) with ESMTP id s23CKutJ014575 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Mon, 3 Mar 2014 06:20:56 -0600 (CST) Received: from umail.lucent.com (umail.ndc.lucent.com [135.3.40.61]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id s23CKuZ2017224 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 3 Mar 2014 06:20:56 -0600 Received: from shoonya.ih.lucent.com (vkg.lra.lucent.com [135.244.36.22]) by umail.lucent.com (8.13.8/TPES) with ESMTP id s23CKtTZ022208 for ; Mon, 3 Mar 2014 06:20:56 -0600 (CST) Message-ID: <531473F2.6010202@bell-labs.com> Date: Mon, 03 Mar 2014 06:22:10 -0600 From: "Vijay K. Gurbani" Organization: Bell Laboratories, Alcatel-Lucent User-Agent: Mozilla/5.0 (X11; Linux i686; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 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.64 on 135.3.39.9 Archived-At: http://mailarchive.ietf.org/arch/msg/sip-overload/M4DeDyvIEzW78E0lY82FU75EDVg Subject: [sip-overload] draft-ietf-soc-overload-control-15 released X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Mar 2014 12:21:08 -0000 Folks: I have released draft-ietf-soc-overload-control-15. Please see http://tools.ietf.org/html/draft-ietf-soc-overload-control-15 This release includes all the comments from IESG review. There are no pending comments to be resolved. Thanks, - vijay -- Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent 1960 Lucent Lane, Rm. 9C-533, Naperville, Illinois 60563 (USA) Email: vkg@{bell-labs.com,acm.org} / vijay.gurbani@alcatel-lucent.com Web: http://ect.bell-labs.com/who/vkg/ | Calendar: http://goo.gl/x3Ogq From nobody Tue Mar 4 12:16:09 2014 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 553781A0295 for ; Tue, 4 Mar 2014 12:16:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.277 X-Spam-Level: X-Spam-Status: No, score=-1.277 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FM_FORGED_GMAIL=0.622, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ITY4xL-spbo8 for ; Tue, 4 Mar 2014 12:16:04 -0800 (PST) Received: from mail-ob0-x22c.google.com (mail-ob0-x22c.google.com [IPv6:2607:f8b0:4003:c01::22c]) by ietfa.amsl.com (Postfix) with ESMTP id 9CC711A01C1 for ; Tue, 4 Mar 2014 12:16:04 -0800 (PST) Received: by mail-ob0-f172.google.com with SMTP id wm4so36912obc.31 for ; Tue, 04 Mar 2014 12:16:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc:content-type; bh=3Um2tDtrkIa5eY3PrjhwCAgJo/aBIVdHxwNLNaNilWk=; b=hptKskhTGS+/6OVPVebV2lzceM7x1KaJlB8MNb6+Vi4Gaq3CTdUSEQkaAUM5F9XjNt VuLuTkXD4eMb+yEn0k+/V9dWW32lVf6k0CbiNE/nUm5X1fcSZKdeuJAwuZyQynEq+1wJ gCJYqTYJBySdCBsimb13C4SqusOgX9SF7EdPswjDO5vrHGOiULF11UURcEtj5jB9BVkf chgI28oRwHMZru79vktmnxcdDuvYUTe0vJQ0v2S1OTXxwhxUbzKesME/9e7KWKGQZ7QZ tVu2gzufyiOJnneG2SEoMTMAooqWySL3CrTps8ZsXrwvN2GeqPlVP0nITAHdDOYwSKVu 9DJg== X-Received: by 10.60.94.52 with SMTP id cz20mr1217091oeb.43.1393964161143; Tue, 04 Mar 2014 12:16:01 -0800 (PST) MIME-Version: 1.0 Sender: charles.newyork@gmail.com Received: by 10.182.55.106 with HTTP; Tue, 4 Mar 2014 12:15:40 -0800 (PST) In-Reply-To: References: From: Charles Shen Date: Wed, 5 Mar 2014 04:15:40 +0800 X-Google-Sender-Auth: YrvdEIFwYDHwpZiP2AydwOUelh0 Message-ID: To: "sip-overload@ietf.org" Content-Type: multipart/alternative; boundary=089e0122991aa7a62b04f3cd9214 Archived-At: http://mailarchive.ietf.org/arch/msg/sip-overload/nLfmxlo8MmsJ6gUGkIQOKNNDDtc Cc: Cullen Jennings , Arata Koike , "Dale R. Worley" , charles@cs.columbia.edu, hgs@cs.columbia.edu Subject: Re: [sip-overload] [dispatch] draft-shen-soc-avalanche-restart-overload X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Mar 2014 20:16:07 -0000 --089e0122991aa7a62b04f3cd9214 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Dear all, I'd like to re-send the message below, and would appreciate very much your opinions! Charles On Tue, Feb 18, 2014 at 12:37 AM, Charles Shen wro= te: > Dear all, > > I am writing about the draft > > A Mechanism for Session Initiation Protocol (SIP) Avalanche Restart > Overload Control > http://datatracker.ietf.org/doc/draft-shen-soc-avalanche-restart-overload= / > > as a result of a discussion on the DISPATCH list suggesting that this > draft may be in-scope of the SOC charter and could benefit from WG review= , > I would like to solicitate your kind opinion on whether the WG agrees on > that and is willing to take on it as a possible WG deliverable. > > Some background discussion below for your reference. Thank you very much! > > Charles > > > ---------- Forwarded message ---------- > From: Richard Barnes > Date: Mon, Feb 17, 2014 at 11:14 AM > Subject: Re: [dispatch] draft-shen-soc-avalanche-restart-overload > To: Charles Shen > Cc: "Cullen Jennings (fluffy)" , DISPATCH < > dispatch@ietf.org> > > > I agree that the charter could be read to include this document. We > should confirm that the WG agrees, and is willing to take on the document= . > > Charles, could you please start a thread on the SOC list? > > Thanks, > --Richard > > > On Mon, Feb 17, 2014 at 11:05 AM, Charles Shen w= rote: > >> If that is the case, I at least don't see the current charter excluding >> the scope of this work from the sentence "The objective of the working >> group is to develop mechanisms for SIP overload control. The problem >> domain of SIP overload control can be split into overload control >> between a user agent and a SIP server and overload control between SIP >> servers.", as this work fits nicely into the "overload control between a >> user agent and a SIP server" problem domain. >> >> >> >> On Mon, Feb 17, 2014 at 12:48 AM, Cullen Jennings (fluffy) < >> fluffy@cisco.com> wrote: >> >>> >>> So the terminology for this is always a bit confusing. The Milestones >>> are not typically considered part of the charter but if the WG wanted t= o do >>> this work, they could add a Milestone without changing a charter. The >>> question is does the Charter text cover this type of work. >>> >>> >>> On Feb 17, 2014, at 3:09 AM, Charles Shen >>> wrote: >>> >>> > Thanks Cullen for your comments, >>> > >>> > According to my understanding, the current charter description >>> > >>> > http://datatracker.ietf.org/wg/soc/charter/ >>> > >>> > does not seem to cover the goal of advancing this draft into a workin= g >>> group deliverable. Please correct me if I were wrong. >>> > >>> > Thanks >>> > >>> > Charles >>> > >>> > >>> > >>> > >>> > On Sat, Feb 15, 2014 at 6:35 PM, Cullen Jennings (fluffy) < >>> fluffy@cisco.com> wrote: >>> > >>> > This seems like a draft that could benefit from review in a WG. Can >>> someone fill in a bit of the background of this draft in SOC. I=E2=80= =99m not >>> seeing why the SOC charter would need to be changed to do this work. >>> > >>> > >>> > >>> > On Feb 11, 2014, at 1:35 PM, Charles Shen >>> wrote: >>> > >>> > > Dear all: >>> > > >>> > > As advised by Richard Barnes, I am writing to seek opinion from you >>> about this draft: >>> > > >>> > > >>> http://datatracker.ietf.org/doc/draft-shen-soc-avalanche-restart-overlo= ad/ >>> > > A Mechanism for Session Initiation Protocol (SIP) Avalanche Restart >>> Overload Control >>> > > >>> > > Abstract: >>> > > When a large number of clients register with a SIP registrar >>> server >>> > > at approximately the same time, the server may become overloaded= . >>> > > Near-simultaneous floods of SIP SUBSCRIBE and PUBLISH requests m= ay >>> > > have similar effects. Such request avalanches can occur, for >>> > > example, after a power failure and recovery in a metropolitan >>> area. >>> > > This document describes how to avoid such overload situations. >>> Under >>> > > this mechanism, a server estimates an avalanche restart backoff >>> > > interval during its normal operation and conveys this interval t= o >>> its >>> > > clients through a new Restart-Timer header in normal response >>> > > messages. Once an avalanche restart actually occurs, the client= s >>> > > perform backoff based on the previously received Restart-Timer >>> header >>> > > value before sending out the first request attempt. Thus, the >>> > > mechanism spreads all the initial client requests and prevents >>> them >>> > > from overloading the server. >>> > > >>> > > The draft has been presented and discussed in IETF meetings since >>> 2010, and generated interest among the community: >>> > > >>> > > >>> https://encrypted.google.com/search?as_q=3Ddraft-shen-soc-avalanche-res= tart-overload&as_sitesearch=3Dwww.ietf.org%2Fmail-archive%2Fweb%2F >>> > > >>> > > I am looking for your kind opinion on what should be the appropriat= e >>> next step for this document: >>> > > >>> > > -- Should this draft be dispatched to SOC (and their charter >>> amended)? >>> > > -- Should this draft be processed as AD-sponsored? >>> > > -- Should this draft be killed (if it is harmful)? >>> > > >>> > > Thank you very much. >>> > > >>> > > Charles >>> > > >>> > > >>> > > >>> > > _______________________________________________ >>> > > dispatch mailing list >>> > > dispatch@ietf.org >>> > > https://www.ietf.org/mailman/listinfo/dispatch >>> > >>> > >>> >> >> _______________________________________________ >> dispatch mailing list >> dispatch@ietf.org >> https://www.ietf.org/mailman/listinfo/dispatch >> >> > > --089e0122991aa7a62b04f3cd9214 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all, I'd like to re-send the message below, and w= ould appreciate very much your opinions!

Charles


On Tue, Feb 18, 2= 014 at 12:37 AM, Charles Shen <charles@cs.columbia.edu> wrote:
Dear all,=C2=A0

I am writing about the draft=C2=A0

A Mechanism for Session Initiat= ion Protocol (SIP) Avalanche Restart Overload Control

as a result of a discussion on the DISPATCH list = suggesting that this draft may be in-scope of the SOC charter and could ben= efit from WG review, I would like to solicitate your kind opinion on whethe= r the WG agrees on that and is willing to take on it as a possible WG deliv= erable.=C2=A0

Some background discussion below for your reference. Th= ank you very much!

Charles

=

---------- Forwarded message ----------=
From: Richard Barnes &l= t;rlb@ipv.sx>
Date: Mon, Feb 17, 2014 at 11:14 AM
Subject: = Re: [dispatch] draft-shen-soc-avalanche-restart-overload
To: Charles She= n <charles@= cs.columbia.edu>
Cc: "Cullen Jennings (fluffy)" <fluffy@cisco.com>, DISPATCH <dispatch@ietf.org>

I agree that the charter could be read to include this doc= ument. =C2=A0We should confirm that the WG agrees, and is willing to take o= n the document.

Charles, could you please start a thread on the SOC list?

Thanks,
--Richard


On Mon, Feb 17, 201= 4 at 11:05 AM, Charles Shen <charles@cs.columbia.edu> = wrote:
If that is the case, I at least don't see the current charter = excluding the scope of this work from the sentence "The objective of t= he working group is to develop mechanisms for SIP=C2=A0overload control. The problem domain= of SIP overload control can be=C2=A0split into overload control between a user agent and a S= IP server and=C2=A0overload control between SIP servers.", as this work fits nicely into= the "overload control between a user agent and a SIP server" pro= blem domain.=C2=A0



On Mon, Feb 1= 7, 2014 at 12:48 AM, Cullen Jennings (fluffy) <fluffy@cisco.com> wrote:

So the terminology for this is always a bit confusing. The Milestones are n= ot typically considered part of the charter but if the WG wanted to do this= work, they could add a Milestone without changing a charter. The question = is does the Charter text cover this type of work.


On Feb 17, 2014, at 3:09 AM, Charles Shen <charles@cs.columbia.edu> wrote:

> Thanks Cullen for your comments,
>
> According to my understanding, the current charter description
>
> http://datatracker.ietf.org/wg/soc/charter/
>
> does not seem to cover the goal of advancing this draft into a working= group deliverable. Please correct me if I were wrong.
>
> Thanks
>
> Charles
>
>
>
>
> On Sat, Feb 15, 2014 at 6:35 PM, Cullen Jennings (fluffy) <fluffy@cisco.com> wro= te:
>
> This seems like a draft that could benefit from review in a WG. Can so= meone fill in a bit of the background of this draft in SOC. I=E2=80=99m not= seeing why the SOC charter would need to be changed to do this work.
>
>
>
> On Feb 11, 2014, at 1:35 PM, Charles Shen <charles@cs.columbia.edu> wrote:=
>
> > Dear all:
> >
> > As advised by Richard Barnes, I am writing to seek opinion from y= ou about this draft:
> >
> > http://datatracker.ietf.org/doc/dra= ft-shen-soc-avalanche-restart-overload/
> > A Mechanism for Session Initiation Protocol (SIP) Avalanche Resta= rt Overload Control
> >
> > Abstract:
> > =C2=A0 =C2=A0When a large number of clients register with a SIP r= egistrar server
> > =C2=A0 =C2=A0at approximately the same time, the server may becom= e overloaded.
> > =C2=A0 =C2=A0Near-simultaneous floods of SIP SUBSCRIBE and PUBLIS= H requests may
> > =C2=A0 =C2=A0have similar effects. =C2=A0Such request avalanches = can occur, for
> > =C2=A0 =C2=A0example, after a power failure and recovery in a met= ropolitan area.
> > =C2=A0 =C2=A0This document describes how to avoid such overload s= ituations. =C2=A0Under
> > =C2=A0 =C2=A0this mechanism, a server estimates an avalanche rest= art backoff
> > =C2=A0 =C2=A0interval during its normal operation and conveys thi= s interval to its
> > =C2=A0 =C2=A0clients through a new Restart-Timer header in normal= response
> > =C2=A0 =C2=A0messages. =C2=A0Once an avalanche restart actually o= ccurs, the clients
> > =C2=A0 =C2=A0perform backoff based on the previously received Res= tart-Timer header
> > =C2=A0 =C2=A0value before sending out the first request attempt. = =C2=A0Thus, the
> > =C2=A0 =C2=A0mechanism spreads all the initial client requests an= d prevents them
> > =C2=A0 =C2=A0from overloading the server.
> >
> > The draft has been presented and discussed in IETF meetings since= 2010, and generated interest among the community:
> >
> > https://encrypted.google.com/search?as_q=3D= draft-shen-soc-avalanche-restart-overload&as_sitesearch=3Dwww.ietf.org%= 2Fmail-archive%2Fweb%2F
> >
> > I am looking for your kind opinion on what should be the appropri= ate next step for this document:
> >
> > -- Should this draft be dispatched to SOC (and their charter amen= ded)?
> > -- Should this draft be processed as AD-sponsored?
> > -- Should this draft be killed (if it is harmful)?
> >
> > Thank you very much.
> >
> > Charles
> >
> >
> >
> > _______________________________________________
> > dispatch mailing list
> > dispatch@i= etf.org
> > https://www.ietf.org/mailman/listinfo/dispatch
>
>

_______________________________________________
dispatch mailing list
dispatch@ietf.org
https://www.ietf.org/mailman/listinfo/dispatch




--089e0122991aa7a62b04f3cd9214-- From nobody Fri Mar 7 10:14:13 2014 Return-Path: X-Original-To: sip-overload@ietfa.amsl.com Delivered-To: sip-overload@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8A9E21A00A2 for ; Fri, 7 Mar 2014 10:14:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LnbGPUKtP2IG for ; Fri, 7 Mar 2014 10:14:08 -0800 (PST) Received: from TheWorld.com (pcls5.std.com [192.74.137.145]) by ietfa.amsl.com (Postfix) with ESMTP id 30B1C1A008B for ; Fri, 7 Mar 2014 10:14:07 -0800 (PST) Received: from shell.TheWorld.com (svani@shell01.theworld.com [192.74.137.71]) by TheWorld.com (8.14.5/8.14.5) with ESMTP id s27IEww9010088; Fri, 7 Mar 2014 13:15:01 -0500 Received: from shell01.TheWorld.com (localhost.theworld.com [127.0.0.1]) by shell.TheWorld.com (8.13.6/8.12.8) with ESMTP id s27IDjS06445230; Fri, 7 Mar 2014 13:13:45 -0500 (EST) Received: (from worley@localhost) by shell01.TheWorld.com (8.13.6/8.13.6/Submit) id s27IDjOM6453480; Fri, 7 Mar 2014 13:13:45 -0500 (EST) Date: Fri, 7 Mar 2014 13:13:45 -0500 (EST) Message-Id: <201403071813.s27IDjOM6453480@shell01.TheWorld.com> From: worley@ariadne.com (Dale R. Worley) Sender: worley@ariadne.com (Dale R. Worley) To: Charles Shen In-reply-to: (charles@cs.columbia.edu) References: Archived-At: http://mailarchive.ietf.org/arch/msg/sip-overload/X3oPIpUYUK-cwYUJRQFDFDrYG9Y Cc: sip-overload@ietf.org Subject: Re: [sip-overload] [dispatch] draft-shen-soc-avalanche-restart-overload-07 X-BeenThere: sip-overload@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: SIP Overload List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Mar 2014 18:14:11 -0000 > From: Charles Shen > > Dear all, I'd like to re-send the message below, and would appreciate very > much your opinions! > > Charles > > > On Tue, Feb 18, 2014 at 12:37 AM, Charles Shen wrote: > > > Dear all, > > > > I am writing about the draft > > > > A Mechanism for Session Initiation Protocol (SIP) Avalanche Restart > > Overload Control > > [ http://tools.ietf.org/id/draft-shen-soc-avalanche-restart-overload-07.txt ] [...] It is generally helpful to specify the particular version number when talking about a draft, because inevitably your e-mail will be read months later, and it will be unclear which version you are referring to. I've edited the Subject line and the URL to give the version number in question. To resend comments which I sent to Dispatch (which wasn't the place to discuss them): > From: worley@ariadne.com (Dale R. Worley) > > I do believe that this draft should be advanced, as this sort of > registration storm causes a problem in practice, though I don't have > any opinion on what would be the proper track for it. > > It would be interesting to know if there have been any large-scale > implementations, and what the results have been in practice. > > In regard to the draft itself, I think a few tweaks would improve it. > > - Clarify that the Restart-Timer value is associated with the URI that > is being registered (for REGISTER) or the URI/event that is being > subscribed to (for SUBSCRIBE and PUBLISH). > > - You may want a more clever way of handling multiple Restart-Timer > values received from different servers during a boot sequence that > sends requests to several servers (which may be incompletely > coordinated with each other). E.g., if the registration server has > a Restart-Timer of 300 and the voicemail server also has a > Restart-Timer of 300, it seems that the UA could safely wait > rand(0:300) then register and subscribe. If the VM server has a zero > restart timer, the UA probably wants to wait until the registration > is done anyway before subscribing to VM. But if the VM server has a > Restart-Timer of 600, there probably should be an additional delay > between registration and subscribing. > > The trouble is that rand(0:300)+rand(0:300) doesn't have the same > distribution as rand(0:600), so you may not want to say "Wait a random > fraction of the difference between the two Restart-Timers." > > Perhaps a workable algorithm is "Choose a random real number > uniformaly between zero and one. Each bootup operation may be > executed no earlier than (the random number) * (the specified > Restart-Timer for that operation) seconds after power-up." That > causes each server to see the time-distribution of requests that it > expects. ... and also insures that the UA will access a server with a Restart-Timer of 300 before it accesses a server with a Restart-Timer of 600, which is probably what the adminstrators of the servers desire to happen. > - The text suggests that the stored Restart-Timer value expires when > the registration expires. ("The validity duration of the > Restart-Timer header is the same as that of the corresponding > registration operation.") That doesn't work at all, because the > power failure may exceed the length of all the registrations. The > Restart-Timer value has to be saved until another value is > received for that same target. > > - You may want to allow/require the UA to place an upper limit on the > Restart-Timer value. At the least, Restart-Timer should not exceed > the maximum registration/subscription duration the UA requests and > the server provides. ... because the server is already prepared to handle registrations that are as frequent as that interval. > - I expect that you want to require that if a REGISTER/SUBSCRIBE > response is received that does not contain Restart-Timer, then the > saved Restart-Timer value is set to zero. That causes the > expected behavior when a server that supports Restart-Timer is > replaced with one that does not. > > Dale