Re: Quick Failover Algorithm in SCTP - question for the WG

Michael Tüxen <Michael.Tuexen@lurchi.franken.de> Thu, 27 January 2011 18:08 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 88B0A28C145 for <tsvwg@core3.amsl.com>; Thu, 27 Jan 2011 10:08:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3]
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 eaEScZJVymG1 for <tsvwg@core3.amsl.com>; Thu, 27 Jan 2011 10:08:22 -0800 (PST)
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 51F623A681F for <tsvwg@ietf.org>; Thu, 27 Jan 2011 10:08:22 -0800 (PST)
Received: from [192.168.1.113] (p508FCC98.dip.t-dialin.net [80.143.204.152]) (Authenticated sender: macmic) by mail-n.franken.de (Postfix) with ESMTP id 5FD461C0B4626; Thu, 27 Jan 2011 19:11:24 +0100 (CET)
Subject: Re: Quick Failover Algorithm in SCTP - question for the WG
Mime-Version: 1.0 (Apple Message framework v1082)
Content-Type: text/plain; charset="us-ascii"
From: Michael Tüxen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <4D41A0CB.9080009@bbn.com>
Date: Thu, 27 Jan 2011 19:11:23 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <38E19B53-7098-4204-A9DB-C05D3B97211F@lurchi.franken.de>
References: <201101250131.p0P1VA5A001374@sj-core-1.cisco.com> <201101251916.p0PJGm76021999@sj-core-3.cisco.com> <A51D8ACD861B7E41BFC7FE5C64BE9648135ADE23@MTLEXVS01.ulticom.com> <201101271415.52688.dreibh@iem.uni-due.de> <4D41A0CB.9080009@bbn.com>
To: Armando Caro <acaro@bbn.com>
X-Mailer: Apple Mail (2.1082)
Cc: tsvwg@ietf.org
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, 27 Jan 2011 18:08:23 -0000

On Jan 27, 2011, at 5:43 PM, Armando Caro wrote:

> On 01/27/2011 08:15 AM, Thomas Dreibholz wrote:
>> Significant difference in implementation behaviour is a very bad thing.
> 
> I think it's not ideal, but it may not be a very bad thing. It depends on how the application is written.
> 
>> From the application writer's
>> perspective, a consistent behaviour of the underlying SCTP implementations
>> would make things a lot easier.
> 
> It might, but I don't think applications should optimize on assumptions about the parameter settings of the network stack.
Hi Armando,

when writing an application using SCTP which has to fulfill some requirements
on failover time I have to tweak the transport parameters to get that feature.

Currently I have to do that very platform specific. Even the same parameter
means different things on different platforms.

So having a portable way to get some predefined failover behavior makes sense
to me...

Best regards
Michael
> 
> With that said, I do think that the quick failover algorithm makes sense to adopt as a WG item. Research results (and I'm guessing practical experience) have shown little (any?) downsides to using this algorithm, and the advantages are clear.
> 
> Armando
> 
> 
>