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

Michael Tüxen <Michael.Tuexen@lurchi.franken.de> Thu, 27 January 2011 19:56 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 A323C3A6A32 for <tsvwg@core3.amsl.com>; Thu, 27 Jan 2011 11:56:14 -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 r3d0Kw1eCS0Z for <tsvwg@core3.amsl.com>; Thu, 27 Jan 2011 11:56:13 -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 38C8F3A6A1D for <tsvwg@ietf.org>; Thu, 27 Jan 2011 11:56:13 -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 6F4F91C0C0BD6; Thu, 27 Jan 2011 20:59:16 +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="iso-8859-1"
From: Michael Tüxen <Michael.Tuexen@lurchi.franken.de>
In-Reply-To: <20110127193736.GB9885@openss7.org>
Date: Thu, 27 Jan 2011 20:59:15 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <B131A016-7FFD-4F03-AF3C-2645806FB4D5@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> <38E19B53-7098-4204-A9DB-C05D3B97211F@lurchi.franken.de> <20110127193736.GB9885@openss7.org>
To: bidulock@openss7.org
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 19:56:14 -0000

On Jan 27, 2011, at 8:37 PM, Brian F. G. Bidulock wrote:

> Michael,
> 
> Michael Tüxen wrote:                           (Thu, 27 Jan 2011 19:11:23)
> 
>> 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...
> 
> Your problem appears to be more of an API issue than a standardization
> of "implementation details".  An API feature that indicates that the
> application wants 'quickest failover' would appear to provide what you
> need without unnecessarily constraining how the implementation achieves
> that.
Brian,

the point is that sometimes I not only want what the implementation
considers 'quickest failover', but I want some time limits to be
satisfied. I agree, I do not care how this is done in detail, but
when we were investigating FreeBSD, Linux and Solaris, we had
to figure out how these implementations do path supervision and
how specific parameters in the API influence that. Based on that
we could write code which can achieve the performance constraints.
Part of the problem was API, this is smoothed out in the current
version of the socket API ID, but another part was just different
behavior. Solaris has some sort of fast path failure detection.

Having a document describing such a mechanism would possibly result
in having such a mechanism available on several implementations.
I can speak for the FreeBSD implementation: We would provide such
an implementation pretty soon such a document is on track for PS.
Some sort of it is already implemented, but it needs some adoption.
I would guess, it would also be implemented in Linux. I can't talk
about other implementations.
But every implementation is free to implement it or to implement even
mechanisms which behave better in some metric in specific situation.
This is the nice feature of the suggested method. It is sender side
only...

Best regards
Michael
> 
> --brian
> 
> -- 
> Brian F. G. Bidulock
> bidulock@openss7.org
> http://www.openss7.org/
>