Re: [sip-overload] [dispatch] draft-shen-soc-avalanche-restart-overload

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 <charles@cs.columbia.edu>wrote:

> 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 <rlb@ipv.sx>
> Date: Mon, Feb 17, 2014 at 11:14 AM
> Subject: Re: [dispatch] draft-shen-soc-avalanche-restart-overload
> To: Charles Shen <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 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 <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 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 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> 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’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 <charles@cs.columbia.edu>
>>> 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-overload/
>>> > > 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 may
>>> > >    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 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
>>> 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=draft-shen-soc-avalanche-restart-overload&as_sitesearch=www.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
>>
>>
>
>