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

[[e-mail] (Dale R. Worley)]

> From: Charles Shen <[e-mail]>

> 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)?

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