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

From: Charles Shen <[email-masked]>
Date: Wed, 5 Mar 2014 04:15:40 +0800

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 <[email-masked]>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 <[email-masked]>
> Date: Mon, Feb 17, 2014 at 11:14 AM
> Subject: Re: [dispatch] draft-shen-soc-avalanche-restart-overload
> To: Charles Shen <[email-masked]>
> Cc: "Cullen Jennings (fluffy)" <[email-masked]>, DISPATCH <
> [email-masked]>
>
>
> 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 <[email-masked]>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) <
>> [email-masked]> 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 <[email-masked]>
>>> 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) <
>>> [email-masked]> 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 <[email-masked]>
>>> 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
>>> > > [email-masked]
>>> > > https://www.ietf.org/mailman/listinfo/dispatch
>>> >
>>> >
>>>
>>
>> _______________________________________________
>> dispatch mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dispatch
>>
>>
>
>

---

From: [email-masked] (Dale R. Worley)
Date: Fri, 7 Mar 2014 13:13:45 -0500 (EST)

> From: Charles Shen <[email-masked]>
> 
> > [ 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: [email-masked] (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