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

From: Charles Shen <[email-masked]>
Date: Mon, 10 Feb 2014 21:35:54 -0500

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

---

From: [email-masked] (Dale R. Worley)
Date: Wed, 12 Feb 2014 15:55:15 -0500 (EST)

> From: Charles Shen <[email-masked]>

> -- Should this draft be killed (if it is harmful)?

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.

- The text suggests that the 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.

- I expect that you want to require that if a REGISTER 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 registrar that supports Restart-Timer is replaced
  with one that does not.

Dale

---

From: Charles Shen <[email-masked]>
Date: Fri, 14 Feb 2014 17:14:09 -0500

Dear Dale,

Thank you very much for your review and great comments. I agree with all of
the points you raised and will incorporate them into the next revision.

Thanks again.

Charles

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Sat, 15 Feb 2014 23:35:38 +0000

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:
> 
> A Mechanism for Session Initiation Protocol (SIP) Avalanche Restart Overload Control
> 
> Abstract:
> The draft has been presented and discussed in IETF meetings since 2010, and generated interest among the community:
> 
> I am looking for your kind opinion on what should be the appropriate next step for this document:
> 
> _______________________________________________
> dispatch mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dispatch

---

From: Charles Shen <[email-masked]>
Date: Sun, 16 Feb 2014 14:09:28 -0500

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.
>
>
>
> > The draft has been presented and discussed in IETF meetings since 2010,
> and generated interest among the community:
> >
> >

---

From: "Cullen Jennings (fluffy)" <[email-masked]>
Date: Mon, 17 Feb 2014 05:48:57 +0000

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:

> 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:
>

---

From: Charles Shen <[email-masked]>
Date: Mon, 17 Feb 2014 11:05:32 -0500

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.
>
>
> > > The draft has been presented and discussed in IETF meetings since
> 2010, and generated interest among the community:
> > >
> > >

---

From: Richard Barnes <[email-masked]>
Date: Mon, 17 Feb 2014 11:14:30 -0500

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:
>
>>
>> someone fill in a bit of the background of this draft in SOC. I'm not