[sip-overload] Fwd: draft-shen-soc-avalanche-restart-overload

[Charles Shen <[e-mail]>]

Thank you Paul, I am forwarding it to Dispatch.

Charles

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


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

On 6/5/2011 11:25 PM, Charles Shen wrote:
>
> 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
> <[e-mail]>  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 [e-mail]  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
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sip-overload
>>
>
>
>
> Thanks
>
> Charles
> _______________________________________________
> sip-overload mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sip-overload

_______________________________________________
sip-overload mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/sip-overload