Re: quick failover in SCTP

Michael Tüxen <Michael.Tuexen@lurchi.franken.de> Thu, 14 October 2010 14:59 UTC

Return-Path: <Michael.Tuexen@lurchi.franken.de>
X-Original-To: tsvwg@core3.amsl.com
Delivered-To: tsvwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 21D2C3A6953 for <tsvwg@core3.amsl.com>; Thu, 14 Oct 2010 07:59:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 3.438
X-Spam-Level: ***
X-Spam-Status: No, score=3.438 tagged_above=-999 required=5 tests=[AWL=1.677, BAYES_00=-2.599, HOST_EQ_DIP_TDIAL=2.144, HOST_MISMATCH_NET=0.311, J_CHICKENPOX_43=0.6, MIME_8BIT_HEADER=0.3, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MaPuEtmk5L7h for <tsvwg@core3.amsl.com>; Thu, 14 Oct 2010 07:59:12 -0700 (PDT)
Received: from mail-n.franken.de (drew.ipv6.franken.de [IPv6:2001:638:a02:a001:20e:cff:fe4a:feaa]) by core3.amsl.com (Postfix) with ESMTP id BA1053A68ED for <tsvwg@ietf.org>; Thu, 14 Oct 2010 07:59:11 -0700 (PDT)
Received: from [192.168.1.190] (p508FCBBF.dip.t-dialin.net [80.143.203.191]) by mail-n.franken.de (Postfix) with ESMTP id 871731C0C0BCC; Thu, 14 Oct 2010 17:00:28 +0200 (CEST)
Subject: Re: quick failover in SCTP
Mime-Version: 1.0 (Apple Message framework v1081)
Content-Type: text/plain; charset="us-ascii"
From: Michael Tüxen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <A51D8ACD861B7E41BFC7FE5C64BE9648135ADBEA@MTLEXVS01.ulticom.com>
Date: Thu, 14 Oct 2010 17:00:27 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <61D33DB8-2B07-49BA-B9F6-CB139BA179BA@lurchi.franken.de>
References: <AANLkTi=07JfcQOKhfLouaU8N6=r57Koh9fKw+j3=O56R@mail.gmail.com><8CF58AED-5D88-46A3-B873-26AAB8DAF9BD@lurchi.franken.de><AANLkTi=2uGTkPjtcohABJ3vpy=5ryAMzXSwGiq3tXgi_@mail.gmail.com><17E9584A-5AC1-4CC7-AC93-7207412DD05B@lurchi.franken.de><AANLkTi=4NDwVgkgsndZYy_t6OcA4b3fgOBC4w+o+HEhA@mail.gmail.com><EC763CF2-05B6-4A3F-A508-72E482A5E5BE@lurchi.franken.de> <AANLkTikAFt7q=nOphfFcs2ur8M131sudmqi8myweHvnj@mail.gmail.com> <A51D8ACD861B7E41BFC7FE5C64BE9648135ADBEA@MTLEXVS01.ulticom.com>
To: David Lehmann <dlehmann@ulticom.com>
X-Mailer: Apple Mail (2.1081)
Cc: tsvwg@ietf.org, Preethi Natarajan <prenatar@cisco.com>
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tsvwg>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 14 Oct 2010 14:59:17 -0000

On Oct 14, 2010, at 4:14 PM, David Lehmann wrote:

>>>>> I would like to see some extensions to you suggestion:
>>>>> * Introduce a threshold (call it PFMR for now).
>>>>>  Then use
>>>>>  if (error counter > PMR)
>>>>>     the path is inactive.
>>>>>  if (error counter <= PMR) && (error counter > PFMR)
>>>>>     the path is potentially failed.
>>>>>  Using PFMR = 0 is what you suggest, PFMR=PMR gives
>>>>>  the old behavior.
>>>> 
>>>> I thought similar thing and I agree with providing a way to disable PF.
>>>> I tend to agree with this idea, but one thing I'm not very sure is how
>>>> PFMR != 0 && PFMR < PMR can be useful.
>>> I could image someone wanting to call a path potentially failed
>>> after 2 consecutive timer based retransmission instead of 1.
>>> Just being a bit more conservative. This might help deploying
>>> such a feature in SIGTRAN networks where CMT is not deployed.
>>> For CMT traffic, PFMR==0 is the right choice, I guess.
>>> But I think PF is also very helpful in non-CMT scenarios.
>> 
>> OK. I think it would be good to have tunable parameter for users. I
>> agree with this.
> 
> Just to be clear the default would be PFMR == 0, which means use another path if the error count is non-zero.  Correct?
Correct.

Best regards
Michael
> 
> -David
> 
>