Re: [tcpm] WG status update
Bruno Mongazon-Cazavet <bruno.mongazon-cazavet@alcatel-lucent.com> Mon, 15 November 2010 10:27 UTC
Return-Path: <bruno.mongazon-cazavet@alcatel-lucent.com>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id CE7EF3A6B6B for <tcpm@core3.amsl.com>; Mon, 15 Nov 2010 02:27:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_FR=0.35, RCVD_IN_DNSWL_MED=-4]
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 dxLZkzeP6gZ3 for <tcpm@core3.amsl.com>; Mon, 15 Nov 2010 02:27:00 -0800 (PST)
Received: from smail2.alcatel.fr (smail2.alcatel.fr [62.23.212.57]) by core3.amsl.com (Postfix) with ESMTP id 6DEF43A6AB0 for <tcpm@ietf.org>; Mon, 15 Nov 2010 02:26:58 -0800 (PST)
Received: from FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (FRMRSSXCHHUB01.dc-m.alcatel-lucent.com [135.120.45.61]) by smail2.alcatel.fr (8.14.3/8.14.3/ICT) with ESMTP id oAFAOUBM029720 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT); Mon, 15 Nov 2010 11:27:35 +0100
Received: from [172.27.205.223] (135.120.57.7) by FRMRSSXCHHUB01.dc-m.alcatel-lucent.com (135.120.45.61) with Microsoft SMTP Server (TLS) id 8.3.106.1; Mon, 15 Nov 2010 11:27:24 +0100
Message-ID: <4CE10B0C.1040705@alcatel-lucent.com>
Date: Mon, 15 Nov 2010 11:27:24 +0100
From: Bruno Mongazon-Cazavet <bruno.mongazon-cazavet@alcatel-lucent.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4
MIME-Version: 1.0
To: "Scheffenegger, Richard" <rs@netapp.com>
References: <C304DB494AC0C04C87C6A6E2FF5603DB4821F155C3@NDJSSCC01.ndc.nasa.gov> <4CDA4FA9.4050006@alcatel-lucent.com> <5FDC413D5FA246468C200652D63E627A0B54DF91@LDCMVEXC1-PRD.hq.netapp.com>
In-Reply-To: <5FDC413D5FA246468C200652D63E627A0B54DF91@LDCMVEXC1-PRD.hq.netapp.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Scanned-By: MIMEDefang 2.64 on 155.132.188.80
Cc: "tcpm@ietf.org" <tcpm@ietf.org>
Subject: Re: [tcpm] WG status update
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 15 Nov 2010 10:27:08 -0000
Dear Richard; Thank you for looking at TCP-Rehash. Please see my comments inline. Regards, Bruno Mongazon Le 10/11/2010 13:51, Scheffenegger, Richard a écrit : > Hi Bruno, > > After a casual look, it appears to me that a lightweight implementation of MP-TCP can have the same benefits, but does not require the opaque exchange of IPv4 addresses... Yes an idea would be to have TCP-Rehash == lightweigth MPTCP There are a few design diffferences that need to be looked at. > Your use case - that the old L3 address is already no longer available at the time of the rehash - may need to be looked at in MPTCP though (iirc, they do a graceful session setup first (thus can work with NAT mostly), and move data transport only after the successful establishment of the 2nd L3 connectivity, and only then tear down the original L3 connectivity). Right but... there is no real constraint on old address availability, thus the old address might still be available. A key difference between TCP-Rehash and MPTCP is the session setup. With TCP-Rehash there is no setup, it is a straight move. If it fails, the connection is broken, this would happen anyway if L3 address changes and there is no "move" mechanism. Doing so is just opportunistic but deterministic. MPTCP is more complex since a new connection is setup before the old connection is being "moved". From design perspective, would it be that complex for MPTCP to handle rehash design ? NAT is a different story (orthogonal i would say) and issue. > Perhaps the effort would be better placed on making sure that such light-weight MPTCP implementations remain feasible, instead of defining an alternate method that is addressing only this one aspect, but incompatible with MPTCP otherwise? To be honest i have both TCP-Rehash and MPTCP linux kernel source code... my intention is not to define an alternate method ! Rather i posted the TCP-Rehash draft with the intention to provide some additional work on the topic. Convergence and collaboration is of course to be considered. I think my work, although it was not disclosed, started sometimes ago, almost at early MPTCP. Please let me know, if from the design point of view, the WG would consider the opportunity to have a lightweight MPTCP that would look like TCP-Rehash. > Richard Scheffenegger > > > >> -----Original Message----- >> From: Bruno Mongazon-Cazavet >> [mailto:bruno.mongazon-cazavet@alcatel-lucent.com] >> Sent: Mittwoch, 10. November 2010 08:54 >> To: Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP] >> Cc: tcpm@ietf.org >> Subject: Re: [tcpm] WG status update >> >> >> Le 10/11/2010 01:54, Eddy, Wesley M. (GRC-MS00)[ASRC >> AEROSPACE CORP] a écrit : >>> Hi, for those of you who aren't in Beijing, here's a >> snapshot of the TCPM WG status. >> >> Hi, >> >> I have posted a 00 draft that might be of interest for your working >> group. I don't see any mention in your snapshot. >> http://www.ietf.org/id/draft-mongazon-tcpm-tcp-rehash-00.txt >> >> I will not be in Beijing to present it but i hope to be in >> Prague to do so. >> I would appreciate the working group can look at it and let >> me know if >> it could be of any interest and how i shall pursue my contribution. >> >> I have done a Linux kernel implementation of the draft and be >> ready for >> a demo in Prague. >> >> Best Regards, >> Bruno. >> _______________________________________________ >> tcpm mailing list >> tcpm@ietf.org >> https://www.ietf.org/mailman/listinfo/tcpm >>
- [tcpm] WG status update Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
- Re: [tcpm] WG status update Mark Allman
- Re: [tcpm] WG status update Fernando Gont
- [tcpm] WG status update Eddy, Wesley M. (GRC-MS00)[Verizon]
- Re: [tcpm] WG status update Alexander Zimmermann
- [tcpm] WG status update Eddy, Wesley M. (GRC-MS00)[ASRC AEROSPACE CORP]
- Re: [tcpm] WG status update Bruno Mongazon-Cazavet
- Re: [tcpm] WG status update Scheffenegger, Richard
- Re: [tcpm] WG status update Scheffenegger, Richard
- Re: [tcpm] WG status update Lars Eggert
- Re: [tcpm] WG status update Murari Sridharan
- Re: [tcpm] WG status update Bruno Mongazon-Cazavet
- Re: [tcpm] WG status update Lars Eggert
- Re: [tcpm] WG status update Bruno Mongazon-Cazavet
- Re: [tcpm] WG status update Lars Eggert
- Re: [tcpm] WG status update L.Wood
- [tcpm] MPTCP vs Rehash (was TCPM WG status update) Costin Raiciu
- Re: [tcpm] MPTCP vs Rehash (was TCPM WG status up… Bruno Mongazon-Cazavet
- Re: [tcpm] WG status update Lars Eggert
- Re: [tcpm] WG status update Joe Touch
- Re: [tcpm] WG status update Bruno Mongazon-Cazavet