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

From: Charles Shen <[email-masked]>
Date: Sun, 5 Jun 2011 23:25:10 -0400

Hi all,

The IETF80 minutes below show mixed feedbacks about the avalanche
restart draft. I would therefore like to follow up discussing about
the comments raised.

1. There is an explicite mention of the "Outbound proxy RFC" which
"has timer to solve the issue". I assumed that means RFC5626 and took
a second look at it. One section I found could be most relevant is
Section 4.5 Flow Recovery, where it says each new registration "is
done in much the same way as forming a brand new flow as described in
Section 4.2; however, if there is a failure in forming this flow, the
UA needs to wait a certain amount of time before retrying to form a
flow to this particular next hop". The subsequent paragraphs in that
section define a way to compute the backoff time.

Back to Section 4.2, I did not find discussion about whether and how
the *initial registation* should be randomized. If that is the case,
the solution is different from what is presented in this avalanche
restart draft. The mechanism in this draft seeks to avoid the initial
storm of registration or similar message causing avalanche restart.
And if this effort is successful, subsequent backoff might not be
necessary, although I think inclusion of RFC5626 backoff timers would
certainly increase robustness.

2. There is also a suggestion to discuss this in dispatch. Since
"avalanche restart" is a problem described in the overload requirement
RFC 5390, maybe AD and/or chairs can advice whether we should cross
post this discussion or keep it in either one list for now.

Thanks

Charles

On Thu, Apr 28, 2011 at 1:54 PM, Salvatore Loreto
<[email-masked]> wrote:
> Hi there,
>
> below the notes from the SoC session during the IETF80 meeting in Prague.
> (I have already uploaded this initial version to ietf proceeding site)
>
> Please review them and submit any correction to the chairs by May 11.
> The chairs have to send the notes [email-masked]  by May18th.
>
> (many thanks to Partha for taking notes during the meeting)
>
> cheers
> /Sal
>
> --
> Salvatore Loreto
> www.sloreto.com
>

snipped ...

>
>
> Avalanche restart overload  (Presenter: Arate Koike)
> ------------------------
> Hadriel: Let register has restart-timer instead of subscribe as it is
> register avalanche. SUBSCRIBE may not go to Registrar.
> Partha: SUBSCRIBE message itself may overload
>
> Open discussion:
> Hadriel: Mention this problem may not be solved by the proposed mechanism.
> Partha: The problem solved by Avalanche is in the boot up time only.
> Hadriel, Robert: Outbound proxy RFC has timer to solve the issue and it is
> not generic
> Partha: Agreed, It will not solve all the problem
> Robert: Discuss in dispatch
>
> _______________________________________________
> sip-overload mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sip-overload
>

Thanks

Charles

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 06 Jun 2011 08:48:49 -0400

Charles,

While this problem certainly falls into the general category of sip 
overload control, ISTM that it has a substantially different 
constituency than has been involved in the other overload control work. 
(Much of the impact is on individual UAs, which have not been of 
significant concern in the other work.) So I do think it would be good 
to take initial discussion into a forum that will get the attention of 
affected parties.

Something that proposes to change the behavior of UAs when they register 
will almost certainly have to be dealt with in sipcore eventually. But 
while initially scoping the problem, dispatch seems the appropriate 
place to me.

	Thanks,
	Paul

---

From: Charles Shen <[email-masked]>
Date: Tue, 7 Jun 2011 18:15:27 -0400

Thank you Paul, I am forwarding it to Dispatch.

Charles

---------- Forwarded message ----------
From: Paul Kyzivat <[email-masked]>
Date: Mon, Jun 6, 2011 at 8:48 AM
Subject: Re: [sip-overload] draft-shen-soc-avalanche-restart-overload
To: [email-masked]

Charles,

While this problem certainly falls into the general category of sip
overload control, ISTM that it has a substantially different
constituency than has been involved in the other overload control
work. (Much of the impact is on individual UAs, which have not been of
significant concern in the other work.) So I do think it would be good
to take initial discussion into a forum that will get the attention of
affected parties.

Something that proposes to change the behavior of UAs when they
register will almost certainly have to be dealt with in sipcore
eventually. But while initially scoping the problem, dispatch seems
the appropriate place to me.

       Thanks,
       Paul