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

Michael Tüxen <Michael.Tuexen@lurchi.franken.de> Thu, 27 January 2011 13:29 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 AFF553A67B3 for <tsvwg@core3.amsl.com>; Thu, 27 Jan 2011 05:29: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 gdyfCMREPraz for <tsvwg@core3.amsl.com>; Thu, 27 Jan 2011 05:29: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 6C0A43A6452 for <tsvwg@ietf.org>; Thu, 27 Jan 2011 05:29: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 32DF41C0C0BCC; Thu, 27 Jan 2011 14:32:14 +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: <201101262035.p0QKZNZF021356@sj-core-5.cisco.com>
Date: Thu, 27 Jan 2011 14:32:13 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <5F833010-36E7-4863-86D5-29D9B4E8DA19@lurchi.franken.de>
References: <201101250131.p0P1VA5A001374@sj-core-1.cisco.com> <4D3EAF12.4050100@oracle.com> <201101251916.p0PJGm76021999@sj-core-3.cisco.com> <A51D8ACD861B7E41BFC7FE5C64BE9648135ADE23@MTLEXVS01.ulticom.com> <201101262035.p0QKZNZF021356@sj-core-5.cisco.com>
To: "James M. Polk" <jmpolk@cisco.com>
X-Mailer: Apple Mail (2.1082)
Cc: tsvwg@ietf.org, Kacheong Poon <ka-cheong.poon@oracle.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, 27 Jan 2011 13:29:14 -0000

On Jan 26, 2011, at 9:35 PM, James M. Polk wrote:
> At 01:56 PM 1/25/2011, David Lehmann wrote:
>> IMHO, there are a few reasons to move forward with Quick Failover.
>> (1) Quick Failover seems to be less complex, which will allow more
>> timely approval/implementation. As Kacheong pointed out, "Doing it does
>> not require co-operation from the receiver side.  There is not much side
>> effect (should not introduce congestion for example)...".
>> (2) Although the current spec may allow quick failover, it implies an
>> unacceptably long wait time before failover.  I don't think Solaris or
>> Linux has quick failover.  Let's say that one does implement it. Now we
>> have two major implementations with quite noticeable behavior
>> differences.  IMHO, users should expect consistent behavior across all
>> SCTP implementations.
>> (3) As Dr. Dreibholz noted, CMT will also benefit from Quick Failover.
>> The CMT spec can reference Quick Failover.
> 
> Do others agree with this position, with the caveat that anything within the multipath ID regarding Quick Failover has to be in line with the Quick Failover ID (i.e., they need to be in sync)?
Hi James,

I think the Quick Failover makes sense for scenarios where CMT is currently
not deployed yet. These implementations focus on standards track protocols
and having a documented method for this, being a standards track document
does make sense. It can easily be deployed since it is a sender side only
thing. We already have the situation that FreeBSD, Linux and Solaris show
different behavior for detecting path failures. For writing portable
applications this is not useful.

Originally I was hesitating to support quick failover, as indicated in a
discussion at an IETF, but changed my mind. It would be helpful to have
a standardized method for this.

CMT also needs to detect a path failure. We could just refer the Quick
Failover ID for this. So we would avoid duplicating the work.

Please note the the intended status for the CMT ID is experimental.
Only have a failure detection in an experimental document does not
seem to be optimal to me.

I'm willing to continue contributing to the Quick Failover ID by
providing review comments and even text if it is applicable.
The Quick Failover ID needs a section for the socket API, for example.

Best regards
Michael
> 
> I want to hear from many on this before proceeding with anything.
> 
> James
> TSVWG chair
> 
> 
>> --
>> David Lehmann
>> Ulticom, Inc.
>> 856-787-2952
> 
>