From nobody Mon Feb 17 08:38:04 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 67C191A04D8 for ; Mon, 17 Feb 2014 08:38:02 -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 1EU9Wk0IR2Ae for ; Mon, 17 Feb 2014 08:37:59 -0800 (PST) Received: from mail-oa0-x236.google.com (mail-oa0-x236.google.com [IPv6:2607:f8b0:4003:c02::236]) by ietfa.amsl.com (Postfix) with ESMTP id 5229B1A0228 for ; Mon, 17 Feb 2014 08:37:59 -0800 (PST) Received: by mail-oa0-f54.google.com with SMTP id i4so17869804oah.41 for ; Mon, 17 Feb 2014 08:37:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:from:date:message-id:subject:to:cc:content-type; bh=pfv7CBUpU44kdpHEmaWfb+bLJhdsc2qnTWl9AMLO/Kc=; b=qqDGbIJnxN8V0/Dg9lyzTAOh4asP0IbZ22EnwMD0RcMdV9g2AUDhYA+keIHiQieqZg nQfxJ9ng+K+bwgCIP+Eogdd+N3w6kKAPv1libLgsvB4B5GKUDyfsojjSIPfQp7d6KyrS gENWJ03l7NdUVddlgVTWOpuuSLFdLSRA8BZas3iwHvS41UDljHxOmukfqz2/4H31J8Gd Px+3FHcyTvK2XkHP/k36LAdGJpDG8hGOA5fDZIiz7GiC7C0CgjoLYfkh1mV6WAY/yVu7 eyceieI5DSJNf4frSOVmbc365RUYD1y4ULDHXyThetY2YJ3ctOD+uOtxA3kEQrFuur1G YpDQ== X-Received: by 10.182.33.73 with SMTP id p9mr21469727obi.37.1392655076622; Mon, 17 Feb 2014 08:37:56 -0800 (PST) MIME-Version: 1.0 Sender: charles.newyork@gmail.com Received: by 10.182.55.106 with HTTP; Mon, 17 Feb 2014 08:37:36 -0800 (PST) From: Charles Shen Date: Mon, 17 Feb 2014 11:37:36 -0500 X-Google-Sender-Auth: EkyUEGTS1a2JN6d9C3VGIn3p38A Message-ID: To: "sip-overload@ietf.org" Content-Type: multipart/alternative; boundary=047d7b5d58b423059804f29cc778 Archived-At: http://mailarchive.ietf.org/arch/msg/sip-overload/uzRy9MSGg5fy_iBklPiiApy1IsU Cc: Cullen Jennings Subject: [sip-overload] Fwd: [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: Mon, 17 Feb 2014 16:38:02 -0000 --047d7b5d58b423059804f29cc778 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 wro= te: > 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 ar= e >> not 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 >> 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> 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=99= m 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-overloa= d/ >> > > A Mechanism for Session Initiation Protocol (SIP) Avalanche Restart >> Overload Control >> > > >> > > Abstract: >> > > When a large number of clients register with a SIP registrar serv= er >> > > at approximately the same time, the server may become overloaded. >> > > Near-simultaneous floods of SIP SUBSCRIBE and PUBLISH requests ma= y >> > > have similar effects. Such request avalanches can occur, for >> > > example, after a power failure and recovery in a metropolitan are= a. >> > > 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 to >> its >> > > clients through a new Restart-Timer header in normal response >> > > messages. Once an avalanche restart actually occurs, the clients >> > > 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 th= em >> > > 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-rest= art-overload&as_sitesearch=3Dwww.ietf.org%2Fmail-archive%2Fweb%2F >> > > >> > > I am looking for your kind opinion on what should be the appropriate >> 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 > > --047d7b5d58b423059804f29cc778 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Dear all,=C2=A0

I am writing about the = draft=C2=A0

A M= echanism for Session Initiation Protocol (SIP) Avalanche Restart Overload C= ontrol

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 t= he charter could be read to include this document. =C2=A0We 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 <<= a href=3D"mailto:charles@cs.columbia.edu" target=3D"_blank">charles@cs.colu= mbia.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



--047d7b5d58b423059804f29cc778--