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 > >
- Quick Failover Algorithm in SCTP - question for t… James M. Polk
- Re: Quick Failover Algorithm in SCTP - question f… Brian F. G. Bidulock
- Re: Quick Failover Algorithm in SCTP - question f… Yoshifumi Nishida
- Re: Quick Failover Algorithm in SCTP - question f… Kacheong Poon
- Re: Quick Failover Algorithm in SCTP - question f… James M. Polk
- RE: Quick Failover Algorithm in SCTP - question f… David Lehmann
- RE: Quick Failover Algorithm in SCTP - question f… James M. Polk
- Re: Quick Failover Algorithm in SCTP - question f… Kacheong Poon
- Re: Quick Failover Algorithm in SCTP - question f… Alberto Cortés
- Re: Quick Failover Algorithm in SCTP - question f… Michael Tüxen
- Re: Quick Failover Algorithm in SCTP - question f… Thomas Dreibholz
- Re: Quick Failover Algorithm in SCTP - question f… Armando Caro
- Re: Quick Failover Algorithm in SCTP - question f… Michael Tüxen
- Re: Quick Failover Algorithm in SCTP - question f… Brian F. G. Bidulock
- Re: Quick Failover Algorithm in SCTP - question f… Michael Tüxen
- Re: Quick Failover Algorithm in SCTP - question f… Jeff Morriss
- Re: Quick Failover Algorithm in SCTP - question f… Janardhan Iyengar
- Re: Quick Failover Algorithm in SCTP - question f… Brian F. G. Bidulock
- Re: Quick Failover Algorithm in SCTP - question f… Brian F. G. Bidulock
- Re: Quick Failover Algorithm in SCTP - question f… Michael Tüxen
- Re: Quick Failover Algorithm in SCTP - question f… Brian F. G. Bidulock
- Re: Quick Failover Algorithm in SCTP - question f… Michael Tüxen
- Re: Quick Failover Algorithm in SCTP - question f… Michael Tüxen
- Re: Quick Failover Algorithm in SCTP - question f… Brian F. G. Bidulock
- Re: Quick Failover Algorithm in SCTP - question f… Brian F. G. Bidulock
- Re: Quick Failover Algorithm in SCTP - question f… Michael Tüxen
- Re: Quick Failover Algorithm in SCTP - question f… Michael Tüxen
- Re: Quick Failover Algorithm in SCTP - question f… Brian F. G. Bidulock
- Re: Quick Failover Algorithm in SCTP - question f… Brian F. G. Bidulock
- Re: Quick Failover Algorithm in SCTP - question f… Yoshifumi Nishida
- Re: Quick Failover Algorithm in SCTP - question f… Brian F. G. Bidulock
- Re: Quick Failover Algorithm in SCTP - question f… Janardhan Iyengar
- Re: Quick Failover Algorithm in SCTP - question f… Janardhan Iyengar
- Re: Quick Failover Algorithm in SCTP - question f… Brian F. G. Bidulock
- Re: Quick Failover Algorithm in SCTP - question f… Brian F. G. Bidulock
- Re: Quick Failover Algorithm in SCTP - question f… Brian F. G. Bidulock
- Re: Quick Failover Algorithm in SCTP - question f… Yoshifumi Nishida