From philip.eardley@bt.com Fri Feb 3 05:04:55 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8197F21F8548 for ; Fri, 3 Feb 2012 05:04:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.144 X-Spam-Level: X-Spam-Status: No, score=-103.144 tagged_above=-999 required=5 tests=[AWL=0.455, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YVhLRAUrPoYs for ; Fri, 3 Feb 2012 05:04:53 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 8B52721F8545 for ; Fri, 3 Feb 2012 05:04:53 -0800 (PST) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 3 Feb 2012 13:04:52 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.230]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Fri, 3 Feb 2012 13:04:52 +0000 From: To: Date: Fri, 3 Feb 2012 13:04:47 +0000 Thread-Topic: [multipathtcp] I-D Action: draft-ietf-mptcp-multiaddressed-06.txt Thread-Index: AczgQeRqrfrqw3qLTZC+JysxDX2sEQCMkQgQ Message-ID: <9510D26531EF184D9017DF24659BB87F3317E442BA@EMV65-UKRD.domain1.systemhost.net> References: <20120131175804.26422.68065.idtracker@ietfa.amsl.com> In-Reply-To: <20120131175804.26422.68065.idtracker@ietfa.amsl.com> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [multipathtcp] I-D Action: draft-ietf-mptcp-multiaddressed-06.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 13:04:55 -0000 Hi Thanks for your work to include the new Fast close - looks good. We believe that this concludes all the outstanding actions, so we'll start = a WG last call on this & on the API doc Best wishes Phil & Yoshifumi -----Original Message----- From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of internet-drafts@ietf.org Sent: 31 January 2012 17:58 To: i-d-announce@ietf.org Cc: multipathtcp@ietf.org Subject: [multipathtcp] I-D Action: draft-ietf-mptcp-multiaddressed-06.txt A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multipath TCP Working Group of the IE= TF. Title : TCP Extensions for Multipath Operation with Multiple Add= resses Author(s) : Alan Ford Costin Raiciu Mark Handley Olivier Bonaventure Filename : draft-ietf-mptcp-multiaddressed-06.txt Pages : 60 Date : 2012-01-31 TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network, and thus improve user experience through higher throughput and improved resilience to network failure. Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e. reliable bytestream), and provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mptcp-multiaddressed-06.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mptcp-multiaddressed-06.txt _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp From philip.eardley@bt.com Fri Feb 3 05:24:36 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A08821F867A for ; Fri, 3 Feb 2012 05:24:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.194 X-Spam-Level: X-Spam-Status: No, score=-103.194 tagged_above=-999 required=5 tests=[AWL=0.404, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x+Yr7+cc36Ny for ; Fri, 3 Feb 2012 05:24:35 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 7DD8121F8674 for ; Fri, 3 Feb 2012 05:24:28 -0800 (PST) Received: from EVMHT61-UKRD.domain1.systemhost.net (10.36.3.127) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 3 Feb 2012 13:24:27 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.230]) by EVMHT61-UKRD.domain1.systemhost.net ([10.36.3.127]) with mapi; Fri, 3 Feb 2012 13:24:27 +0000 From: To: Date: Fri, 3 Feb 2012 13:24:25 +0000 Thread-Topic: WG Last call for Multipath TCP protocol doc Thread-Index: AczidyZSiFWm/o8+TXmYFaJdcgNenA== Message-ID: <9510D26531EF184D9017DF24659BB87F3317E442F3@EMV65-UKRD.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_9510D26531EF184D9017DF24659BB87F3317E442F3EMV65UKRDdoma_" MIME-Version: 1.0 Subject: [multipathtcp] WG Last call for Multipath TCP protocol doc X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 13:24:36 -0000 --_000_9510D26531EF184D9017DF24659BB87F3317E442F3EMV65UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is to announce the WG last call for "TCP Extensions for Multipath Oper= ation with Multiple Addresses" http://tools.ietf.org/html/draft-ietf-mptcp= -multiaddressed-06 Since this is a reasonably substantial doc and we are WG last calling the A= PI doc as well, we will run until the end of Feb (Wed 29th). Please send comments to the list The purpose of a WGLC is to provide a final check that the WG has rough con= sensus to advance the document: - The WG believes that this document is technically sound - The WG believes that this document is useful - The WG believes that this document is ready to go to the IESG Please reply with positive support, as well as any comments /questions Thanks Phil & Yoshifumi -- Abstract TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network, and thus improve user experience through higher throughput and improved resilience to network failure. Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e. reliable bytestream), and provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. --_000_9510D26531EF184D9017DF24659BB87F3317E442F3EMV65UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is to annou= nce the WG last call for “TCP Extensions for Multipath Operation with= Multiple Addresses“  http://tools.ietf.org/html/draft-ietf-mptcp= -multiaddressed-06

 =

Since this is a reasonably substantial doc and we = are WG last calling the API doc as well, we will run until the end of Feb (= Wed 29th).

Please send comme= nts to the list

 

The purpose of a WGLC is to provide a final check that t= he WG has rough consensus to advance the document:

- The WG believes that this document is technically sound=

- The WG believes that this document is usef= ul

- The WG believes that this document = is ready to go to the IESG

 <= /o:p>

Please reply with positive support, as well a= s any comments /questions

 

Thanks

Phil = & Yoshifumi

 

-- 
Abstract
 <=
/pre>
   TCP/IP communication is currently restricted to a si=
ngle path per
   connection, yet multiple pa=
ths often exist between peers.  The
   =
simultaneous use of these multiple paths for a TCP/IP session would
   improve resource usage within the network, and t=
hus improve user
   experience through highe=
r throughput and improved resilience to
   n=
etwork failure.
 
 &nbs=
p; Multipath TCP provides the ability to simultaneously use multiple
   paths between peers.  This document presen=
ts a set of extensions to
   traditional TCP=
 to support multipath operation.  The protocol offers
=

   the same type of service to applications as TCP (i.e. rel=
iable
   bytestream), and provides the compo=
nents necessary to establish and
   use mult=
iple TCP flows across potentially disjoint paths.
 
= --_000_9510D26531EF184D9017DF24659BB87F3317E442F3EMV65UKRDdoma_-- From philip.eardley@bt.com Fri Feb 3 05:26:40 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD5DE21F867A for ; Fri, 3 Feb 2012 05:26:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.235 X-Spam-Level: X-Spam-Status: No, score=-103.235 tagged_above=-999 required=5 tests=[AWL=0.363, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FeOkieVuoQt5 for ; Fri, 3 Feb 2012 05:26:39 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA2721F8673 for ; Fri, 3 Feb 2012 05:26:39 -0800 (PST) Received: from EVMHT64-UKRD.domain1.systemhost.net (10.36.3.101) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 3 Feb 2012 13:26:39 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.2.230]) by EVMHT64-UKRD.domain1.systemhost.net ([10.36.3.101]) with mapi; Fri, 3 Feb 2012 13:26:38 +0000 From: To: Date: Fri, 3 Feb 2012 13:26:36 +0000 Thread-Topic: WG Last call for Multipath TCP API doc Thread-Index: AczidyZSiFWm/o8+TXmYFaJdcgNenAAAAyjw Message-ID: <9510D26531EF184D9017DF24659BB87F3317E442F8@EMV65-UKRD.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_9510D26531EF184D9017DF24659BB87F3317E442F8EMV65UKRDdoma_" MIME-Version: 1.0 Subject: [multipathtcp] WG Last call for Multipath TCP API doc X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 13:26:40 -0000 --_000_9510D26531EF184D9017DF24659BB87F3317E442F8EMV65UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable This is to announce the WG last call for "MPTCP Application Interface Consi= derations" http://tools.ietf.org/html/draft-ietf-mptcp-api-03 Since we are WG last calling the protocol doc as well, we will run until th= e end of Feb (Wed 29th). Please send comments to the list The purpose of a WGLC is to provide a final check that the WG has rough con= sensus to advance the document: - The WG believes that this document is technically sound - The WG believes that this document is useful - The WG believes that this document is ready to go to the IESG Please reply with positive support, as well as any comments /questions Thanks Phil & Yoshifumi -- Abstract Multipath TCP (MPTCP) adds the capability of using multiple paths to a regular TCP session. Even though it is designed to be totally backward compatible to applications, the data transport differs compared to regular TCP, and there are several additional degrees of freedom that applications may wish to exploit. This document summarizes the impact that MPTCP may have on applications, such as changes in performance. Furthermore, it discusses compatibility issues of MPTCP in combination with non-MPTCP-aware applications. Finally, the document describes a basic application interface for MPTCP-aware applications that provides access to multipath address information and a level of control equivalent to regular TCP. --_000_9510D26531EF184D9017DF24659BB87F3317E442F8EMV65UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

This is to annou= nce the WG last call for “MPTCP Applica= tion Interface Considerations” <= a href=3D"http://tools.ietf.org/html/draft-ietf-mptcp-api-03">http://tools.= ietf.org/html/draft-ietf-mptcp-api-03

 

Since we are WG last calling the protocol doc as well, we will run until the end of Feb (Wed 29th).

Please send comments to the= list

 

The purpose of a WGLC is to provide a final check that the WG has = rough consensus to advance the document:

- The WG believes that this document is technically sound

- The WG believes that this document is useful

- The WG believes that this document is ready to = go to the IESG

 

Please reply with positive support, as well as any commen= ts /questions

 

Thanks

Phil & Yoshif= umi

 

-- 
Abstract
 

&n= bsp;  Multipath TCP (MPTCP) adds the capability of using multiple path= s to

   a regular TCP session.  Ev= en though it is designed to be totally

 &nbs= p; backward compatible to applications, the data transport differs

   compared to regular TCP, and there are sever= al additional degrees of

   freedom tha= t applications may wish to exploit.  This document

   summarizes the impact that MPTCP may have on applicatio= ns, such as

   changes in performance.&= nbsp; Furthermore, it discusses compatibility

&nb= sp;  issues of MPTCP in combination with non-MPTCP-aware applications.=

   Finally, the document describes a b= asic application interface for

   MPTCP= -aware applications that provides access to multipath address

   information and a level of control equivalent to = regular TCP.

 

 
= --_000_9510D26531EF184D9017DF24659BB87F3317E442F8EMV65UKRDdoma_-- From john@jlc.net Fri Feb 3 08:28:23 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2C89B21F84B4 for ; Fri, 3 Feb 2012 08:28:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.349 X-Spam-Level: X-Spam-Status: No, score=-106.349 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CuEvMEGs4Jhe for ; Fri, 3 Feb 2012 08:28:22 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 9658B21F848A for ; Fri, 3 Feb 2012 08:28:22 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 9CD9D33C21; Fri, 3 Feb 2012 11:28:22 -0500 (EST) Date: Fri, 3 Feb 2012 11:28:22 -0500 From: John Leslie To: philip.eardley@bt.com Message-ID: <20120203162822.GM46701@verdi> References: <9510D26531EF184D9017DF24659BB87F3317E442F8@EMV65-UKRD.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9510D26531EF184D9017DF24659BB87F3317E442F8@EMV65-UKRD.domain1.systemhost.net> User-Agent: Mutt/1.4.1i Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] WG Last call for Multipath TCP API doc X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 16:28:23 -0000 philip.eardley@bt.com wrote: > > This is to announce the WG last call for "MPTCP Application Interface > Considerations" http://tools.ietf.org/html/draft-ietf-mptcp-api-03 ] 7. Security Considerations ] ] Will be added in a later version of this document. I don't think this is appropriate. It's not that I think a _discussion_ of requirements for some future API needs much in the way of Security Considerations; but this should not be punted to "some future version". ] 5.2. Requirements on the Basic MPTCP API ]... ] REQ1: Turn on/off MPTCP: An application should be able to request to ] turn on or turn off the usage of MPTCP. This means that an ] application should be able to explicitly request the use of ] MPTCP if this is possible. Applications should also be able ] to request not to enable MPTCP and to use regular TCP ] transport instead. This can be implicit in many cases, since ] MPTCP must disabled by the use of binding to a specific ] address. MPTCP may also be enabled if an application uses a ] dedicated multipath address family (such as AF_MULTIPATH, ] [9]). I stumbled over this: what should happen if an application _both_ requests to enable MPTCP _and_ to bind to a specific address? (I don't care a lot, and it's even OK with me to leave this poorly defined; but if we have a strong opinion it's better to make it explicit.) -- John Leslie From nishida@sfc.wide.ad.jp Fri Feb 3 11:38:21 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 007ED21F85D8 for ; Fri, 3 Feb 2012 11:38:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.041 X-Spam-Level: X-Spam-Status: No, score=-98.041 tagged_above=-999 required=5 tests=[AWL=-1.056, BAYES_05=-1.11, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0T7-o8kdmy3m for ; Fri, 3 Feb 2012 11:38:20 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id 7545B21F8595 for ; Fri, 3 Feb 2012 11:38:20 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id BD26D2780D4 for ; Sat, 4 Feb 2012 04:38:16 +0900 (JST) Received: by lahl5 with SMTP id l5so2335169lah.31 for ; Fri, 03 Feb 2012 11:38:12 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.36.135 with SMTP id q7mr2149020lbj.86.1328297892131; Fri, 03 Feb 2012 11:38:12 -0800 (PST) Received: by 10.112.7.5 with HTTP; Fri, 3 Feb 2012 11:38:12 -0800 (PST) Date: Fri, 3 Feb 2012 11:38:12 -0800 Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: text/plain; charset=ISO-8859-1 Subject: [multipathtcp] codepoint for mptcp options X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 19:38:21 -0000 Hello, After some discussions with ADs, we think we'll need to discuss which codepoint we should use for mptcp options. I think we have the following choices for this. 1: Ask IANA to allocate new codepoint 2: Use experimental codepoint (253/254) 3: Use experimental codepoint (253/254) with draft-ietf-tcpm-experimental-options-00 If we go 1, I think we'll need to list rationales to convince IESG. If we don't have good reason for 1, I think we'd better go 3. 2 might not be good for wider experiments My concern for 3 is using draft-ietf-tcpm-experimental-options-00 will require extra option space for magic number, which might cause issues since some mptcp options use lots of space (e.g. DSS) Please let us know your thoughts on this. Thanks, -- Yoshifumi & Phil From lars@netapp.com Fri Feb 3 11:50:08 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 20CE621F8516 for ; Fri, 3 Feb 2012 11:50:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.367 X-Spam-Level: X-Spam-Status: No, score=-10.367 tagged_above=-999 required=5 tests=[AWL=0.232, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N+rGwIkCYEFI for ; Fri, 3 Feb 2012 11:50:07 -0800 (PST) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 98BE921F8513 for ; Fri, 3 Feb 2012 11:50:07 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.73,352,1325491200"; d="p7s'?scan'208";a="622247034" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 03 Feb 2012 11:50:06 -0800 Received: from sacrsexc2-prd.hq.netapp.com (sacrsexc2-prd.hq.netapp.com [10.99.115.28]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q13Jo3OQ011060; Fri, 3 Feb 2012 11:50:06 -0800 (PST) Received: from VMWEXCEHT04-PRD.hq.netapp.com ([10.106.77.34]) by sacrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 3 Feb 2012 11:49:57 -0800 Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.193]) by vmwexceht04-prd.hq.netapp.com ([10.106.77.34]) with mapi id 14.01.0355.002; Fri, 3 Feb 2012 11:49:52 -0800 From: "Eggert, Lars" To: Yoshifumi Nishida Thread-Topic: [multipathtcp] codepoint for mptcp options Thread-Index: AQHM4qtm31zTfpIF7ESk8/gRIupZzpYsGsOA Date: Fri, 3 Feb 2012 19:49:52 +0000 Message-ID: <435B3225-46B4-46D5-8B02-AD26D4E958F1@netapp.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: multipart/signed; boundary="Apple-Mail=_08F0100B-3DE3-4728-BBCD-DA988BAD72EA"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-OriginalArrivalTime: 03 Feb 2012 19:49:57.0645 (UTC) FILETIME=[01ED4BD0:01CCE2AD] Cc: multipathtcp Subject: Re: [multipathtcp] codepoint for mptcp options X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 19:50:08 -0000 --Apple-Mail=_08F0100B-3DE3-4728-BBCD-DA988BAD72EA Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii Hi, On Feb 3, 2012, at 11:38, Yoshifumi Nishida wrote: > 1: Ask IANA to allocate new codepoint > 2: Use experimental codepoint (253/254) > 3: Use experimental codepoint (253/254) with > draft-ietf-tcpm-experimental-options-00 >=20 > If we go 1, I think we'll need to list rationales to convince IESG. I think we want to go for #1. If I were to make the argument, I'd say that (1) MPTCP is safe for = experimentation on the broader Internet, (2) there is considerable = interest(*) and (3) therefore a standards-track bis is likely to come = shortly. Hence, we want permanent, dedicated option numbers. Lars (*) With a Linux implementation scheduled to be merged upstream, and a = BSD implementation funded for implementation.= --Apple-Mail=_08F0100B-3DE3-4728-BBCD-DA988BAD72EA Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQDCCBUow ggQyoAMCAQICEFcfSRTG0jNknqb9LV9GuFkwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEyMTAwMDAwMDBaFw0x MjEyMDkyMzU5NTlaMIIBDTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEeMBwGCSqGSIb3DQEJARYPbGFyc0BuZXRhcHAuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAokrhJTcXt6J/VEpZOicLoguBlYTjXP9v Ze4HuuhXnURUS8YouAfgaqA0zYbt5yd6fh4PBMdAaEWr5yJyHuFykXlrCumjUWSpLuqTS2A+pt4q cZaAQk9iLDN/UVd3SpkUuvWbxXlqzG7/BSqa3VNObBzCmyh+V7aXxri+30CT//DSsNRC4VFy6sn6 dMgSaFenXLwe/FBwY0qTMfICT1PrrX6Sw1S8OfH9rykLlZXbmfkFExxQngp1DJH9xMHeODHGbCv/ ty5gdxMOrLe+vENxFEcy1YQWBZd1kNL4UObugF8A/jE/s+Oa3H1VFH8ghqZTdqGDysVxmtKHuNFx 6jIBSQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNV HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMx ZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQBA7q6tR92qpd7xo7VBsrOfGCWzoxIVfTc7t0RhB/Oz/+c3lnhYnNScIuKN JmyZvznmVxqB9BJ72+NkvmdB/hnILSBTRawL2tyLo9PkBtN0nRt4gS6wjpWnD8G83hlJLE7r25jk 7HkRev61dTIXsANFpJKF02C4XSoDfEzNV6MpuEvHvcgHCqMrlwWwfKc7+NoDnE8PBuRzwSXvlD5L mswCY2iiOsd7ImNO4OzTCxETvKTDu92+FTIbRJJpYjVNv1UF7e3w9Kq65BkZJErUH19beUeQl0Wh 2BJQE6/15rQyCnP0iJ/Nmx2/kI6M0PWunEsI6FMs0MbosreaWGHlQmomMIIG7jCCBdagAwIBAgIQ cRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQL EzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYD VQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB 0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXc MM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ //6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSal J1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYI KwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0T AQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9w Y2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1h Z2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28u dmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHp MIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+v OEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSH O3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOV nDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVib vtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5J yNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggSL MIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDIwMzE5NDk1M1owIwYJKoZIhvcNAQkEMRYEFM2I Ch/eNwt9J3hfdU32VuhTS/8aMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEFcfSRTG0jNknqb9LV9GuFkwggEF BgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMA0GCSqGSIb3DQEBAQUABIIBABJNJuGg rmKsjHVNE2iQnyLo5m+YwDS2/chL07eRsElnabpp9yRB0z9MLtP7CTBAM7h7VVyOVUkLGoMTyOrP X8pQgsRACH06bvi/o49SYLVdimS4KtAnHG57X/Lf0YYUvgsy+xgAuuSacMlDzkNyqYtZp9UFBU7P oITgQJr2S6mPDqpTAaLtCmXL9HTIDNAOi1bjQ2OC5Lu7gxc5gRjqDpOvPaoxhfCN4tqa9ixCyYkk jhidotk3Jw/hu1krXUYg8mQyRqovky7H0GL4oXRZgA0TzfBtKAiE2me6qaYCC5BXsa52a8DLEpUf 5H3NZDXRS/pIGUecHl3Vzt1N5/uAW0UAAAAAAAA= --Apple-Mail=_08F0100B-3DE3-4728-BBCD-DA988BAD72EA-- From touch@isi.edu Fri Feb 3 15:09:02 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78D0021F84FB for ; Fri, 3 Feb 2012 15:09:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.318 X-Spam-Level: X-Spam-Status: No, score=-103.318 tagged_above=-999 required=5 tests=[AWL=-0.719, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L0wGEN79p+09 for ; Fri, 3 Feb 2012 15:09:01 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 484DF21F84EB for ; Fri, 3 Feb 2012 15:08:57 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q13N8Nr2029085 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 3 Feb 2012 15:08:23 -0800 (PST) Message-ID: <4F2C68E7.1000506@isi.edu> Date: Fri, 03 Feb 2012 15:08:23 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "Eggert, Lars" References: <435B3225-46B4-46D5-8B02-AD26D4E958F1@netapp.com> In-Reply-To: <435B3225-46B4-46D5-8B02-AD26D4E958F1@netapp.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: multipathtcp Subject: Re: [multipathtcp] codepoint for mptcp options X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2012 23:09:02 -0000 Hi, all, #1 is appropriate if and when this is reconsidered as standards-track only. I don't like the idea of experimental protocols using assigned options. It burns a TCP option that can't be reclaimed. IMO, #3 is appropriate IMO. At some point, if a new standards-track version released, you can then more easily decide whether to support both the #1 and #3 variant or just the #1 variant - based on whether there are protocol changes in the standards-track version that are not backward compatible. Joe On 2/3/2012 11:49 AM, Eggert, Lars wrote: > Hi, > > On Feb 3, 2012, at 11:38, Yoshifumi Nishida wrote: >> 1: Ask IANA to allocate new codepoint >> 2: Use experimental codepoint (253/254) >> 3: Use experimental codepoint (253/254) with >> draft-ietf-tcpm-experimental-options-00 >> >> If we go 1, I think we'll need to list rationales to convince IESG. > > I think we want to go for #1. > > If I were to make the argument, I'd say that (1) MPTCP is safe for experimentation on the broader Internet, (2) there is considerable interest(*) and (3) therefore a standards-track bis is likely to come shortly. Hence, we want permanent, dedicated option numbers. > > Lars > > (*) With a Linux implementation scheduled to be merged upstream, and a BSD implementation funded for implementation. > > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From lars@netapp.com Fri Feb 3 16:41:40 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D19121F85C6 for ; Fri, 3 Feb 2012 16:41:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.373 X-Spam-Level: X-Spam-Status: No, score=-10.373 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wWJ5IKuedvLW for ; Fri, 3 Feb 2012 16:41:39 -0800 (PST) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 95B8E21F852E for ; Fri, 3 Feb 2012 16:41:39 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.73,354,1325491200"; d="p7s'?scan'208";a="622331367" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 03 Feb 2012 16:41:39 -0800 Received: from svlrsexc1-prd.hq.netapp.com (svlrsexc1-prd.hq.netapp.com [10.57.115.30]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q140fd8L014188; Fri, 3 Feb 2012 16:41:39 -0800 (PST) Received: from VMWEXCEHT02-PRD.hq.netapp.com ([10.106.76.240]) by svlrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.4675); Fri, 3 Feb 2012 16:41:34 -0800 Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.193]) by vmwexceht02-prd.hq.netapp.com ([10.106.76.240]) with mapi id 14.01.0355.002; Fri, 3 Feb 2012 16:41:33 -0800 From: "Eggert, Lars" To: Joe Touch Thread-Topic: [multipathtcp] codepoint for mptcp options Thread-Index: AQHM4qtm31zTfpIF7ESk8/gRIupZzpYsGsOAgAA3doCAABoJAA== Date: Sat, 4 Feb 2012 00:41:32 +0000 Message-ID: <80595D64-3011-435E-BA35-A9BB911F2213@netapp.com> References: <435B3225-46B4-46D5-8B02-AD26D4E958F1@netapp.com> <4F2C68E7.1000506@isi.edu> In-Reply-To: <4F2C68E7.1000506@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.116] Content-Type: multipart/signed; boundary="Apple-Mail=_0B0BF1A0-68DB-41A5-B3B7-20DD9F34BC22"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-OriginalArrivalTime: 04 Feb 2012 00:41:34.0432 (UTC) FILETIME=[BED31E00:01CCE2D5] Cc: multipathtcp Subject: Re: [multipathtcp] codepoint for mptcp options X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Feb 2012 00:41:40 -0000 --Apple-Mail=_0B0BF1A0-68DB-41A5-B3B7-20DD9F34BC22 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, On Feb 3, 2012, at 15:08, Joe Touch wrote: > #1 is appropriate if and when this is reconsidered as standards-track = only. I don't like the idea of experimental protocols using assigned = options. It burns a TCP option that can't be reclaimed. so while I'm fully in agreement with the conservation principle, let me = say that we have assigned option numbers for experimental use through = the IETF before, i.e., RFC 4782. Yes, we have only done this once, but = there is precedence. Also, could we even burn the additional byte in the beginning of the = option with MPTCP? What would the impact be, e.g., does this the amount = of SACK we can transport?=20 Finally, this is an IETF effort with (soon) multiple available = implementations. Yes, it's Experimental, but IMO it's much less = Experimental than Quickstart (RFC4782) was. MPTCP has already introduced sub-option numbers so that it can operate = using only one assigned option number. IMO we should just assign the = option number. What do others think? Lars= --Apple-Mail=_0B0BF1A0-68DB-41A5-B3B7-20DD9F34BC22 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQDCCBUow ggQyoAMCAQICEFcfSRTG0jNknqb9LV9GuFkwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEyMTAwMDAwMDBaFw0x MjEyMDkyMzU5NTlaMIIBDTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEeMBwGCSqGSIb3DQEJARYPbGFyc0BuZXRhcHAuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAokrhJTcXt6J/VEpZOicLoguBlYTjXP9v Ze4HuuhXnURUS8YouAfgaqA0zYbt5yd6fh4PBMdAaEWr5yJyHuFykXlrCumjUWSpLuqTS2A+pt4q cZaAQk9iLDN/UVd3SpkUuvWbxXlqzG7/BSqa3VNObBzCmyh+V7aXxri+30CT//DSsNRC4VFy6sn6 dMgSaFenXLwe/FBwY0qTMfICT1PrrX6Sw1S8OfH9rykLlZXbmfkFExxQngp1DJH9xMHeODHGbCv/ ty5gdxMOrLe+vENxFEcy1YQWBZd1kNL4UObugF8A/jE/s+Oa3H1VFH8ghqZTdqGDysVxmtKHuNFx 6jIBSQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNV HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMx ZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQBA7q6tR92qpd7xo7VBsrOfGCWzoxIVfTc7t0RhB/Oz/+c3lnhYnNScIuKN JmyZvznmVxqB9BJ72+NkvmdB/hnILSBTRawL2tyLo9PkBtN0nRt4gS6wjpWnD8G83hlJLE7r25jk 7HkRev61dTIXsANFpJKF02C4XSoDfEzNV6MpuEvHvcgHCqMrlwWwfKc7+NoDnE8PBuRzwSXvlD5L mswCY2iiOsd7ImNO4OzTCxETvKTDu92+FTIbRJJpYjVNv1UF7e3w9Kq65BkZJErUH19beUeQl0Wh 2BJQE6/15rQyCnP0iJ/Nmx2/kI6M0PWunEsI6FMs0MbosreaWGHlQmomMIIG7jCCBdagAwIBAgIQ cRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQL EzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYD VQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB 0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXc MM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ //6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSal J1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYI KwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0T AQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9w Y2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1h Z2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28u dmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHp MIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+v OEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSH O3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOV nDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVib vtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5J yNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggSL MIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDIwNDAwNDEzNVowIwYJKoZIhvcNAQkEMRYEFLdY Ies3d81hgC4g4rtXm5cE+L8+MIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEFcfSRTG0jNknqb9LV9GuFkwggEF BgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMA0GCSqGSIb3DQEBAQUABIIBAGOWl8ai FFitZjSr2pmE4t8996WUt/2/hFTYDbmH2iEPpuM6EB4dhwnFidL5uI1tUc6URPg8EPzxCv0Zaqlf zG7PJAv0ifCu9QBRWHxlD730D4N79WMOIP5+kXloSDW+Bm2XGRD3vDP4agVkaf3hScaYZ8WjNb0T 49d+Z19X9Qp00P9NAUri6LSkQdd/d43bznflrWqmWFtIQRl8tm2ESRcOIbBzD6XVqNetClxCUWab 15fG1DC2YQLBau1fF/cri0nuVviO+EBb7jESXeYuy8csY7Mc9rN2gJMnqM0kbhcBdDQzvsjRmSQJ IIVG4D4A4uAZLiZqxeLXQhcS+3P5jL8AAAAAAAA= --Apple-Mail=_0B0BF1A0-68DB-41A5-B3B7-20DD9F34BC22-- From wes@mti-systems.com Sat Feb 4 21:07:47 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9E3121F8493 for ; Sat, 4 Feb 2012 21:07:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gLhpfYRKrc3V for ; Sat, 4 Feb 2012 21:07:47 -0800 (PST) Received: from omr7.networksolutionsemail.com (omr7.networksolutionsemail.com [205.178.146.57]) by ietfa.amsl.com (Postfix) with ESMTP id 799C321F8475 for ; Sat, 4 Feb 2012 21:07:44 -0800 (PST) Received: from cm-omr12 (mail.networksolutionsemail.com [205.178.146.50]) by omr7.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q1557hX3006088 for ; Sun, 5 Feb 2012 00:07:43 -0500 Authentication-Results: cm-omr12 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [107.44.27.178] ([107.44.27.178:42533] helo=[68.245.171.115]) by cm-omr12 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id 1E/1B-00307-E9E0E2F4; Sun, 05 Feb 2012 00:07:43 -0500 Message-ID: <4F2E0E9F.6080802@mti-systems.com> Date: Sun, 05 Feb 2012 00:07:43 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Yoshifumi Nishida References: In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: multipathtcp Subject: Re: [multipathtcp] codepoint for mptcp options X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 05:07:47 -0000 On 2/3/2012 2:38 PM, Yoshifumi Nishida wrote: > Hello, > > After some discussions with ADs, we think we'll need to discuss which > codepoint we should use for mptcp options. > I think we have the following choices for this. > > 1: Ask IANA to allocate new codepoint > 2: Use experimental codepoint (253/254) > 3: Use experimental codepoint (253/254) with > draft-ietf-tcpm-experimental-options-00 > > If we go 1, I think we'll need to list rationales to convince IESG. > If we don't have good reason for 1, I think we'd better go 3. 2 might > not be good for wider experiments > > My concern for 3 is using draft-ietf-tcpm-experimental-options-00 will > require extra option space for magic number, which might cause issues > since some mptcp options use lots of space (e.g. DSS) > > Please let us know your thoughts on this. Based on the situation, my opinion is that *if* we can spare the resources, option 3 is functionally identical to option 1, and is "the right thing" to do. If we can't spare the space, I'm personally supportive of option 1, largely for the same reasons that Lars described. The "if" above is something I don't know the answer to. We need to "show the math" in order to justify option 1. Option 2 is definitely "wrong", based on what we know about TCP options today. When the request came to the IESG this week from IANA, in order to get an early allocation for MPTCP ("early" means prior to the RFC), I did ask that the decision be deferred until the WG could make sure it has consensus on the question Yoshifumi raised above and can technically back the need for option 1, if it's the consensus. -- Wes Eddy MTI Systems From john@jlc.net Sun Feb 5 02:35:48 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EF6F21F854F for ; Sun, 5 Feb 2012 02:35:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.359 X-Spam-Level: X-Spam-Status: No, score=-106.359 tagged_above=-999 required=5 tests=[AWL=0.240, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XrvZBiB5Y3RC for ; Sun, 5 Feb 2012 02:35:47 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 7032221F84DF for ; Sun, 5 Feb 2012 02:35:47 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 7436133C20; Sun, 5 Feb 2012 05:35:46 -0500 (EST) Date: Sun, 5 Feb 2012 05:35:46 -0500 From: John Leslie To: Wesley Eddy Message-ID: <20120205103546.GB61963@verdi> References: <4F2E0E9F.6080802@mti-systems.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F2E0E9F.6080802@mti-systems.com> User-Agent: Mutt/1.4.1i Cc: multipathtcp Subject: Re: [multipathtcp] codepoint for mptcp options X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 10:35:48 -0000 Wesley Eddy wrote: > On 2/3/2012 2:38 PM, Yoshifumi Nishida wrote: >> >> 1: Ask IANA to allocate new codepoint >> 2: Use experimental codepoint (253/254) >> 3: Use experimental codepoint (253/254) with >> draft-ietf-tcpm-experimental-options-00 I agree with Lars that we should go for a new TCP option, rather than look like an experiment. The TCP Option Number space _is_ limited, but not all that limited. In the history of TCP we've burned through 29 of 255 (the first two really don't count, IMHO, but the two "experimental" ones do). Eleven of those are considered obsolete and could be reassigned if things got _really_ tight. The actual problem in TCP Option numbers is squatting (due to the difficulty of getting option numbers allocated for experiments). IANA lists ten known cases of squatting (and IMHO will try to avoid assigning those numbers): ] ] 30 Reserved ] 31 Reserved (known unauthorized use without ] proper IANA assignment) ] 32 Reserved (known unauthorized use without ] proper IANA assignment) ] 33 Reserved (known unauthorized use without ] proper IANA assignment) ] 34-75 Reserved ] 69 Reserved (known unauthorized use without ] proper IANA assignment) ] 70 Reserved (known unauthorized use without ] proper IANA assignment) ] 71-75 Reserved ] 76 Reserved (known unauthorized use without ] proper IANA assignment) ] 77 Reserved (known unauthorized use without ] proper IANA assignment) ] 78 Reserved (known unauthorized use without ] proper IANA assignment) ] 79-252 Reserved ] 253 RFC3692-style Experiment 1 (also improperly ] used for shipping products) [*][RFC4727] ] 254 RFC3692-style Experiment 2 (also improperly ] used for shipping products) [*][RFC4727] (That asterisk is very important, IMHO) ] ] [*] It is only appropriate to use these values in explicitly- ] configured experiments; they MUST NOT be shipped as defaults in ] implementations. See [RFC3692] for details. > When the request came to the IESG this week from IANA, in order to get > an early allocation for MPTCP ("early" means prior to the RFC), I did > ask that the decision be deferred until the WG could make sure it has > consensus on the question Yoshifumi raised above and can technically > back the need for option 1, if it's the consensus. The IESG _does_ need to be careful in assigning these, but they have every reason to believe Lars understands the trade-offs. I doubt they will actually assign one without Wes agreeing to recommend it, but I don't believe they will get anal about whether the RFC defining it is "Experimental" status. MPTCP is a very necessary addition to TCP. IMHO we're chartered to produce an Experimental spec because it's considered so important that we need to get it right. If something _does_ go wrong, we'll keep at it until we get it right; and in the almost-unimaginable case where the Experimental use has to be suppressed, that will be far easier with a dedicated option number. -- John Leslie From georg.hampel@alcatel-lucent.com Wed Feb 8 10:15:36 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5E30821F86EB for ; Wed, 8 Feb 2012 10:15:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.618 X-Spam-Level: X-Spam-Status: No, score=-7.618 tagged_above=-999 required=5 tests=[AWL=-1.020, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LmpnemQvwYFU for ; Wed, 8 Feb 2012 10:15:35 -0800 (PST) Received: from ihemail3.lucent.com (ihemail3.lucent.com [135.245.0.37]) by ietfa.amsl.com (Postfix) with ESMTP id 04ED621F86EE for ; Wed, 8 Feb 2012 10:15:32 -0800 (PST) Received: from usnavsmail1.ndc.alcatel-lucent.com (usnavsmail1.ndc.alcatel-lucent.com [135.3.39.9]) by ihemail3.lucent.com (8.13.8/IER-o) with ESMTP id q18IFTxN004199 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 8 Feb 2012 12:15:30 -0600 (CST) Received: from USNAVSXCHHUB03.ndc.alcatel-lucent.com (usnavsxchhub03.ndc.alcatel-lucent.com [135.3.39.112]) by usnavsmail1.ndc.alcatel-lucent.com (8.14.3/8.14.3/GMO) with ESMTP id q18IFTJp013976 (version=TLSv1/SSLv3 cipher=RC4-MD5 bits=128 verify=NOT) for ; Wed, 8 Feb 2012 12:15:29 -0600 Received: from USNAVSXCHMBSA2.ndc.alcatel-lucent.com ([135.3.39.124]) by USNAVSXCHHUB03.ndc.alcatel-lucent.com ([135.3.39.112]) with mapi; Wed, 8 Feb 2012 12:15:29 -0600 From: "Hampel, K Georg (K Georg)" To: "multipathtcp@ietf.org" Date: Wed, 8 Feb 2012 12:15:28 -0600 Thread-Topic: New draft: MPTCP proxies & anchors Thread-Index: AczmjaLZks51LbdmQ12Mo93NpUiw4w== Message-ID: <154773479ED2314980CB638A48FC443488EC32FF@USNAVSXCHMBSA2.ndc.alcatel-lucent.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: multipart/alternative; boundary="_000_154773479ED2314980CB638A48FC443488EC32FFUSNAVSXCHMBSA2n_" MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.57 on 135.245.2.37 X-Scanned-By: MIMEDefang 2.64 on 135.3.39.9 Subject: [multipathtcp] New draft: MPTCP proxies & anchors X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Feb 2012 18:15:36 -0000 --_000_154773479ED2314980CB638A48FC443488EC32FFUSNAVSXCHMBSA2n_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable All, We have posted a new I-D with the title: "MPTCP Proxies and Anchors": http://www.ietf.org/id/draft-hampel-mptcp-proxies-anchors-00.txt The MPTCP proxy has already been discussed in the WG. We also introduce the= MPTCP anchor which supports end-to-end MPTCP connections and is a logical = complement to the proxy. In this draft, we work through various scenarios where proxies/anchors shou= ld/could be supported and what the implications are for MPTCP signaling. So= me of the issues have already been identified before, e.g. in our draft fro= m June 2011, ML discussions and conference call late 2011. Others are new. We invite everybody to read the draft and to provide comments. Thanks. Regards, - Georg --_000_154773479ED2314980CB638A48FC443488EC32FFUSNAVSXCHMBSA2n_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

All,

 

We have posted a new I-D with the title: “MPTCP Pr= oxies and Anchors”:

 

h= ttp://www.ietf.org/id/draft-hampel-mptcp-proxies-anchors-00.txt

 

The MPTCP proxy has already been discussed in the WG. We also introduce the MPTCP anchor which supports end-to-end MPTCP connections= and is a logical complement to the proxy.

 

In this draft, we work through various scenarios where p= roxies/anchors should/could be supported and what the implications are for MPTCP signaling= . Some of the issues have already been identified before, e.g. in our draft from J= une 2011, ML discussions and conference call late 2011. Others are new.

 

We invite everybody to read the draft and to provide com= ments. Thanks.

 

Regards,

 

- Georg

 

 

 

 

--_000_154773479ED2314980CB638A48FC443488EC32FFUSNAVSXCHMBSA2n_-- From Michael.Scharf@alcatel-lucent.com Thu Feb 9 15:17:44 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 056B821F85D6 for ; Thu, 9 Feb 2012 15:17:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.226 X-Spam-Level: X-Spam-Status: No, score=-6.226 tagged_above=-999 required=5 tests=[AWL=0.023, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7y4qgV8hN-D0 for ; Thu, 9 Feb 2012 15:17:41 -0800 (PST) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by ietfa.amsl.com (Postfix) with ESMTP id B3B5D21F85D7 for ; Thu, 9 Feb 2012 15:17:40 -0800 (PST) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id q19NHbkv023476; Fri, 10 Feb 2012 00:17:37 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Feb 2012 00:17:33 +0100 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C06C80A4C@SLFSNX.rcs.alcatel-research.de> In-Reply-To: <20120203162822.GM46701@verdi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] WG Last call for Multipath TCP API doc Thread-Index: AczikOBW42TWZbjdRFStn1Wp+r4BBwE5EwOg References: <9510D26531EF184D9017DF24659BB87F3317E442F8@EMV65-UKRD.domain1.systemhost.net> <20120203162822.GM46701@verdi> From: "SCHARF, Michael" To: "John Leslie" , X-Scanned-By: MIMEDefang 2.69 on 149.204.45.73 Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] WG Last call for Multipath TCP API doc X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Feb 2012 23:17:44 -0000 > > This is to announce the WG last call for "MPTCP Application=20 > Interface=20 > > Considerations" http://tools.ietf.org/html/draft-ietf-mptcp-api-03 >=20 > ] 7. Security Considerations > ] > ] Will be added in a later version of this document. >=20 > I don't think this is appropriate. Yes, fully agreed. Sorry for that. I'll submit an update that fixes this ASAP. As a starting point, my first draft for that section would be: This document defines a backward-compatible API for MPTCP-unaware applications. As the function offered by this interface is equivalent to existing APIs and doesn't offer additional functionality, the interface design does not result in new security issues. In general, enabling MPTCP has some security implications for applications, which are introduced in Section 3.2.3, and these threads are further detailed in RFC 6181. The protocol specification of MPTCP [5] defines several mechanism to protect MPTCP against those attacks. In addition, the basic MPTCP API for MPTCP-aware applications defines functions that provide an equivalent level of control and information as exists for regular TCP. New functions enable adding and removing local addresses from an MPTCP connection (TCP_MULTIPATH_ADD and TCP_MULTIPATH_REMOVE). These functions don't add security threads if the MPTCP stack verifies whether the addresses provided by the application are indeed assigned to local interfaces. However, applications should use the TCP_MULTIPATH_ADD function with care, as new subflows might get established to those addresses. Furthermore, it could result in some form of information leakage since MPTCP might advertise those addresses to the other connection endpoint, which could learn IP addresses of interfaces that are not visible otherwise. MPTCP-aware applications should also take care when querying and using information about the addresses used by subflows (TCP_MULTIPATH_SUBFLOWS). As MPTCP can dynamically open and close subflows, a list of addresses queried once can get outdated during the lifetime of an MPTCP connection. Then, the list may contain invalid entries, i. e., addresses that are not used any more or that might not even be valid. Applications that want to ensure that MPTCP only uses a certain set of addresses should explicitly bind to those addresses. Of course, I'd also welcome further suggestions. > It's not that I think a _discussion_ of requirements for=20 > some future API needs much in the way of Security=20 > Considerations; but this should not be punted to "some future=20 > version". >=20 > ] 5.2. Requirements on the Basic MPTCP API ]... > ] REQ1: Turn on/off MPTCP: An application should be able to request to > ] turn on or turn off the usage of MPTCP. This means that an > ] application should be able to explicitly request the use of > ] MPTCP if this is possible. Applications should also be able > ] to request not to enable MPTCP and to use regular TCP > ] transport instead. This can be implicit in many cases, since > ] MPTCP must disabled by the use of binding to a specific > ] address. MPTCP may also be enabled if an application uses a > ] dedicated multipath address family (such as AF_MULTIPATH, > ] [9]). >=20 > I stumbled over this: what should happen if an application=20 > _both_ requests to enable MPTCP _and_ to bind to a specific address? >=20 > (I don't care a lot, and it's even OK with me to leave=20 > this poorly defined; but if we have a strong opinion it's=20 > better to make it > explicit.) In that case, the general rule from Section 4.2.1 should apply: "If an application uses a specific address or binds to a specific interface, then MPTCP MUST respect this and not interfere in the application's choices." In other words, if the application does not explicitly add other local addresses by TCP_MULTIPATH_ADD, MPTCP must only use this specific local address. Obviously, if the remote peer has several addresses, several subflows to those different addresses may be used, since MPTCP is explicitly enabled. Given that binding is a legacy function call and thus discussed in Section 4, I thought that this is clear. If not, we can think of adding a sentence in Section 5 as well. Thanks for the feedback! Michael From john@jlc.net Fri Feb 10 02:21:43 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E08021F8635 for ; Fri, 10 Feb 2012 02:21:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.371 X-Spam-Level: X-Spam-Status: No, score=-106.371 tagged_above=-999 required=5 tests=[AWL=0.228, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zNLjbSQ+IDAu for ; Fri, 10 Feb 2012 02:21:42 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9A721F8627 for ; Fri, 10 Feb 2012 02:21:41 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 2DBB133C27; Fri, 10 Feb 2012 05:21:41 -0500 (EST) Date: Fri, 10 Feb 2012 05:21:41 -0500 From: John Leslie To: "SCHARF, Michael" Message-ID: <20120210102141.GR61963@verdi> References: <9510D26531EF184D9017DF24659BB87F3317E442F8@EMV65-UKRD.domain1.systemhost.net> <20120203162822.GM46701@verdi> <133D9897FB9C5E4E9DF2779DC91E947C06C80A4C@SLFSNX.rcs.alcatel-research.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C06C80A4C@SLFSNX.rcs.alcatel-research.de> User-Agent: Mutt/1.4.1i Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] WG Last call for Multipath TCP API doc X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 10:21:43 -0000 SCHARF, Michael wrote: > >>> http://tools.ietf.org/html/draft-ietf-mptcp-api-03 >> >>] 7. Security Considerations >>] >>] Will be added in a later version of this document. >> >> I don't think this is appropriate. > > Yes, fully agreed. Sorry for that. I'll submit an update that fixes this > ASAP. > > As a starting point, my first draft for that section would be: > > > > This document defines a backward-compatible API for MPTCP-unaware > applications. As the function offered by this interface is equivalent to > existing APIs and doesn't offer additional functionality, the interface > design does not result in new security issues. In general, enabling > MPTCP has some security implications for applications, which are > introduced in Section 3.2.3, and these threads are further detailed in > RFC 6181. The protocol specification of MPTCP [5] defines several > mechanism to protect MPTCP against those attacks. > > In addition, the basic MPTCP API for MPTCP-aware applications defines > functions that provide an equivalent level of control and information as > exists for regular TCP. New functions enable adding and removing local > addresses from an MPTCP connection (TCP_MULTIPATH_ADD and > TCP_MULTIPATH_REMOVE). These functions don't add security threads if the ^^^^^^^ did you mean "threats"? > MPTCP stack verifies whether the addresses provided by the application > are indeed assigned to local interfaces. However, applications should > use the TCP_MULTIPATH_ADD function with care, as new subflows might get > established to those addresses. Furthermore, it could result in some > form of information leakage since MPTCP might advertise those addresses > to the other connection endpoint, which could learn IP addresses of > interfaces that are not visible otherwise. > > MPTCP-aware applications should also take care when querying and using > information about the addresses used by subflows > (TCP_MULTIPATH_SUBFLOWS). As MPTCP can dynamically open and close > subflows, a list of addresses queried once can get outdated during the > lifetime of an MPTCP connection. Then, the list may contain invalid > entries, i. e., addresses that are not used any more or that might not > even be valid. Applications that want to ensure that MPTCP only uses a > certain set of addresses should explicitly bind to those addresses. > > WFM >>] 5.2. Requirements on the Basic MPTCP API ]... >>] REQ1: Turn on/off MPTCP: An application should be able to request to >>] turn on or turn off the usage of MPTCP. This means that an >>] application should be able to explicitly request the use of >>] MPTCP if this is possible. Applications should also be able >>] to request not to enable MPTCP and to use regular TCP >>] transport instead. This can be implicit in many cases, since >>] MPTCP must disabled by the use of binding to a specific >>] address. MPTCP may also be enabled if an application uses a >>] dedicated multipath address family (such as AF_MULTIPATH, >>] [9]). >> >> I stumbled over this: what should happen if an application >> _both_ requests to enable MPTCP _and_ to bind to a specific address? >> >> (I don't care a lot, and it's even OK with me to leave >> this poorly defined; but if we have a strong opinion it's >> better to make it explicit.) > > In that case, the general rule from Section 4.2.1 should apply: "If an > application uses a specific address or binds to a specific interface, > then MPTCP MUST respect this and not interfere in the application's > choices." > > In other words, if the application does not explicitly add other local > addresses by TCP_MULTIPATH_ADD, MPTCP must only use this specific local > address. Obviously, if the remote peer has several addresses, several > subflows to those different addresses may be used, since MPTCP is > explicitly enabled. > > Given that binding is a legacy function call and thus discussed in > Section 4, I thought that this is clear. If not, we can think of adding > a sentence in Section 5 as well. I merely "stumbled" -- this wasn't obvious to me when I read it. Presumably if I were implementing, I'd read Section 4 again. As I recall, I got to Section 5.2 with an impression than "bind to specific address" _implied_ disabling MPTCP, rather than allowing MPTCP but limiting this end to the specific address. Alas, I have no specific text to offer... -- John Leslie From Michael.Scharf@alcatel-lucent.com Fri Feb 10 04:27:46 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F63E21F84F8 for ; Fri, 10 Feb 2012 04:27:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.227 X-Spam-Level: X-Spam-Status: No, score=-6.227 tagged_above=-999 required=5 tests=[AWL=0.022, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AwivOQfOulag for ; Fri, 10 Feb 2012 04:27:46 -0800 (PST) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by ietfa.amsl.com (Postfix) with ESMTP id BB13721F84F7 for ; Fri, 10 Feb 2012 04:27:45 -0800 (PST) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id q1ACRgG0007384; Fri, 10 Feb 2012 13:27:42 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Fri, 10 Feb 2012 13:27:39 +0100 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C06C80A9D@SLFSNX.rcs.alcatel-research.de> In-Reply-To: <20120210102141.GR61963@verdi> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] WG Last call for Multipath TCP API doc Thread-Index: Aczn3cuizudw5PfiRh6ydGWhRqT+nQAEQ7vA References: <9510D26531EF184D9017DF24659BB87F3317E442F8@EMV65-UKRD.domain1.systemhost.net> <20120203162822.GM46701@verdi> <133D9897FB9C5E4E9DF2779DC91E947C06C80A4C@SLFSNX.rcs.alcatel-research.de> <20120210102141.GR61963@verdi> From: "SCHARF, Michael" To: "John Leslie" X-Scanned-By: MIMEDefang 2.69 on 149.204.45.73 Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] WG Last call for Multipath TCP API doc X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 12:27:46 -0000 > > In addition, the basic MPTCP API for MPTCP-aware=20 > applications defines=20 > > functions that provide an equivalent level of control and=20 > information=20 > > as exists for regular TCP. New functions enable adding and=20 > removing=20 > > local addresses from an MPTCP connection (TCP_MULTIPATH_ADD and=20 > > TCP_MULTIPATH_REMOVE). These functions don't add security=20 > threads if=20 > > the > ^^^^^^^ > did you mean "threats"? Yes, this is obviously a spelling error (actually, it occured even more than once). Thanks for pointing that out! Michael From touch@isi.edu Fri Feb 10 12:01:18 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 546A811E80D7 for ; Fri, 10 Feb 2012 12:01:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.025 X-Spam-Level: X-Spam-Status: No, score=-103.025 tagged_above=-999 required=5 tests=[AWL=-0.426, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aGZE1b8+F4Q9 for ; Fri, 10 Feb 2012 12:01:16 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 7816411E80F5 for ; Fri, 10 Feb 2012 12:01:14 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q1AK0bqs026063 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 10 Feb 2012 12:00:37 -0800 (PST) Message-ID: <4F357765.30908@isi.edu> Date: Fri, 10 Feb 2012 12:00:37 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: John Leslie References: <9510D26531EF184D9017DF24659BB87F3317E442F8@EMV65-UKRD.domain1.systemhost.net> <20120203162822.GM46701@verdi> <133D9897FB9C5E4E9DF2779DC91E947C06C80A4C@SLFSNX.rcs.alcatel-research.de> <20120210102141.GR61963@verdi> In-Reply-To: <20120210102141.GR61963@verdi> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] WG Last call for Multipath TCP API doc X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Feb 2012 20:01:20 -0000 On 2/10/2012 2:21 AM, John Leslie wrote: > SCHARF, Michael wrote: >> >>>> http://tools.ietf.org/html/draft-ietf-mptcp-api-03 >>> >>> ] 7. Security Considerations >>> ] >>> ] Will be added in a later version of this document. >>> >>> I don't think this is appropriate. >> >> Yes, fully agreed. Sorry for that. I'll submit an update that fixes this >> ASAP. >> >> As a starting point, my first draft for that section would be: >> >> >> >> This document defines a backward-compatible API for MPTCP-unaware >> applications. As the function offered by this interface is equivalent to >> existing APIs and doesn't offer additional functionality, the interface >> design does not result in new security issues. In general, enabling >> MPTCP has some security implications for applications, which are >> introduced in Section 3.2.3, and these threads are further detailed in >> RFC 6181. The protocol specification of MPTCP [5] defines several >> mechanism to protect MPTCP against those attacks. >> >> In addition, the basic MPTCP API for MPTCP-aware applications defines >> functions that provide an equivalent level of control and information as >> exists for regular TCP. New functions enable adding and removing local >> addresses from an MPTCP connection (TCP_MULTIPATH_ADD and >> TCP_MULTIPATH_REMOVE). These functions don't add security threads if the > ^^^^^^^ > did you mean "threats"? > >> MPTCP stack verifies whether the addresses provided by the application >> are indeed assigned to local interfaces. It's worth noting here that this decision may be impossible, esp. given the prevalence of network and host virtualization and remote interface support. It might be useful somewhere here to also remind users that this isn't a path separation mechanism; it is an *address* separation one. Addresses should be used to assume path differentiation, esp. for security reasons. Joe From Michael.Scharf@alcatel-lucent.com Sun Feb 12 03:18:30 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B4D0B21F861D for ; Sun, 12 Feb 2012 03:18:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.228 X-Spam-Level: X-Spam-Status: No, score=-6.228 tagged_above=-999 required=5 tests=[AWL=0.021, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mfbM85nLpq43 for ; Sun, 12 Feb 2012 03:18:30 -0800 (PST) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by ietfa.amsl.com (Postfix) with ESMTP id E2E0521F8625 for ; Sun, 12 Feb 2012 03:18:29 -0800 (PST) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id q1CBIR7L032324; Sun, 12 Feb 2012 12:18:28 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Sun, 12 Feb 2012 12:18:24 +0100 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C06C80ADB@SLFSNX.rcs.alcatel-research.de> In-Reply-To: <4F357765.30908@isi.edu> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [multipathtcp] WG Last call for Multipath TCP API doc Thread-Index: AczoMN60aLDMTV1yQUipfjUCHaOwzgBQ5Ckg References: <20120210102141.GR61963@verdi> <4F357765.30908@isi.edu> From: "SCHARF, Michael" To: "Joe Touch" , "John Leslie" X-Scanned-By: MIMEDefang 2.69 on 149.204.45.73 Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] WG Last call for Multipath TCP API doc X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 12 Feb 2012 11:18:30 -0000 > >> > >> > >> This document defines a backward-compatible API for MPTCP-unaware=20 > >> applications. As the function offered by this interface is=20 > equivalent=20 > >> to existing APIs and doesn't offer additional functionality, the=20 > >> interface design does not result in new security issues.=20 > In general,=20 > >> enabling MPTCP has some security implications for=20 > applications, which=20 > >> are introduced in Section 3.2.3, and these threads are further=20 > >> detailed in RFC 6181. The protocol specification of MPTCP=20 > [5] defines=20 > >> several mechanism to protect MPTCP against those attacks. > >> > >> In addition, the basic MPTCP API for MPTCP-aware=20 > applications defines=20 > >> functions that provide an equivalent level of control and=20 > information=20 > >> as exists for regular TCP. New functions enable adding=20 > and removing=20 > >> local addresses from an MPTCP connection (TCP_MULTIPATH_ADD and=20 > >> TCP_MULTIPATH_REMOVE). These functions don't add security=20 > threads if=20 > >> the > > ^^^^^^^ > > did you mean "threats"? > > > >> MPTCP stack verifies whether the addresses provided by the=20 > >> application are indeed assigned to local interfaces. >=20 > It's worth noting here that this decision may be impossible,=20 > esp. given the prevalence of network and host virtualization=20 > and remote interface support. The key point of this sentence is that providing hints for additional "local" addresses doesn't really result in security issues. But, right, the term "local interface" might be misleading. One alternative could be: "These functions don't add security threats if the MPTCP stack verifies whether the addresses provided by the application are indeed available as source addresses for subflows." Does this sort out your concern? A TCP stack can today determine what addresses it can use as source for TCP connections, and this text suggests basically the same check. > It might be useful somewhere here to also remind users that=20 > this isn't a path separation mechanism; it is an *address*=20 > separation one. Addresses should be used to assume path=20 > differentiation, esp. for security reasons. I don't fully understand how this relates to security considerations. The basic API only allows to add/remove "local" addresses, which inherently doesn't provide path control. The interface doesn't enable an app to ask for a "remote" address to be added to the connection. Do you have a specific suggestion for a sentence to be added? Personally, I think that the distinction between "address" and "path" could instead be discussed in Section 5.1 "Design Considerations". We could explain there that adding/removing addresses doesn't provide a path selection mechanism, and that applications cannot assume that using different addresses indeed result in different path. It may be quite obvious, but we could explain it just to be on the safe side. Thanks! Michael From touch@isi.edu Mon Feb 13 09:23:24 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0ED9821F851C for ; Mon, 13 Feb 2012 09:23:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.984 X-Spam-Level: X-Spam-Status: No, score=-102.984 tagged_above=-999 required=5 tests=[AWL=-0.385, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Et65DRpMe7J1 for ; Mon, 13 Feb 2012 09:23:23 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id E26E821F86C8 for ; Mon, 13 Feb 2012 09:23:22 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q1DHMoxU001423 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 13 Feb 2012 09:22:50 -0800 (PST) Message-ID: <4F3946EA.7060700@isi.edu> Date: Mon, 13 Feb 2012 09:22:50 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "SCHARF, Michael" References: <20120210102141.GR61963@verdi> <4F357765.30908@isi.edu> <133D9897FB9C5E4E9DF2779DC91E947C06C80ADB@SLFSNX.rcs.alcatel-research.de> In-Reply-To: <133D9897FB9C5E4E9DF2779DC91E947C06C80ADB@SLFSNX.rcs.alcatel-research.de> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] WG Last call for Multipath TCP API doc X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 17:23:24 -0000 Hi, Michael, On 2/12/2012 3:18 AM, SCHARF, Michael wrote: >>>> >>>> >>>> This document defines a backward-compatible API for MPTCP-unaware >>>> applications. As the function offered by this interface is >> equivalent >>>> to existing APIs and doesn't offer additional functionality, the >>>> interface design does not result in new security issues. >> In general, >>>> enabling MPTCP has some security implications for >> applications, which >>>> are introduced in Section 3.2.3, and these threads are further >>>> detailed in RFC 6181. The protocol specification of MPTCP >> [5] defines >>>> several mechanism to protect MPTCP against those attacks. >>>> >>>> In addition, the basic MPTCP API for MPTCP-aware >> applications defines >>>> functions that provide an equivalent level of control and >> information >>>> as exists for regular TCP. New functions enable adding >> and removing >>>> local addresses from an MPTCP connection (TCP_MULTIPATH_ADD and >>>> TCP_MULTIPATH_REMOVE). These functions don't add security >> threads if >>>> the >>> ^^^^^^^ >>> did you mean "threats"? >>> >>>> MPTCP stack verifies whether the addresses provided by the >>>> application are indeed assigned to local interfaces. >> >> It's worth noting here that this decision may be impossible, >> esp. given the prevalence of network and host virtualization >> and remote interface support. > > The key point of this sentence is that providing hints for additional > "local" addresses doesn't really result in security issues. > > But, right, the term "local interface" might be misleading. One > alternative could be: "These functions don't add security threats if the > MPTCP stack verifies whether the addresses provided by the application > are indeed available as source addresses for subflows." > > Does this sort out your concern? A TCP stack can today determine what > addresses it can use as source for TCP connections, and this text > suggests basically the same check. Yes - the point being that 'available as source addresses' isn't the same thing as "local interface". >> It might be useful somewhere here to also remind users that >> this isn't a path separation mechanism; it is an *address* >> separation one. Addresses should be used to assume path >> differentiation, esp. for security reasons. > > I don't fully understand how this relates to security considerations. > The basic API only allows to add/remove "local" addresses, which > inherently doesn't provide path control. The interface doesn't enable an > app to ask for a "remote" address to be added to the connection. Do you > have a specific suggestion for a sentence to be added? "Addresses should not be used to assume path differentiation, especially for security purposes." > Personally, I think that the distinction between "address" and "path" > could instead be discussed in Section 5.1 "Design Considerations". We > could explain there that adding/removing addresses doesn't provide a > path selection mechanism, and that applications cannot assume that using > different addresses indeed result in different path. It may be quite > obvious, but we could explain it just to be on the safe side. It's not at all obvious; I gave this as a reason this variant has a misleading name back in its BOF days. It's multi-address TCP, not multipath. The longer the inaccurate name persists, the more important it is to note the difference *in every place it is relevant*. Joe From scott.brim@gmail.com Mon Feb 13 11:19:24 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC09521F86B9 for ; Mon, 13 Feb 2012 11:19:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FuuIFt2FMEWJ for ; Mon, 13 Feb 2012 11:19:24 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5BE4821F86A0 for ; Mon, 13 Feb 2012 11:19:24 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so5060336pbc.31 for ; Mon, 13 Feb 2012 11:19:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=Fqe8agcY1ZESDKPRw5/z6Dg+SJt+qXl/XH9mEq6mzpM=; b=RxgrPsNfB11iS6SHVUlubhJmqP3B2k2XSZogJjuMezjKfX7gOsE9KZIYC7y2Y8DElN l3+clU+gKxzW+3zYcBdBp6aRvbMMIuP0xgujpShqXrpLHk1UFH2vJiw6Saw6nbjcxyeJ +czX2NmxS0Q6U9WFz/pUHm5E06dCQZ8YkqPOg= Received: by 10.68.74.167 with SMTP id u7mr50034262pbv.103.1329160764204; Mon, 13 Feb 2012 11:19:24 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.67.202 with HTTP; Mon, 13 Feb 2012 11:19:04 -0800 (PST) In-Reply-To: <4F3946EA.7060700@isi.edu> References: <20120210102141.GR61963@verdi> <4F357765.30908@isi.edu> <133D9897FB9C5E4E9DF2779DC91E947C06C80ADB@SLFSNX.rcs.alcatel-research.de> <4F3946EA.7060700@isi.edu> From: Scott Brim Date: Mon, 13 Feb 2012 14:19:04 -0500 Message-ID: To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] WG Last call for Multipath TCP API doc X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 19:19:25 -0000 On Mon, Feb 13, 2012 at 12:22, Joe Touch wrote: > Hi, Michael, > > On 2/12/2012 3:18 AM, SCHARF, Michael wrote: >>>>> MPTCP stack verifies whether the addresses provided by the >>>>> application are indeed assigned to local interfaces. >>> >>> It's worth noting here that this decision may be impossible, >>> esp. given the prevalence of network and host virtualization >>> and remote interface support. >> >> The key point of this sentence is that providing hints for additional >> "local" addresses doesn't really result in security issues. >> >> But, right, the term "local interface" might be misleading. One >> alternative could be: "These functions don't add security threats if the >> MPTCP stack verifies whether the addresses provided by the application >> are indeed available as source addresses for subflows." >> >> Does this sort out your concern? A TCP stack can today determine what >> addresses it can use as source for TCP connections, and this text >> suggests basically the same check. > > Yes - the point being that 'available as source addresses' isn't the same > thing as "local interface". Is there a case where "available as a source address" does not imply "assigned to a local interface", whether real or virtual? > "Addresses should not be used to assume path differentiation, especially for > security purposes." imho: "Use of different addresses should not be assumed to lead to use of different paths, especially for security purposes." > It's not at all obvious; I gave this as a reason this variant has a > misleading name back in its BOF days. It's multi-address TCP, not multipath. > > The longer the inaccurate name persists, the more important it is to note > the difference *in every place it is relevant*. Since the inaccurate name will last until research brings network capabilities up to a level where we can match the name :-), I agree. Scott From touch@isi.edu Mon Feb 13 11:57:30 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55B9021F84EA for ; Mon, 13 Feb 2012 11:57:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.977 X-Spam-Level: X-Spam-Status: No, score=-102.977 tagged_above=-999 required=5 tests=[AWL=-0.378, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UwgS1XsXD0rB for ; Mon, 13 Feb 2012 11:57:29 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 2F25A21F84B5 for ; Mon, 13 Feb 2012 11:57:24 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q1DJuoht027455 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 13 Feb 2012 11:56:50 -0800 (PST) Message-ID: <4F396B02.8000608@isi.edu> Date: Mon, 13 Feb 2012 11:56:50 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: Scott Brim References: <20120210102141.GR61963@verdi> <4F357765.30908@isi.edu> <133D9897FB9C5E4E9DF2779DC91E947C06C80ADB@SLFSNX.rcs.alcatel-research.de> <4F3946EA.7060700@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] WG Last call for Multipath TCP API doc X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Feb 2012 19:57:30 -0000 On 2/13/2012 11:19 AM, Scott Brim wrote: > On Mon, Feb 13, 2012 at 12:22, Joe Touch wrote: >> Hi, Michael, >> >> On 2/12/2012 3:18 AM, SCHARF, Michael wrote: >>>>>> MPTCP stack verifies whether the addresses provided by the >>>>>> application are indeed assigned to local interfaces. >>>> >>>> It's worth noting here that this decision may be impossible, >>>> esp. given the prevalence of network and host virtualization >>>> and remote interface support. >>> >>> The key point of this sentence is that providing hints for additional >>> "local" addresses doesn't really result in security issues. >>> >>> But, right, the term "local interface" might be misleading. One >>> alternative could be: "These functions don't add security threats if the >>> MPTCP stack verifies whether the addresses provided by the application >>> are indeed available as source addresses for subflows." >>> >>> Does this sort out your concern? A TCP stack can today determine what >>> addresses it can use as source for TCP connections, and this text >>> suggests basically the same check. >> >> Yes - the point being that 'available as source addresses' isn't the same >> thing as "local interface". > > Is there a case where "available as a source address" does not imply > "assigned to a local interface", whether real or virtual? Sure - where addresses are assigned to multiple interfaces (either inside a single machine or on different machines), where addresses are deliberately used that are not on the local machine (e.g., "spoofing", where legitimate use of spoofing exists inside an organization that owns both the box that's spoofing and the IP address), etc. >> "Addresses should not be used to assume path differentiation, especially for >> security purposes." > > imho: "Use of different addresses should not be assumed to lead to use > of different paths, especially for security purposes." WFM. >> It's not at all obvious; I gave this as a reason this variant has a >> misleading name back in its BOF days. It's multi-address TCP, not multipath. >> >> The longer the inaccurate name persists, the more important it is to note >> the difference *in every place it is relevant*. > > Since the inaccurate name will last until research brings network > capabilities up to a level where we can match the name :-), I agree. Single pairs of addresses can use multiple paths (dynamic routing), and different addresses can use the same path. Is this research for, e.g., geographic addressing (IPv9?) Joe From c.raiciu@cs.ucl.ac.uk Tue Feb 14 00:32:35 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BBB721F85AF for ; Tue, 14 Feb 2012 00:32:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9bL2NjHG5fNS for ; Tue, 14 Feb 2012 00:32:34 -0800 (PST) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by ietfa.amsl.com (Postfix) with ESMTP id 3249621F85BE for ; Tue, 14 Feb 2012 00:32:34 -0800 (PST) Received: from [92.80.108.21] (helo=[192.168.1.8]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1RxDnt-0001KP-4n; Tue, 14 Feb 2012 08:32:01 +0000 Mime-Version: 1.0 (Apple Message framework v1084) Content-Type: text/plain; charset=us-ascii From: Costin Raiciu In-Reply-To: <20120205103546.GB61963@verdi> Date: Tue, 14 Feb 2012 10:32:16 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <4F2E0E9F.6080802@mti-systems.com> <20120205103546.GB61963@verdi> To: multipathtcp X-Mailer: Apple Mail (2.1084) Cc: Mark Handley Subject: Re: [multipathtcp] codepoint for mptcp options X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 08:32:35 -0000 Hi, As draft authors, we also strongly support going for a new codepoint.=20 While we could make the experimental ones work with a lot of non-trivial = bit gimnastics, it will be quite painful and may push us over the edge = in what option usage is acceptable in practice. Furthermore, MPTCP has lots of extensibility built in: a version field = in the initial handshake, and different sub-types, have both been = designed to ensure MPTCP only needs one codepoint for its deployment. MPTCP is an important change to TCP whose time has come, as networks are = effectively becoming multipath everywhere (mobiles device with many = interfaces, wide-scale server multihoming and datacenters). As Lars said = there is considerable interest in MPTCP: - we have a solid Linux MPTCP stack that we are planning to push = upstream starting the end of this year (this has been funded recently by = Google, and Intel is also helping out with coding). - a planned FreeBSD MPTCP implementation has been funded recently - Intel are actively working on integrating MPTCP on Android and seeing = how MPTCP works for mobility. That is why I think MPTCP could evolve to Proposed Standard sooner = rather than later. Even if we go with experimental codepoints now, when = MPTCP evolves to PS we will need a new properly assigned codepoint. = Using an experimental codepoint will only make evolution to proposed = standard harder due to interop problems between the different MPTCP = stacks. Cheers, Costin On 5 Feb 2012, at 12:35, John Leslie wrote: > Wesley Eddy wrote: >> On 2/3/2012 2:38 PM, Yoshifumi Nishida wrote: >>>=20 >>> 1: Ask IANA to allocate new codepoint >>> 2: Use experimental codepoint (253/254) >>> 3: Use experimental codepoint (253/254) with >>> draft-ietf-tcpm-experimental-options-00 >=20 > I agree with Lars that we should go for a new TCP option, rather = than > look like an experiment. >=20 > The TCP Option Number space _is_ limited, but not all that limited. > In the history of TCP we've burned through 29 of 255 (the first two > really don't count, IMHO, but the two "experimental" ones do). Eleven > of those are considered obsolete and could be reassigned if things > got _really_ tight. >=20 > The actual problem in TCP Option numbers is squatting (due to the > difficulty of getting option numbers allocated for experiments). > IANA lists ten known cases of squatting (and IMHO will try to avoid > assigning those numbers): > ]=20 > ] 30 Reserved > ] 31 Reserved (known unauthorized use without > ] proper IANA assignment) > ] 32 Reserved (known unauthorized use without > ] proper IANA assignment) > ] 33 Reserved (known unauthorized use without > ] proper IANA assignment) > ] 34-75 Reserved > ] 69 Reserved (known unauthorized use without > ] proper IANA assignment) > ] 70 Reserved (known unauthorized use without > ] proper IANA assignment) > ] 71-75 Reserved > ] 76 Reserved (known unauthorized use without > ] proper IANA assignment) > ] 77 Reserved (known unauthorized use without > ] proper IANA assignment) > ] 78 Reserved (known unauthorized use without > ] proper IANA assignment) > ] 79-252 Reserved > ] 253 RFC3692-style Experiment 1 (also improperly > ] used for shipping products) [*][RFC4727] > ] 254 RFC3692-style Experiment 2 (also improperly > ] used for shipping products) [*][RFC4727] >=20 > (That asterisk is very important, IMHO) > ]=20 > ] [*] It is only appropriate to use these values in explicitly- > ] configured experiments; they MUST NOT be shipped as defaults in > ] implementations. See [RFC3692] for details. >=20 >> When the request came to the IESG this week from IANA, in order to = get >> an early allocation for MPTCP ("early" means prior to the RFC), I did >> ask that the decision be deferred until the WG could make sure it has >> consensus on the question Yoshifumi raised above and can technically >> back the need for option 1, if it's the consensus. >=20 > The IESG _does_ need to be careful in assigning these, but they > have every reason to believe Lars understands the trade-offs. I doubt > they will actually assign one without Wes agreeing to recommend it, > but I don't believe they will get anal about whether the RFC defining > it is "Experimental" status. >=20 > MPTCP is a very necessary addition to TCP. IMHO we're chartered to > produce an Experimental spec because it's considered so important that > we need to get it right. If something _does_ go wrong, we'll keep at > it until we get it right; and in the almost-unimaginable case where > the Experimental use has to be suppressed, that will be far easier > with a dedicated option number. >=20 > -- > John Leslie > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From guillaume.dugue@laas.fr Tue Feb 14 00:59:52 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8603621F8799 for ; Tue, 14 Feb 2012 00:59:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ei1UgC4xLbXB for ; Tue, 14 Feb 2012 00:59:52 -0800 (PST) Received: from laas.laas.fr (laas.laas.fr [IPv6:2001:660:6602:4::2]) by ietfa.amsl.com (Postfix) with ESMTP id AA7D421F8798 for ; Tue, 14 Feb 2012 00:59:51 -0800 (PST) Received: from [140.93.1.165] (veterini [140.93.1.165]) (authenticated bits=0) by laas.laas.fr (8.14.4/8.14.5) with ESMTP id q1E8xjtP004676 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Tue, 14 Feb 2012 09:59:46 +0100 (MET) Message-ID: <4F3A2281.7030600@laas.fr> Date: Tue, 14 Feb 2012 09:59:45 +0100 From: Guillaume DUGUE Organization: LAAS CNRS User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: multipathtcp@ietf.org References: <4F2E0E9F.6080802@mti-systems.com> <20120205103546.GB61963@verdi> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 8bit X-Mailman-Approved-At: Tue, 14 Feb 2012 01:42:35 -0800 Subject: [multipathtcp] MPTCP MIB X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 09:32:35 -0000 Dear working group and contributors, I do not think I have seen it so far, but can anyone give me any insight about a draft being under study for the description of the MPTCP MIB. Thank you very much, Best regards, Guillaume Dugué LAAS-CNRS, Toulouse, FRANCE From scott.brim@gmail.com Tue Feb 14 05:44:21 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DD3D21F877B for ; Tue, 14 Feb 2012 05:44:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.599 X-Spam-Level: X-Spam-Status: No, score=-103.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfJ-lt1O-O3E for ; Tue, 14 Feb 2012 05:44:20 -0800 (PST) Received: from mail-pw0-f44.google.com (mail-pw0-f44.google.com [209.85.160.44]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5D521F876C for ; Tue, 14 Feb 2012 05:44:20 -0800 (PST) Received: by pbcwz7 with SMTP id wz7so490350pbc.31 for ; Tue, 14 Feb 2012 05:44:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=+IkXJUdEb/iBNmBd8B35ATNWNM6LMGE5c7PWWmEvnOU=; b=CfM0QIx+oshkqpu3NQhlfnTrbYLrYMInWG3Hx2Bi85osrKAYt+aik0QOhfpf9x0hhw I9MB1T8DVyWXTMCctDYDDhR+zf4TSVukYBENQWGTPI76IT606afU0gxk/h0qpqEyHam4 RSR4b7lVysDPPYbVkuevMT2AHwue3mgZSx/Is= Received: by 10.68.72.69 with SMTP id b5mr58768499pbv.120.1329227060159; Tue, 14 Feb 2012 05:44:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.68.67.202 with HTTP; Tue, 14 Feb 2012 05:44:00 -0800 (PST) In-Reply-To: References: <4F2E0E9F.6080802@mti-systems.com> <20120205103546.GB61963@verdi> From: Scott Brim Date: Tue, 14 Feb 2012 08:44:00 -0500 Message-ID: To: Costin Raiciu Content-Type: text/plain; charset=ISO-8859-1 Cc: multipathtcp , Mark Handley Subject: Re: [multipathtcp] codepoint for mptcp options X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 13:44:21 -0000 On Tue, Feb 14, 2012 at 03:32, Costin Raiciu wrote: > MPTCP is an important change to TCP whose time has come, as networks are effectively becoming multipath everywhere (mobiles device with many interfaces, wide-scale server multihoming and datacenters). As Lars said there is considerable interest in MPTCP: > - we have a solid Linux MPTCP stack that we are planning to push upstream starting the end of this year (this has been funded recently by Google, and Intel is also helping out with coding). > - a planned FreeBSD MPTCP implementation has been funded recently > - Intel are actively working on integrating MPTCP on Android and seeing how MPTCP works for mobility. While I agree on getting a new codepoint, I would not use the vast popularity and widepspread deployment of MPTCP as a justification :-) From lars@netapp.com Tue Feb 14 07:41:32 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75BDB21F8715 for ; Tue, 14 Feb 2012 07:41:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.314 X-Spam-Level: X-Spam-Status: No, score=-10.314 tagged_above=-999 required=5 tests=[AWL=0.285, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x12n7SjxjQLT for ; Tue, 14 Feb 2012 07:41:32 -0800 (PST) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2365B21F8686 for ; Tue, 14 Feb 2012 07:41:31 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.73,417,1325491200"; d="p7s'?scan'208";a="625292155" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 14 Feb 2012 07:41:30 -0800 Received: from svlrsexc2-prd.hq.netapp.com (svlrsexc2-prd.hq.netapp.com [10.57.115.31]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q1EFfUhU019301; Tue, 14 Feb 2012 07:41:30 -0800 (PST) Received: from SACMVEXC4-PRD.hq.netapp.com ([10.99.115.26]) by svlrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Feb 2012 07:41:26 -0800 Received: from VMWEXCEHT03-PRD.hq.netapp.com ([10.106.76.241]) by SACMVEXC4-PRD.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Feb 2012 07:41:26 -0800 Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.193]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.02.0247.003; Tue, 14 Feb 2012 07:41:25 -0800 From: "Eggert, Lars" To: Guillaume DUGUE Thread-Topic: [multipathtcp] MPTCP MIB Thread-Index: AQHM6v0D72vwmnz37kmgp5py0iYTI5Y9DmiA Date: Tue, 14 Feb 2012 15:41:25 +0000 Message-ID: References: <4F2E0E9F.6080802@mti-systems.com> <20120205103546.GB61963@verdi> <4F3A2281.7030600@laas.fr> In-Reply-To: <4F3A2281.7030600@laas.fr> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.104.60.115] Content-Type: multipart/signed; boundary="Apple-Mail=_358E054A-0E6A-4ABE-AB0D-F432F5FA9557"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-OriginalArrivalTime: 14 Feb 2012 15:41:26.0119 (UTC) FILETIME=[1C823F70:01CCEB2F] Cc: "" Subject: Re: [multipathtcp] MPTCP MIB X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 15:41:32 -0000 --Apple-Mail=_358E054A-0E6A-4ABE-AB0D-F432F5FA9557 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=iso-8859-1 Hi, On Feb 14, 2012, at 0:59, Guillaume DUGUE wrote: > I do not think I have seen it so far, but can anyone give me any = insight about a draft being under study for the description of the MPTCP = MIB. I don't think there is such a draft at the moment. And I think we need = more experience with the implementations before we can really know what = parameters/metrics would be useful to include in one. Lars= --Apple-Mail=_358E054A-0E6A-4ABE-AB0D-F432F5FA9557 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQDCCBUow ggQyoAMCAQICEFcfSRTG0jNknqb9LV9GuFkwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEyMTAwMDAwMDBaFw0x MjEyMDkyMzU5NTlaMIIBDTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEeMBwGCSqGSIb3DQEJARYPbGFyc0BuZXRhcHAuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAokrhJTcXt6J/VEpZOicLoguBlYTjXP9v Ze4HuuhXnURUS8YouAfgaqA0zYbt5yd6fh4PBMdAaEWr5yJyHuFykXlrCumjUWSpLuqTS2A+pt4q cZaAQk9iLDN/UVd3SpkUuvWbxXlqzG7/BSqa3VNObBzCmyh+V7aXxri+30CT//DSsNRC4VFy6sn6 dMgSaFenXLwe/FBwY0qTMfICT1PrrX6Sw1S8OfH9rykLlZXbmfkFExxQngp1DJH9xMHeODHGbCv/ ty5gdxMOrLe+vENxFEcy1YQWBZd1kNL4UObugF8A/jE/s+Oa3H1VFH8ghqZTdqGDysVxmtKHuNFx 6jIBSQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNV HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMx ZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQBA7q6tR92qpd7xo7VBsrOfGCWzoxIVfTc7t0RhB/Oz/+c3lnhYnNScIuKN JmyZvznmVxqB9BJ72+NkvmdB/hnILSBTRawL2tyLo9PkBtN0nRt4gS6wjpWnD8G83hlJLE7r25jk 7HkRev61dTIXsANFpJKF02C4XSoDfEzNV6MpuEvHvcgHCqMrlwWwfKc7+NoDnE8PBuRzwSXvlD5L mswCY2iiOsd7ImNO4OzTCxETvKTDu92+FTIbRJJpYjVNv1UF7e3w9Kq65BkZJErUH19beUeQl0Wh 2BJQE6/15rQyCnP0iJ/Nmx2/kI6M0PWunEsI6FMs0MbosreaWGHlQmomMIIG7jCCBdagAwIBAgIQ cRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQL EzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYD VQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB 0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXc MM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ //6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSal J1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYI KwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0T AQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9w Y2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1h Z2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28u dmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHp MIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+v OEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSH O3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOV nDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVib vtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5J yNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggSL MIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDIxNDE1NDEzOFowIwYJKoZIhvcNAQkEMRYEFIoE MbbPrvCeSkybojBIaFxAKqJwMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEFcfSRTG0jNknqb9LV9GuFkwggEF BgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMA0GCSqGSIb3DQEBAQUABIIBAEBG1D9a 7FW3BX4YVUe4GfZEGs0sXr5wZTnWt5mQsvYXLdn1RLQFMYbb6w1g1IcZNEDPQPZZ/vEZD8eK4qMa mVlBJE+Y6hP8+7s3ZkqUXAewHbHNGPhfcaKBDdLGwsrwW9FRvgTeD4+cVSU1Kki6roeY7mUiELTZ Fvg3pVGZJYXWBE3IUY0UKYGUZ/Ou+hK91HVrOV7VyqOF35pqpxDZ7ZoTm4GSn1L3Bi0PxB36I5JO 7qUQr5y3ocgVv2/yPFJWOSqh3WabCAp8guPvFNJ6r3YNpvL2sRJjwbugc01pBxultPoiGTUhz2CR 60eXS8KFkO6jmRT5fvK1m1m3yDWTPn8AAAAAAAA= --Apple-Mail=_358E054A-0E6A-4ABE-AB0D-F432F5FA9557-- From jnc@mercury.lcs.mit.edu Tue Feb 14 08:14:44 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 589BE21F8697 for ; Tue, 14 Feb 2012 08:14:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.438 X-Spam-Level: X-Spam-Status: No, score=-6.438 tagged_above=-999 required=5 tests=[AWL=0.161, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aEuuRm5QYUSX for ; Tue, 14 Feb 2012 08:14:43 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 958AC21F8667 for ; Tue, 14 Feb 2012 08:14:43 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id 9EA9B18C0A8; Tue, 14 Feb 2012 11:14:42 -0500 (EST) To: multipathtcp@ietf.org Message-Id: <20120214161442.9EA9B18C0A8@mercury.lcs.mit.edu> Date: Tue, 14 Feb 2012 11:14:42 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [multipathtcp] codepoint for mptcp options X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 16:14:44 -0000 > From: John Leslie > I agree with Lars that we should go for a new TCP option Yes, I too think this makes sense. > The TCP Option Number space _is_ limited, but not all that limited. > In the history of TCP we've burned through 29 of 255 .... Eleven of > those are considered obsolete and could be reassigned if things got > _really_ tight. When I compare the scarcity of the resource and the usage rate (above) on the one hand, and the level of likely interest/usage in this design on the other, it's clear that the balance is in favour of assigning one. Noel From touch@isi.edu Tue Feb 14 08:33:48 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECCA821F86F4 for ; Tue, 14 Feb 2012 08:33:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.919 X-Spam-Level: X-Spam-Status: No, score=-102.919 tagged_above=-999 required=5 tests=[AWL=-0.320, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c7l39WDq5Ccv for ; Tue, 14 Feb 2012 08:33:47 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id DB1B521F86E5 for ; Tue, 14 Feb 2012 08:33:46 -0800 (PST) Received: from [192.168.1.87] (pool-71-105-89-105.lsanca.dsl-w.verizon.net [71.105.89.105]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q1EGXJaJ016997 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 14 Feb 2012 08:33:23 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Joe Touch In-Reply-To: <20120214161442.9EA9B18C0A8@mercury.lcs.mit.edu> Date: Tue, 14 Feb 2012 08:33:43 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <2D6F54AF-E2E1-436C-B29A-52077A21083A@isi.edu> References: <20120214161442.9EA9B18C0A8@mercury.lcs.mit.edu> To: Noel Chiappa X-Mailer: Apple Mail (2.1257) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] codepoint for mptcp options X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 16:33:48 -0000 FWIW, *if* this is assigned a TCP option of its own, I urge the group to = select a name that is *accurately* describes the purpose of this option, = e.g. "multiaddress" or "multiIP". "Multipath" is misleading, and because = TCP options persist, is likely to continue to cause confusion. Joe On Feb 14, 2012, at 8:14 AM, Noel Chiappa wrote: >> From: John Leslie >=20 >> I agree with Lars that we should go for a new TCP option >=20 > Yes, I too think this makes sense. >=20 >> The TCP Option Number space _is_ limited, but not all that limited. >> In the history of TCP we've burned through 29 of 255 .... Eleven of >> those are considered obsolete and could be reassigned if things got >> _really_ tight. >=20 > When I compare the scarcity of the resource and the usage rate (above) = on > the one hand, and the level of likely interest/usage in this design on = the > other, it's clear that the balance is in favour of assigning one. >=20 > Noel > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From lars@netapp.com Tue Feb 14 08:39:58 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2470D21F86BB for ; Tue, 14 Feb 2012 08:39:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.318 X-Spam-Level: X-Spam-Status: No, score=-10.318 tagged_above=-999 required=5 tests=[AWL=0.281, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Tn-CioYb4NvM for ; Tue, 14 Feb 2012 08:39:57 -0800 (PST) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8444121F86B6 for ; Tue, 14 Feb 2012 08:39:52 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.73,417,1325491200"; d="p7s'?scan'208";a="625316332" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 14 Feb 2012 08:39:52 -0800 Received: from svlrsexc1-prd.hq.netapp.com (svlrsexc1-prd.hq.netapp.com [10.57.115.30]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q1EGdqLq008497; Tue, 14 Feb 2012 08:39:52 -0800 (PST) Received: from VMWEXCEHT03-PRD.hq.netapp.com ([10.106.76.241]) by svlrsexc1-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Feb 2012 08:39:47 -0800 Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.193]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.02.0247.003; Tue, 14 Feb 2012 08:39:47 -0800 From: "Eggert, Lars" To: Joe Touch Thread-Topic: [multipathtcp] codepoint for mptcp options Thread-Index: AQHM6zPC31zTfpIF7ESk8/gRIupZzpY9HImAgAABwIA= Date: Tue, 14 Feb 2012 16:39:46 +0000 Message-ID: <96F74139-807D-4473-9F98-118B4269F9C7@netapp.com> References: <20120214161442.9EA9B18C0A8@mercury.lcs.mit.edu> <2D6F54AF-E2E1-436C-B29A-52077A21083A@isi.edu> In-Reply-To: <2D6F54AF-E2E1-436C-B29A-52077A21083A@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_757B315D-B474-4496-89ED-237682D6ECD4"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-OriginalArrivalTime: 14 Feb 2012 16:39:47.0573 (UTC) FILETIME=[4389BA50:01CCEB37] Cc: "" , Noel Chiappa Subject: Re: [multipathtcp] codepoint for mptcp options X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 16:39:58 -0000 --Apple-Mail=_757B315D-B474-4496-89ED-237682D6ECD4 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 14, 2012, at 8:33, Joe Touch wrote: > FWIW, *if* this is assigned a TCP option of its own, I urge the group = to select a name that is *accurately* describes the purpose of this = option, e.g. "multiaddress" or "multiIP". "Multipath" is misleading, and = because TCP options persist, is likely to continue to cause confusion. I think "multipath" is the best term. If you have a single-homed host = talking to a multi-homed host, MPTCP will be opening connections along = multiple paths but only one IP address is in use at one end. I don't = think this case is described by either "multi-address" or "multi-IP". Also, the WG and protocol are also named "multipath" TCP. Using a = different name for the option is confusing (and renaming the protocol = and WG is impractical and confusing.)=20 Lars= --Apple-Mail=_757B315D-B474-4496-89ED-237682D6ECD4 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQDCCBUow ggQyoAMCAQICEFcfSRTG0jNknqb9LV9GuFkwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEyMTAwMDAwMDBaFw0x MjEyMDkyMzU5NTlaMIIBDTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEeMBwGCSqGSIb3DQEJARYPbGFyc0BuZXRhcHAuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAokrhJTcXt6J/VEpZOicLoguBlYTjXP9v Ze4HuuhXnURUS8YouAfgaqA0zYbt5yd6fh4PBMdAaEWr5yJyHuFykXlrCumjUWSpLuqTS2A+pt4q cZaAQk9iLDN/UVd3SpkUuvWbxXlqzG7/BSqa3VNObBzCmyh+V7aXxri+30CT//DSsNRC4VFy6sn6 dMgSaFenXLwe/FBwY0qTMfICT1PrrX6Sw1S8OfH9rykLlZXbmfkFExxQngp1DJH9xMHeODHGbCv/ ty5gdxMOrLe+vENxFEcy1YQWBZd1kNL4UObugF8A/jE/s+Oa3H1VFH8ghqZTdqGDysVxmtKHuNFx 6jIBSQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNV HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMx ZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQBA7q6tR92qpd7xo7VBsrOfGCWzoxIVfTc7t0RhB/Oz/+c3lnhYnNScIuKN JmyZvznmVxqB9BJ72+NkvmdB/hnILSBTRawL2tyLo9PkBtN0nRt4gS6wjpWnD8G83hlJLE7r25jk 7HkRev61dTIXsANFpJKF02C4XSoDfEzNV6MpuEvHvcgHCqMrlwWwfKc7+NoDnE8PBuRzwSXvlD5L mswCY2iiOsd7ImNO4OzTCxETvKTDu92+FTIbRJJpYjVNv1UF7e3w9Kq65BkZJErUH19beUeQl0Wh 2BJQE6/15rQyCnP0iJ/Nmx2/kI6M0PWunEsI6FMs0MbosreaWGHlQmomMIIG7jCCBdagAwIBAgIQ cRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQL EzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYD VQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB 0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXc MM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ //6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSal J1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYI KwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0T AQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9w Y2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1h Z2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28u dmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHp MIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+v OEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSH O3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOV nDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVib vtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5J yNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggSL MIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDIxNDE2Mzk1OVowIwYJKoZIhvcNAQkEMRYEFCKe 507p8Z60o0eCKcBOioIaTf0tMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEFcfSRTG0jNknqb9LV9GuFkwggEF BgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMA0GCSqGSIb3DQEBAQUABIIBAJd5MoQm NtaK7w59pfX/08R6JZO8tZaswK3tJ8hoeHt2nfgXaqLhz3JrXeovVTX725HL3+jsoGgyxpmg+Y4u eTutVSdWgGtaSG0NM82Xtgd0EZDIEHw6/W8Kg3mlN3wLThF4ss9hvspEZ8odc9aQILw+j8+bOwcO vrNErWq2bd4no/YDiIOclBb8e7Ca5sNyO+FgTPI1bU8/LzfMgCluFcZyejDJEHf+a1yVTLHbQwIU gdCB+maXfQJcdHpFYYJAaPPH4a61M4EtShdLS4s1xIHZM0OQR4arh+9X8q6JCNgBmQbuElNzzKJU 0vUNHhbP/IoxGkEr9Pf6VfMDsyMve8UAAAAAAAA= --Apple-Mail=_757B315D-B474-4496-89ED-237682D6ECD4-- From alanford@cisco.com Tue Feb 14 08:44:24 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E740521E8052 for ; Tue, 14 Feb 2012 08:44:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.532 X-Spam-Level: X-Spam-Status: No, score=-8.532 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kRFnML+3vxKG for ; Tue, 14 Feb 2012 08:44:24 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 5B59021F856D for ; Tue, 14 Feb 2012 08:44:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=alanford@cisco.com; l=1173; q=dns/txt; s=iport; t=1329237860; x=1330447460; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=0d4+JFoN4vqf2URWw4ZHriYsUsz/DAs7QyRQrKiLPRM=; b=mfe23b/FxCd/IP5a5g0gD/qIVy4cdYANCs/3XQqJycHV8tRGyqecS5Cy vAXMoiwIGxsdMBYOrXUx1R8F/h0GVjkcIkS5Ii8CCrz40GBxumvfowuxf pjH9KdhB7TKqE1QBNjsni3I6Q3DHNJdvPLdy4CKqBOUEysZDi3eJRju9K A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AscIAHGOOk+Q/khM/2dsb2JhbABDDrAWAoEHgXIBAQEEEgEnAgE8EgEIGIEFAgQBDQUipX4BlwWLcTABAi4LAQkIAwKEJQwDBguDLwSVMo5Dg2o3 X-IronPort-AV: E=Sophos;i="4.73,417,1325462400"; d="scan'208";a="129405803" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 14 Feb 2012 16:44:16 +0000 Received: from xbh-ams-101.cisco.com (xbh-ams-101.cisco.com [144.254.74.71]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q1EGiGUu019530; Tue, 14 Feb 2012 16:44:16 GMT Received: from xmb-ams-203.cisco.com ([144.254.75.14]) by xbh-ams-101.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Feb 2012 17:44:16 +0100 Received: from 144.254.90.168 ([144.254.90.168]) by XMB-AMS-203.cisco.com ([144.254.75.14]) with Microsoft Exchange Server HTTP-DAV ; Tue, 14 Feb 2012 16:44:16 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Tue, 14 Feb 2012 16:44:12 +0000 From: Alan Ford To: "Eggert, Lars" , Joe Touch Message-ID: Thread-Topic: [multipathtcp] codepoint for mptcp options Thread-Index: AQHM6zPC31zTfpIF7ESk8/gRIupZzpY9HImAgAABwID//3sRHg== In-Reply-To: <96F74139-807D-4473-9F98-118B4269F9C7@netapp.com> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 14 Feb 2012 16:44:16.0786 (UTC) FILETIME=[E4005F20:01CCEB37] Cc: "" , Noel Chiappa Subject: Re: [multipathtcp] codepoint for mptcp options X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 16:44:25 -0000 On 14/02/2012 16:39, "Eggert, Lars" wrote: > On Feb 14, 2012, at 8:33, Joe Touch wrote: >> FWIW, *if* this is assigned a TCP option of its own, I urge the group to >> select a name that is *accurately* describes the purpose of this option, e.g. >> "multiaddress" or "multiIP". "Multipath" is misleading, and because TCP >> options persist, is likely to continue to cause confusion. > > I think "multipath" is the best term. If you have a single-homed host talking > to a multi-homed host, MPTCP will be opening connections along multiple paths > but only one IP address is in use at one end. I don't think this case is > described by either "multi-address" or "multi-IP". > > Also, the WG and protocol are also named "multipath" TCP. Using a different > name for the option is confusing (and renaming the protocol and WG is > impractical and confusing.) Agreed. What's more, the protocol, by using a version field in the initial handshake, and extensible sub-types for messages, has been designed mindful of the hope that new (and more accurate) path selection mechanisms *could* be "plugged in" in the future. Regards, Alan From touch@isi.edu Tue Feb 14 08:47:43 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1964321F8576 for ; Tue, 14 Feb 2012 08:47:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.866 X-Spam-Level: X-Spam-Status: No, score=-102.866 tagged_above=-999 required=5 tests=[AWL=-0.267, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4SEXD1PWgtU4 for ; Tue, 14 Feb 2012 08:47:42 -0800 (PST) Received: from darkstar.isi.edu (darkstar.isi.edu [128.9.128.127]) by ietfa.amsl.com (Postfix) with ESMTP id 2137621F8540 for ; Tue, 14 Feb 2012 08:47:38 -0800 (PST) Received: from [192.168.1.87] (pool-71-105-89-105.lsanca.dsl-w.verizon.net [71.105.89.105]) (authenticated bits=0) by darkstar.isi.edu (8.13.8/8.13.8) with ESMTP id q1EGlPto022113 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 14 Feb 2012 08:47:29 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Joe Touch In-Reply-To: <96F74139-807D-4473-9F98-118B4269F9C7@netapp.com> Date: Tue, 14 Feb 2012 08:47:49 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <20120214161442.9EA9B18C0A8@mercury.lcs.mit.edu> <2D6F54AF-E2E1-436C-B29A-52077A21083A@isi.edu> <96F74139-807D-4473-9F98-118B4269F9C7@netapp.com> To: "Eggert, Lars" X-Mailer: Apple Mail (2.1257) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "" , Noel Chiappa Subject: Re: [multipathtcp] codepoint for mptcp options X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 16:47:43 -0000 On Feb 14, 2012, at 8:39 AM, Eggert, Lars wrote: > On Feb 14, 2012, at 8:33, Joe Touch wrote: >> FWIW, *if* this is assigned a TCP option of its own, I urge the group = to select a name that is *accurately* describes the purpose of this = option, e.g. "multiaddress" or "multiIP". "Multipath" is misleading, and = because TCP options persist, is likely to continue to cause confusion. >=20 > I think "multipath" is the best term. If you have a single-homed host = talking to a multi-homed host, MPTCP will be opening connections along = multiple paths but only one IP address is in use at one end. I don't = think this case is described by either "multi-address" or "multi-IP". >=20 > Also, the WG and protocol are also named "multipath" TCP. Using a = different name for the option is confusing (and renaming the protocol = and WG is impractical and confusing.)=20 >=20 > Lars IP addresses don't determine path. Even single-homed to multi-homed = requires multiple addresses, but doesn't necessarily require independent = paths. Perhaps "multihomed" makes more sense - even by your own description = above. FWIW, I did bring this up when it was a BOF, so claiming inertia at this = point doesn't cut it. Joe= From touch@isi.edu Tue Feb 14 08:49:46 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C57AD21F8745 for ; Tue, 14 Feb 2012 08:49:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.828 X-Spam-Level: X-Spam-Status: No, score=-104.828 tagged_above=-999 required=5 tests=[AWL=1.771, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cChfyzfo2xdS for ; Tue, 14 Feb 2012 08:49:46 -0800 (PST) Received: from boreas.isi.edu (boreas.isi.edu [128.9.160.161]) by ietfa.amsl.com (Postfix) with ESMTP id 4CF6121F873A for ; Tue, 14 Feb 2012 08:49:46 -0800 (PST) Received: from [192.168.1.87] (pool-71-105-89-105.lsanca.dsl-w.verizon.net [71.105.89.105]) (authenticated bits=0) by boreas.isi.edu (8.13.8/8.13.8) with ESMTP id q1EGn4P3000153 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 14 Feb 2012 08:49:14 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Joe Touch In-Reply-To: Date: Tue, 14 Feb 2012 08:49:29 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7F4D67DE-9A41-4550-85FE-983BCDEC2639@isi.edu> References: To: Alan Ford X-Mailer: Apple Mail (2.1257) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "" , Noel Chiappa Subject: Re: [multipathtcp] codepoint for mptcp options X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 16:49:46 -0000 On Feb 14, 2012, at 8:44 AM, Alan Ford wrote: > On 14/02/2012 16:39, "Eggert, Lars" wrote: >> On Feb 14, 2012, at 8:33, Joe Touch wrote: >>> FWIW, *if* this is assigned a TCP option of its own, I urge the = group to >>> select a name that is *accurately* describes the purpose of this = option, e.g. >>> "multiaddress" or "multiIP". "Multipath" is misleading, and because = TCP >>> options persist, is likely to continue to cause confusion. >>=20 >> I think "multipath" is the best term. If you have a single-homed host = talking >> to a multi-homed host, MPTCP will be opening connections along = multiple paths >> but only one IP address is in use at one end. I don't think this case = is >> described by either "multi-address" or "multi-IP". >>=20 >> Also, the WG and protocol are also named "multipath" TCP. Using a = different >> name for the option is confusing (and renaming the protocol and WG is >> impractical and confusing.) >=20 > Agreed. >=20 > What's more, the protocol, by using a version field in the initial > handshake, and extensible sub-types for messages, has been designed = mindful > of the hope that new (and more accurate) path selection mechanisms = *could* > be "plugged in" in the future. >=20 > Regards, > Alan As an exercise, can you confirm whether you think this option could ever = be used when there are two single-homed hosts in a way that differs from = existing TCP? If so, you could accurately call that a path-selection = extension to this at best. Joe From touch@isi.edu Tue Feb 14 08:51:51 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E7B6021E808B for ; Tue, 14 Feb 2012 08:51:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.049 X-Spam-Level: X-Spam-Status: No, score=-103.049 tagged_above=-999 required=5 tests=[AWL=-0.450, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Fzdp3z1JgDnk for ; Tue, 14 Feb 2012 08:51:51 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 1022121E808A for ; Tue, 14 Feb 2012 08:51:51 -0800 (PST) Received: from [192.168.1.87] (pool-71-105-89-105.lsanca.dsl-w.verizon.net [71.105.89.105]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q1EGoifO013596 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Tue, 14 Feb 2012 08:50:55 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v1257) Content-Type: text/plain; charset=us-ascii From: Joe Touch In-Reply-To: <2D6F54AF-E2E1-436C-B29A-52077A21083A@isi.edu> Date: Tue, 14 Feb 2012 08:51:08 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: <05D5FE9E-038F-4712-B12D-12CC2A1D1EA4@isi.edu> References: <20120214161442.9EA9B18C0A8@mercury.lcs.mit.edu> <2D6F54AF-E2E1-436C-B29A-52077A21083A@isi.edu> To: Noel Chiappa X-Mailer: Apple Mail (2.1257) X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] codepoint for mptcp options X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 16:51:52 -0000 PS - I still think this is an end-run around process. TCP options are = intended for standards-track extensions, and this isn't - yet. IMO, this is a great place to emphasize the use of the experimental code = point, esp. shared use. If we can't argue that successfully for this, = then perhaps we never can and should abandon the concept of experimental = code points altogether. Joe On Feb 14, 2012, at 8:33 AM, Joe Touch wrote: > FWIW, *if* this is assigned a TCP option of its own, I urge the group = to select a name that is *accurately* describes the purpose of this = option, e.g. "multiaddress" or "multiIP". "Multipath" is misleading, and = because TCP options persist, is likely to continue to cause confusion. >=20 > Joe >=20 > On Feb 14, 2012, at 8:14 AM, Noel Chiappa wrote: >=20 >>> From: John Leslie >>=20 >>> I agree with Lars that we should go for a new TCP option >>=20 >> Yes, I too think this makes sense. >>=20 >>> The TCP Option Number space _is_ limited, but not all that limited. >>> In the history of TCP we've burned through 29 of 255 .... Eleven of >>> those are considered obsolete and could be reassigned if things got >>> _really_ tight. >>=20 >> When I compare the scarcity of the resource and the usage rate = (above) on >> the one hand, and the level of likely interest/usage in this design = on the >> other, it's clear that the balance is in favour of assigning one. >>=20 >> Noel >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp >=20 From jnc@mercury.lcs.mit.edu Tue Feb 14 08:52:30 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 10C4321F85D9 for ; Tue, 14 Feb 2012 08:52:30 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.448 X-Spam-Level: X-Spam-Status: No, score=-6.448 tagged_above=-999 required=5 tests=[AWL=0.151, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbGpLolUw-+Z for ; Tue, 14 Feb 2012 08:52:29 -0800 (PST) Received: from mercury.lcs.mit.edu (mercury.lcs.mit.edu [18.26.0.122]) by ietfa.amsl.com (Postfix) with ESMTP id 7D60A21F853E for ; Tue, 14 Feb 2012 08:52:29 -0800 (PST) Received: by mercury.lcs.mit.edu (Postfix, from userid 11178) id B66A218C090; Tue, 14 Feb 2012 11:52:28 -0500 (EST) To: multipathtcp@ietf.org Message-Id: <20120214165228.B66A218C090@mercury.lcs.mit.edu> Date: Tue, 14 Feb 2012 11:52:28 -0500 (EST) From: jnc@mercury.lcs.mit.edu (Noel Chiappa) Cc: jnc@mercury.lcs.mit.edu Subject: Re: [multipathtcp] codepoint for mptcp options X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 16:52:30 -0000 > From: "Eggert, Lars" > If you have a single-homed host talking to a multi-homed host, MPTCP > will be opening connections along multiple paths but only one IP > address is in use at one end. I don't think this case is described > by either "multi-address" or "multi-IP". > Also, the WG and protocol are also named "multipath" TCP. Using a > different name for the option is confusing (and renaming the > protocol and WG is impractical and confusing.) I don't have any strong opinion on the name, and the latter point is a good one. However, on the purely technical level, I think Joe is sort of correct. The current TCP/IP architecture doesn't give users any control over paths (at least, as routing would think of that term). Multiple addresses/interfaces are a 'poor man's way' of providing a certain amount of path diversity, but it can make no guarantee, because of the previous point. Even with a single TCP connection between two singly-addressed hosts, packets from the connection might flow over two paths (but usually don't, because ISPs try to avoid that because it can cause packet reordering). And I can imagine MPTCP connections where the packets on two sub-connections all take the exact same path through the network (e.g. a multi-homed host with two interfaces to the same network, for reliability reasons - although people have used ARP hacks in the past for that particular capability). Yes, multiple sub-connections to different addresses will usually get you a different path - but there's no control, or guarantee. Noel From wes@mti-systems.com Tue Feb 14 09:01:41 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 505E421F8797 for ; Tue, 14 Feb 2012 09:01:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2EeN7aDu88dD for ; Tue, 14 Feb 2012 09:01:40 -0800 (PST) Received: from omr13.networksolutionsemail.com (omr13.networksolutionsemail.com [205.178.146.63]) by ietfa.amsl.com (Postfix) with ESMTP id D099121F8755 for ; Tue, 14 Feb 2012 09:01:39 -0800 (PST) Received: from cm-omr12 (mail.networksolutionsemail.com [205.178.146.50]) by omr13.networksolutionsemail.com (8.13.8/8.13.8) with ESMTP id q1EH1bkQ026783 for ; Tue, 14 Feb 2012 12:01:39 -0500 Authentication-Results: cm-omr12 smtp.user=wes@mti-systems.com; auth=pass (PLAIN) X-Authenticated-UID: wes@mti-systems.com Received: from [107.47.224.179] ([107.47.224.179:20193] helo=[68.245.171.115]) by cm-omr12 (envelope-from ) (ecelerity 2.2.2.41 r(31179/31189)) with ESMTPA id E4/95-00307-1739A3F4; Tue, 14 Feb 2012 12:01:38 -0500 Message-ID: <4F3A9374.8020504@mti-systems.com> Date: Tue, 14 Feb 2012 12:01:40 -0500 From: Wesley Eddy Organization: MTI Systems User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:10.0) Gecko/20120129 Thunderbird/10.0 MIME-Version: 1.0 To: Joe Touch References: <20120214161442.9EA9B18C0A8@mercury.lcs.mit.edu> <2D6F54AF-E2E1-436C-B29A-52077A21083A@isi.edu> <96F74139-807D-4473-9F98-118B4269F9C7@netapp.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Cc: "" , Noel Chiappa Subject: Re: [multipathtcp] codepoint for mptcp options X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 17:01:41 -0000 On 2/14/2012 11:47 AM, Joe Touch wrote: > > On Feb 14, 2012, at 8:39 AM, Eggert, Lars wrote: > >> On Feb 14, 2012, at 8:33, Joe Touch wrote: >>> FWIW, *if* this is assigned a TCP option of its own, I urge the group to select a name that is *accurately* describes the purpose of this option, e.g. "multiaddress" or "multiIP". "Multipath" is misleading, and because TCP options persist, is likely to continue to cause confusion. >> >> I think "multipath" is the best term. If you have a single-homed host talking to a multi-homed host, MPTCP will be opening connections along multiple paths but only one IP address is in use at one end. I don't think this case is described by either "multi-address" or "multi-IP". >> >> Also, the WG and protocol are also named "multipath" TCP. Using a different name for the option is confusing (and renaming the protocol and WG is impractical and confusing.) >> >> Lars > > IP addresses don't determine path. Even single-homed to multi-homed requires multiple addresses, but doesn't necessarily require independent paths. > > Perhaps "multihomed" makes more sense - even by your own description above. > > FWIW, I did bring this up when it was a BOF, so claiming inertia at this point doesn't cut it. The existing RFCs using "MPTCP" seem clear about what it is (e.g. see RFC 6182), and an option allocation will need to relate to them using the same name. I think section 5.5 has a reasonable discussion of the current use of addresses as an approximation. Those RFCs are just as persistent as the IANA registry (or moreso). I hope we can move past talking about whether the name is slightly misleading or not, since I don't think it's relevant to the decision. -- Wes Eddy MTI Systems From lars@netapp.com Tue Feb 14 09:16:12 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B83221F8790 for ; Tue, 14 Feb 2012 09:16:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.321 X-Spam-Level: X-Spam-Status: No, score=-10.321 tagged_above=-999 required=5 tests=[AWL=0.278, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HsMFifEhwrDu for ; Tue, 14 Feb 2012 09:16:11 -0800 (PST) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id BC03021F85F2 for ; Tue, 14 Feb 2012 09:16:11 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.73,417,1325491200"; d="p7s'?scan'208";a="625330463" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 14 Feb 2012 09:16:11 -0800 Received: from sacrsexc2-prd.hq.netapp.com (sacrsexc2-prd.hq.netapp.com [10.99.115.28]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q1EHG9AW007491; Tue, 14 Feb 2012 09:16:11 -0800 (PST) Received: from VMWEXCEHT03-PRD.hq.netapp.com ([10.106.76.241]) by sacrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Feb 2012 09:16:06 -0800 Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.193]) by vmwexceht03-prd.hq.netapp.com ([10.106.76.241]) with mapi id 14.02.0247.003; Tue, 14 Feb 2012 09:16:02 -0800 From: "Eggert, Lars" To: Joe Touch Thread-Topic: [multipathtcp] codepoint for mptcp options Thread-Index: AQHM6zPC31zTfpIF7ESk8/gRIupZzpY9HImAgAABwID//3sRHoAAh5aAgAAHeYA= Date: Tue, 14 Feb 2012 17:16:01 +0000 Message-ID: References: <7F4D67DE-9A41-4550-85FE-983BCDEC2639@isi.edu> In-Reply-To: <7F4D67DE-9A41-4550-85FE-983BCDEC2639@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_8E222EEE-5DA8-42FA-B527-FCB2A6341932"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-OriginalArrivalTime: 14 Feb 2012 17:16:06.0102 (UTC) FILETIME=[560ADF60:01CCEB3C] Cc: "" , Noel Chiappa Subject: Re: [multipathtcp] codepoint for mptcp options X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 17:16:12 -0000 --Apple-Mail=_8E222EEE-5DA8-42FA-B527-FCB2A6341932 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 14, 2012, at 8:49, Joe Touch wrote: > As an exercise, can you confirm whether you think this option could = ever be used when there are two single-homed hosts in a way that differs = from existing TCP? If so, you could accurately call that a = path-selection extension to this at best. Yes. There was someone on the MPTCP developers list recently who wanted = to use four subflows between to single-homed machines, because their ISP = capped single-flow throughput at a quarter of the upstream bandwidth. (This isn't something that the implementation supports without manual = configuration, but the code does support it.) Lars= --Apple-Mail=_8E222EEE-5DA8-42FA-B527-FCB2A6341932 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQDCCBUow ggQyoAMCAQICEFcfSRTG0jNknqb9LV9GuFkwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEyMTAwMDAwMDBaFw0x MjEyMDkyMzU5NTlaMIIBDTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEeMBwGCSqGSIb3DQEJARYPbGFyc0BuZXRhcHAuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAokrhJTcXt6J/VEpZOicLoguBlYTjXP9v Ze4HuuhXnURUS8YouAfgaqA0zYbt5yd6fh4PBMdAaEWr5yJyHuFykXlrCumjUWSpLuqTS2A+pt4q cZaAQk9iLDN/UVd3SpkUuvWbxXlqzG7/BSqa3VNObBzCmyh+V7aXxri+30CT//DSsNRC4VFy6sn6 dMgSaFenXLwe/FBwY0qTMfICT1PrrX6Sw1S8OfH9rykLlZXbmfkFExxQngp1DJH9xMHeODHGbCv/ ty5gdxMOrLe+vENxFEcy1YQWBZd1kNL4UObugF8A/jE/s+Oa3H1VFH8ghqZTdqGDysVxmtKHuNFx 6jIBSQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNV HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMx ZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQBA7q6tR92qpd7xo7VBsrOfGCWzoxIVfTc7t0RhB/Oz/+c3lnhYnNScIuKN JmyZvznmVxqB9BJ72+NkvmdB/hnILSBTRawL2tyLo9PkBtN0nRt4gS6wjpWnD8G83hlJLE7r25jk 7HkRev61dTIXsANFpJKF02C4XSoDfEzNV6MpuEvHvcgHCqMrlwWwfKc7+NoDnE8PBuRzwSXvlD5L mswCY2iiOsd7ImNO4OzTCxETvKTDu92+FTIbRJJpYjVNv1UF7e3w9Kq65BkZJErUH19beUeQl0Wh 2BJQE6/15rQyCnP0iJ/Nmx2/kI6M0PWunEsI6FMs0MbosreaWGHlQmomMIIG7jCCBdagAwIBAgIQ cRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQL EzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYD VQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB 0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXc MM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ //6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSal J1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYI KwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0T AQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9w Y2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1h Z2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28u dmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHp MIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+v OEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSH O3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOV nDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVib vtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5J yNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggSL MIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDIxNDE3MTYxNFowIwYJKoZIhvcNAQkEMRYEFLix 0xJLSEVrHTBFHGEkNkZm2LsqMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEFcfSRTG0jNknqb9LV9GuFkwggEF BgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMA0GCSqGSIb3DQEBAQUABIIBAFxy9AHV YAZSSUQ/wd/6KpI1qNq7buiADOoYdwIqjqprcQ6bg+oZVoTwKq8d6lytlpXYzUyrRrlmmroBdjV5 KFks+V5n43itSP6FcaE1B0ZaE/lcidIuxWk+szuZk0DGQgFMK/0U+kAV9gB3s1DJ4Tom2dtwt6RF ZuJ8p3nhuXwKzD3IUBQC4XLuj2aBHS/8Svh75QW405RGM5IzGsX2pwAGh0x23QNumfJDwZ9Xkx9o aS/ReikUnunbeuAri59R+ctJx26WNNB0ud04dWVMv+rY6QUb3pJYpLNujIj0VkIKGMmuj8XZ4cKP TPvo4OXiMF2i5Qd7gAykZO9MbjbdQLQAAAAAAAA= --Apple-Mail=_8E222EEE-5DA8-42FA-B527-FCB2A6341932-- From lars@netapp.com Tue Feb 14 09:18:46 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E20221F852E for ; Tue, 14 Feb 2012 09:18:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.325 X-Spam-Level: X-Spam-Status: No, score=-10.325 tagged_above=-999 required=5 tests=[AWL=0.274, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e9K+kQtQ1Mw8 for ; Tue, 14 Feb 2012 09:18:45 -0800 (PST) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 7705321F847E for ; Tue, 14 Feb 2012 09:18:42 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.73,417,1325491200"; d="p7s'?scan'208";a="625331545" Received: from smtp1.corp.netapp.com ([10.57.156.124]) by mx2-out.netapp.com with ESMTP; 14 Feb 2012 09:18:42 -0800 Received: from svlrsexc2-prd.hq.netapp.com (svlrsexc2-prd.hq.netapp.com [10.57.115.31]) by smtp1.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q1EHIfcT020935; Tue, 14 Feb 2012 09:18:41 -0800 (PST) Received: from SACMVEXC4-PRD.hq.netapp.com ([10.99.115.26]) by svlrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Feb 2012 09:18:37 -0800 Received: from VMWEXCEHT01-PRD.hq.netapp.com ([10.106.76.239]) by SACMVEXC4-PRD.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.3959); Tue, 14 Feb 2012 09:18:37 -0800 Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.193]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.02.0247.003; Tue, 14 Feb 2012 09:18:35 -0800 From: "Eggert, Lars" To: Joe Touch Thread-Topic: [multipathtcp] codepoint for mptcp options Thread-Index: AQHM6zPC31zTfpIF7ESk8/gRIupZzpY9HImAgAAE3QCAAAe6gA== Date: Tue, 14 Feb 2012 17:18:34 +0000 Message-ID: <22626528-8789-407C-B825-45A5D664561F@netapp.com> References: <20120214161442.9EA9B18C0A8@mercury.lcs.mit.edu> <2D6F54AF-E2E1-436C-B29A-52077A21083A@isi.edu> <05D5FE9E-038F-4712-B12D-12CC2A1D1EA4@isi.edu> In-Reply-To: <05D5FE9E-038F-4712-B12D-12CC2A1D1EA4@isi.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_51B14B9A-BE51-4CA5-BEEF-81D9E9DB7791"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-OriginalArrivalTime: 14 Feb 2012 17:18:37.0056 (UTC) FILETIME=[B004A000:01CCEB3C] Cc: "" , Noel Chiappa Subject: Re: [multipathtcp] codepoint for mptcp options X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 17:18:46 -0000 --Apple-Mail=_51B14B9A-BE51-4CA5-BEEF-81D9E9DB7791 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 14, 2012, at 8:51, Joe Touch wrote: > PS - I still think this is an end-run around process. TCP options are = intended for standards-track extensions, and this isn't - yet. That's not true. TCP options can be assigned via a Standards Action *or* = IESG Approval. IESG Approval is a choice exactly because there are cases where we want = to be able to assign numbers without a Standards Action. It's not done = often, but it can be done if the IESG can be convinced to do so. (Which = is what we will need to do if we want to go that route.) Lars= --Apple-Mail=_51B14B9A-BE51-4CA5-BEEF-81D9E9DB7791 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQDCCBUow ggQyoAMCAQICEFcfSRTG0jNknqb9LV9GuFkwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEyMTAwMDAwMDBaFw0x MjEyMDkyMzU5NTlaMIIBDTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEeMBwGCSqGSIb3DQEJARYPbGFyc0BuZXRhcHAuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAokrhJTcXt6J/VEpZOicLoguBlYTjXP9v Ze4HuuhXnURUS8YouAfgaqA0zYbt5yd6fh4PBMdAaEWr5yJyHuFykXlrCumjUWSpLuqTS2A+pt4q cZaAQk9iLDN/UVd3SpkUuvWbxXlqzG7/BSqa3VNObBzCmyh+V7aXxri+30CT//DSsNRC4VFy6sn6 dMgSaFenXLwe/FBwY0qTMfICT1PrrX6Sw1S8OfH9rykLlZXbmfkFExxQngp1DJH9xMHeODHGbCv/ ty5gdxMOrLe+vENxFEcy1YQWBZd1kNL4UObugF8A/jE/s+Oa3H1VFH8ghqZTdqGDysVxmtKHuNFx 6jIBSQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNV HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMx ZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQBA7q6tR92qpd7xo7VBsrOfGCWzoxIVfTc7t0RhB/Oz/+c3lnhYnNScIuKN JmyZvznmVxqB9BJ72+NkvmdB/hnILSBTRawL2tyLo9PkBtN0nRt4gS6wjpWnD8G83hlJLE7r25jk 7HkRev61dTIXsANFpJKF02C4XSoDfEzNV6MpuEvHvcgHCqMrlwWwfKc7+NoDnE8PBuRzwSXvlD5L mswCY2iiOsd7ImNO4OzTCxETvKTDu92+FTIbRJJpYjVNv1UF7e3w9Kq65BkZJErUH19beUeQl0Wh 2BJQE6/15rQyCnP0iJ/Nmx2/kI6M0PWunEsI6FMs0MbosreaWGHlQmomMIIG7jCCBdagAwIBAgIQ cRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQL EzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYD VQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB 0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXc MM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ //6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSal J1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYI KwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0T AQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9w Y2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1h Z2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28u dmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHp MIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+v OEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSH O3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOV nDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVib vtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5J yNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggSL MIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDIxNDE3MTg0N1owIwYJKoZIhvcNAQkEMRYEFHfQ tAXgh2sYX89YfbRSe51mtFkUMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEFcfSRTG0jNknqb9LV9GuFkwggEF BgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMA0GCSqGSIb3DQEBAQUABIIBABCqfK+z xwvIcwJvZGnzZEqgFkDcBdZw1TRhGnlho0kU5Te5C7x0nvw79efZFsRBsWn4m/kpyuAmaXO+6h2V vBz1OWJvgUZENKjGWRXOBG68GzDdTXfhD5tbTGj3B/txZY8rQoKlQbbmDZLH2UuTWnOqNrG0obMJ bur/0dTDFV9+63AB6XTC+Kmamdd3nRmn1g5hMAufW0Go2jYu1dWXuCgcYeezC49XRA14SWLqbXLz 5ycBadt5fXoUKHAwi1d/FhOBb/KLzOy+QFB9eozhnGvVhxeOLYpdpOY3H3Epx6Tksv+h0ozKSOeY ze1bZzVzsVyqKU8sUPkaHwlhSt6ybiEAAAAAAAA= --Apple-Mail=_51B14B9A-BE51-4CA5-BEEF-81D9E9DB7791-- From lars@netapp.com Tue Feb 14 09:21:36 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 771EB21E8092 for ; Tue, 14 Feb 2012 09:21:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.328 X-Spam-Level: X-Spam-Status: No, score=-10.328 tagged_above=-999 required=5 tests=[AWL=0.271, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nqE0spY928Jv for ; Tue, 14 Feb 2012 09:21:35 -0800 (PST) Received: from mx2.netapp.com (mx2.netapp.com [216.240.18.37]) by ietfa.amsl.com (Postfix) with ESMTP id 8470E21E8088 for ; Tue, 14 Feb 2012 09:21:34 -0800 (PST) X-IronPort-AV: E=Sophos;i="4.73,417,1325491200"; d="p7s'?scan'208";a="625332478" Received: from smtp2.corp.netapp.com ([10.57.159.114]) by mx2-out.netapp.com with ESMTP; 14 Feb 2012 09:21:34 -0800 Received: from sacrsexc2-prd.hq.netapp.com (sacrsexc2-prd.hq.netapp.com [10.99.115.28]) by smtp2.corp.netapp.com (8.13.1/8.13.1/NTAP-1.6) with ESMTP id q1EHLYGo011399; Tue, 14 Feb 2012 09:21:34 -0800 (PST) Received: from VMWEXCEHT01-PRD.hq.netapp.com ([10.106.76.239]) by sacrsexc2-prd.hq.netapp.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 14 Feb 2012 09:21:29 -0800 Received: from SACEXCMBX04-PRD.hq.netapp.com ([169.254.6.193]) by vmwexceht01-prd.hq.netapp.com ([10.106.76.239]) with mapi id 14.02.0247.003; Tue, 14 Feb 2012 09:21:25 -0800 From: "Eggert, Lars" To: Noel Chiappa Thread-Topic: [multipathtcp] codepoint for mptcp options Thread-Index: AQHM6zkI31zTfpIF7ESk8/gRIupZzpY9Kd8A Date: Tue, 14 Feb 2012 17:21:23 +0000 Message-ID: References: <20120214165228.B66A218C090@mercury.lcs.mit.edu> In-Reply-To: <20120214165228.B66A218C090@mercury.lcs.mit.edu> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [10.106.53.51] Content-Type: multipart/signed; boundary="Apple-Mail=_AC76C9C6-3252-4FE3-9CA0-7708433D88C0"; protocol="application/pkcs7-signature"; micalg=sha1 MIME-Version: 1.0 X-OriginalArrivalTime: 14 Feb 2012 17:21:29.0515 (UTC) FILETIME=[16CFC7B0:01CCEB3D] Cc: "" Subject: Re: [multipathtcp] codepoint for mptcp options X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 17:21:36 -0000 --Apple-Mail=_AC76C9C6-3252-4FE3-9CA0-7708433D88C0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii On Feb 14, 2012, at 8:52, Noel Chiappa wrote: > However, on the purely technical level, I think Joe is sort of = correct. The > current TCP/IP architecture doesn't give users any control over paths = (at > least, as routing would think of that term). Multiple = addresses/interfaces are > a 'poor man's way' of providing a certain amount of path diversity, = but it can > make no guarantee, because of the previous point. >=20 > Even with a single TCP connection between two singly-addressed hosts, = packets > from the connection might flow over two paths (but usually don't, = because ISPs > try to avoid that because it can cause packet reordering). And I can = imagine > MPTCP connections where the packets on two sub-connections all take = the exact > same path through the network (e.g. a multi-homed host with two = interfaces to > the same network, for reliability reasons - although people have used = ARP > hacks in the past for that particular capability). >=20 > Yes, multiple sub-connections to different addresses will usually get = you > a different path - but there's no control, or guarantee. Good point. The original research work on MPTCP in the Trilogy project looked at = cases where a multipath-aware routing layer exposed the presence of = multiple paths explicitly, and the end systems could indicate which path = a flow should take. For the IETF standardization of MPTCP, that part got dropped, since the = current Internet routing layer obviously doesn't support that. But the = MPTCP design encompasses such cases. Lars= --Apple-Mail=_AC76C9C6-3252-4FE3-9CA0-7708433D88C0 Content-Disposition: attachment; filename="smime.p7s" Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIMQDCCBUow ggQyoAMCAQICEFcfSRTG0jNknqb9LV9GuFkwDQYJKoZIhvcNAQEFBQAwgd0xCzAJBgNVBAYTAlVT MRcwFQYDVQQKEw5WZXJpU2lnbiwgSW5jLjEfMB0GA1UECxMWVmVyaVNpZ24gVHJ1c3QgTmV0d29y azE7MDkGA1UECxMyVGVybXMgb2YgdXNlIGF0IGh0dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9ycGEg KGMpMDkxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZhbGlkYXRlZDE3MDUGA1UEAxMuVmVyaVNpZ24g Q2xhc3MgMSBJbmRpdmlkdWFsIFN1YnNjcmliZXIgQ0EgLSBHMzAeFw0xMTEyMTAwMDAwMDBaFw0x MjEyMDkyMzU5NTlaMIIBDTEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlT aWduIFRydXN0IE5ldHdvcmsxRjBEBgNVBAsTPXd3dy52ZXJpc2lnbi5jb20vcmVwb3NpdG9yeS9S UEEgSW5jb3JwLiBieSBSZWYuLExJQUIuTFREKGMpOTgxHjAcBgNVBAsTFVBlcnNvbmEgTm90IFZh bGlkYXRlZDEzMDEGA1UECxMqRGlnaXRhbCBJRCBDbGFzcyAxIC0gTmV0c2NhcGUgRnVsbCBTZXJ2 aWNlMRQwEgYDVQQDFAtMYXJzIEVnZ2VydDEeMBwGCSqGSIb3DQEJARYPbGFyc0BuZXRhcHAuY29t MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAokrhJTcXt6J/VEpZOicLoguBlYTjXP9v Ze4HuuhXnURUS8YouAfgaqA0zYbt5yd6fh4PBMdAaEWr5yJyHuFykXlrCumjUWSpLuqTS2A+pt4q cZaAQk9iLDN/UVd3SpkUuvWbxXlqzG7/BSqa3VNObBzCmyh+V7aXxri+30CT//DSsNRC4VFy6sn6 dMgSaFenXLwe/FBwY0qTMfICT1PrrX6Sw1S8OfH9rykLlZXbmfkFExxQngp1DJH9xMHeODHGbCv/ ty5gdxMOrLe+vENxFEcy1YQWBZd1kNL4UObugF8A/jE/s+Oa3H1VFH8ghqZTdqGDysVxmtKHuNFx 6jIBSQIDAQABo4HSMIHPMAkGA1UdEwQCMAAwRAYDVR0gBD0wOzA5BgtghkgBhvhFAQcXATAqMCgG CCsGAQUFBwIBFhxodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhMAsGA1UdDwQEAwIFoDAdBgNV HSUEFjAUBggrBgEFBQcDBAYIKwYBBQUHAwIwUAYDVR0fBEkwRzBFoEOgQYY/aHR0cDovL2luZGMx ZGlnaXRhbGlkLWczLWNybC52ZXJpc2lnbi5jb20vSW5kQzFEaWdpdGFsSUQtRzMuY3JsMA0GCSqG SIb3DQEBBQUAA4IBAQBA7q6tR92qpd7xo7VBsrOfGCWzoxIVfTc7t0RhB/Oz/+c3lnhYnNScIuKN JmyZvznmVxqB9BJ72+NkvmdB/hnILSBTRawL2tyLo9PkBtN0nRt4gS6wjpWnD8G83hlJLE7r25jk 7HkRev61dTIXsANFpJKF02C4XSoDfEzNV6MpuEvHvcgHCqMrlwWwfKc7+NoDnE8PBuRzwSXvlD5L mswCY2iiOsd7ImNO4OzTCxETvKTDu92+FTIbRJJpYjVNv1UF7e3w9Kq65BkZJErUH19beUeQl0Wh 2BJQE6/15rQyCnP0iJ/Nmx2/kI6M0PWunEsI6FMs0MbosreaWGHlQmomMIIG7jCCBdagAwIBAgIQ cRVmBUrkkSFN6bxE+azT3DANBgkqhkiG9w0BAQUFADCByjELMAkGA1UEBhMCVVMxFzAVBgNVBAoT DlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTowOAYDVQQL EzEoYykgMTk5OSBWZXJpU2lnbiwgSW5jLiAtIEZvciBhdXRob3JpemVkIHVzZSBvbmx5MUUwQwYD VQQDEzxWZXJpU2lnbiBDbGFzcyAxIFB1YmxpYyBQcmltYXJ5IENlcnRpZmljYXRpb24gQXV0aG9y aXR5IC0gRzMwHhcNMDkwNTAxMDAwMDAwWhcNMTkwNDMwMjM1OTU5WjCB3TELMAkGA1UEBhMCVVMx FzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3Jr MTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAo YykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBD bGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBDQSAtIEczMIIBIjANBgkqhkiG9w0BAQEFAAOC AQ8AMIIBCgKCAQEA7cRH3yooHXwGa7vXITLJbBOP6bGNQU4099oL42r6ZYggCxET6ZvgSU6Lb9UB 0F8NR5GKWkx0Pj/GkQm7TDSejW6hglFi92l2WJYHr54UGAdPWr2f0jGyVBlzRmoZQhHsEnMhjfXc MM3l2VYKMcU2bSkUl70t2olHGYjYSwQ967Y8Zx50ABMN0Ibak2f4MwOuGjxraXj2wCyO4YM/d/mZ //6fUlrCtIcK2GypR8FUKWVDPkrAlh/Brfd3r2yxBF6+wbaULZeQLSfSux7pg2qE9sSyriMGZSal J1grByK0b6ZiSBp38tVQJ5op05b7KPW6JHZi44xZ6/tu1ULEvkHH9QIDAQABo4ICuTCCArUwNAYI KwYBBQUHAQEEKDAmMCQGCCsGAQUFBzABhhhodHRwOi8vb2NzcC52ZXJpc2lnbi5jb20wEgYDVR0T AQH/BAgwBgEB/wIBADBwBgNVHSAEaTBnMGUGC2CGSAGG+EUBBxcBMFYwKAYIKwYBBQUHAgEWHGh0 dHBzOi8vd3d3LnZlcmlzaWduLmNvbS9jcHMwKgYIKwYBBQUHAgIwHhocaHR0cHM6Ly93d3cudmVy aXNpZ24uY29tL3JwYTA0BgNVHR8ELTArMCmgJ6AlhiNodHRwOi8vY3JsLnZlcmlzaWduLmNvbS9w Y2ExLWczLmNybDAOBgNVHQ8BAf8EBAMCAQYwbgYIKwYBBQUHAQwEYjBgoV6gXDBaMFgwVhYJaW1h Z2UvZ2lmMCEwHzAHBgUrDgMCGgQUS2u5KJYGDLvQUjibKaxLB4shBRgwJhYkaHR0cDovL2xvZ28u dmVyaXNpZ24uY29tL3ZzbG9nbzEuZ2lmMC4GA1UdEQQnMCWkIzAhMR8wHQYDVQQDExZQcml2YXRl TGFiZWw0LTIwNDgtMTE4MB0GA1UdDgQWBBR5R2EIQf04BKJL57XM9UP2SSsR+DCB8QYDVR0jBIHp MIHmoYHQpIHNMIHKMQswCQYDVQQGEwJVUzEXMBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNV BAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsxOjA4BgNVBAsTMShjKSAxOTk5IFZlcmlTaWduLCBJ bmMuIC0gRm9yIGF1dGhvcml6ZWQgdXNlIG9ubHkxRTBDBgNVBAMTPFZlcmlTaWduIENsYXNzIDEg UHVibGljIFByaW1hcnkgQ2VydGlmaWNhdGlvbiBBdXRob3JpdHkgLSBHM4IRAItbdVaEVIULAM+v OEjOsaQwDQYJKoZIhvcNAQEFBQADggEBADlNz0GZgbWpBbVSOOk5hIls5DSoWufYbAlMJBq6WaSH O3Mh8ZOBz79oY1pn/jWFK6HDXaNKwjoZ3TDWzE3v8dKBl8pUWkO/N4t6jhmND0OojPKvYLMVirOV nDzgnrMnmKQ1chfl/Cpdh9OKDcLRRSr4wPSsKpM61a4ScAjr+zvid+zoK2Q1ds262uDRyxTWcVib vtU+fbbZ6CTFJGZMXZEfdrMXPn8NxiGJL7M3uKH/XLJtSd5lUkL7DojS7Uodv0vj+Mxy+kgOZY5J yNb4mZg7t5Q+MXEGh/psWVMu198r7V9jAKwV7QO4VRaMxmgD5yKocwuxvKDaUljdCg5/wYIxggSL MIIEhwIBATCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJbmMuMR8wHQYD VQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1c2UgYXQgaHR0 cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29uYSBOb3QgVmFs aWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vic2NyaWJlciBD QSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMAkGBSsOAwIaBQCgggJtMBgGCSqGSIb3DQEJAzELBgkq hkiG9w0BBwEwHAYJKoZIhvcNAQkFMQ8XDTEyMDIxNDE3MjEzN1owIwYJKoZIhvcNAQkEMRYEFLWN mrvBco/huPLrX1pErOXl9idVMIIBAwYJKwYBBAGCNxAEMYH1MIHyMIHdMQswCQYDVQQGEwJVUzEX MBUGA1UEChMOVmVyaVNpZ24sIEluYy4xHzAdBgNVBAsTFlZlcmlTaWduIFRydXN0IE5ldHdvcmsx OzA5BgNVBAsTMlRlcm1zIG9mIHVzZSBhdCBodHRwczovL3d3dy52ZXJpc2lnbi5jb20vcnBhIChj KTA5MR4wHAYDVQQLExVQZXJzb25hIE5vdCBWYWxpZGF0ZWQxNzA1BgNVBAMTLlZlcmlTaWduIENs YXNzIDEgSW5kaXZpZHVhbCBTdWJzY3JpYmVyIENBIC0gRzMCEFcfSRTG0jNknqb9LV9GuFkwggEF BgsqhkiG9w0BCRACCzGB9aCB8jCB3TELMAkGA1UEBhMCVVMxFzAVBgNVBAoTDlZlcmlTaWduLCBJ bmMuMR8wHQYDVQQLExZWZXJpU2lnbiBUcnVzdCBOZXR3b3JrMTswOQYDVQQLEzJUZXJtcyBvZiB1 c2UgYXQgaHR0cHM6Ly93d3cudmVyaXNpZ24uY29tL3JwYSAoYykwOTEeMBwGA1UECxMVUGVyc29u YSBOb3QgVmFsaWRhdGVkMTcwNQYDVQQDEy5WZXJpU2lnbiBDbGFzcyAxIEluZGl2aWR1YWwgU3Vi c2NyaWJlciBDQSAtIEczAhBXH0kUxtIzZJ6m/S1fRrhZMA0GCSqGSIb3DQEBAQUABIIBAIaYdGiC iSUXa2+Em8tHSEEUXY31I+1avCAfvxHO4PSZDlqnf1tB+ZPHxjutf9o8t//awds6obD6Hs4PxR8g uI2bc+k9h0+gd9OVbVn9mOqXw71fX5vXC2S0HJlAnRfKumOU8JJLngPs27eBn74mSbYeUpbqibT6 yRIGSN8zFJrj8nMg46l6lr8b4xr6LYTsyq9KmXxuZhW27qGghL4e4VAJSwKbJLYw4ur4UBvsbocR te6uYd+lXr7qrPa3+a/06vfVV9XFfKyJtu5aL6Rtrw2sjhHew1QTV23a5vWa9Q5gasj4FvdTIRtj wTd1F3p6gJCPJ7cMjLnt9AZTfL2Wl/MAAAAAAAA= --Apple-Mail=_AC76C9C6-3252-4FE3-9CA0-7708433D88C0-- From touch@isi.edu Tue Feb 14 10:13:34 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E466C21F8663 for ; Tue, 14 Feb 2012 10:13:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.957 X-Spam-Level: X-Spam-Status: No, score=-102.957 tagged_above=-999 required=5 tests=[AWL=-0.358, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id afslp+y7wyMV for ; Tue, 14 Feb 2012 10:13:34 -0800 (PST) Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by ietfa.amsl.com (Postfix) with ESMTP id 37C5521F862D for ; Tue, 14 Feb 2012 10:13:34 -0800 (PST) Received: from [128.9.160.166] (abc.isi.edu [128.9.160.166]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id q1EID4Gj001232 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 14 Feb 2012 10:13:05 -0800 (PST) Message-ID: <4F3AA430.10101@isi.edu> Date: Tue, 14 Feb 2012 10:13:04 -0800 From: Joe Touch User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:9.0) Gecko/20111222 Thunderbird/9.0.1 MIME-Version: 1.0 To: "Eggert, Lars" References: <7F4D67DE-9A41-4550-85FE-983BCDEC2639@isi.edu> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-ISI-4-43-8-MailScanner: Found to be clean X-MailScanner-From: touch@isi.edu Cc: "" , Noel Chiappa Subject: Re: [multipathtcp] codepoint for mptcp options X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 18:13:35 -0000 On 2/14/2012 9:16 AM, Eggert, Lars wrote: > On Feb 14, 2012, at 8:49, Joe Touch wrote: >> As an exercise, can you confirm whether you think this option could ever be used when there are two single-homed hosts in a way that differs from existing TCP? If so, you could accurately call that a path-selection extension to this at best. > > Yes. There was someone on the MPTCP developers list recently who wanted to use four subflows between to single-homed machines, because their ISP capped single-flow throughput at a quarter of the upstream bandwidth. > > (This isn't something that the implementation supports without manual configuration, but the code does support it.) > > Lars OK - that's multiflow then. You're giving a lot of good reasons multipath is a really misleading name. Joe From C.RAICIU@cs.ucl.ac.uk Tue Feb 14 12:25:34 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CBE121E807A for ; Tue, 14 Feb 2012 12:25:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jIAie4KnHm7X for ; Tue, 14 Feb 2012 12:25:34 -0800 (PST) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) by ietfa.amsl.com (Postfix) with ESMTP id D39DE21E8011 for ; Tue, 14 Feb 2012 12:25:33 -0800 (PST) Received: from [92.80.108.21] (helo=[192.168.1.8]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (C.Raiciu authenticated) (Exim 4.54) id 1RxOwG-0001X2-Tp for multipathtcp@ietf.org; Tue, 14 Feb 2012 20:25:25 +0000 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Apple Message framework v1084) From: Costin Raiciu In-Reply-To: <7F4D67DE-9A41-4550-85FE-983BCDEC2639@isi.edu> Date: Tue, 14 Feb 2012 22:24:34 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <7F4D67DE-9A41-4550-85FE-983BCDEC2639@isi.edu> To: multipathtcp List X-Mailer: Apple Mail (2.1084) Subject: Re: [multipathtcp] codepoint for mptcp options X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 20:25:34 -0000 > As an exercise, can you confirm whether you think this option could = ever be used when there are two single-homed hosts in a way that differs = from existing TCP? If so, you could accurately call that a = path-selection extension to this at best. Actually MPTCP works very well with ECMP deployed in the network by = operators.=20 MPTCP enabled end-hosts open multiple subflows between the same = addresses but different port combinations (i.e. at least one port has to = differ). This is used heavily when MPTCP is used in data-centers, which commonly = employ ECMP to allows endpoints to use multiple paths. Costin >=20 > Joe >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nishida@sfc.wide.ad.jp Tue Feb 14 12:45:37 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62AB721E80EB for ; Tue, 14 Feb 2012 12:45:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.704 X-Spam-Level: X-Spam-Status: No, score=-98.704 tagged_above=-999 required=5 tests=[AWL=-0.230, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00ZUYdne+fjk for ; Tue, 14 Feb 2012 12:45:37 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id DA41021E8018 for ; Tue, 14 Feb 2012 12:45:36 -0800 (PST) Received: from mail-lpp01m020-f172.google.com (mail-lpp01m020-f172.google.com [209.85.217.172]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 9D5F0278095 for ; Wed, 15 Feb 2012 05:45:31 +0900 (JST) Received: by lbbgk8 with SMTP id gk8so162752lbb.31 for ; Tue, 14 Feb 2012 12:45:28 -0800 (PST) MIME-Version: 1.0 Received: by 10.112.84.1 with SMTP id u1mr8014089lby.35.1329252328360; Tue, 14 Feb 2012 12:45:28 -0800 (PST) Received: by 10.112.76.162 with HTTP; Tue, 14 Feb 2012 12:45:28 -0800 (PST) In-Reply-To: <4F3AA430.10101@isi.edu> References: <7F4D67DE-9A41-4550-85FE-983BCDEC2639@isi.edu> <4F3AA430.10101@isi.edu> Date: Tue, 14 Feb 2012 12:45:28 -0800 Message-ID: From: Yoshifumi Nishida To: Joe Touch Content-Type: text/plain; charset=ISO-8859-1 Cc: multipathtcp Subject: Re: [multipathtcp] codepoint for mptcp options X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 20:45:37 -0000 On Tue, Feb 14, 2012 at 10:13 AM, Joe Touch wrote: > > > On 2/14/2012 9:16 AM, Eggert, Lars wrote: >> >> On Feb 14, 2012, at 8:49, Joe Touch wrote: >>> >>> As an exercise, can you confirm whether you think this option could ever >>> be used when there are two single-homed hosts in a way that differs from >>> existing TCP? If so, you could accurately call that a path-selection >>> extension to this at best. >> >> >> Yes. There was someone on the MPTCP developers list recently who wanted to >> use four subflows between to single-homed machines, because their ISP capped >> single-flow throughput at a quarter of the upstream bandwidth. >> >> (This isn't something that the implementation supports without manual >> configuration, but the code does support it.) >> >> Lars > > > OK - that's multiflow then. > IMO, I think we could call them flows in multiple logical paths, which multipath doesn't sound misleading to me. -- Yoshifumi From olivier.bonaventure@uclouvain.be Tue Feb 14 12:56:44 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81D3921E8116 for ; Tue, 14 Feb 2012 12:56:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.599 X-Spam-Level: X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8Blw+9LZC8MK for ; Tue, 14 Feb 2012 12:56:43 -0800 (PST) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id C534F21E8112 for ; Tue, 14 Feb 2012 12:56:43 -0800 (PST) Received: from mbpobo.local (host-85-27-91-91.brutele.be [85.27.91.91]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 305B111E92B; Tue, 14 Feb 2012 21:56:39 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 305B111E92B DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1329252999; bh=nnFQh5DivVFDjkh5NoKbt5LuRdmLUe9g9vAEjquKuy8=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=nNFkBZeEjzRL6z6m9hEjD3zZynsvIybKTSRjuIcj4aBzkFk1efIwG8oTNd/W89TEb D28CrBT+RGWXm7CgOyTa5o+4EM014gAAea6Yqn09s1tItrSLRMK+h1FPVocUSMfCHj EP6yQPFE8nmM3rbFPK8CTtvdm3iK9OAkzLmwkCq8= Message-ID: <4F3ACA87.90001@uclouvain.be> Date: Tue, 14 Feb 2012 21:56:39 +0100 From: Olivier Bonaventure User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:10.0.1) Gecko/20120208 Thunderbird/10.0.1 MIME-Version: 1.0 To: Joe Touch References: <20120214161442.9EA9B18C0A8@mercury.lcs.mit.edu> <2D6F54AF-E2E1-436C-B29A-52077A21083A@isi.edu> In-Reply-To: <2D6F54AF-E2E1-436C-B29A-52077A21083A@isi.edu> X-Enigmail-Version: 1.3.5 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.97-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 305B111E92B.A172F X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Cc: multipathtcp@ietf.org, Noel Chiappa Subject: Re: [multipathtcp] codepoint for mptcp options X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 14 Feb 2012 20:56:44 -0000 Joe, > FWIW, *if* this is assigned a TCP option of its own, I urge the group to select a name that is *accurately* describes the purpose of this option, e.g. "multiaddress" or "multiIP". "Multipath" is misleading, and because TCP options persist, is likely to continue to cause confusion. I would suggest using MPTCP as the option name. This is the acronym of the WG, it correctly reflects the protocol. I don't think that we need to spell out the acronym. Olivier From internet-drafts@ietf.org Thu Feb 16 07:57:36 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F10721F874A; Thu, 16 Feb 2012 07:57:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.011, BAYES_00=-2.599, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 165GUgkvH3Vy; Thu, 16 Feb 2012 07:57:31 -0800 (PST) Received: from ietfa.amsl.com (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7A6D21F8749; Thu, 16 Feb 2012 07:57:31 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 3.64p2 Message-ID: <20120216155731.25997.86390.idtracker@ietfa.amsl.com> Date: Thu, 16 Feb 2012 07:57:31 -0800 Cc: multipathtcp@ietf.org Subject: [multipathtcp] I-D Action: draft-ietf-mptcp-api-04.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 15:57:36 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Multipath TCP Working Group of the IE= TF. Title : MPTCP Application Interface Considerations Author(s) : Michael Scharf Alan Ford Filename : draft-ietf-mptcp-api-04.txt Pages : 29 Date : 2012-02-16 Multipath TCP (MPTCP) adds the capability of using multiple paths to a regular TCP session. Even though it is designed to be totally backward compatible to applications, the data transport differs compared to regular TCP, and there are several additional degrees of freedom that applications may wish to exploit. This document summarizes the impact that MPTCP may have on applications, such as changes in performance. Furthermore, it discusses compatibility issues of MPTCP in combination with non-MPTCP-aware applications. Finally, the document describes a basic application interface for MPTCP-aware applications that provides access to multipath address information and a level of control equivalent to regular TCP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mptcp-api-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mptcp-api-04.txt From Michael.Scharf@alcatel-lucent.com Thu Feb 16 08:07:52 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1A9C21F8759 for ; Thu, 16 Feb 2012 08:07:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.186 X-Spam-Level: X-Spam-Status: No, score=-6.186 tagged_above=-999 required=5 tests=[AWL=0.063, BAYES_00=-2.599, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L8juArlTtPx5 for ; Thu, 16 Feb 2012 08:07:48 -0800 (PST) Received: from mailrelay2.alcatel.de (mailrelay2.alcatel.de [194.113.59.96]) by ietfa.amsl.com (Postfix) with ESMTP id 853D421F862D for ; Thu, 16 Feb 2012 08:07:39 -0800 (PST) Received: from SLFSNX.rcs.alcatel-research.de (slfsn1.rcs.de.alcatel-lucent.com [149.204.60.98]) by mailrelay2.alcatel.de (8.14.3/8.14.3/ICT) with ESMTP id q1GG7cGx022315; Thu, 16 Feb 2012 17:07:38 +0100 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Date: Thu, 16 Feb 2012 17:07:33 +0100 Message-ID: <133D9897FB9C5E4E9DF2779DC91E947C06C80D7F@SLFSNX.rcs.alcatel-research.de> X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: MPTCP API draft update Thread-Index: Aczsw85CfXoV+ZNpSTu8ekEAQVSsZgAABnFA From: "SCHARF, Michael" To: X-Scanned-By: MIMEDefang 2.69 on 149.204.45.73 Subject: [multipathtcp] MPTCP API draft update X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Feb 2012 16:07:52 -0000 Hi all, This is an update of the API draft that addresses the WGLC comments we received so far. It adds the missing security consideration section, including a sentence on path separation, and it better explains what happens if an app binds to a specific address, as discussed on the mailing list. Given that his results in some additional paragraphs and rewording, we decided to post an update of the whole document. Please use this version in further reviews. Thanks Michael & Alan -----Original Message----- From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Thursday, February 16, 2012 4:58 PM To: i-d-announce@ietf.org Cc: multipathtcp@ietf.org Subject: [multipathtcp] I-D Action: draft-ietf-mptcp-api-04.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multipath TCP Working Group of the IETF. Title : MPTCP Application Interface Considerations Author(s) : Michael Scharf Alan Ford Filename : draft-ietf-mptcp-api-04.txt Pages : 29 Date : 2012-02-16 Multipath TCP (MPTCP) adds the capability of using multiple paths to a regular TCP session. Even though it is designed to be totally backward compatible to applications, the data transport differs compared to regular TCP, and there are several additional degrees of freedom that applications may wish to exploit. This document summarizes the impact that MPTCP may have on applications, such as changes in performance. Furthermore, it discusses compatibility issues of MPTCP in combination with non-MPTCP-aware applications. Finally, the document describes a basic application interface for MPTCP-aware applications that provides access to multipath address information and a level of control equivalent to regular TCP. A URL for this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-mptcp-api-04.txt Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ This Internet-Draft can be retrieved at: ftp://ftp.ietf.org/internet-drafts/draft-ietf-mptcp-api-04.txt _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp From ayar@mailbox.tu-berlin.de Mon Feb 20 06:01:28 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D8A0721F86A6 for ; Mon, 20 Feb 2012 06:01:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.649 X-Spam-Level: X-Spam-Status: No, score=-3.649 tagged_above=-999 required=5 tests=[BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2GaQ9J+2rSvH for ; Mon, 20 Feb 2012 06:01:22 -0800 (PST) Received: from mail.tu-berlin.de (mail.tu-berlin.de [130.149.7.33]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF0C21F85F2 for ; Mon, 20 Feb 2012 06:01:22 -0800 (PST) X-tubIT-Incoming-IP: 130.149.7.200 Received: from www.redaktion.tu-berlin.de ([130.149.7.200] helo=mailbox.tu-berlin.de) by mail.tu-berlin.de (exim-4.75/mailfrontend-2) with esmtp for id 1RzTnt-0002pK-I4; Mon, 20 Feb 2012 15:01:21 +0100 Received: from nat.tkn.tu-berlin.de (nat.tkn.tu-berlin.de [130.149.49.18]) by webmail.tu-berlin.de (Horde Framework) with HTTP; Mon, 20 Feb 2012 15:01:19 +0100 Message-ID: <20120220150119.33111sskz80cevcf@webmail.tu-berlin.de> Date: Mon, 20 Feb 2012 15:01:19 +0100 From: ayar@mailbox.tu-berlin.de To: "multipathtcp@ietf.org" MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed" Content-Disposition: inline Content-Transfer-Encoding: 7bit User-Agent: Internet Messaging Program (IMP) H3 (4.3.9) X-Mailman-Approved-At: Mon, 20 Feb 2012 06:10:56 -0800 Subject: [multipathtcp] A New Draft: draft-ayar-transparent-sca-proxy-00 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 14:07:12 -0000 Hi all, We have posted a new draft with the title: "A Transparent Performance Enhancing Proxy Architecture To Enable TCP over Multiple Paths for Single-Homed Hosts" (http://tools.ietf.org/html/draft-ayar-transparent-sca-proxy-00). In this draft, we define a TCP Splitter/Combiner Architecture (SCA) that enables non-MPTCP-capable single-homed hosts to benefit from the multiple paths within Internet by means of transparent performance enhancing proxies (PEPs). Since existence of the SCA is shielded from the TCP end-points, it can also be deployed on the TCP end-hosts. We invite everybody to read the draft and look forward to your comments. Thanks, Tacettin From christoph.paasch@uclouvain.be Mon Feb 20 06:18:01 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 31B5321F876A for ; Mon, 20 Feb 2012 06:18:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.299 X-Spam-Level: X-Spam-Status: No, score=-6.299 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8U6EkMrDVl02 for ; Mon, 20 Feb 2012 06:17:56 -0800 (PST) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 29F9221F8747 for ; Mon, 20 Feb 2012 06:17:56 -0800 (PST) Received: from [IPv6:2001:6a8:3080:2:6ab5:99ff:feea:c2fa] (haproxy2.sipr.ucl.ac.be [130.104.5.120]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cpaasch@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id F229411E77E for ; Mon, 20 Feb 2012 15:17:50 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be F229411E77E DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1329747471; bh=WME/2o/WRQMuVwF21/JAzGpG+AIFKnYJYu/p+nC8HMU=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:Subject:References: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=MRQKnbU5zZqZMFZ01DO1LohklxJavlvEI6AT+3VWM2/0Ydf4pYCMuyqaD89tqR1Wr t21kaQzzHzCT6xIGBhiVh3tLJWKvaQ3fVOazpOYTNj0OEAs1FPg0OEUkprnE4sESaI N0IWuxRgpNORm15F1KdmI96apg9Dh1RWYMRbZIQA= Message-ID: <4F42560E.7000509@uclouvain.be> Date: Mon, 20 Feb 2012 15:17:50 +0100 From: Christoph Paasch Organization: =?ISO-8859-1?Q?Universit=E9_Catholique_de_Louvain?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: MultiPath TCP - IETF WG References: <20120131175804.26422.68065.idtracker@ietfa.amsl.com> In-Reply-To: <20120131175804.26422.68065.idtracker@ietfa.amsl.com> X-TagToolbar-Keys: D20120220151750682 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: F229411E77E.A24D1 X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Subject: Re: [multipathtcp] I-D Action: draft-ietf-mptcp-multiaddressed-06.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: christoph.paasch@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Feb 2012 14:18:01 -0000 Hello, sorry for writing this so late (8 days left until the end of the LC), but I only now had the time to do a full read of the draft. I have several comments concerning the draft as you can see below. ============ * Retransmission of the third ACK, to ensure reliable delivery of the keys in MP_CAPABLE (page 14): The retransmission of the third ack was introduced to allow lost third acks, if the server is operating stateless. However, this introduced an additional RTT before the client is able to send data and thus, we now allow the client to send data before he receives the acknowledgment of his third ack (in PRE_ESTABLISHED state). I now realize, that the retransmission does not buy us a lot: E.g., if the third ACK gets lost, but the client already starts to send data and this data reaches the stateless server. The server then can only send a subflow-ack without DATA_ACK and thus behave as in regular TCP. The client then should interpret this subflow-ack not as the one acknowledging the third ack (the one with the MP_CAPABLE), but rather fallback to regular TCP. Because, otherwise the client and server are no more in-sync. Thus, the retransmission only buys us something if the server is behaving stateless, the third ack got lost and the server is the one trying to send data first. This same problem is already present for stateless servers operating with regular TCP. I'm not sure that this current behavior of sending data in PRE_ESTABLISHED state is safe (e.g., how to behave if the third ack and the first data-packet got lost, but the second data-packet reaches the server? - the server sends a duplicate subflow-ack without MPTCP-options. How will the client interpret this subflow-ack?). I think we should remove the retransmission of the third ack, as it does not buy us a lot, and keep with the simpler and more straight-forward mechanism of not caring about lost third-acks (as in draft v02). ============ * Note about pre-established state for *new* subflows (page 19, second paragraph): It is not clear to me, if we are allowed to send data on new subflows while we are still in PRE_ESTABLISHED state. Because for the initial subflow it is allowed. If we are allowed to send data on new subflows while in PRE_ESTABLISHED, it does not really make sense to differentiate between PRE_ESTABLISEHED and ESTABLISHED for the additional subflows. However, on page 21, we say that "If Host B does not receive the expected MAC, or the MP_JOIN option is missing from the ACK, it MUST close the subflow with a TCP RST." Thus, I would say that we are not allowed to send data while in PRE_ESTABLISHED state for new subflows. So, we should clearly specify that this behavior is different for MP_JOIN's than for MP_CAPABLE's. ============ * Duplicate ACK's with an MPTCP-option should not be considered as signals of congestion (first paragraph of page 13 and page 45, "Duplicate ACK"): I think, we should limit this to duplicate ACK's, containing either REMOVE_ADDR, ADD_ADDR, MP_PRIO or MP_FAIL. Otherwise, we have to make sure that we do not put DATA_ACK in duplicate ack's (which is not so easy to do from an implementation point-of-view). Additionally, it should be allowed to put a DATA_ACK in a duplicate ack, because this DATA_ACK may advance the snd_una (due to data arrived on another subflow). And, the faster we get the info back for the new snd_una, the better it is for MPTCP's performance (e.g., the other subflow may have a high RTT). ============ * page 25: "If a mapping for that subflow-level sequence space does not arrive within a receive window of data, that subflow SHOULD be treated as broken,..." This is needed, because we allow to receive a DSS-mapping for a certain subflow-sequence-space on a packet whose sub-sequence-numbers do not belong to this space. I suggest, that we do not support this due to several reasons: 1. why should an implementation decide to send the DSS-mapping on a packet belonging to a different seq-space than specified in the DSS-mapping-option. 2. if we do it, and we store a full receive-window, we have to use quite a lot of memory before treating the subflow as broken. If we would only support DSS-mappings on packets who belong to this sequence-space, we can drop the data as soon as we receive a subsequence packet on this subflow with a DSS-mapping that does not cover the previous sequence-space (e.g., this happens in case of coalescing middleboxes). And, if we don't receive mappings, we can drop data as soon as we exceed 64KB, as the DATA_LEN's maximum is at 64KB. ============ * p.27, Section 3.3.3: "Note that when the DATA FIN is not attached to a TCP segment containing data, the Data Sequence Mapping MUST have Subflow Sequence Number of 0." I don't see, why this is needed (we don't implement this - and DATA_FIN's are still working very fine). Couldn't we drop this paragraph for simplicity? ============ * p.29, Section 3.3.5: "It should only update its local receive window values when the largest sequence number allowed increases." Why not as in RFC 793, p.72: "If SND.UNA < SEG.ACK =< SND.NXT, the send window should be updated. If (SND.WL1 < SEG.SEQ or (SND.WL1 = SEG.SEQ and SND.WL2 =< SEG.ACK)), set SND.WND <- SEG.WND, set SND.WL1 <- SEG.SEQ, and set SND.WL2 <- SEG.ACK." This is in my opinion more correct than the sentence in our draft. Maybe we could just reference RFC793 in the mptcp-draft. ============ * p. 41: "If it is known that all unacknowledged data in flight is contiguous..." Does it really need to be contiguous? Because, basically when falling back, the sender of the MP_FAIL (data-receiver) will discard all data he receives after the DATA-sequence-number which triggered the fallback. Only packets after the infinite-mapping option will be allowed. Otherwise, we may have a corrupted byte-stream presented to the application. Thus, the data-sender (after receiving the MP_FAIL) will just send the infinite-mapping option on the next packet. Irregardless, if the data in-flight is contiguous or not. ============ Some minor nits: p.8, Section 2: "...between two hosts communicating hosts like..." One "hosts" too much. p.10, Section 2.4: "...number space and a MPTCP option..." -> "...number space and an MPTCP option..." p.10, Section 2.4: In the figure detailing the content of the DSS-option, DATA_LEN is missing. p.26, Section 3.3.2: "... to the behaviour of the standard TCP cumulative ACK in TCP SACK" Not the ack in TCP SACK. It's just the usual standard TCP cumulative ACK. p. 45: "Instead an explicit data-level ACK is This separate subflow- and..." This sentence got somehow mixed with something else. Cheers, Christoph On 01/31/2012 06:58 PM, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multipath TCP Working Group of the IETF. > > Title : TCP Extensions for Multipath Operation with Multiple Addresses > Author(s) : Alan Ford > Costin Raiciu > Mark Handley > Olivier Bonaventure > Filename : draft-ietf-mptcp-multiaddressed-06.txt > Pages : 60 > Date : 2012-01-31 > > TCP/IP communication is currently restricted to a single path per > connection, yet multiple paths often exist between peers. The > simultaneous use of these multiple paths for a TCP/IP session would > improve resource usage within the network, and thus improve user > experience through higher throughput and improved resilience to > network failure. > > Multipath TCP provides the ability to simultaneously use multiple > paths between peers. This document presents a set of extensions to > traditional TCP to support multipath operation. The protocol offers > the same type of service to applications as TCP (i.e. reliable > bytestream), and provides the components necessary to establish and > use multiple TCP flows across potentially disjoint paths. > > > A URL for this Internet-Draft is: > http://www.ietf.org/internet-drafts/draft-ietf-mptcp-multiaddressed-06.txt > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > This Internet-Draft can be retrieved at: > ftp://ftp.ietf.org/internet-drafts/draft-ietf-mptcp-multiaddressed-06.txt > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > -- Christoph Paasch PhD Student IP Networking Lab --- http://inl.info.ucl.ac.be MultiPath TCP in the Linux Kernel --- http://mptcp.info.ucl.ac.be Université Catholique de Louvain -- From alanford@cisco.com Tue Feb 21 04:58:06 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54EC021F87B6 for ; Tue, 21 Feb 2012 04:58:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.232 X-Spam-Level: X-Spam-Status: No, score=-8.232 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, RCVD_IN_DNSWL_HI=-8, RCVD_NUMERIC_HELO=2.067] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8c7tsPgjv07b for ; Tue, 21 Feb 2012 04:58:02 -0800 (PST) Received: from ams-iport-2.cisco.com (ams-iport-2.cisco.com [144.254.224.141]) by ietfa.amsl.com (Postfix) with ESMTP id 5FAF221F87B1 for ; Tue, 21 Feb 2012 04:58:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=alanford@cisco.com; l=11063; q=dns/txt; s=iport; t=1329829081; x=1331038681; h=date:subject:from:to:message-id:in-reply-to:mime-version: content-transfer-encoding; bh=oYNwmsUR6Wm8ml9a72Dn3unQdy4N1EtD1Ezl6Zt2LrU=; b=fLuTCTvcquVNBSLXKkKuuArl2pq/wekAi6WaGmAHE6gIqEqBXxvqfdFt w5h4a/KFZ40tKBi5hAG8pU9KXfiNo3UITYo61h4ZbCBR6P2B7T94B8E5w HRDedhVNhR2OH+tGbvhOHzyrRKVByVTkIUfCGKysk3w4d3NE+u83th5DF E=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AuYIAMCTQ0+Q/khN/2dsb2JhbAA+BbIaAoEHgXMBAQEDAQEBAQ8BFBMCASoHEA0BCBhVMAEBBAESCRmHXgmgGAGXKYlgEIIDAwELBwcJAwQGAQEtAQWEGAgHCoMzBJU4jkuEIoFTAQQD X-IronPort-AV: E=Sophos;i="4.73,457,1325462400"; d="scan'208";a="66648460" Received: from ams-core-4.cisco.com ([144.254.72.77]) by ams-iport-2.cisco.com with ESMTP; 21 Feb 2012 12:57:59 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-4.cisco.com (8.14.3/8.14.3) with ESMTP id q1LCvx6w018940; Tue, 21 Feb 2012 12:57:59 GMT Received: from xmb-ams-203.cisco.com ([144.254.75.14]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Tue, 21 Feb 2012 13:57:58 +0100 Received: from 144.254.90.168 ([144.254.90.168]) by XMB-AMS-203.cisco.com ([144.254.75.14]) with Microsoft Exchange Server HTTP-DAV ; Tue, 21 Feb 2012 12:57:58 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Tue, 21 Feb 2012 12:57:57 +0000 From: Alan Ford To: , MultiPath TCP - IETF WG Message-ID: Thread-Topic: [multipathtcp] I-D Action: draft-ietf-mptcp-multiaddressed-06.txt Thread-Index: AczwmG61PvlKjJRx4kmBqNHlbYCp1w== In-Reply-To: <4F42560E.7000509@uclouvain.be> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 21 Feb 2012 12:57:58.0999 (UTC) FILETIME=[6FE6BE70:01CCF098] Subject: Re: [multipathtcp] I-D Action: draft-ietf-mptcp-multiaddressed-06.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Feb 2012 12:58:06 -0000 Hi Christoph, Thank you for your feedback. Comments inline... On 20/02/2012 14:17, "Christoph Paasch" wrote: > Hello, > > sorry for writing this so late (8 days left until the end of the LC), > but I only now had the time to do a full read of the draft. > > I have several comments concerning the draft as you can see below. > > > ============ > * Retransmission of the third ACK, to ensure reliable delivery of the > keys in MP_CAPABLE (page 14): > > The retransmission of the third ack was introduced to allow lost third > acks, if the server is operating stateless. However, this introduced an > additional RTT before the client is able to send data and thus, we now > allow the client to send data before he receives the acknowledgment of > his third ack (in PRE_ESTABLISHED state). > > I now realize, that the retransmission does not buy us a lot: > > E.g., if the third ACK gets lost, but the client already starts to send > data and this data reaches the stateless server. > The server then can only send a subflow-ack without DATA_ACK and thus > behave as in regular TCP. > The client then should interpret this subflow-ack not as the one > acknowledging the third ack (the one with the MP_CAPABLE), but rather > fallback to regular TCP. Because, otherwise the client and server are no > more in-sync. > > Thus, the retransmission only buys us something if the server is > behaving stateless, the third ack got lost and the server is the one > trying to send data first. This same problem is already present for > stateless servers operating with regular TCP. > > I'm not sure that this current behavior of sending data in > PRE_ESTABLISHED state is safe (e.g., how to behave if the third ack and > the first data-packet got lost, but the second data-packet reaches the > server? - the server sends a duplicate subflow-ack without > MPTCP-options. How will the client interpret this subflow-ack?). > > I think we should remove the retransmission of the third ack, as it does > not buy us a lot, and keep with the simpler and more straight-forward > mechanism of not caring about lost third-acks (as in draft v02). It is true that if we removed the retransmission of the third ACK was added for this corner case. But this is a well-known flaw in stateless operation and SYN cookies, and our motivation for doing this was to make MPTCP's handling of this better than regular TCP today. I agree, however, that it would make things simpler, and faster in the majority of circumstances, to revert to a simple three-way handshake. Does anybody else have any thoughts? > ============ > * Note about pre-established state for *new* subflows (page 19, second > paragraph): > > It is not clear to me, if we are allowed to send data on new subflows > while we are still in PRE_ESTABLISHED state. Because for the initial > subflow it is allowed. > > If we are allowed to send data on new subflows while in PRE_ESTABLISHED, > it does not really make sense to differentiate between PRE_ESTABLISEHED > and ESTABLISHED for the additional subflows. > > However, on page 21, we say that "If Host B does not receive the > expected MAC, or the MP_JOIN option is missing from the ACK, it MUST > close the subflow with a TCP RST." > Thus, I would say that we are not allowed to send data while in > PRE_ESTABLISHED state for new subflows. So, we should clearly specify > that this behavior is different for MP_JOIN's than for MP_CAPABLE's. Yes, the intention is that there is no data sent in the PRE_ESTABLISHED state on additional subflows. This will be clarified. > ============ > * Duplicate ACK's with an MPTCP-option should not be considered as > signals of congestion (first paragraph of page 13 and page 45, > "Duplicate ACK"): > > I think, we should limit this to duplicate ACK's, containing either > REMOVE_ADDR, ADD_ADDR, MP_PRIO or MP_FAIL. > > Otherwise, we have to make sure that we do not put DATA_ACK in duplicate > ack's (which is not so easy to do from an implementation point-of-view). > Additionally, it should be allowed to put a DATA_ACK in a duplicate ack, > because this DATA_ACK may advance the snd_una (due to data arrived on > another subflow). > And, the faster we get the info back for the new snd_una, the better it > is for MPTCP's performance (e.g., the other subflow may have a high RTT). Fair enough, that can be clarified easily enough, although I would rather say "all MPTCP options except DSS" rather than explicitly list those signals that it applies to. > ============ > * page 25: "If a mapping for that subflow-level sequence space does not > arrive within a receive window of data, that subflow SHOULD be treated > as broken,..." > > This is needed, because we allow to receive a DSS-mapping for a certain > subflow-sequence-space on a packet whose sub-sequence-numbers do not > belong to this space. > > I suggest, that we do not support this due to several reasons: > > 1. why should an implementation decide to send the DSS-mapping on a > packet belonging to a different seq-space than specified in the > DSS-mapping-option. > > 2. if we do it, and we store a full receive-window, we have to use quite > a lot of memory before treating the subflow as broken. > If we would only support DSS-mappings on packets who belong to this > sequence-space, we can drop the data as soon as we receive a subsequence > packet on this subflow with a DSS-mapping that does not cover the > previous sequence-space (e.g., this happens in case of coalescing > middleboxes). And, if we don't receive mappings, we can drop data as > soon as we exceed 64KB, as the DATA_LEN's maximum is at 64KB. One reason for this clause is to cope with the case if a sender needed to send an MPTCP option urgently, but did not want to interrupt the data stream. The sender would then send data before sending its mapping, which would be covered by a mapping on a following packet. I think it is needed. > ============ > * p.27, Section 3.3.3: "Note that when the DATA FIN is not attached to a > TCP segment containing data, the Data Sequence Mapping MUST have Subflow > Sequence Number of 0." > > I don't see, why this is needed (we don't implement this - and > DATA_FIN's are still working very fine). > Couldn't we drop this paragraph for simplicity? This is needed: we must maintain the semantics of the data sequence space. The DATA FIN does not map to subflow level sequence space, so we must set that to zero. > ============ > * p.29, Section 3.3.5: "It should only update its local receive window > values when the largest sequence number allowed increases." > > Why not as in RFC 793, p.72: > "If SND.UNA < SEG.ACK =< SND.NXT, the send window should be updated. If > (SND.WL1 < SEG.SEQ or (SND.WL1 = SEG.SEQ and SND.WL2 =< SEG.ACK)), set > SND.WND <- SEG.WND, set SND.WL1 <- SEG.SEQ, and set SND.WL2 <- SEG.ACK." > > This is in my opinion more correct than the sentence in our draft. Maybe > we could just reference RFC793 in the mptcp-draft. Will need to think about that. > ============ > * p. 41: "If it is known that all unacknowledged data in flight is > contiguous..." > > Does it really need to be contiguous? > > Because, basically when falling back, the sender of the MP_FAIL > (data-receiver) will discard all data he receives after the > DATA-sequence-number which triggered the fallback. Only packets after > the infinite-mapping option will be allowed. Otherwise, we may have a > corrupted byte-stream presented to the application. > Thus, the data-sender (after receiving the MP_FAIL) will just send the > infinite-mapping option on the next packet. Irregardless, if the data > in-flight is contiguous or not. This is only talking about the case with a single subflow in use. In that case, we want to be able to fall back without losing any data. This is to cope with payload-changing middleboxes. In this case, the receiver does NOT discard any data, and just carries on reading as if it was a standard TCP session. But in order to do that, all data must be contiguous. This is a safety clause more than anything else. > ============ > Some minor nits: Thanks, will fix these. Cheers, Alan > > p.8, Section 2: > "...between two hosts communicating hosts like..." > > One "hosts" too much. > > p.10, Section 2.4: > "...number space and a MPTCP option..." -> "...number space and an MPTCP > option..." > > p.10, Section 2.4: > In the figure detailing the content of the DSS-option, DATA_LEN is missing. > > p.26, Section 3.3.2: > "... to the behaviour of the standard TCP cumulative ACK in TCP SACK" > Not the ack in TCP SACK. It's just the usual standard TCP cumulative ACK. > > p. 45: > "Instead an explicit data-level ACK is This separate subflow- and..." > > This sentence got somehow mixed with something else. > > > > Cheers, > > Christoph > > > > On 01/31/2012 06:58 PM, internet-drafts@ietf.org wrote: >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. This draft is a work item of the Multipath TCP Working Group of >> the IETF. >> >> Title : TCP Extensions for Multipath Operation with Multiple >> Addresses >> Author(s) : Alan Ford >> Costin Raiciu >> Mark Handley >> Olivier Bonaventure >> Filename : draft-ietf-mptcp-multiaddressed-06.txt >> Pages : 60 >> Date : 2012-01-31 >> >> TCP/IP communication is currently restricted to a single path per >> connection, yet multiple paths often exist between peers. The >> simultaneous use of these multiple paths for a TCP/IP session would >> improve resource usage within the network, and thus improve user >> experience through higher throughput and improved resilience to >> network failure. >> >> Multipath TCP provides the ability to simultaneously use multiple >> paths between peers. This document presents a set of extensions to >> traditional TCP to support multipath operation. The protocol offers >> the same type of service to applications as TCP (i.e. reliable >> bytestream), and provides the components necessary to establish and >> use multiple TCP flows across potentially disjoint paths. >> >> >> A URL for this Internet-Draft is: >> http://www.ietf.org/internet-drafts/draft-ietf-mptcp-multiaddressed-06.txt >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> This Internet-Draft can be retrieved at: >> ftp://ftp.ietf.org/internet-drafts/draft-ietf-mptcp-multiaddressed-06.txt >> >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp >> > From nishida@sfc.wide.ad.jp Wed Feb 22 02:17:09 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 633E221F878E for ; Wed, 22 Feb 2012 02:17:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -98.661 X-Spam-Level: X-Spam-Status: No, score=-98.661 tagged_above=-999 required=5 tests=[AWL=-0.187, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RELAY_IS_203=0.994, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LfqY1F+4M8WB for ; Wed, 22 Feb 2012 02:17:09 -0800 (PST) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) by ietfa.amsl.com (Postfix) with ESMTP id D564421F8716 for ; Wed, 22 Feb 2012 02:17:08 -0800 (PST) Received: from mail-lpp01m010-f44.google.com (mail-lpp01m010-f44.google.com [209.85.215.44]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 293772780D6 for ; Wed, 22 Feb 2012 19:17:01 +0900 (JST) Received: by lahl5 with SMTP id l5so2547928lah.31 for ; Wed, 22 Feb 2012 02:16:58 -0800 (PST) Received-SPF: pass (google.com: domain of nishida@sfc.wide.ad.jp designates 10.152.128.38 as permitted sender) client-ip=10.152.128.38; Authentication-Results: mr.google.com; spf=pass (google.com: domain of nishida@sfc.wide.ad.jp designates 10.152.128.38 as permitted sender) smtp.mail=nishida@sfc.wide.ad.jp Received: from mr.google.com ([10.152.128.38]) by 10.152.128.38 with SMTP id nl6mr22387041lab.15.1329905818438 (num_hops = 1); Wed, 22 Feb 2012 02:16:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.152.128.38 with SMTP id nl6mr18649776lab.15.1329905818423; Wed, 22 Feb 2012 02:16:58 -0800 (PST) Received: by 10.112.107.39 with HTTP; Wed, 22 Feb 2012 02:16:58 -0800 (PST) Date: Wed, 22 Feb 2012 02:16:58 -0800 Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: text/plain; charset=ISO-8859-1 Subject: [multipathtcp] agenda request for IETF83 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 10:17:09 -0000 Hello folks, We're requesting 1.5 or 2 hours meeting slots at Paris meeting. If you want to present something, please provide us the following info. 1: presenter's name 2: title 3: length of the presentation Thanks, -- Yoshifumi and Phil From christoph.paasch@uclouvain.be Wed Feb 22 07:01:53 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30A0621F87DC for ; Wed, 22 Feb 2012 07:01:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.449 X-Spam-Level: X-Spam-Status: No, score=-6.449 tagged_above=-999 required=5 tests=[AWL=0.150, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Bz0ZDQuO7-NQ for ; Wed, 22 Feb 2012 07:01:48 -0800 (PST) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 2F3C221F87CA for ; Wed, 22 Feb 2012 07:01:48 -0800 (PST) Received: from [IPv6:2001:6a8:3080:2:6ab5:99ff:feea:c2fa] (haproxy2.sipr.ucl.ac.be [130.104.5.120]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cpaasch@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id EF84911E9E9; Wed, 22 Feb 2012 16:01:31 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be EF84911E9E9 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1329922891; bh=86bqzidC/jIMnMmUCYmPK06RuhdK71a92epSvyiuZi0=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=otijPstoKsZ4YIFhkFgYch5/xkMVMove9ChrEkghWkB09EjpIgU2W4ghz4mXxu8jD 4YAuKkJF7CKEPtGGzoK4i4HJWxWlTlVALp1grl55iWRIYszp90JWuI9kgirnfurCtQ AosQh4WgFnLxl+mFohzXQN8FIWjPnCL+eJroooH8= Message-ID: <4F45034B.4030908@uclouvain.be> Date: Wed, 22 Feb 2012 16:01:31 +0100 From: Christoph Paasch Organization: =?ISO-8859-1?Q?Universit=E9_Catholique_de_Louvain?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Alan Ford References: In-Reply-To: X-TagToolbar-Keys: D20120222160131839 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97-exp at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: EF84911E9E9.A42F0 X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Cc: MultiPath TCP - IETF WG Subject: Re: [multipathtcp] I-D Action: draft-ietf-mptcp-multiaddressed-06.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: christoph.paasch@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Feb 2012 15:01:53 -0000 Hi Alan, thanks for your reply. Some comments inline: On 02/21/2012 01:57 PM, Alan Ford wrote: > On 20/02/2012 14:17, "Christoph Paasch" > wrote: >> ============ >> * Retransmission of the third ACK, to ensure reliable delivery of the >> keys in MP_CAPABLE (page 14): >> >> The retransmission of the third ack was introduced to allow lost third >> acks, if the server is operating stateless. However, this introduced an >> additional RTT before the client is able to send data and thus, we now >> allow the client to send data before he receives the acknowledgment of >> his third ack (in PRE_ESTABLISHED state). >> >> I now realize, that the retransmission does not buy us a lot: >> >> E.g., if the third ACK gets lost, but the client already starts to send >> data and this data reaches the stateless server. >> The server then can only send a subflow-ack without DATA_ACK and thus >> behave as in regular TCP. >> The client then should interpret this subflow-ack not as the one >> acknowledging the third ack (the one with the MP_CAPABLE), but rather >> fallback to regular TCP. Because, otherwise the client and server are no >> more in-sync. >> >> Thus, the retransmission only buys us something if the server is >> behaving stateless, the third ack got lost and the server is the one >> trying to send data first. This same problem is already present for >> stateless servers operating with regular TCP. >> >> I'm not sure that this current behavior of sending data in >> PRE_ESTABLISHED state is safe (e.g., how to behave if the third ack and >> the first data-packet got lost, but the second data-packet reaches the >> server? - the server sends a duplicate subflow-ack without >> MPTCP-options. How will the client interpret this subflow-ack?). >> >> I think we should remove the retransmission of the third ack, as it does >> not buy us a lot, and keep with the simpler and more straight-forward >> mechanism of not caring about lost third-acks (as in draft v02). > > It is true that if we removed the retransmission of the third ACK was added > for this corner case. But this is a well-known flaw in stateless operation > and SYN cookies, and our motivation for doing this was to make MPTCP's > handling of this better than regular TCP today. > > I agree, however, that it would make things simpler, and faster in the > majority of circumstances, to revert to a simple three-way handshake. > > Does anybody else have any thoughts? I realize one more thing, "conflicting" with the fact that no new subflows may be established while in PRE_ESTABLISHED, as described in section 3.1. Because, in section 3.6, we say that no new subflows are allowed as long as we did not receive a DATA_ACK. And, we will always enter PRE_ESTABLISHED before (or at the same time) receiving the first DATA_ACK. Thus, section 3.1 does not need to specify this, or may forward-reference to section 3.6. >> ============ >> * Duplicate ACK's with an MPTCP-option should not be considered as >> signals of congestion (first paragraph of page 13 and page 45, >> "Duplicate ACK"): >> >> I think, we should limit this to duplicate ACK's, containing either >> REMOVE_ADDR, ADD_ADDR, MP_PRIO or MP_FAIL. >> >> Otherwise, we have to make sure that we do not put DATA_ACK in duplicate >> ack's (which is not so easy to do from an implementation point-of-view). >> Additionally, it should be allowed to put a DATA_ACK in a duplicate ack, >> because this DATA_ACK may advance the snd_una (due to data arrived on >> another subflow). >> And, the faster we get the info back for the new snd_una, the better it >> is for MPTCP's performance (e.g., the other subflow may have a high RTT). > > Fair enough, that can be clarified easily enough, although I would rather > say "all MPTCP options except DSS" rather than explicitly list those signals > that it applies to. "all MPTCP options except DSS" is fine for me. >> ============ >> * page 25: "If a mapping for that subflow-level sequence space does not >> arrive within a receive window of data, that subflow SHOULD be treated >> as broken,..." >> >> This is needed, because we allow to receive a DSS-mapping for a certain >> subflow-sequence-space on a packet whose sub-sequence-numbers do not >> belong to this space. >> >> I suggest, that we do not support this due to several reasons: >> >> 1. why should an implementation decide to send the DSS-mapping on a >> packet belonging to a different seq-space than specified in the >> DSS-mapping-option. >> >> 2. if we do it, and we store a full receive-window, we have to use quite >> a lot of memory before treating the subflow as broken. >> If we would only support DSS-mappings on packets who belong to this >> sequence-space, we can drop the data as soon as we receive a subsequence >> packet on this subflow with a DSS-mapping that does not cover the >> previous sequence-space (e.g., this happens in case of coalescing >> middleboxes). And, if we don't receive mappings, we can drop data as >> soon as we exceed 64KB, as the DATA_LEN's maximum is at 64KB. > > One reason for this clause is to cope with the case if a sender needed to > send an MPTCP option urgently, but did not want to interrupt the data > stream. The sender would then send data before sending its mapping, which > would be covered by a mapping on a following packet. When would the sender want to send an MPTCP option urgently? E.g., for ADD_ADDR the draft says "... Therefore, it is expected that an MPTCP implementation will send the ADD_ADDR option on separate ACKs..." I don't think that sending a duplicate ACK, holding the ADD_ADDR will "interrupt" the data-stream. And, are ADD_ADDR's (or REMOVE_ADDR's) so urgent? The DSS-mapping has to be transmitted reliably, because otherwise we will have plenty of segments without mapping lingering around in the subflow-level receive-queues, and "consuming" space in the receive-window. Thus, we have to put the DSS-mapping on a data-packet. If the DSS-mapping-option does not map with the packet's subflow seq-space, we will be consuming the "slot" of this packet's DSS-mapping, which in turn again needs to be sent on the next data-packet. So, all DSS-mappings will be "switched" by one packet. Additionally, an attacker who manages to inject traffic on one subflow (he correctly guesses the 32-bit subflow-sequence-numbers - but is not able to do so for the 64-bit data-sequence-numbers) can fill up the whole receive-window with dummy-packets that do not contain DSS-mappings. Thus, he will considerably slow down the connection. > I think it is needed. Shouldn't we see if there is a real need for the "urgent MPTCP option" you mentioned earlier, and if it's worth going down the pain to support this ? I believe the protocol will be more straight-forward and potentially less memory-hungry if we don't support it. >> ============ >> * p.27, Section 3.3.3: "Note that when the DATA FIN is not attached to a >> TCP segment containing data, the Data Sequence Mapping MUST have Subflow >> Sequence Number of 0." >> >> I don't see, why this is needed (we don't implement this - and >> DATA_FIN's are still working very fine). >> Couldn't we drop this paragraph for simplicity? > > This is needed: we must maintain the semantics of the data sequence space. > The DATA FIN does not map to subflow level sequence space, so we must set > that to zero. Ok, fair enough. >> ============ >> * p. 41: "If it is known that all unacknowledged data in flight is >> contiguous..." >> >> Does it really need to be contiguous? >> >> Because, basically when falling back, the sender of the MP_FAIL >> (data-receiver) will discard all data he receives after the >> DATA-sequence-number which triggered the fallback. Only packets after >> the infinite-mapping option will be allowed. Otherwise, we may have a >> corrupted byte-stream presented to the application. >> Thus, the data-sender (after receiving the MP_FAIL) will just send the >> infinite-mapping option on the next packet. Irregardless, if the data >> in-flight is contiguous or not. > > This is only talking about the case with a single subflow in use. In that > case, we want to be able to fall back without losing any data. This is to > cope with payload-changing middleboxes. In this case, the receiver does NOT > discard any data, and just carries on reading as if it was a standard TCP > session. But in order to do that, all data must be contiguous. This is a > safety clause more than anything else. I understand now, that the note of "contiguous" data in flight relates to the data-level, and not to the subflow-level (I interpreted it to belong to the subflow-level). However, there is one more issue in this part of the draft: It says, "(if the data is not contiguous, the sender MUST send an RST)". However, sending a RST and establishing a new (regular) TCP session, continuing the flow from the corrupted data-seq number on, does not help. The receiver has to discard all data in the out-of-order queue to avoid the following problem: Suppose, we have two subflows, and the payload-modifying middlebox will add one byte to the segments with data-seq-number 1-10. 1-10 has been sent on subflow 1, and segment 11-20 has been sent on subflow 2. Segment 11-20 are acked at the subflow-level and will be stored in the data-level out-of-order queue because we don't yet have 1-10. Due to the DSS-csum error on subflow 1, this one will get closed and segment 1-10 will be reinjected on subflow 2. Now, we only have one single subflow (2), and 1-10 will be sent on this one, and the middlebox will again add one byte to this segment, resulting in a DSS-csum failure and fallback to regular TCP. 1-10 will be sent again on subflow 2 and the middlebox adds the byte, thus this segment becomes 1-11. Now, we have a 1-byte overlap in the receive-queue with packets 1-11 and (previously in the out-of-order queue) segment 11-20 and the byte-stream has thus been corrupted. The sender will retransmit segment 11-20 (at the reception 12-21 due to the middlebox), but when this segment reaches the receiver, the application may already have read the previous segments. Thus, this is the reason why the receiver has to discard all out-of-order data when announcing the fallback with MP_FAIL. Additionally, it is not necessary that the sender sends a RST if the data is not contiguous. It works by doing the direct fallback with the infinite-mapping option. Cheers, Christoph -- Christoph Paasch PhD Student IP Networking Lab --- http://inl.info.ucl.ac.be MultiPath TCP in the Linux Kernel --- http://mptcp.info.ucl.ac.be Université Catholique de Louvain -- From alanford@cisco.com Thu Feb 23 04:30:07 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A340621F86B2 for ; Thu, 23 Feb 2012 04:30:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.415 X-Spam-Level: X-Spam-Status: No, score=-9.415 tagged_above=-999 required=5 tests=[AWL=1.184, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gk-m1Dh8noUZ for ; Thu, 23 Feb 2012 04:30:06 -0800 (PST) Received: from ams-iport-1.cisco.com (ams-iport-1.cisco.com [144.254.224.140]) by ietfa.amsl.com (Postfix) with ESMTP id 70DD821F869C for ; Thu, 23 Feb 2012 04:30:05 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=alanford@cisco.com; l=11924; q=dns/txt; s=iport; t=1330000205; x=1331209805; h=date:subject:from:to:cc:message-id:in-reply-to: mime-version:content-transfer-encoding; bh=dIbGr8GnZANrOHChKYrRP/wXF5BZm0u3BiXlKdNMgcU=; b=XY/jdXGdaG4rhXDxAWbvTI21XM7a3Ud/zMHeYjHCANEpf3ZVJ4RZPaD6 AQ6Ff7z+RlX288aacA/AH7aJJ0/2xUb7nrg84lz3dF7fLnY331libha0u lLneWh7Pq8BuN9eWCSTOhJpM/9HN8OOrxqQJF6PPaMlNYGIvs5OxSoWSI 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AngJAHIwRk+Q/khM/2dsb2JhbAA/BbFYgQWBB4FzAQEBAwESAScCASoSBQ0BCBiBBQEBBA4FIodfoAcBlxaJYxA1gk0PAgQCCQQJAgYHAQI2EQEJhhmDMASVOJJtgVMBBAIB X-IronPort-AV: E=Sophos;i="4.73,470,1325462400"; d="scan'208";a="130353850" Received: from ams-core-3.cisco.com ([144.254.72.76]) by ams-iport-1.cisco.com with ESMTP; 23 Feb 2012 12:30:03 +0000 Received: from xbh-ams-201.cisco.com (xbh-ams-201.cisco.com [144.254.75.7]) by ams-core-3.cisco.com (8.14.3/8.14.3) with ESMTP id q1NCU3nn014873; Thu, 23 Feb 2012 12:30:03 GMT Received: from xmb-ams-203.cisco.com ([144.254.75.14]) by xbh-ams-201.cisco.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 23 Feb 2012 13:30:03 +0100 Received: from 10.55.89.183 ([10.55.89.183]) by XMB-AMS-203.cisco.com ([144.254.75.14]) with Microsoft Exchange Server HTTP-DAV ; Thu, 23 Feb 2012 12:30:03 +0000 User-Agent: Microsoft-Entourage/12.32.0.111121 Date: Thu, 23 Feb 2012 12:30:00 +0000 From: Alan Ford To: Message-ID: Thread-Topic: [multipathtcp] I-D Action: draft-ietf-mptcp-multiaddressed-06.txt Thread-Index: AczyJtv3JLAapq7s/EC2yglvf6YtMA== In-Reply-To: <4F45034B.4030908@uclouvain.be> Mime-version: 1.0 Content-type: text/plain; charset="US-ASCII" Content-transfer-encoding: 7bit X-OriginalArrivalTime: 23 Feb 2012 12:30:03.0644 (UTC) FILETIME=[DE235BC0:01CCF226] Cc: MultiPath TCP - IETF WG Subject: Re: [multipathtcp] I-D Action: draft-ietf-mptcp-multiaddressed-06.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 12:30:07 -0000 Hi Christoph, all, Responses inline... On 22/02/2012 15:01, "Christoph Paasch" wrote: > On 02/21/2012 01:57 PM, Alan Ford wrote: >> On 20/02/2012 14:17, "Christoph Paasch" >> wrote: >>> ============ >>> * Retransmission of the third ACK, to ensure reliable delivery of the >>> keys in MP_CAPABLE (page 14): >>> >>> The retransmission of the third ack was introduced to allow lost third >>> acks, if the server is operating stateless. However, this introduced an >>> additional RTT before the client is able to send data and thus, we now >>> allow the client to send data before he receives the acknowledgment of >>> his third ack (in PRE_ESTABLISHED state). >>> >>> I now realize, that the retransmission does not buy us a lot: >>> >>> E.g., if the third ACK gets lost, but the client already starts to send >>> data and this data reaches the stateless server. >>> The server then can only send a subflow-ack without DATA_ACK and thus >>> behave as in regular TCP. >>> The client then should interpret this subflow-ack not as the one >>> acknowledging the third ack (the one with the MP_CAPABLE), but rather >>> fallback to regular TCP. Because, otherwise the client and server are no >>> more in-sync. >>> >>> Thus, the retransmission only buys us something if the server is >>> behaving stateless, the third ack got lost and the server is the one >>> trying to send data first. This same problem is already present for >>> stateless servers operating with regular TCP. >>> >>> I'm not sure that this current behavior of sending data in >>> PRE_ESTABLISHED state is safe (e.g., how to behave if the third ack and >>> the first data-packet got lost, but the second data-packet reaches the >>> server? - the server sends a duplicate subflow-ack without >>> MPTCP-options. How will the client interpret this subflow-ack?). >>> >>> I think we should remove the retransmission of the third ack, as it does >>> not buy us a lot, and keep with the simpler and more straight-forward >>> mechanism of not caring about lost third-acks (as in draft v02). >> >> It is true that if we removed the retransmission of the third ACK was added >> for this corner case. But this is a well-known flaw in stateless operation >> and SYN cookies, and our motivation for doing this was to make MPTCP's >> handling of this better than regular TCP today. >> >> I agree, however, that it would make things simpler, and faster in the >> majority of circumstances, to revert to a simple three-way handshake. >> >> Does anybody else have any thoughts? > > I realize one more thing, "conflicting" with the fact that no new > subflows may be established while in PRE_ESTABLISHED, as described in > section 3.1. Because, in section 3.6, we say that no new subflows are > allowed as long as we did not receive a DATA_ACK. And, we will always > enter PRE_ESTABLISHED before (or at the same time) receiving the first > DATA_ACK. > > Thus, section 3.1 does not need to specify this, or may > forward-reference to section 3.6. Thanks, we'll change that - that simplifies things. >>> ============ >>> * Duplicate ACK's with an MPTCP-option should not be considered as >>> signals of congestion (first paragraph of page 13 and page 45, >>> "Duplicate ACK"): >>> >>> I think, we should limit this to duplicate ACK's, containing either >>> REMOVE_ADDR, ADD_ADDR, MP_PRIO or MP_FAIL. >>> >>> Otherwise, we have to make sure that we do not put DATA_ACK in duplicate >>> ack's (which is not so easy to do from an implementation point-of-view). >>> Additionally, it should be allowed to put a DATA_ACK in a duplicate ack, >>> because this DATA_ACK may advance the snd_una (due to data arrived on >>> another subflow). >>> And, the faster we get the info back for the new snd_una, the better it >>> is for MPTCP's performance (e.g., the other subflow may have a high RTT). >> >> Fair enough, that can be clarified easily enough, although I would rather >> say "all MPTCP options except DSS" rather than explicitly list those signals >> that it applies to. > > "all MPTCP options except DSS" is fine for me. > >>> ============ >>> * page 25: "If a mapping for that subflow-level sequence space does not >>> arrive within a receive window of data, that subflow SHOULD be treated >>> as broken,..." >>> >>> This is needed, because we allow to receive a DSS-mapping for a certain >>> subflow-sequence-space on a packet whose sub-sequence-numbers do not >>> belong to this space. >>> >>> I suggest, that we do not support this due to several reasons: >>> >>> 1. why should an implementation decide to send the DSS-mapping on a >>> packet belonging to a different seq-space than specified in the >>> DSS-mapping-option. >>> >>> 2. if we do it, and we store a full receive-window, we have to use quite >>> a lot of memory before treating the subflow as broken. >>> If we would only support DSS-mappings on packets who belong to this >>> sequence-space, we can drop the data as soon as we receive a subsequence >>> packet on this subflow with a DSS-mapping that does not cover the >>> previous sequence-space (e.g., this happens in case of coalescing >>> middleboxes). And, if we don't receive mappings, we can drop data as >>> soon as we exceed 64KB, as the DATA_LEN's maximum is at 64KB. >> >> One reason for this clause is to cope with the case if a sender needed to >> send an MPTCP option urgently, but did not want to interrupt the data >> stream. The sender would then send data before sending its mapping, which >> would be covered by a mapping on a following packet. > > When would the sender want to send an MPTCP option urgently? E.g., for > ADD_ADDR the draft says "... Therefore, it is expected that an MPTCP > implementation will send the ADD_ADDR option on separate ACKs..." > > I don't think that sending a duplicate ACK, holding the ADD_ADDR will > "interrupt" the data-stream. And, are ADD_ADDR's (or REMOVE_ADDR's) so > urgent? I accept the scenarios where this could be deliberately used are low. There is one scenario where this is currently expressly forbidden but could be useful: for the very first packet of a connection. On the third ACK of the initial subflow, we could send data and it will be covered by a DSS mapping on a following packet. (We could make this a special case, however). I cannot remember if we thought of any other reasons for this clause... > The DSS-mapping has to be transmitted reliably, because otherwise we > will have plenty of segments without mapping lingering around in the > subflow-level receive-queues, and "consuming" space in the receive-window. > Thus, we have to put the DSS-mapping on a data-packet. If the > DSS-mapping-option does not map with the packet's subflow seq-space, we > will be consuming the "slot" of this packet's DSS-mapping, which in turn > again needs to be sent on the next data-packet. So, all DSS-mappings > will be "switched" by one packet. > > Additionally, an attacker who manages to inject traffic on one subflow > (he correctly guesses the 32-bit subflow-sequence-numbers - but is not > able to do so for the 64-bit data-sequence-numbers) can fill up the > whole receive-window with dummy-packets that do not contain > DSS-mappings. Thus, he will considerably slow down the connection. > >> I think it is needed. > > Shouldn't we see if there is a real need for the "urgent MPTCP option" > you mentioned earlier, and if it's worth going down the pain to support > this ? > > I believe the protocol will be more straight-forward and potentially > less memory-hungry if we don't support it. > >>> ============ >>> * p.27, Section 3.3.3: "Note that when the DATA FIN is not attached to a >>> TCP segment containing data, the Data Sequence Mapping MUST have Subflow >>> Sequence Number of 0." >>> >>> I don't see, why this is needed (we don't implement this - and >>> DATA_FIN's are still working very fine). >>> Couldn't we drop this paragraph for simplicity? >> >> This is needed: we must maintain the semantics of the data sequence space. >> The DATA FIN does not map to subflow level sequence space, so we must set >> that to zero. > > Ok, fair enough. > >>> ============ >>> * p. 41: "If it is known that all unacknowledged data in flight is >>> contiguous..." >>> >>> Does it really need to be contiguous? >>> >>> Because, basically when falling back, the sender of the MP_FAIL >>> (data-receiver) will discard all data he receives after the >>> DATA-sequence-number which triggered the fallback. Only packets after >>> the infinite-mapping option will be allowed. Otherwise, we may have a >>> corrupted byte-stream presented to the application. >>> Thus, the data-sender (after receiving the MP_FAIL) will just send the >>> infinite-mapping option on the next packet. Irregardless, if the data >>> in-flight is contiguous or not. >> >> This is only talking about the case with a single subflow in use. In that >> case, we want to be able to fall back without losing any data. This is to >> cope with payload-changing middleboxes. In this case, the receiver does NOT >> discard any data, and just carries on reading as if it was a standard TCP >> session. But in order to do that, all data must be contiguous. This is a >> safety clause more than anything else. > > I understand now, that the note of "contiguous" data in flight relates > to the data-level, and not to the subflow-level (I interpreted it to > belong to the subflow-level). > > However, there is one more issue in this part of the draft: > It says, "(if the data is not contiguous, the sender MUST send an RST)". > However, sending a RST and establishing a new > (regular) TCP session, continuing the flow from the corrupted data-seq > number on, does not help. The receiver has to discard all data in the > out-of-order queue to avoid the following problem: > > > Suppose, we have two subflows, and the payload-modifying middlebox will > add one byte to the segments with data-seq-number 1-10. 1-10 has been > sent on subflow 1, and segment 11-20 has been sent on subflow 2. > Segment 11-20 are acked at the subflow-level and will be stored in the > data-level out-of-order queue because we don't yet have 1-10. > > Due to the DSS-csum error on subflow 1, this one will get closed and > segment 1-10 will be reinjected on subflow 2. > > Now, we only have one single subflow (2), and 1-10 will be sent on this > one, and the middlebox will again add one byte to this segment, > resulting in a DSS-csum failure and fallback to regular TCP. > > 1-10 will be sent again on subflow 2 and the middlebox adds the > byte, thus this segment becomes 1-11. > > Now, we have a 1-byte overlap in the receive-queue with packets 1-11 and > (previously in the out-of-order queue) segment 11-20 and the byte-stream > has thus been corrupted. > > The sender will retransmit segment 11-20 (at the reception 12-21 due to > the middlebox), but when this segment reaches the receiver, the > application may already have read the previous segments. > > Thus, this is the reason why the receiver has to discard all > out-of-order data when announcing the fallback with MP_FAIL. > Additionally, it is not necessary that the sender sends a RST if the > data is not contiguous. It works by doing the direct fallback with the > infinite-mapping option. Yes, you have a valid case there (if the same payload-altering middlebox is operating on both subflows). I think our intention has always been for all data to be discarded resent from the data-level sequence number specified in MP_FAIL; however, this may not be explicitly clear in the text. We shall improve this. Regards, Alan From philip.eardley@bt.com Thu Feb 23 06:35:02 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9D8F021F87BD for ; Thu, 23 Feb 2012 06:35:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.295 X-Spam-Level: X-Spam-Status: No, score=-103.295 tagged_above=-999 required=5 tests=[AWL=0.303, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B0owVRktCtju for ; Thu, 23 Feb 2012 06:35:00 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 3CA1B21F87D3 for ; Thu, 23 Feb 2012 06:35:00 -0800 (PST) Received: from EVMHT68-UKRD.domain1.systemhost.net (10.36.3.105) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 23 Feb 2012 14:34:59 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.72]) by EVMHT68-UKRD.domain1.systemhost.net ([10.36.3.105]) with mapi; Thu, 23 Feb 2012 14:34:58 +0000 From: To: Date: Thu, 23 Feb 2012 14:34:55 +0000 Thread-Topic: REMINDER: WG Last call for Multipath TCP protocol doc Thread-Index: AczidyZSiFWm/o8+TXmYFaJdcgNenAPwPNdQ Message-ID: <9510D26531EF184D9017DF24659BB87F331BF18813@EMV65-UKRD.domain1.systemhost.net> References: <9510D26531EF184D9017DF24659BB87F3317E442F3@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F3317E442F3@EMV65-UKRD.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_9510D26531EF184D9017DF24659BB87F331BF18813EMV65UKRDdoma_" MIME-Version: 1.0 Subject: [multipathtcp] REMINDER: WG Last call for Multipath TCP protocol doc X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 14:35:02 -0000 --_000_9510D26531EF184D9017DF24659BB87F331BF18813EMV65UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for your comments so far on this. just a reminder that we're now in = the final week for the WGLC From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of philip.eardley@bt.com Sent: 03 February 2012 13:24 To: multipathtcp@ietf.org Subject: [multipathtcp] WG Last call for Multipath TCP protocol doc This is to announce the WG last call for "TCP Extensions for Multipath Oper= ation with Multiple Addresses" http://tools.ietf.org/html/draft-ietf-mptcp= -multiaddressed-06 Since this is a reasonably substantial doc and we are WG last calling the A= PI doc as well, we will run until the end of Feb (Wed 29th). Please send comments to the list The purpose of a WGLC is to provide a final check that the WG has rough con= sensus to advance the document: - The WG believes that this document is technically sound - The WG believes that this document is useful - The WG believes that this document is ready to go to the IESG Please reply with positive support, as well as any comments /questions Thanks Phil & Yoshifumi -- Abstract TCP/IP communication is currently restricted to a single path per connection, yet multiple paths often exist between peers. The simultaneous use of these multiple paths for a TCP/IP session would improve resource usage within the network, and thus improve user experience through higher throughput and improved resilience to network failure. Multipath TCP provides the ability to simultaneously use multiple paths between peers. This document presents a set of extensions to traditional TCP to support multipath operation. The protocol offers the same type of service to applications as TCP (i.e. reliable bytestream), and provides the components necessary to establish and use multiple TCP flows across potentially disjoint paths. --_000_9510D26531EF184D9017DF24659BB87F331BF18813EMV65UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for your comments so far on this. just a reminder that we’= ;re now in the final week for the WGLC

 

From: multipathtcp-b= ounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] On Behalf Of = philip.eardley@bt.com
Sent: 03 February 2012 13:24
To: = multipathtcp@ietf.org
Subject: [multipathtcp] WG Last call for Mu= ltipath TCP protocol doc

 

This is to announce the WG la= st call for “TCP Extensions for Multipath Operation with Multiple Add= resses“  http://tools.ietf.org/html/draft-ietf-mptcp-multiaddress= ed-06

 

Since this is a reasonably substantial doc and we are WG last = calling the API doc as well, we will run until the end of Feb (Wed 29t= h).

Please send comments to the l= ist

 

The purpose of a WGLC is to provide a final check that the WG has ro= ugh consensus to advance the document:

-= The WG believes that this document is technically sound

- The WG believes that this document is useful<= /p>

- The WG believes that this document is ready to go= to the IESG

 

Please reply with positive support, as well as any comments= /questions

 

Thanks

Phil & Yoshifum= i

 

-- 
Abstract
 
&nbs=
p;  TCP/IP communication is currently restricted to a single path per<=
o:p>
   connection, yet multiple paths often exis=
t between peers.  The
   simultaneous u=
se of these multiple paths for a TCP/IP session would
=
   improve resource usage within the network, and thus improve us=
er
   experience through higher throughput a=
nd improved resilience to
   network failure=
.
 
   Multipath T=
CP provides the ability to simultaneously use multiple
   paths between peers.  This document presents a set of ex= tensions to
   traditional TCP to support mu=
ltipath operation.  The protocol offers
 &nb=
sp; the same type of service to applications as TCP (i.e. reliable
   bytestream), and provides the components necessar=
y to establish and
   use multiple TCP flows=
 across potentially disjoint paths.

 

= --_000_9510D26531EF184D9017DF24659BB87F331BF18813EMV65UKRDdoma_-- From philip.eardley@bt.com Thu Feb 23 06:36:45 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 592F121F878E for ; Thu, 23 Feb 2012 06:36:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.319 X-Spam-Level: X-Spam-Status: No, score=-103.319 tagged_above=-999 required=5 tests=[AWL=0.279, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M5kkuGAROyKO for ; Thu, 23 Feb 2012 06:36:43 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 4874521F880B for ; Thu, 23 Feb 2012 06:36:43 -0800 (PST) Received: from EVMHT62-UKRD.domain1.systemhost.net (10.36.3.128) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.213.0; Thu, 23 Feb 2012 14:36:42 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.72]) by EVMHT62-UKRD.domain1.systemhost.net ([10.36.3.128]) with mapi; Thu, 23 Feb 2012 14:36:42 +0000 From: To: Date: Thu, 23 Feb 2012 14:36:40 +0000 Thread-Topic: REMINDER: WG Last call for Multipath TCP API doc Thread-Index: AczidyZSiFWm/o8+TXmYFaJdcgNenAAAAyjwA/BIS7A= Message-ID: <9510D26531EF184D9017DF24659BB87F331BF18819@EMV65-UKRD.domain1.systemhost.net> References: <9510D26531EF184D9017DF24659BB87F3317E442F8@EMV65-UKRD.domain1.systemhost.net> In-Reply-To: <9510D26531EF184D9017DF24659BB87F3317E442F8@EMV65-UKRD.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_9510D26531EF184D9017DF24659BB87F331BF18819EMV65UKRDdoma_" MIME-Version: 1.0 Subject: [multipathtcp] REMINDER: WG Last call for Multipath TCP API doc X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Feb 2012 14:36:45 -0000 --_000_9510D26531EF184D9017DF24659BB87F331BF18819EMV65UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for your comments so far on this. just a reminder that we're now in = the final week for the WGLC The comments so far have already been addressed in a slightly revised v-04 = on 16th Feb, http://tools.ietf.org/html/draft-ietf-mptcp-api From: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bounces@ietf.org] = On Behalf Of philip.eardley@bt.com Sent: 03 February 2012 13:27 To: multipathtcp@ietf.org Subject: [multipathtcp] WG Last call for Multipath TCP API doc This is to announce the WG last call for "MPTCP Application Interface Consi= derations" http://tools.ietf.org/html/draft-ietf-mptcp-api-03 Since we are WG last calling the protocol doc as well, we will run until th= e end of Feb (Wed 29th). Please send comments to the list The purpose of a WGLC is to provide a final check that the WG has rough con= sensus to advance the document: - The WG believes that this document is technically sound - The WG believes that this document is useful - The WG believes that this document is ready to go to the IESG Please reply with positive support, as well as any comments /questions Thanks Phil & Yoshifumi -- Abstract Multipath TCP (MPTCP) adds the capability of using multiple paths to a regular TCP session. Even though it is designed to be totally backward compatible to applications, the data transport differs compared to regular TCP, and there are several additional degrees of freedom that applications may wish to exploit. This document summarizes the impact that MPTCP may have on applications, such as changes in performance. Furthermore, it discusses compatibility issues of MPTCP in combination with non-MPTCP-aware applications. Finally, the document describes a basic application interface for MPTCP-aware applications that provides access to multipath address information and a level of control equivalent to regular TCP. --_000_9510D26531EF184D9017DF24659BB87F331BF18819EMV65UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

= Thanks for your comments so far on this. just a reminder that we’re n= ow in the final week for the WGLC

The comments so far have already been addressed in a sli= ghtly revised v-04 on 16th Feb, http://tools.ietf.org/html/draft-ietf-mptcp-api=

 

F= rom: multipathtcp-bounces@ietf.org [mailto:multipathtcp-bou= nces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: 03= February 2012 13:27
To: multipathtcp@ietf.org
Subject:= [multipathtcp] WG Last call for Multipath TCP API doc

 

This is to announce the WG last call for “MPTCP Application Interface Considerations” http://tools.ietf.org/html/draft-= ietf-mptcp-api-03

 

Since = we are WG last calling the protocol do= c as well, we will run until the end of Feb (Wed 29th).

Please send comments to the list

 

The purpose= of a WGLC is to provide a final check that the WG has rough consensus to a= dvance the document:

- The WG believes t= hat this document is technically sound

-= The WG believes that this document is useful

- The WG believes that this document is ready to go to the IESG =

 

Pl= ease reply with positive support, as well as any comments /questions

 

Than= ks

Phil & Yoshifumi

 

-- 
Abstr=
act
 

   Multipath= TCP (MPTCP) adds the capability of using multiple paths to

   a regular TCP session.  Even though it is desi= gned to be totally

   backward compatib= le to applications, the data transport differs

&n= bsp;  compared to regular TCP, and there are several additional degree= s of

   freedom that applications may w= ish to exploit.  This document

   = summarizes the impact that MPTCP may have on applications, such as

   changes in performance.  Furthermore, i= t discusses compatibility

   issues of = MPTCP in combination with non-MPTCP-aware applications.

   Finally, the document describes a basic application int= erface for

   MPTCP-aware applications = that provides access to multipath address

 &= nbsp; information and a level of control equivalent to regular TCP.

 

 
=
= --_000_9510D26531EF184D9017DF24659BB87F331BF18819EMV65UKRDdoma_-- From philip.eardley@bt.com Fri Feb 24 00:44:04 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E846121F87BA for ; Fri, 24 Feb 2012 00:44:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.338 X-Spam-Level: X-Spam-Status: No, score=-103.338 tagged_above=-999 required=5 tests=[AWL=0.259, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 542VWZAkXvAY for ; Fri, 24 Feb 2012 00:44:01 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id BB54421F87B8 for ; Fri, 24 Feb 2012 00:44:00 -0800 (PST) Received: from EVMHT65-UKRD.domain1.systemhost.net (10.36.3.102) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 24 Feb 2012 08:43:50 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.72]) by EVMHT65-UKRD.domain1.systemhost.net ([10.36.3.102]) with mapi; Fri, 24 Feb 2012 08:43:50 +0000 From: To: Date: Fri, 24 Feb 2012 08:43:48 +0000 Thread-Topic: TCP option kind assignment for MPTCP Thread-Index: Aczy0G1sBhnqjkWiTSWY7dCshgkHfA== Message-ID: <9510D26531EF184D9017DF24659BB87F331BF18C6D@EMV65-UKRD.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_9510D26531EF184D9017DF24659BB87F331BF18C6DEMV65UKRDdoma_" MIME-Version: 1.0 Subject: [multipathtcp] TCP option kind assignment for MPTCP X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 08:44:05 -0000 --_000_9510D26531EF184D9017DF24659BB87F331BF18C6DEMV65UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Thanks for all the discussion about this and your help clarifying the issue= s which has been very useful. There seems to be consensus to go for Yoshifumi's option 1, ie ask for a ne= w standards allocation (rather than use the experimental codepoint 253/254)= . Here is a draft email request for IANA and IESG, please correct errors in= troduced and suggest any improvements Thanks! Phil & Yoshifumi --- Dear IESG and IANA, Thank-you for your advice about the steps we need to take to understand wha= t IANA request the MPTCP WG should make for assignment of a TCP Option Kind= Number. We have now discussed this and the WG has reached consensus to req= uest IANA to allocate a new (standards) codepoint. The Multipath TCP WG has been developing the MPTCP protocol. The main parts= of the protocol have been stable for some time and the I-D is currently in= WG last call http://tools.ietf.org/html/draft-ietf-mptcp-multiaddressed As defined by our charter, the protocol is experimental track - although we= hope to re-charter soon and include a standards track bis. The WG has discussed two IANA options: 1) A new standards codepoint 2) Use an experimental codepoint + http://tools.ietf.org/html/draft-ie= tf-tcpm-experimental-options Since the protocol is currently Experimental track, option (2) seems more l= ogical. We now explain why the WG has concluded it is not the right one, es= sentially due to a lack of space in the TCP options field. If option 2) is chosen, there are two cases to consider: A) SYN packets Several of MPTCP's messages are sent on the TCP-SYN handshake, including MP= _JOIN which adds a new sub-flow to an existing MPTCP connection (Section 2.= 2, http://tools.ietf.org/html/draft-ietf-mptcp-multiaddressed-06#page-9 ). = Space is most critical for MP_JOIN on the SYN/ACK (Fig 6) where typically w= e'd expect: * MSS (4 bytes) * window scale (3 bytes), * SACK permitted (2 bytes) * timestamp (10 bytes) * Magic Number for Experimental Option (2 or 4 bytes) * MP_JOIN on SYN/ACK (16 bytes) TOTAL 37-39 bytes. This appears to fit into the max 40 bytes of the TCP option field. However, some operating systems pad each option up to a word boundary (a br= ief survey suggests Windows XP and Mac OS X do this, whereas Linux does not= ), which leads to TOTAL 44 bytes which doesn't fit. Since we do not want MPTCP to be limited to Linux-only, this would imply th= at MP_JOIN must be re-designed, which would have security implications. B) TCP data packets The MPTCP message DATA_SEQUENCE_SIGNAL contains a mapping between the seque= nce numbers of a MPTCP sub-flow and the MPTCP connection (Section 2.4 http:= //tools.ietf.org/html/draft-ietf-mptcp-multiaddressed-06#section-2.4 ). Typ= ically we'd expect: * timestamp (10 bytes) * Magic Number for Experimental Option (2 or 4 bytes) * MPTCP's DATA_SEQUENCE_SIGNAL (max 28 bytes) TOTAL 40-42 bytes, or 44 bytes with word padding. However, the DATA_SEQUENCE_SIGNAL has been designed flexibly and can use le= ss than 28bytes, so we could fit within the 40 byte limit. It contains a Da= ta Sequence Number and Data ACK, both of which can be 0, 4 or 8 bytes in le= ngth; for example, it might be possible to alternate which one is included,= although this may have performance implications. Therefore the critical factor is that using an Experimental codepoint for t= he TCP Option Kind Number will either require re-design of MP_JOIN and (pre= sumably) poorer security, or else will limit MPTCP to operating systems tha= t don't pad each TCP option up to a word boundary. There is also a positive case for choosing Option 1) (A new standards codep= oint):- * MPTCP is being implemented by multiple operating systems. There is a refe= rence implementation in Linux, available at http://mptcp.info.ucl.ac.be/ Th= e plan is to push this upstream starting the end of this year. A Free BSD i= mplementation has been funded recently, it is also being implemented in Sol= aris, and there is work to integrate it on Android. The existing implementa= tion has already had quite a lot of downloads and experimentation. All this= indicates considerable interest in MPTCP. * We intend for MPTCP to get wide use and would like it to be used by defau= lt. * A standards-track bis is likely to come shortly - we want to re-charter t= o do this. Migration should be easier with a standards codepoint, as it sho= uld be easier to avoid interoperability problems between different MPTCP st= acks. * MPTCP is designed to use only one option number whilst being extensible. = It uses a version field in the initial handshake and the protocol uses sub-= option numbers (8 sub-option types are defined for the various MPTCP messag= es) and also has flags to allow other cryptographic handshake algorithms (b= eyond HMAC-SHA1). In summary, an additional option number will not be requi= red. * There is a prior instance of allocation of a TCP Option kind number for a= n Experimental track protocol (Quick-Start). Our preferred allocation is TCP Option Kind #30 as this is what the impleme= ntation uses. Best wishes Philip Eardley & Yoshifumi Nishida, MPTCP WG Chairs --_000_9510D26531EF184D9017DF24659BB87F331BF18C6DEMV65UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Thanks for all t= he discussion about this and your help clarifying the issues which has been= very useful.

 

There seems to be consensus to go for Yoshifumi’s opt= ion 1, ie ask for a new standards allocation (rather than use the experimen= tal codepoint 253/254). Here is a draft email request for IANA and IESG, pl= ease correct errors introduced and suggest any improvements

<= p class=3DMsoNormal>Thanks!

Phil & Y= oshifumi

---

 

Dear IESG and IANA,<= /o:p>

Thank-you for your advice about the steps we = need to take to understand what IANA request the MPTCP WG should make for a= ssignment of a TCP Option Kind Number. We have now discussed this and the W= G has reached consensus to request IANA to allocate a new (standards) codep= oint.

 

The Multipath TCP WG has been developing the MPTCP protocol. The ma= in parts of the protocol have been stable for some time and the I-D is curr= ently in WG last call http://tools.ietf.org/html/draft-ietf-mptcp-multiaddresse= d

As defined by our charter, the pr= otocol is experimental track – although we hope to re-charter soon an= d include a standards track bis.

&n= bsp;

 

The WG has discussed two IANA options:

1)      A new st= andards codepoint

2)  = ;    Use an experimental codepoint += http://tools.ietf.org/html/draft-ietf-tcpm-experimental-options =

 

Si= nce the protocol is currently Experimental track, option (2) seems more log= ical. We now explain why the WG has concluded it is not the right one, esse= ntially due to a lack of space in the TCP options field.

 

If option 2) is = chosen, there are two cases to consider:

A)     SYN packets

Several of MPTCP’s messages are sent= on the TCP-SYN handshake, including MP_JOIN which adds a new sub-flow to a= n existing MPTCP connection (Section 2.2, http://tools.ietf.org/html/= draft-ietf-mptcp-multiaddressed-06#page-9 ). Space is most critical for= MP_JOIN on the SYN/ACK (Fig 6) where typically we’d expect:

* MSS (4 bytes)     &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;           =

* window scale (3 bytes),

* SACK permitted (2 bytes)

= * timestamp (10 bytes)

* Magic Number f= or Experimental Option (2 or 4 bytes)

* = MP_JOIN on SYN/ACK (16 bytes)

TOTAL 37-= 39 bytes.

 

This appears to fit into the max 40 bytes of the TCP option fi= eld.

However, some operating systems pad= each option up to a word boundary (a brief survey suggests Windows XP and = Mac OS X do this, whereas Linux does not), which leads to TOTAL 44 bytes wh= ich doesn’t fit.

 

Since we do not want MPTCP to be limited to Linux= -only, this would imply that MP_JOIN must be re-designed, which would have = security implications.

 =

B)      <= /span>TCP data packets

The MPT= CP message DATA_SEQUENCE_SIGNAL contains a mapping between the sequence num= bers of a MPTCP sub-flow and the MPTCP connection (Section 2.4 h= ttp://tools.ietf.org/html/draft-ietf-mptcp-multiaddressed-06#section-2.4 ). Typically we’d expect:

* time= stamp (10 bytes)

* Magic Number for Exp= erimental Option (2 or 4 bytes)

* MPTCP&= #8217;s DATA_SEQUENCE_SIGNAL (max 28 bytes)

TOTAL 40-42 bytes, or 44 bytes with word padding.

 

However, the DATA_= SEQUENCE_SIGNAL has been designed flexibly and can use less than 28bytes, s= o we could fit within the 40 byte limit. It contains a Data Sequence Number= and Data ACK, both of which can be 0, 4 or 8 bytes in length; for example,= it might be possible to alternate which one is included, although this may= have performance implications.

&nb= sp;

Therefore the critical factor is that usi= ng an Experimental codepoint for the TCP Option Kind Number will either req= uire re-design of MP_JOIN and (presumably) poorer security, or else will li= mit MPTCP to operating systems that don’t pad each TCP option up to a= word boundary.

 

There is also a positive case for choosing Option 1) (A n= ew standards codepoint):-

* MPTCP is bei= ng implemented by multiple operating systems. There is a reference implemen= tation in Linux, available at http= ://mptcp.info.ucl.ac.be/ The plan is to push this upstream starting the= end of this year. A Free BSD implementation has been funded recently, it i= s also being implemented in Solaris, and there is work to integrate it on A= ndroid. The existing implementation has already had quite a lot of download= s and experimentation. All this indicates considerable interest in MPTCP.

* We intend for MPTCP to get wide use and= would like it to be used by default.

*= A standards-track bis is likely to come shortly – we want to re-char= ter to do this. Migration should be easier with a standards codepoint, as i= t should be easier to avoid interoperability problems between different MPT= CP stacks.

* MPTCP is designed to use o= nly one option number whilst being extensible. It uses a version field in t= he initial handshake and the protocol uses sub-option numbers (8 sub-option= types are defined for the various MPTCP messages) and also has flags to al= low other cryptographic handshake algorithms (beyond HMAC-SHA1). In summary= , an additional option number will not be required.

* There is a prior instance of allocation of a TCP Option kind= number for an Experimental track protocol (Quick-Start).

         &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;            =             &nb= sp;

Our preferred allocation is TCP Opt= ion Kind #30 as this is what the implementation uses.

 

Best wishes

Philip Eardley & Yoshifumi Nishida, MPTCP W= G Chairs

 

= --_000_9510D26531EF184D9017DF24659BB87F331BF18C6DEMV65UKRDdoma_-- From philip.eardley@bt.com Fri Feb 24 05:22:05 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C86CA21F8748 for ; Fri, 24 Feb 2012 05:22:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.356 X-Spam-Level: X-Spam-Status: No, score=-103.356 tagged_above=-999 required=5 tests=[AWL=0.242, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iB2g8YKOUrPw for ; Fri, 24 Feb 2012 05:22:05 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp62.intersmtp.com [62.239.224.235]) by ietfa.amsl.com (Postfix) with ESMTP id 067FD21F86EA for ; Fri, 24 Feb 2012 05:22:05 -0800 (PST) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A006ED62.smtp-e2.hygiene.service (10.187.98.11) with Microsoft SMTP Server (TLS) id 8.3.213.0; Fri, 24 Feb 2012 13:22:04 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.72]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Fri, 24 Feb 2012 13:22:03 +0000 From: To: Date: Fri, 24 Feb 2012 13:22:03 +0000 Thread-Topic: MPTCP Paris slot Thread-Index: Aczy90wFSV/NQMfiQpKfrPWl1D88ow== Message-ID: <9510D26531EF184D9017DF24659BB87F331BF19136@EMV65-UKRD.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_9510D26531EF184D9017DF24659BB87F331BF19136EMV65UKRDdoma_" MIME-Version: 1.0 Subject: [multipathtcp] MPTCP Paris slot X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 13:22:06 -0000 --_000_9510D26531EF184D9017DF24659BB87F331BF19136EMV65UKRDdoma_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable When planning your travel to Paris, note that we have the *^%!$ slot of Fri= day 11.20 - 1.30 (with the usual caution that this could change) --_000_9510D26531EF184D9017DF24659BB87F331BF19136EMV65UKRDdoma_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

When planning your travel to P= aris, note that we have the *^%!$ slot of Friday 11.20 – 1.30 (with t= he usual caution that this could change)

 

 

= --_000_9510D26531EF184D9017DF24659BB87F331BF19136EMV65UKRDdoma_-- From christoph.paasch@uclouvain.be Fri Feb 24 06:37:15 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5CA721F87AB for ; Fri, 24 Feb 2012 06:37:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.499 X-Spam-Level: X-Spam-Status: No, score=-6.499 tagged_above=-999 required=5 tests=[AWL=0.100, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2h0Ry7CccvrT for ; Fri, 24 Feb 2012 06:37:14 -0800 (PST) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id E1C4221F87CC for ; Fri, 24 Feb 2012 06:37:13 -0800 (PST) Received: from [130.104.228.43] (cpaasch.dhcp.info.ucl.ac.be [130.104.228.43]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: cpaasch@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id D80261C5CFE; Fri, 24 Feb 2012 15:36:52 +0100 (CET) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be D80261C5CFE DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1330094212; bh=bN3zVb31EW7ocjyZaChO1J+mJFMFetzRZpx5escebwY=; h=Message-ID:Date:From:Reply-To:MIME-Version:To:CC:Subject: References:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=dAgcZ2oFcrnv0s7UocCDxXfaJUdke7kSa8jTWsEx4nq7TMW6n6daspgznqJSFZXSX +vxQVS5zNeNuYnz5yjP/vaGjSwuw4UY1Z3wPOlL8CVLsNwauhYTMunT+ae9CPnlTSJ 8XHFFczxCMp7z5LtPEr56S8e/6icieg+5zIcF74g= Message-ID: <4F47A084.5000009@uclouvain.be> Date: Fri, 24 Feb 2012 15:36:52 +0100 From: Christoph Paasch Organization: =?ISO-8859-1?Q?Universit=E9_Catholique_de_Louvain?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120216 Thunderbird/10.0.2 MIME-Version: 1.0 To: Alan Ford References: In-Reply-To: X-TagToolbar-Keys: D20120224153652688 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Virus-Scanned: clamav-milter 0.97-exp at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: D80261C5CFE.A223D X-SGSI-MailScanner: Found to be clean X-SGSI-From: christoph.paasch@uclouvain.be X-SGSI-Spam-Status: No Cc: MultiPath TCP - IETF WG Subject: Re: [multipathtcp] I-D Action: draft-ietf-mptcp-multiaddressed-06.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list Reply-To: christoph.paasch@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 14:37:16 -0000 Hello Alan, all, On 02/23/2012 01:30 PM, Alan Ford wrote: >>>> ============ >>>> * Retransmission of the third ACK, to ensure reliable delivery of the >>>> keys in MP_CAPABLE (page 14): >>>> >>>> The retransmission of the third ack was introduced to allow lost third >>>> acks, if the server is operating stateless. However, this introduced an >>>> additional RTT before the client is able to send data and thus, we now >>>> allow the client to send data before he receives the acknowledgment of >>>> his third ack (in PRE_ESTABLISHED state). >>>> >>>> I now realize, that the retransmission does not buy us a lot: >>>> >>>> E.g., if the third ACK gets lost, but the client already starts to send >>>> data and this data reaches the stateless server. >>>> The server then can only send a subflow-ack without DATA_ACK and thus >>>> behave as in regular TCP. >>>> The client then should interpret this subflow-ack not as the one >>>> acknowledging the third ack (the one with the MP_CAPABLE), but rather >>>> fallback to regular TCP. Because, otherwise the client and server are no >>>> more in-sync. >>>> >>>> Thus, the retransmission only buys us something if the server is >>>> behaving stateless, the third ack got lost and the server is the one >>>> trying to send data first. This same problem is already present for >>>> stateless servers operating with regular TCP. >>>> >>>> I'm not sure that this current behavior of sending data in >>>> PRE_ESTABLISHED state is safe (e.g., how to behave if the third ack and >>>> the first data-packet got lost, but the second data-packet reaches the >>>> server? - the server sends a duplicate subflow-ack without >>>> MPTCP-options. How will the client interpret this subflow-ack?). >>>> >>>> I think we should remove the retransmission of the third ack, as it does >>>> not buy us a lot, and keep with the simpler and more straight-forward >>>> mechanism of not caring about lost third-acks (as in draft v02). >>> >>> It is true that if we removed the retransmission of the third ACK was added >>> for this corner case. But this is a well-known flaw in stateless operation >>> and SYN cookies, and our motivation for doing this was to make MPTCP's >>> handling of this better than regular TCP today. >>> >>> I agree, however, that it would make things simpler, and faster in the >>> majority of circumstances, to revert to a simple three-way handshake. >>> >>> Does anybody else have any thoughts? >> >> I realize one more thing, "conflicting" with the fact that no new >> subflows may be established while in PRE_ESTABLISHED, as described in >> section 3.1. Because, in section 3.6, we say that no new subflows are >> allowed as long as we did not receive a DATA_ACK. And, we will always >> enter PRE_ESTABLISHED before (or at the same time) receiving the first >> DATA_ACK. >> >> Thus, section 3.1 does not need to specify this, or may >> forward-reference to section 3.6. > > Thanks, we'll change that - that simplifies things. Good. So, retransmission of the third ack will stay? I just wanted to favor simplicity to make the protocol less complex. The more complex MPTCP is, the harder it will be to get it deployed. If the argument, that we want to fix with MPTCP the "broken" TCP SYN-cookies with regular TCP, is strong enough to justify the additional complexity, I'm fine with it. >>>> ============ >>>> * page 25: "If a mapping for that subflow-level sequence space does not >>>> arrive within a receive window of data, that subflow SHOULD be treated >>>> as broken,..." >>>> >>>> This is needed, because we allow to receive a DSS-mapping for a certain >>>> subflow-sequence-space on a packet whose sub-sequence-numbers do not >>>> belong to this space. >>>> >>>> I suggest, that we do not support this due to several reasons: >>>> >>>> 1. why should an implementation decide to send the DSS-mapping on a >>>> packet belonging to a different seq-space than specified in the >>>> DSS-mapping-option. >>>> >>>> 2. if we do it, and we store a full receive-window, we have to use quite >>>> a lot of memory before treating the subflow as broken. >>>> If we would only support DSS-mappings on packets who belong to this >>>> sequence-space, we can drop the data as soon as we receive a subsequence >>>> packet on this subflow with a DSS-mapping that does not cover the >>>> previous sequence-space (e.g., this happens in case of coalescing >>>> middleboxes). And, if we don't receive mappings, we can drop data as >>>> soon as we exceed 64KB, as the DATA_LEN's maximum is at 64KB. >>> >>> One reason for this clause is to cope with the case if a sender needed to >>> send an MPTCP option urgently, but did not want to interrupt the data >>> stream. The sender would then send data before sending its mapping, which >>> would be covered by a mapping on a following packet. >> >> When would the sender want to send an MPTCP option urgently? E.g., for >> ADD_ADDR the draft says "... Therefore, it is expected that an MPTCP >> implementation will send the ADD_ADDR option on separate ACKs..." >> >> I don't think that sending a duplicate ACK, holding the ADD_ADDR will >> "interrupt" the data-stream. And, are ADD_ADDR's (or REMOVE_ADDR's) so >> urgent? > > I accept the scenarios where this could be deliberately used are low. There > is one scenario where this is currently expressly forbidden but could be > useful: for the very first packet of a connection. On the third ACK of the > initial subflow, we could send data and it will be covered by a DSS mapping > on a following packet. (We could make this a special case, however). Regular TCP send's data on the third ACK, due to two reasons (unless I missed one): 1. spare one packet 2. make the data reach slightly faster the application However, for MPTCP these two arguments do not hold: 1. The DSS-mapping still needs to be sent on a separate packet. Thus, we do not spare one packet. 2. We need the DSS-mapping before being able to push the data to the application. (DSS-csum verification and we need the data-seq-number to verify that the data is in-window). Thus, we still have to wait for the DSS-mapping before pushing to the application. Thus, what would be the incentive to put data on the third ack in case of MPTCP ? A scenario concerning missing DSS-mapping on packets: If we are passing by a segment-coalescing middlebox, one mapping will be lost of either of the two coalesced segments. The receiver has to store this segment with the missing mapping due to our current design. The sender is not aware of it. The subflow has acknowledged these segments (at the subflow-level), and will continue with normal operation until the meta-level retransmission timer will trigger the retransmission of the data-segment. This retransmission will map to another sequence-number space and will thus not resolve the mapping of the original segment. As the middlebox continues coalescing segments, the receiver will have more and more of these in it's subflow-level receive-queues, waiting for a covering DSS-mapping until the whole receive-buffer has been used up by these "lingering" packets and they will finally get dropped. By the time, as the receive-buffer filled up, the receive-window dropped close to zero, and the sender is continuously receive-window blocked. Thus, performance has dropped. If we do not support the missing DSS-mapping, the receiver can drop the "empty" segment as soon as the subflow-receive-queue receives a new packet holding a DSS-mapping that does not cover the "empty" segment in the receive-queue. > I cannot remember if we thought of any other reasons for this clause... > >> The DSS-mapping has to be transmitted reliably, because otherwise we >> will have plenty of segments without mapping lingering around in the >> subflow-level receive-queues, and "consuming" space in the receive-window. >> Thus, we have to put the DSS-mapping on a data-packet. If the >> DSS-mapping-option does not map with the packet's subflow seq-space, we >> will be consuming the "slot" of this packet's DSS-mapping, which in turn >> again needs to be sent on the next data-packet. So, all DSS-mappings >> will be "switched" by one packet. >> >> Additionally, an attacker who manages to inject traffic on one subflow >> (he correctly guesses the 32-bit subflow-sequence-numbers - but is not >> able to do so for the 64-bit data-sequence-numbers) can fill up the >> whole receive-window with dummy-packets that do not contain >> DSS-mappings. Thus, he will considerably slow down the connection. >> >>> I think it is needed. >> >> Shouldn't we see if there is a real need for the "urgent MPTCP option" >> you mentioned earlier, and if it's worth going down the pain to support >> this ? >> >> I believe the protocol will be more straight-forward and potentially >> less memory-hungry if we don't support it. >> >>>> ============ >>>> * p. 41: "If it is known that all unacknowledged data in flight is >>>> contiguous..." >>>> >>>> Does it really need to be contiguous? >>>> >>>> Because, basically when falling back, the sender of the MP_FAIL >>>> (data-receiver) will discard all data he receives after the >>>> DATA-sequence-number which triggered the fallback. Only packets after >>>> the infinite-mapping option will be allowed. Otherwise, we may have a >>>> corrupted byte-stream presented to the application. >>>> Thus, the data-sender (after receiving the MP_FAIL) will just send the >>>> infinite-mapping option on the next packet. Irregardless, if the data >>>> in-flight is contiguous or not. >>> >>> This is only talking about the case with a single subflow in use. In that >>> case, we want to be able to fall back without losing any data. This is to >>> cope with payload-changing middleboxes. In this case, the receiver does NOT >>> discard any data, and just carries on reading as if it was a standard TCP >>> session. But in order to do that, all data must be contiguous. This is a >>> safety clause more than anything else. >> >> I understand now, that the note of "contiguous" data in flight relates >> to the data-level, and not to the subflow-level (I interpreted it to >> belong to the subflow-level). >> >> However, there is one more issue in this part of the draft: >> It says, "(if the data is not contiguous, the sender MUST send an RST)". >> However, sending a RST and establishing a new >> (regular) TCP session, continuing the flow from the corrupted data-seq >> number on, does not help. The receiver has to discard all data in the >> out-of-order queue to avoid the following problem: >> >> >> Suppose, we have two subflows, and the payload-modifying middlebox will >> add one byte to the segments with data-seq-number 1-10. 1-10 has been >> sent on subflow 1, and segment 11-20 has been sent on subflow 2. >> Segment 11-20 are acked at the subflow-level and will be stored in the >> data-level out-of-order queue because we don't yet have 1-10. >> >> Due to the DSS-csum error on subflow 1, this one will get closed and >> segment 1-10 will be reinjected on subflow 2. >> >> Now, we only have one single subflow (2), and 1-10 will be sent on this >> one, and the middlebox will again add one byte to this segment, >> resulting in a DSS-csum failure and fallback to regular TCP. >> >> 1-10 will be sent again on subflow 2 and the middlebox adds the >> byte, thus this segment becomes 1-11. >> >> Now, we have a 1-byte overlap in the receive-queue with packets 1-11 and >> (previously in the out-of-order queue) segment 11-20 and the byte-stream >> has thus been corrupted. >> >> The sender will retransmit segment 11-20 (at the reception 12-21 due to >> the middlebox), but when this segment reaches the receiver, the >> application may already have read the previous segments. >> >> Thus, this is the reason why the receiver has to discard all >> out-of-order data when announcing the fallback with MP_FAIL. >> Additionally, it is not necessary that the sender sends a RST if the >> data is not contiguous. It works by doing the direct fallback with the >> infinite-mapping option. > > Yes, you have a valid case there (if the same payload-altering middlebox is > operating on both subflows). > > I think our intention has always been for all data to be discarded resent > from the data-level sequence number specified in MP_FAIL; however, this may > not be explicitly clear in the text. We shall improve this. Yes, making the discard explicit in the text will make it more clear. Thanks! Cheers, Christoph -- Christoph Paasch PhD Student IP Networking Lab --- http://inl.info.ucl.ac.be MultiPath TCP in the Linux Kernel --- http://mptcp.info.ucl.ac.be Université Catholique de Louvain -- From john@jlc.net Fri Feb 24 06:50:55 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD2FC21F87B0 for ; Fri, 24 Feb 2012 06:50:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.418 X-Spam-Level: X-Spam-Status: No, score=-106.418 tagged_above=-999 required=5 tests=[AWL=0.181, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s3zLkiv1xByF for ; Fri, 24 Feb 2012 06:50:55 -0800 (PST) Received: from mailhost.jlc.net (mailhost.jlc.net [199.201.159.4]) by ietfa.amsl.com (Postfix) with ESMTP id C9E3B21F8748 for ; Fri, 24 Feb 2012 06:50:54 -0800 (PST) Received: by mailhost.jlc.net (Postfix, from userid 104) id 8B70733C4B; Fri, 24 Feb 2012 09:50:54 -0500 (EST) Date: Fri, 24 Feb 2012 09:50:54 -0500 From: John Leslie To: philip.eardley@bt.com Message-ID: <20120224145054.GL5226@verdi> References: <9510D26531EF184D9017DF24659BB87F331BF18C6D@EMV65-UKRD.domain1.systemhost.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <9510D26531EF184D9017DF24659BB87F331BF18C6D@EMV65-UKRD.domain1.systemhost.net> User-Agent: Mutt/1.4.1i Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] TCP option kind assignment for MPTCP X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Feb 2012 14:50:56 -0000 The parts about exceeding 40 bytes are excellent. Alas, there are several WMDs in the rest: let me recommend rewording... philip.eardley@bt.com wrote: > > Since the protocol is currently Experimental track, option (2) seems > more logical... ^^^^ ^^^^^^^ This isn't even right, and it definitely sets the wrong tone. I suggest "might seem logical". > There is also a positive case for choosing Option 1) (A new standards > codepoint):- > * MPTCP is being implemented by multiple operating systems... This is a subtle point. It's not that MPTCP _is_ being implemented on multiple OSs, it's that MPTCP _needs_to_ be implemented on multiple OSs. Otherwise we couldn't run useful experiments. s/ is / needs to be / > * There is a prior instance of allocation of a TCP Option kind number > for an Experimental track protocol (Quick-Start). This should go at the end. It would help (IMHO) to quote from the IANA page: " " Registration Procedures " IESG Approval or Standards Action and " " [*] It is only appropriate to use these values in explicitly- " configured experiments; they MUST NOT be shipped as defaults in " implementations. and note the difficulties of obeying this restriction given our need for implementation in multiple operating systems. > Our preferred allocation is TCP Option Kind #30 as this is what the > implementation uses. This _should_not_ be in the request. It makes _us_ look like squatters. ==== I also recommend including some text discussing the need to experiment with multiple operating systems and with options visible in the backbone. (It's not that they need to be acted upon in the backbone: it's that they need to find their way between endpoints without requiring action by middleboxes. Of course, there will _be_ middleboxes, some of which we must treat as damage; but we need real-Internet experience with paths free of middleboxes.) -- John Leslie From philip.eardley@bt.com Mon Feb 27 01:00:53 2012 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3BCCD21F84FD for ; Mon, 27 Feb 2012 01:00:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -103.071 X-Spam-Level: X-Spam-Status: No, score=-103.071 tagged_above=-999 required=5 tests=[AWL=-0.072, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-1, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JOvNzExuQJxf for ; Mon, 27 Feb 2012 01:00:52 -0800 (PST) Received: from smtpe1.intersmtp.com (smtp64.intersmtp.com [62.239.224.237]) by ietfa.amsl.com (Postfix) with ESMTP id 64F5421F8503 for ; Mon, 27 Feb 2012 01:00:52 -0800 (PST) Received: from EVMHT67-UKRD.domain1.systemhost.net (10.36.3.104) by RDW083A008ED64.smtp-e4.hygiene.service (10.187.98.13) with Microsoft SMTP Server (TLS) id 8.3.213.0; Mon, 27 Feb 2012 09:00:50 +0000 Received: from EMV65-UKRD.domain1.systemhost.net ([169.254.1.72]) by EVMHT67-UKRD.domain1.systemhost.net ([10.36.3.104]) with mapi; Mon, 27 Feb 2012 09:00:51 +0000 From: To: Date: Mon, 27 Feb 2012 09:00:50 +0000 Thread-Topic: [multipathtcp] TCP option kind assignment for MPTCP Thread-Index: AczzA78Y7u7J6P6SSQquAir4O659kACKgGiQ Message-ID: <9510D26531EF184D9017DF24659BB87F331C2D5188@EMV65-UKRD.domain1.systemhost.net> References: <9510D26531EF184D9017DF24659BB87F331BF18C6D@EMV65-UKRD.domain1.systemhost.net> <20120224145054.GL5226@verdi> In-Reply-To: <20120224145054.GL5226@verdi> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] TCP option kind assignment for MPTCP X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 27 Feb 2012 09:00:53 -0000 Thanks. will work all these in We will drop the request for option #30 & let IANA decide (if our request i= s approved) - it seems there is already someone (else) using it http://devcentral.f5.com/Tutorials/TechTips/tabid/63/articleType/ArticleVie= w/articleId/1086447/Accessing-TCP-Options-from-iRules.aspx=20 or: http://tools.ietf.org/html/draft-williams-overlaypath-ip-tcp-rfc-00=20 phil -----Original Message----- From: John Leslie [mailto:john@jlc.net]=20 Sent: 24 February 2012 14:51 To: Eardley,PL,Philip,DUB8 R Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] TCP option kind assignment for MPTCP The parts about exceeding 40 bytes are excellent. Alas, there are several WMDs in the rest: let me recommend rewording... philip.eardley@bt.com wrote: >=20 > Since the protocol is currently Experimental track, option (2) seems > more logical... ^^^^ ^^^^^^^ This isn't even right, and it definitely sets the wrong tone. I suggest "might seem logical". > There is also a positive case for choosing Option 1) (A new standards > codepoint):- > * MPTCP is being implemented by multiple operating systems... This is a subtle point. It's not that MPTCP _is_ being implemented on multiple OSs, it's that MPTCP _needs_to_ be implemented on multiple OSs. Otherwise we couldn't run useful experiments. s/ is / needs to be / > * There is a prior instance of allocation of a TCP Option kind number > for an Experimental track protocol (Quick-Start). This should go at the end. It would help (IMHO) to quote from the IANA page: "=20 " Registration Procedures " IESG Approval or Standards Action and "=20 " [*] It is only appropriate to use these values in explicitly- " configured experiments; they MUST NOT be shipped as defaults in " implementations. and note the difficulties of obeying this restriction given our need for implementation in multiple operating systems. > Our preferred allocation is TCP Option Kind #30 as this is what the > implementation uses. This _should_not_ be in the request. It makes _us_ look like squatters. =3D=3D=3D=3D I also recommend including some text discussing the need to experiment with multiple operating systems and with options visible in the backbone. (It's not that they need to be acted upon in the backbone: it's that they need to find their way between endpoints without requiring action by middleboxes. Of course, there will _be_ middleboxes, some of which we must treat as damage; but we need real-Internet experience with paths free of middleboxes.) -- John Leslie