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

Paul Kyzivat <pkyzivat@cisco.com> Mon, 06 June 2011 12:49 UTC

Return-Path: <pkyzivat@cisco.com>
X-Original-To: sip-overload@ietfa.amsl.com
Delivered-To: sip-overload@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BC5D311E8138 for <sip-overload@ietfa.amsl.com>; Mon, 6 Jun 2011 05:49:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6vPxME7Wb9yw for <sip-overload@ietfa.amsl.com>; Mon, 6 Jun 2011 05:49:06 -0700 (PDT)
Received: from sj-iport-6.cisco.com (sj-iport-6.cisco.com [171.71.176.117]) by ietfa.amsl.com (Postfix) with ESMTP id 7402711E813A for <sip-overload@ietf.org>; Mon, 6 Jun 2011 05:49:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=3993; q=dns/txt; s=iport; t=1307364546; x=1308574146; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=Sc/BJW9lpgppfEwvFzeVOXpkvCZqG00ADXEaW37tvFY=; b=OFE0/YL4YZqDW0JT8jowxSk3520dVMmgYYxd6xH1uZOzdZLHHotp6tx5 fZ3TcNYltKPi0FH9tjaWHXpiJ0wlaqNLoxJC5xCsm38TC8laOdGF9pn42 qktyHn70n2XG4C5smpLKYNS94CUO7EyLuBkgyGUWYgys1z51kuZvCn4Gz U=;
X-IronPort-AV: E=Sophos;i="4.65,326,1304294400"; d="scan'208";a="708764715"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-6.cisco.com with ESMTP; 06 Jun 2011 12:48:50 +0000
Received: from [161.44.174.125] (dhcp-161-44-174-125.cisco.com [161.44.174.125]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p56CmoDn011636; Mon, 6 Jun 2011 12:48:50 GMT
Message-ID: <4DECCCB1.8060705@cisco.com>
Date: Mon, 06 Jun 2011 08:48:49 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: sip-overload@ietf.org
References: <BANLkTi=Q_Z_tcK=Lrwo-_XAxMgQwp4Z2og@mail.gmail.com>
In-Reply-To: <BANLkTi=Q_Z_tcK=Lrwo-_XAxMgQwp4Z2og@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [sip-overload] draft-shen-soc-avalanche-restart-overload
X-BeenThere: sip-overload@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: SIP Overload <sip-overload.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sip-overload>, <mailto:sip-overload-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/sip-overload>
List-Post: <mailto:sip-overload@ietf.org>
List-Help: <mailto:sip-overload-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sip-overload>, <mailto:sip-overload-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 06 Jun 2011 12:49:07 -0000

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
> <salvatore.loreto@ericsson.com>  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 toproceedings@ietf.org  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
>> sip-overload@ietf.org
>> https://www.ietf.org/mailman/listinfo/sip-overload
>>
>
>
>
> Thanks
>
> Charles
> _______________________________________________
> sip-overload mailing list
> sip-overload@ietf.org
> https://www.ietf.org/mailman/listinfo/sip-overload