From nobody Mon Aug 3 03:40:41 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D60D91A1BD2 for ; Mon, 3 Aug 2015 03:40:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jJxSkAECTbe4 for ; Mon, 3 Aug 2015 03:40:35 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.135]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD4561A1B9C for ; Mon, 3 Aug 2015 03:39:25 -0700 (PDT) Received: from EVMHT04-UKBR.domain1.systemhost.net (193.113.108.57) by EVMED01-UKBR.bt.com (10.216.161.31) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 3 Aug 2015 11:39:24 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by EVMHT04-UKBR.domain1.systemhost.net (193.113.108.57) with Microsoft SMTP Server (TLS) id 8.3.342.0; Mon, 3 Aug 2015 11:39:23 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03b.domain1.systemhost.net (10.55.202.22) with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 3 Aug 2015 11:39:23 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.0995.031; Mon, 3 Aug 2015 11:39:23 +0100 From: To: , , Thread-Topic: Any updates to 'Use Cases and Operational Experience with Multipath TCP'? Thread-Index: AdDN2J/vONgbXB1bQh+6PkRkUxizWg== Date: Mon, 3 Aug 2015 10:39:22 +0000 Message-ID: <55bcde97bcaf423aa1ac7dc84a8423f6@rew09926dag03b.domain1.systemhost.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.202.232] Content-Type: multipart/alternative; boundary="_000_55bcde97bcaf423aa1ac7dc84a8423f6rew09926dag03bdomain1sy_" MIME-Version: 1.0 Archived-At: Subject: [multipathtcp] Any updates to 'Use Cases and Operational Experience with Multipath TCP'? X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 10:40:39 -0000 --_000_55bcde97bcaf423aa1ac7dc84a8423f6rew09926dag03bdomain1sy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable SungHoon, Thomas, As mentioned during the WG meeting, although we've completed the WG last ca= ll it still would be good to add any updates resulting from your recent dep= loyment experiences. https://datatracker.ietf.org/doc/draft-ietf-mptcp-expe= rience/ In order to keep things progressing, we'll progress the document to the AD = & IESG at the end of August, so any changes you can suggest before then wou= ld be great. Thanks, Phil & Yoshi --_000_55bcde97bcaf423aa1ac7dc84a8423f6rew09926dag03bdomain1sy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

SungHoon, Thomas,

 

As mentioned during the WG meeting, altho= ugh we’ve completed the WG last call it still would be good to add an= y updates resulting from your recent deployment experiences. h= ttps://datatracker.ietf.org/doc/draft-ietf-mptcp-experience/=

 

In order to keep things progressing, we&#= 8217;ll progress the document to the AD & IESG at the end of August, so= any changes you can suggest before then would be great.

 

Thanks,

Phil & Yoshi

--_000_55bcde97bcaf423aa1ac7dc84a8423f6rew09926dag03bdomain1sy_-- From nobody Mon Aug 3 03:48:22 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2B511A1E0B for ; Mon, 3 Aug 2015 03:48:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0P2Ia6kVzX4 for ; Mon, 3 Aug 2015 03:48:18 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.137]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A3B7F1A1C04 for ; Mon, 3 Aug 2015 03:48:17 -0700 (PDT) Received: from EPDAG01C-UKBR.domain1.systemhost.net (193.113.197.204) by EVMED03-UKBR.bt.com (10.216.161.33) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 3 Aug 2015 11:48:14 +0100 Received: from rew09926dag03a.domain1.systemhost.net (10.55.202.18) by EPDAG01C-UKBR.domain1.systemhost.net (193.113.197.204) with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 3 Aug 2015 11:48:15 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03a.domain1.systemhost.net (10.55.202.18) with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 3 Aug 2015 11:48:14 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.0995.031; Mon, 3 Aug 2015 11:48:14 +0100 From: To: Thread-Topic: [multipathtcp] Doodle for Interim MPTCP WG meeting Thread-Index: AQHQxHHyZ1Qmb05sokmk9/FXVadVjZ36KsKw Date: Mon, 3 Aug 2015 10:48:13 +0000 Message-ID: <333cec0e583740c694e4572a0d30c8d7@rew09926dag03b.domain1.systemhost.net> References: <1437565377086.72935@bt.com> In-Reply-To: <1437565377086.72935@bt.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.202.232] Content-Type: multipart/alternative; boundary="_000_333cec0e583740c694e4572a0d30c8d7rew09926dag03bdomain1sy_" MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] Doodle for Interim MPTCP WG meeting X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 10:48:20 -0000 --_000_333cec0e583740c694e4572a0d30c8d7rew09926dag03bdomain1sy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just a reminder - please fill in the doodle thanks From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of phil= ip.eardley@bt.com Sent: 22 July 2015 12:43 To: multipathtcp@ietf.org Subject: [multipathtcp] Doodle for Interim MPTCP WG meeting Hi, Please fill in the doodle for when you can make an (audio) interim meeting = of the WG. http://doodle.com/h6v6zyutbrz9ruud In the past we found that 3pm GMT was a good time for people; please say if= this is a bad time for you, as we could see if a different time is now bet= ter for the WG. It was very exciting to hear about all the excellent multipath TCP cativity= during yesterday's meeting. However, we didn't complete the agenda * MPTCP proxy - Xinpeng Wei * Using MPTCP for channel combining for NASA project - Chairs on behalf of = William Ivancic * Deployment use cases - slides presented by Chairs on behalf of A.Palanive= lan There are also several drafts from people who weren't in Prague, at least s= ome of which we should think about how / if to progress (for instance by in= cluding in the protocol bis document). So these should also be considered. We also plan to do the final completion of the Operationl Experiences draft= and create the Implementations WG draft in the next weeks. So the interim meeting will cover the above topics. Best wishes, Phil & Yoshi. --_000_333cec0e583740c694e4572a0d30c8d7rew09926dag03bdomain1sy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just a reminder – please fill in the dood= le

 

thanks

 

From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: 22 July 2015 12:43
To: multipathtcp@ietf.org
Subject: [multipathtcp] Doodle for Interim MPTCP WG meeting

 

Hi,

 

Please fill in the doodle for when you can make an (audio) = interim meeting of the WG.

http://doodle.com= /h6v6zyutbrz9ruud

 

In the past we found that 3pm GMT was a good time for people; pl= ease say if this is a bad time for you, as we could see if a different time= is now better for the WG. 

 

It was very exciting to hear about all the excellent multipath T= CP cativity during yesterday's meeting. However, we didn't complete the age= nda

* MPTCP proxy - Xinpeng Wei
* Using MPTCP for channel combining for NASA project - Chairs on behalf of = William Ivancic
* Deployment use cases - slides presented by Chairs on behalf of A.Palanive= lan

 

There are also several drafts from people who weren't in Prague,= at least some of which we should think about how / if to progress (for ins= tance by including in the protocol bis document). So these should also be considered.

 

We also plan to do the final completion of the Operationl Experi= ences draft and create the Implementations WG draft in the next weeks.=

 

So the interim meeting will cover the above topics.

 

Best wishes,

Phil & Yoshi.

 

--_000_333cec0e583740c694e4572a0d30c8d7rew09926dag03bdomain1sy_-- From nobody Mon Aug 3 10:15:29 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED68E1AD082 for ; Mon, 3 Aug 2015 10:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.414 X-Spam-Level: *** X-Spam-Status: No, score=3.414 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RELAY_IS_203=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id m-emhInaQoBl for ; Mon, 3 Aug 2015 10:15:26 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6FCEE1ACEFD for ; Mon, 3 Aug 2015 10:15:26 -0700 (PDT) Received: from mail-ob0-f182.google.com (mail-ob0-f182.google.com [209.85.214.182]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 432E42780E6 for ; Tue, 4 Aug 2015 02:15:24 +0900 (JST) Received: by obbop1 with SMTP id op1so104195671obb.2 for ; Mon, 03 Aug 2015 10:15:22 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.39.194 with SMTP id r2mr18014998obk.20.1438622122754; Mon, 03 Aug 2015 10:15:22 -0700 (PDT) Received: by 10.202.104.15 with HTTP; Mon, 3 Aug 2015 10:15:22 -0700 (PDT) Date: Mon, 3 Aug 2015 10:15:22 -0700 Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: multipart/alternative; boundary=001a11c1d8d697ce2d051c6b50ea Archived-At: Subject: [multipathtcp] minutes for Prague meeting X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 03 Aug 2015 17:15:28 -0000 --001a11c1d8d697ce2d051c6b50ea Content-Type: text/plain; charset=UTF-8 Hi, We have uploaded the minute for Prague meeting. Please check the following url and let us know if you have any comments or suggestions. http://tools.ietf.org/wg/mptcp/minutes?item=minutes-93-mptcp.html We appreciate Costin and Alan for note taking. Thank you so much! Thanks, -- Yoshi & Phil --001a11c1d8d697ce2d051c6b50ea Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,
We have uploaded the minute for Prague meeting.Please check the following url and let us know if you have any comments or= suggestions.

http://tools.ietf.org/wg/mptcp/minutes?item=3Dmin= utes-93-mptcp.html

We appreciate Costin and Alan for note taking= . Thank you so much!

Thanks,
--
Yoshi & Phil
=
--001a11c1d8d697ce2d051c6b50ea-- From nobody Mon Aug 3 21:15:22 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0E741B34CA for ; Mon, 3 Aug 2015 21:15:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 3.12 X-Spam-Level: *** X-Spam-Status: No, score=3.12 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CBwh4t6clvjs for ; Mon, 3 Aug 2015 21:15:18 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC7031B34F2 for ; Mon, 3 Aug 2015 21:15:04 -0700 (PDT) Received: from mail-oi0-f44.google.com (mail-oi0-f44.google.com [209.85.218.44]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 7B7052780F8 for ; Tue, 4 Aug 2015 13:15:02 +0900 (JST) Received: by oizz185 with SMTP id z185so4126233oiz.0 for ; Mon, 03 Aug 2015 21:15:00 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.202.91.212 with SMTP id p203mr1257240oib.108.1438661700992; Mon, 03 Aug 2015 21:15:00 -0700 (PDT) Received: by 10.202.104.15 with HTTP; Mon, 3 Aug 2015 21:15:00 -0700 (PDT) Date: Mon, 3 Aug 2015 21:15:00 -0700 Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: multipart/alternative; boundary=001a113d56e6a3c84a051c74875b Archived-At: Subject: [multipathtcp] sequence number length in DSS option X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 04:15:20 -0000 --001a113d56e6a3c84a051c74875b Content-Type: text/plain; charset=UTF-8 Hi, While I was listening to audio archives, I was wondering if the 4 and 8 octets DSS sequence number discussion has been settled down. I understand Alan's comment that there is no good way to harmonize on this between the sender and the receiver in the current spec. Hence, implementations need to support both modes. But, what if we have a way to signal that it only supports one mode? Let's say 8 octet mode is mandatory to be implemented and 4 octet mode is optional. I personally think there might be the following two ways for signaling. 1: use new subtype create new subtype (say MP_CAPABLE2) and if MP_CAPABLE2 is used instead of MP_CAPABLE, it indicates that the implementation supports only 8 octets mode. 2: use new flag in DSS/DataACK option allocate one bit in the flag of DSS option (say S flag) If sender wants to use 4 octets mode, it first needs to send a DSS option with S flag and 8 octets seqnum. After it receives DSS with S flag, it can use DSS with 4 octets seqnum. I think It won't cause any harm, even if both sides use S flag simultaneously or the sender sets S flag in all DSS options. Of course this is useless If all implementors can agree to support both modes, but just in case. Thanks, -- Yoshi --001a113d56e6a3c84a051c74875b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,=C2=A0

While I was listening to audi= o archives, I was wondering if the 4 and 8 octets DSS sequence number discu= ssion has been settled down.
I understand Alan's comment that= there is no good way to harmonize on this between the sender and the recei= ver in the current spec. Hence, implementations need to support both modes.=

But, what if we have a way to signal that it = only supports one mode?
Let's say 8 octet mode is mandatory t= o be implemented and 4 octet mode is optional.
I personally think= there might be the following two ways for signaling.

<= div>1: use new subtype=C2=A0
=C2=A0 =C2=A0 create new subtype (sa= y MP_CAPABLE2) and if MP_CAPABLE2 is used instead of MP_CAPABLE, it indicat= es that the implementation supports only 8 octets mode.

2: use new flag in DSS/DataACK option
=C2=A0 =C2=A0 allocat= e one bit in the flag of DSS option (say S flag)
=C2=A0 =C2=A0 If= sender wants to use 4 octets mode, it first needs to send a DSS option wit= h S flag and 8 octets seqnum. After it receives DSS with S flag, it can use= DSS with 4 octets seqnum. I think It won't cause any harm, even if bot= h sides use S flag simultaneously or the sender sets S flag in all DSS opti= ons.

Of course this is useless If all implementors= can agree to support both modes, but just in case.

Thanks,
--
Yoshi
--001a113d56e6a3c84a051c74875b-- From nobody Mon Aug 3 21:32:27 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 62A661B3583 for ; Mon, 3 Aug 2015 21:32:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Eopj7WGl7YS8 for ; Mon, 3 Aug 2015 21:32:25 -0700 (PDT) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1C14D1B3580 for ; Mon, 3 Aug 2015 21:32:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1438662744; x=2302576344; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=wLc/BN9T+fNBXnC3ru+HiYl6dTbbdxkpscgnuozO4Gg=; b=eJfpUO98RypW5jUneLStL+6W5CrntfoyLZjp4pBgUx/GJc4YVjunT1R5FnDtHWbP LhvawybZy4XCdaZE/ja+9xtf4vmUEOV6hveXbJEpeyWvcqmtup4pbnqzocrcpt6n yHUNScJJo9cEeLfsozboanlK70zlklMWDuJHv27wyyBnnwrOKPAz9skg+0OXX7Yr p5+YE8GPCtmPNngq3+xo03Hk4gTRtCK904ZScJ7wkOtUrS+aYKWb9ZDYZPYYP6Gx FZd6dfhMhCe+LQQAyEOawOygDcjl3cnbkEev9jH0sN9dK4BtJPQidC99qQBNbIHT FUaxMlbcHzf8xPUn5czLfw==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 92.E3.29817.85040C55; Mon, 3 Aug 2015 21:32:24 -0700 (PDT) X-AuditID: 11973e15-f794b6d000007479-97-55c040589056 Received: from sesame.apple.com (sesame.apple.com [17.128.115.128]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id 59.3B.04920.85040C55; Mon, 3 Aug 2015 21:32:24 -0700 (PDT) Received: from localhost ([17.153.46.161]) by sesame.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NSJ00INKJ9Y7480@sesame.apple.com> for multipathtcp@ietf.org; Mon, 03 Aug 2015 21:32:24 -0700 (PDT) Date: Mon, 03 Aug 2015 21:32:23 -0700 From: Christoph Paasch To: Yoshifumi Nishida Message-id: <20150804043223.GO656@da0602a-dhcp119.apple.com> References: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline In-reply-to: User-Agent: Mutt/1.5.23 (2014-03-12) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUi2FAYoRvhcCDUoPOZlsXn1dfZHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMenMLcaCJt6Kt2f7GRsYJ3F1MXJySAiYSGw4/pwJwhaTuHBv PVsXIxeHkMBeRonZ+/+xwxT9nzWRGSLRxyRx5CZIB4jTziQxoXchWBWLgKrEzC0dbCA2m4CW xNvb7awgtoiAnsSH7x/BVjALaEhcf9gMViMs4CDR1d8LFucVsJHYdeIiC4gtJBAgsf3MU1aI uKDEj8n3WCB6tSTW7zwONUda4tHfGWB7OQWCJXbe3gw2U1RAReLKhLfsIMdJCHxkleg7uYdp AqPwLCSzZiGZNQvJrAWMzKsYhXITM3N0M/PM9BILCnJS9ZLzczcxgkJ5up3oDsYzq6wOMQpw MCrx8Aq83B8qxJpYVlyZe4hRmoNFSZw3YQlQSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA6OJ VPAKw7OWj/IXxc388vaoVc91jfnnFy/qjf2X+SjTttYv6vYjCVaRZTHHZyausWfl5y7lObLO kbdxpm75+g/vZJd85/K4ZvudeV+YZJ64ecYb3qzsrUVt6kt23Xb7IxkjZXb36e+mvWcVLMxq n3/L2d1g9vC3l1fxK9H1r0qtJMKnJOSa9SqxFGckGmoxFxUnAgAA2OEyRgIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUi2FDcoBvhcCDU4MwBdYvPq6+zOTB6LFny kymAMYrLJiU1J7MstUjfLoErY9KZW4wFTbwVb8/2MzYwTuLqYuTkkBAwkfg/ayIzhC0mceHe erYuRi4OIYE+JokjN58zQTjtTBITeheyg1SxCKhKzNzSwQZiswloSby93c4KYosI6El8+P6R CcRmFtCQuP6wGaxGWMBBoqu/FyzOK2AjsevERRYQW0ggQGL7maesEHFBiR+T77FA9GpJrN95 HGqOtMSjvzPA9nIKBEvsvL0ZbKaogIrElQlv2ScwCsxC0j4LSfssJO0LGJlXMQoUpeYkVprq JRYU5KTqJefnbmIEh15hxA7G/8usDjEKcDAq8fDueLY/VIg1say4MvcQowQHs5II78IbQCHe lMTKqtSi/Pii0pzU4kOM0hwsSuK8j9t2hQoJpCeWpGanphakFsFkmTg4pRoYpdt2zEq/fWHX 6k2f0ydcXHLm7rFzpRtm+V20Tlu5efvjhMigN2lSrCtmpaVUq1iulubjX3tsf85hp7Vbl0T8 f+/uMLPKsXJjhf2a1yxrrLw6QzhXXolXzLb+k3d2/bH5e5JYJqysWd8cPmXaVs0rl0sa7un3 f5o82/zkoUUzAgyMD24Kuv//7GMlluKMREMt5qLiRADOpJfzOQIAAA== Archived-At: Cc: multipathtcp Subject: Re: [multipathtcp] sequence number length in DSS option X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 04:32:26 -0000 Hello Yoshifumi, On 03/08/15 - 21:15:00, Yoshifumi Nishida wrote: > While I was listening to audio archives, I was wondering if the 4 and 8 > octets DSS sequence number discussion has been settled down. > I understand Alan's comment that there is no good way to harmonize on this > between the sender and the receiver in the current spec. Hence, > implementations need to support both modes. > > But, what if we have a way to signal that it only supports one mode? > Let's say 8 octet mode is mandatory to be implemented and 4 octet mode is > optional. > I personally think there might be the following two ways for signaling. > > 1: use new subtype > create new subtype (say MP_CAPABLE2) and if MP_CAPABLE2 is used instead > of MP_CAPABLE, it indicates that the implementation supports only 8 octets > mode. > > 2: use new flag in DSS/DataACK option > allocate one bit in the flag of DSS option (say S flag) > If sender wants to use 4 octets mode, it first needs to send a DSS > option with S flag and 8 octets seqnum. After it receives DSS with S flag, > it can use DSS with 4 octets seqnum. I think It won't cause any harm, even > if both sides use S flag simultaneously or the sender sets S flag in all > DSS options. > > Of course this is useless If all implementors can agree to support both > modes, but just in case. I do not think it is worth the effort of negotiating support for 4 octet DSS options, because all current implementations do support both modes. And if an implementation wants to be interoperable with others, it anyways will need to implement support for both. Cheers, Christoph From nobody Mon Aug 3 22:27:06 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 495AF1B35D9 for ; Mon, 3 Aug 2015 22:27:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.62 X-Spam-Level: ** X-Spam-Status: No, score=2.62 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pnF4f7_3dCL0 for ; Mon, 3 Aug 2015 22:27:04 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0297E1B35C5 for ; Mon, 3 Aug 2015 22:27:03 -0700 (PDT) Received: from mail-ob0-f175.google.com (mail-ob0-f175.google.com [209.85.214.175]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 043622780ED for ; Tue, 4 Aug 2015 14:27:02 +0900 (JST) Received: by obdeg2 with SMTP id eg2so115279456obd.0 for ; Mon, 03 Aug 2015 22:27:00 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.39.194 with SMTP id r2mr1615054obk.20.1438666020519; Mon, 03 Aug 2015 22:27:00 -0700 (PDT) Received: by 10.202.104.15 with HTTP; Mon, 3 Aug 2015 22:27:00 -0700 (PDT) Date: Mon, 3 Aug 2015 22:27:00 -0700 Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [multipathtcp] q about addr id=0 issue in address management X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 05:27:05 -0000 Hi, I might miss something as I am not an implementor of MPTCP, but I have a very naive question about addr id=0 issue in the address management draft. I think I understand that the issue forces a Multipath TCP implementation to at least store the address identifier of the initial subflow for each connection. But, it seems to me that this can be done by one octet variable. I am personally not very sure if this is too expensive. I will appreciate if someone could elaborate on this point. Thanks, -- Yoshi From nobody Mon Aug 3 23:08:32 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 23B751B3634 for ; Mon, 3 Aug 2015 23:08:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.101 X-Spam-Level: X-Spam-Status: No, score=-4.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0fRUZ7uOds_E for ; Mon, 3 Aug 2015 23:08:29 -0700 (PDT) Received: from mail-in6.apple.com (mail-out6.apple.com [17.151.62.28]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C305A1B3632 for ; Mon, 3 Aug 2015 23:08:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1438668509; x=2302582109; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=fJkZ7pv6WjEr2xhgFZcOeW/YvuQmuVlch/DLbLOX/KE=; b=IGOCZMCuYdkXo6g9lw67UhD1XQ8UZ3qYVMmDouVpO1PIeFyjtzuY3ETM22SDgCBI b2iLLz4ENfmEv3lKb5v9G6jQjloDgb/cqOQ4QTTFfCHrOXmUsd7rit9FXHa2xwzF dB5wQOUjvouoY1FFr26x+1WEk9UXdCDXuOf+5H6xEfBKitvUUu0bHqjHQmNF0OkJ 5soLIzLYR28sw9ixZwL4ATPaDSy/n2+EASGopujuxh4PTthrnMArZwAALPxhvx5s jc8lFKpgYOwxBSrKk12drILIWswAQuxa3WEmw0vxfV+MppqGUjsbUVngUuNCkbTr HDWYy/WB7HHFZBUUcEmh7g==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id BB.60.29817.DD650C55; Mon, 3 Aug 2015 23:08:29 -0700 (PDT) X-AuditID: 11973e15-f794b6d000007479-7b-55c056dd0f1e Received: from sesame.apple.com (sesame.apple.com [17.128.115.128]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay5.apple.com (Apple SCV relay) with SMTP id 87.EB.04920.CD650C55; Mon, 3 Aug 2015 23:08:29 -0700 (PDT) Received: from localhost ([17.153.46.161]) by sesame.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NSJ006Q3NQ4EM60@sesame.apple.com> for multipathtcp@ietf.org; Mon, 03 Aug 2015 23:08:28 -0700 (PDT) Date: Mon, 03 Aug 2015 23:08:28 -0700 From: Christoph Paasch To: Yoshifumi Nishida Message-id: <20150804060828.GA14467@Chimay.local> References: MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline In-reply-to: User-Agent: Mutt/1.5.23 (2014-03-12) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUi2FAYoXs37ECowdPn3BafV19nc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXRuPUtcwFJ/grZi+4zdTAeJCni5GTQ0LARKLr/idWCFtM4sK9 9WxdjFwcQgJ7GSVWvFvMBlc08xgTRKKPSeLU60VQVe1MEr07vrODVLEIqEpM3L2FBcRmE9CS eHu7HWysiICexIfvH5lAbGYBDYnrD5vBpgoLeEpsnDyHGcTmFTCU2HT1H5DNATQ0QOLBGTGI sKDEj8n3WCBatSTW7zwONUZa4tHfGWBrOQWCJWYceQ5miwqoSFyZ8JYd5DYJgbesEtMe/2Ka wCg8C8msWUhmzUIyawEj8ypGodzEzBzdzDwzvcSCgpxUveT83E2MoECebie6g/HMKqtDjAIc jEo8vAIv94cKsSaWFVfmHmKU5mBREudNWAIUEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwFjS Xn4lwCqAP9uEK/WjVkSD6Ka1bpIr/jpq677Z8Kk/Z09b8z2tWPaHW82DsviranSmG2W67gox jZ7sYnV6lovZQzXLpykViT837NiWLHHlicPkZZPZzXZffrQicudz172ZSvs4v+RXXXj3zUfq +38+3uUp7mJ/dKc29S+RujzlJ5ea0x32fiWW4oxEQy3mouJEAAP63Z5FAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUi2FDcoHs37ECowaWdbBafV19nc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXRuPUtcwFJ/grZi+4zdTAeJCni5GTQ0LARKJr5jEmCFtM4sK9 9WxdjFwcQgJ9TBKnXi+CctqZJHp3fGcHqWIRUJWYuHsLC4jNJqAl8fZ2OyuILSKgJ/Hh+0ew ScwCGhLXHzazgdjCAp4SGyfPYQaxeQUMJTZd/QdkcwANDZB4cEYMIiwo8WPyPRaIVi2J9TuP Q42Rlnj0dwbYWk6BYIkZR56D2aICKhJXJrxln8AoMAtJ+ywk7bOQtC9gZF7FKFCUmpNYaaqX WFCQk6qXnJ+7iREceIUROxj/L7M6xCjAwajEw7vj2f5QIdbEsuLK3EOMEhzMSiK8C28AhXhT EiurUovy44tKc1KLDzFKc7AoifM+btsVKiSQnliSmp2aWpBaBJNl4uCUamD0m/SxvX//YfP1 nIr3K64x8a1MS+9MOa3GeTowYeHJKzn7OtR8N5gxBG3d9uj57MI7GbdPcuUuSXqntSDO+fbW V/09Ls6sPKx3LgZ++nHH4rXywpUcrdnuXxad5axcfUJ4x6k3upuMf/edmB7fnJhoM61/TfF9 tpbPLR22/OEZB/Nuv396wTBHiaU4I9FQi7moOBEAXvwHujgCAAA= Archived-At: Cc: multipathtcp Subject: Re: [multipathtcp] q about addr id=0 issue in address management X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 04 Aug 2015 06:08:31 -0000 Hello Yoshifumi, On 03/08/15 - 22:27:00, Yoshifumi Nishida wrote: > I might miss something as I am not an implementor of MPTCP, but I have > a very naive question about addr id=0 issue in the address management > draft. > > I think I understand that the issue forces a Multipath TCP > implementation to at least store the address identifier of the initial > subflow for each connection. But, it seems to me that this can be done > by one octet variable. indeed, additional state has to be stored on a per-subflow basis to make sure that we are able to track the address-id. Storing this additional state is not a big deal in my opinion. The complexity comes rather from the handling of address-events in the stack as one has to take into account that the initial address does not need to be advertised again (https://github.com/multipath-tcp/mptcp/blob/mptcp_v0.90/net/mptcp/mptcp_fullmesh.c#L1285). Also, when an address disappears, the stack has to take into account that this address might actually be the one that has been used for the initial subflow. In Linux we maintain a global address-table with unique address-ids per local address, and special-case around the initial subflow. So, when an address disappears, we have to look through all subflows to see whether there are subflows that use this address with a different address-id. > I am personally not very sure if this is too expensive. I will > appreciate if someone could elaborate on this point. I agree that we should not introduce a change to the protocol spec to slightly reduce the implementation's complexity. If we could include the address-id in the MP_CAPABLE it would be great as it would be a small change to the protocol and fit the design of MP_JOIN as well. But I can understand that we don't want to reduce the entropy - although I'm not convinced that this is really a big deal as we would still have 110 bits of entropy for the HMAC. Cheers, Christoph From nobody Wed Aug 5 03:32:04 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5F7041B2F04 for ; Wed, 5 Aug 2015 03:32:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KuWvg2HhkYqp for ; Wed, 5 Aug 2015 03:32:00 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.135]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8A7D1B2EFF for ; Wed, 5 Aug 2015 03:31:59 -0700 (PDT) Received: from EVHUB03-UKBR.domain1.systemhost.net (193.113.108.185) by EVMED01-UKBR.bt.com (10.216.161.31) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 5 Aug 2015 11:31:57 +0100 Received: from rew09926dag03c.domain1.systemhost.net (10.55.202.26) by EVHUB03-UKBR.domain1.systemhost.net (193.113.108.185) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 3 Aug 2015 11:44:45 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03c.domain1.systemhost.net (10.55.202.26) with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 3 Aug 2015 11:44:38 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.0995.031; Mon, 3 Aug 2015 11:44:38 +0100 From: To: Thread-Topic: Consensus call on adding Experimental MPTCP option to protocol bis Thread-Index: AdDN2Sxnsmo2Qua/T626bA6iyankJA== Date: Mon, 3 Aug 2015 10:44:37 +0000 Message-ID: <069d6e2e52ae45d6bd27891d1db98b89@rew09926dag03b.domain1.systemhost.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.202.232] Content-Type: multipart/alternative; boundary="_000_069d6e2e52ae45d6bd27891d1db98b89rew09926dag03bdomain1sy_" MIME-Version: 1.0 Archived-At: Subject: [multipathtcp] Consensus call on adding Experimental MPTCP option to protocol bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 10:32:02 -0000 --_000_069d6e2e52ae45d6bd27891d1db98b89rew09926dag03bdomain1sy_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RHVyaW5nIHRoZSBXRyBtZWV0aW5nIHdlIGRpc2N1c3NlZCBhZGRpbmcgYW5kIGV4cGVyaW1lbnRh bCBNUFRDUCBvcHRpb24gdG8gdGhlIHByb3RvY29sIGJpcyBodHRwczovL2RhdGF0cmFja2VyLmll dGYub3JnL2RvYy9kcmFmdC1ib25hdmVudHVyZS1tcHRjcC1leHAtb3B0aW9uLw0KVGhpcyBlbWFp bCBpcyB0byBjb25maXJtIHRoZSBjb25zZW5zdXMgb2YgdGhlIGZhY2UtdG8tZmFjZSBtZWV0aW5n Lg0KUGxlYXNlIHNob3V0IGlmIHlvdSB0aGluayB0aGlzIHNob3VsZG7igJl0IGJlIGFkZGVkLg0K DQpUaGFua3MNClBoaWwgJiBZb3NoaQ0K --_000_069d6e2e52ae45d6bd27891d1db98b89rew09926dag03bdomain1sy_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTIuMHB0Ow0K CWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iLCJzZXJpZiI7fQ0KYTpsaW5rLCBzcGFuLk1z b0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0 LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xs b3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVj b3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6 cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiI7DQoJY29s b3I6Ymx1ZTsNCglmb250LXdlaWdodDpub3JtYWw7DQoJZm9udC1zdHlsZTpub3JtYWw7DQoJdGV4 dC1kZWNvcmF0aW9uOm5vbmUgbm9uZTt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlw ZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiOw0KCW1z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYx Mi4wcHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRp di5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lm IGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9 IjEwMjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxv OnNoYXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIx IiAvPg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkg bGFuZz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29y ZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPkR1 cmluZyB0aGUgV0cgbWVldGluZyB3ZSBkaXNjdXNzZWQgYWRkaW5nIGFuZCBleHBlcmltZW50YWwg TVBUQ1Agb3B0aW9uIHRvIHRoZSBwcm90b2NvbCBiaXMNCjxhIGhyZWY9Imh0dHBzOi8vZGF0YXRy YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJvbmF2ZW50dXJlLW1wdGNwLWV4cC1vcHRpb24vIj5o dHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1ib25hdmVudHVyZS1tcHRjcC1l eHAtb3B0aW9uLzwvYT4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPlRoaXMgZW1haWwgaXMgdG8gY29uZmlybSB0aGUgY29u c2Vuc3VzIG9mIHRoZSBmYWNlLXRvLWZhY2UgbWVldGluZy4NCjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtB cmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPlBsZWFzZSBzaG91 dCBpZiB5b3UgdGhpbmsgdGhpcyBzaG91bGRu4oCZdCBiZSBhZGRlZC48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj48bzpwPiZu YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xv cjpibHVlIj5UaGFua3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1z ZXJpZiZxdW90Oztjb2xvcjpibHVlIj5QaGlsICZhbXA7IFlvc2hpDQo8L3NwYW4+PG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_069d6e2e52ae45d6bd27891d1db98b89rew09926dag03bdomain1sy_-- From nobody Wed Aug 5 09:38:11 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 360A21B3198 for ; Wed, 5 Aug 2015 09:38:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.202 X-Spam-Level: X-Spam-Status: No, score=-2.202 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zMqfufHSP--T for ; Wed, 5 Aug 2015 09:38:09 -0700 (PDT) Received: from mail-in2.apple.com (mail-out2.apple.com [17.151.62.25]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2A531A7020 for ; Wed, 5 Aug 2015 09:37:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1438792671; x=2302706271; h=From:Sender:Reply-To:Subject:Date:Message-id:To:Cc:MIME-version:Content-type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-reply-to:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=FkZNDtRB2ynOGs7lU5goGzbqRF1dZp8VGrED3pyHiC4=; b=QkDBVuzfZmMECWI2YLgEqKe7y0TmP73v/cWwHSMwKVvqkpbMHHpGJqNHFh8EFZmN DyB+jsC5U36jq31i3zqSeF8VVeMYKgYqCiARPZhKzgIAyXE8G7ATyaDS3pUYT1ij LwdNbuo1tlHrYgZNQNzfHCQDNlbuZfRW7uTG3kEM3T2lvOYnFLlSwxEoXtuRvM8d yT6oqW24m2ck96yw6B0Dhb4IM16s2ZzhoKhEvjVFLGfmsSA4ESGyAS2kJFIVT0oc oEhGel35IdpDz2SO2GJlA3TN/6gBxG1FyC1EI6tL1k33xzd01zQUfxSS0/j21aCb bB/9QYlg8COBuo2xXWSyJg==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) by mail-in2.apple.com (Apple Secure Mail Relay) with SMTP id 12.54.09727.FDB32C55; Wed, 5 Aug 2015 09:37:51 -0700 (PDT) X-AuditID: 11973e11-f79d46d0000025ff-1b-55c23bdfe0c3 Received: from spicerack.apple.com (spicerack.apple.com [17.128.115.40]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay8.apple.com (Apple SCV relay) with SMTP id B7.9A.00725.FDB32C55; Wed, 5 Aug 2015 09:37:51 -0700 (PDT) Received: from localhost ([17.153.73.2]) by spicerack.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NSM00A13BJ2KQ60@spicerack.apple.com> for multipathtcp@ietf.org; Wed, 05 Aug 2015 09:37:51 -0700 (PDT) Date: Wed, 05 Aug 2015 09:37:50 -0700 From: Christoph Paasch To: philip.eardley@bt.com Message-id: <20150805163750.GM14467@Chimay.local> References: <069d6e2e52ae45d6bd27891d1db98b89@rew09926dag03b.domain1.systemhost.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline In-reply-to: <069d6e2e52ae45d6bd27891d1db98b89@rew09926dag03b.domain1.systemhost.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUi2FCYpnvf+lCoQdtKUYvPq6+zOTB6LFny kymAMYrLJiU1J7MstUjfLoErY9WMQywFzcwVa7Z8Z2pgPMzUxcjJISFgIrF43zU2CFtM4sK9 9UA2F4eQwD5GiWsTzjDDFK3Z+ZAJIjGZSeLU0dtg3UICvUwSCw8EgdgsAqoSzYc2gcXZBLQk 3t5uZwWxRQQkJVZsXwW2gRnE/vsJLC4skCCxbN01dhCbV8BQ4s3bfjaImWESH7dOgIoLSvyY fI8FoldLYv3O40wQtrTEo78zwGo4BcIlVv1pB+sVFVCRuDLhLTvIoRICL1kl3vXtZZvAKDwL yaxZSGbNQjJrASPzKkah3MTMHN3MPCO9xIKCnFS95PzcTYygQJ5uJ7iD8fgqq0OMAhyMSjy8 H5wPhgqxJpYVV+YeYpTmYFES5+1RPRQqJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgbEutXEe 69UPexeZX9r3VKb5+Nsuj3fWcYJu3PvYHafmH66QDU9p5b90YdLW2EhTg06NTWVODDXC/zKv qr3Y/Gz2hym7/5os9Tk0r20/40WrE5xv71i5MV/dM9HC4qno261v+Tfdk5p9+MBHFbPLB/d+ 5VY0lOfduXVWQs3nR/sCS1d8bl1TP4lfiaU4I9FQi7moOBEAW4yLZEUCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUi2FCsoXvf+lCoQdt9IYvPq6+zOTB6LFny kymAMYrLJiU1J7MstUjfLoErY9WMQywFzcwVa7Z8Z2pgPMzUxcjJISFgIrFm50MoW0ziwr31 bF2MXBxCApOZJE4dvQ2WEBLoZZJYeCAIxGYRUJVoPrQJLM4moCXx9nY7K4gtIiApsWL7KjYQ mxnE/vsJLC4skCCxbN01dhCbV8BQ4s3bfjaImWESH7dOgIoLSvyYfI8FoldLYv3O40wQtrTE o78zwGo4BcIlVv1pB+sVFVCRuDLhLfsERoFZSNpnIWmfhaR9ASPzKkaBotScxEoLvcSCgpxU veT83E2M4MArTNvB2LTc6hCjAAejEg/vB+eDoUKsiWXFlbmHGCU4mJVEeFeYHgoV4k1JrKxK LcqPLyrNSS0+xCjNwaIkzvuobVeokEB6YklqdmpqQWoRTJaJg1OqgbE7STZh1dSrs8LKhPwE J0ypcb3dFhYrP0fl9tRDjQ7hotPk2eJnPPh07HjvPB1uhxN6cfk/P/y4ujZV4eq09PLe7um/ uR0WNznP7q1xbutn5NljdntGaXITn1uVXeSq2jenGaesqJuboMFkcTH7ycQ2L8WTZTONUn9q Xpu4+6faA932CWvONyixFGckGmoxFxUnAgB+OAvXOAIAAA== Archived-At: Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Consensus call on adding Experimental MPTCP option to protocol bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Aug 2015 16:38:10 -0000 Hello, On 03/08/15 - 10:44:37, philip.eardley@bt.com wrote: > During the WG meeting we discussed adding and experimental MPTCP option to the protocol bis https://datatracker.ietf.org/doc/draft-bonaventure-mptcp-exp-option/ > This email is to confirm the consensus of the face-to-face meeting. I'm in favor of adding the experimental MPTCP option to RFC6824bis. Christoph From nobody Fri Aug 7 00:17:03 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EB3C91B37C0 for ; Fri, 7 Aug 2015 00:17:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.914 X-Spam-Level: ** X-Spam-Status: No, score=2.914 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_LOW=-0.7, RELAY_IS_203=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Z4S-ZEUR-VrT for ; Fri, 7 Aug 2015 00:17:00 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 723211B37BF for ; Fri, 7 Aug 2015 00:17:00 -0700 (PDT) Received: from mail-oi0-f50.google.com (mail-oi0-f50.google.com [209.85.218.50]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 84B372781C3 for ; Fri, 7 Aug 2015 16:16:58 +0900 (JST) Received: by oiev193 with SMTP id v193so21333382oie.3 for ; Fri, 07 Aug 2015 00:16:57 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.202.220.65 with SMTP id t62mr5040542oig.115.1438931817151; Fri, 07 Aug 2015 00:16:57 -0700 (PDT) Received: by 10.202.104.15 with HTTP; Fri, 7 Aug 2015 00:16:57 -0700 (PDT) In-Reply-To: <20150804043223.GO656@da0602a-dhcp119.apple.com> References: <20150804043223.GO656@da0602a-dhcp119.apple.com> Date: Fri, 7 Aug 2015 00:16:57 -0700 Message-ID: From: Yoshifumi Nishida To: Christoph Paasch Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: multipathtcp Subject: Re: [multipathtcp] sequence number length in DSS option X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 07:17:02 -0000 Hi Christoph, On Mon, Aug 3, 2015 at 9:32 PM, Christoph Paasch wrote: > Hello Yoshifumi, > > On 03/08/15 - 21:15:00, Yoshifumi Nishida wrote: >> While I was listening to audio archives, I was wondering if the 4 and 8 >> octets DSS sequence number discussion has been settled down. >> I understand Alan's comment that there is no good way to harmonize on this >> between the sender and the receiver in the current spec. Hence, >> implementations need to support both modes. >> >> But, what if we have a way to signal that it only supports one mode? >> Let's say 8 octet mode is mandatory to be implemented and 4 octet mode is >> optional. >> I personally think there might be the following two ways for signaling. >> >> 1: use new subtype >> create new subtype (say MP_CAPABLE2) and if MP_CAPABLE2 is used instead >> of MP_CAPABLE, it indicates that the implementation supports only 8 octets >> mode. >> >> 2: use new flag in DSS/DataACK option >> allocate one bit in the flag of DSS option (say S flag) >> If sender wants to use 4 octets mode, it first needs to send a DSS >> option with S flag and 8 octets seqnum. After it receives DSS with S flag, >> it can use DSS with 4 octets seqnum. I think It won't cause any harm, even >> if both sides use S flag simultaneously or the sender sets S flag in all >> DSS options. >> >> Of course this is useless If all implementors can agree to support both >> modes, but just in case. > > I do not think it is worth the effort of negotiating support for 4 octet DSS > options, because all current implementations do support both modes. > > And if an implementation wants to be interoperable with others, it anyways > will need to implement support for both. Yep, If all implementations can support both modes, it's totally fine. I just would like to check if we settled down here. Once a PS spec is published, it might be painful to change it. Thanks, -- Yoshi From nobody Fri Aug 7 00:27:40 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF5BF1A8973 for ; Fri, 7 Aug 2015 00:27:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.62 X-Spam-Level: ** X-Spam-Status: No, score=2.62 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d1JhHgvLcZYF for ; Fri, 7 Aug 2015 00:27:38 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [IPv6:2001:200:0:8803::53]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B773C1A897D for ; Fri, 7 Aug 2015 00:26:39 -0700 (PDT) Received: from mail-ob0-f169.google.com (mail-ob0-f169.google.com [209.85.214.169]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id EE98C2781C3 for ; Fri, 7 Aug 2015 16:26:37 +0900 (JST) Received: by obdeg2 with SMTP id eg2so73619264obd.0 for ; Fri, 07 Aug 2015 00:26:36 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.178.33 with SMTP id cv1mr5289043oec.11.1438932396406; Fri, 07 Aug 2015 00:26:36 -0700 (PDT) Received: by 10.202.104.15 with HTTP; Fri, 7 Aug 2015 00:26:36 -0700 (PDT) In-Reply-To: <20150804060828.GA14467@Chimay.local> References: <20150804060828.GA14467@Chimay.local> Date: Fri, 7 Aug 2015 00:26:36 -0700 Message-ID: From: Yoshifumi Nishida To: Christoph Paasch Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: multipathtcp Subject: Re: [multipathtcp] q about addr id=0 issue in address management X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 07:27:39 -0000 Hi Christoph, On Mon, Aug 3, 2015 at 11:08 PM, Christoph Paasch wrote: > Hello Yoshifumi, > > On 03/08/15 - 22:27:00, Yoshifumi Nishida wrote: >> I might miss something as I am not an implementor of MPTCP, but I have >> a very naive question about addr id=0 issue in the address management >> draft. >> >> I think I understand that the issue forces a Multipath TCP >> implementation to at least store the address identifier of the initial >> subflow for each connection. But, it seems to me that this can be done >> by one octet variable. > > indeed, additional state has to be stored on a per-subflow basis to make > sure that we are able to track the address-id. Storing this additional state > is not a big deal in my opinion. > > The complexity comes rather from the handling of address-events in the stack > as one has to take into account that the initial address does not need to be > advertised again > (https://github.com/multipath-tcp/mptcp/blob/mptcp_v0.90/net/mptcp/mptcp_fullmesh.c#L1285). > > Also, when an address disappears, the stack has to take into account that > this address might actually be the one that has been used for the initial > subflow. In Linux we maintain a global address-table with unique address-ids > per local address, and special-case around the initial subflow. > So, when an address disappears, we have to look through all subflows to see > whether there are subflows that use this address with a different > address-id. Thanks, I think I understand. But, I'm not very sure how much performance gain we can get by this. However, I also think reducing the entropy might not be a big deal. -- Yoshi From nobody Fri Aug 7 00:41:13 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EBD1C1B3806 for ; Fri, 7 Aug 2015 00:41:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.6 X-Spam-Level: X-Spam-Status: No, score=-0.6 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id igPiaeN-vd4S for ; Fri, 7 Aug 2015 00:41:10 -0700 (PDT) Received: from mail-wi0-x22c.google.com (mail-wi0-x22c.google.com [IPv6:2a00:1450:400c:c05::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B67E1B3805 for ; Fri, 7 Aug 2015 00:41:09 -0700 (PDT) Received: by wibhh20 with SMTP id hh20so54400491wib.0 for ; Fri, 07 Aug 2015 00:41:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=qJ2enHvYV0psmxkWZzldExBPIpCBt3+92u1O25o7kH4=; b=KAfb9aMZdN3kfEmG/1NQuJJr/rCIGc/N0c7JHi+xP6ZeoA5JbftBmQ3EbI4cJmeKFt nri3dXtQit/roXHcxmec9RkYrRVyVZEess9jdU0Ak9MsA1gfjfxQcTbB2WJsnyNuiimT +hl+38e/RtPfVAbiP+bsQy5LR7+3GYe9e0wCGHG3j39RbvIuoBqfm1SPMrjs1+0I/7PA vRZeohx9LnAN+a1zSklrWB+nD2UtRxtDC8g1DHv91G86PvqLQr/CYbdJ4yaFaXmNkIJW jYE8OzaGJuvs5iC9bRD69oGmAbFskicCRBHTxOaSm4bT9cC6pPnB+LuwyerRp2hYbqzT yJ4w== X-Received: by 10.194.71.165 with SMTP id w5mr8292706wju.135.1438933268313; Fri, 07 Aug 2015 00:41:08 -0700 (PDT) Received: from [192.168.0.6] ([81.168.57.225]) by smtp.gmail.com with ESMTPSA id jz4sm13306243wjb.16.2015.08.07.00.41.07 (version=TLS1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Aug 2015 00:41:07 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=us-ascii From: Alan Ford In-Reply-To: <20150804060828.GA14467@Chimay.local> Date: Fri, 7 Aug 2015 08:41:05 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <4B52CD65-B1B9-4F44-B152-0AE96471204B@gmail.com> References: <20150804060828.GA14467@Chimay.local> To: Christoph Paasch X-Mailer: Apple Mail (2.1283) Archived-At: Cc: multipathtcp Subject: Re: [multipathtcp] q about addr id=0 issue in address management X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 07:41:12 -0000 Hi Christoph, On 4 Aug 2015, at 07:08, Christoph Paasch wrote: > On 03/08/15 - 22:27:00, Yoshifumi Nishida wrote: >> I think I understand that the issue forces a Multipath TCP >> implementation to at least store the address identifier of the = initial >> subflow for each connection. But, it seems to me that this can be = done >> by one octet variable. >=20 > indeed, additional state has to be stored on a per-subflow basis to = make > sure that we are able to track the address-id. Storing this additional = state > is not a big deal in my opinion. Surely it's per-connection state not per-subflow? Identifying which of = your subflows has id=3D0 for this particular connection? > The complexity comes rather from the handling of address-events in the = stack > as one has to take into account that the initial address does not need = to be > advertised again > = (https://github.com/multipath-tcp/mptcp/blob/mptcp_v0.90/net/mptcp/mptcp_f= ullmesh.c#L1285). I don't know the code here, but surely this test applies irrespective of = identifier? > Also, when an address disappears, the stack has to take into account = that > this address might actually be the one that has been used for the = initial > subflow. In Linux we maintain a global address-table with unique = address-ids > per local address, and special-case around the initial subflow. > So, when an address disappears, we have to look through all subflows = to see > whether there are subflows that use this address with a different > address-id. Ah, I get this one :( If an address came back, how would you know it's the initial one and = thus should have id=3D0? Well, that's not actually a scenario I had = considered so far in general. The spec is not explicit as to whether the = identifiers should be the same if an interface is removed and later = comes back. Would it add extra problems if, in that case, it was said that new = identifiers could be used? The main reason for the address identifier is = simply to identify subflow ends when the IP address may have bee changed = by a NAT. Plus, implying it would be the same adds extra semantics to an = IP address. If you moved networks, or from wifi to wired, but had the = same IP address, you may actually not want the far end to think it's the = same. In this scenario I think you would be fine issuing a new address ID for = a new interface, even if the IP address is the same as the = previously-lost initial subflow. And then this would go away. I am happy = to clarify this in the spec if you don't think it would cause any = additional implementation issues? Regards, Alan From nobody Fri Aug 7 00:42:07 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8540C1B3815 for ; Fri, 7 Aug 2015 00:42:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xuukIwJAI4eI for ; Fri, 7 Aug 2015 00:42:05 -0700 (PDT) Received: from mail-wi0-x22d.google.com (mail-wi0-x22d.google.com [IPv6:2a00:1450:400c:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D61101B3812 for ; Fri, 7 Aug 2015 00:42:04 -0700 (PDT) Received: by wicne3 with SMTP id ne3so50006666wic.1 for ; Fri, 07 Aug 2015 00:42:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=QEGL5Zim5AP2IwDwgV1Q/ZqB7/FOEq4JR6+zXrfnXig=; b=hibpwacGrtc6BmU2FaBkyBaclPJj5vveLvPEFjfHGQkDF8pQOjUuMBfUcIlPB3Rems QyIlQQhtO9H6IgD0ga2/I+eHz7fboBtrZTDiZs0n90bUwCIRS/w/V8BdxRga4fE3U/H+ QDhU49nWd3LdOeGEjk2gbPhlGUbyYkTq2nH9jiIhP/Og7/Gg8rM9ADIW01ouL4VKKCB2 5p6XJVOt/+3n9Rd/zj21XsrgjkFA877pZaNzvEqnxSTiwkmBP8qej8ITou2aOSwX/fVh 9hwrSLMF5SCZtkrspAoFxyCda60ORsGXzUnM59Sh+9xTW6jh1hJmyv+Empr1E0wP8wDt U5qw== X-Received: by 10.180.74.69 with SMTP id r5mr3705476wiv.84.1438933323680; Fri, 07 Aug 2015 00:42:03 -0700 (PDT) Received: from [192.168.0.6] ([81.168.57.225]) by smtp.gmail.com with ESMTPSA id jz4sm13306243wjb.16.2015.08.07.00.42.02 (version=TLS1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Fri, 07 Aug 2015 00:42:03 -0700 (PDT) Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: multipart/alternative; boundary="Apple-Mail=_DD55A0F2-9DEC-4BE9-85E9-5CF4837D4D69" From: Alan Ford In-Reply-To: <069d6e2e52ae45d6bd27891d1db98b89@rew09926dag03b.domain1.systemhost.net> Date: Fri, 7 Aug 2015 08:42:02 +0100 Message-Id: References: <069d6e2e52ae45d6bd27891d1db98b89@rew09926dag03b.domain1.systemhost.net> To: X-Mailer: Apple Mail (2.1283) Archived-At: Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Consensus call on adding Experimental MPTCP option to protocol bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 07 Aug 2015 07:42:06 -0000 --Apple-Mail=_DD55A0F2-9DEC-4BE9-85E9-5CF4837D4D69 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 I am in favour, but I did raise an issue on the other thread but nobody = replied - do we really need 16 bits for the identifier or would 8 bits = be sufficient? On 3 Aug 2015, at 11:44, = wrote: > During the WG meeting we discussed adding and experimental MPTCP = option to the protocol bis = https://datatracker.ietf.org/doc/draft-bonaventure-mptcp-exp-option/ > This email is to confirm the consensus of the face-to-face meeting. > Please shout if you think this shouldn=92t be added. > =20 > Thanks > Phil & Yoshi > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp --Apple-Mail=_DD55A0F2-9DEC-4BE9-85E9-5CF4837D4D69 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=windows-1252 I am in favour, but I did raise an issue on the = other thread but nobody replied - do we really need 16 bits for the = identifier or would 8 bits be sufficient?

On 3 Aug = 2015, at 11:44, <philip.eardley@bt.com> = <philip.eardley@bt.com>= wrote:

During the WG meeting we discussed = adding and experimental MPTCP option to the protocol bis This email is to confirm the consensus = of the face-to-face meeting.
_______________________________________= ________
multipathtcp mailing list
multipathtcp@ietf.org
Subject: [multipathtcp] Interim (audio) MPTCP WG meeting, Thursday 10th September, 3pm GMT/UTC X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 09:34:35 -0000 --_000_13f21dcf2f1242398d2181afaf53d7c0rew09926dag03bdomain1sy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Let's fix the date: Thursday 10th September, 3pm GMT/UTC =3D 4pm UK, 5pm CEST. You can see a few timezones here http://www.timeanddate.com/worldclock/meetingdetails.html?year=3D2015&month= =3D9&day=3D12&hour=3D15&min=3D0&sec=3D0&p1=3D1346&p2=3D179&p3=3D37&p4=3D137= &p5=3D248&p6=3D33 Suggest we aim for 1.5 hours, with a maximum of 2 hours. We'll ask the IETF Secretariat to arrange the audio /webex. Draft agenda etc on the wiki http://trac.tools.ietf.org/wg/mptcp/trac/wiki/= Interim_Sept_2015 Please let us know topics for the agenda - what you'd like to present or di= scuss Thanks Phil and Yoshi From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of phil= ip.eardley@bt.com Sent: 03 August 2015 11:48 To: multipathtcp@ietf.org Subject: Re: [multipathtcp] Doodle for Interim MPTCP WG meeting Just a reminder - please fill in the doodle thanks From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of phil= ip.eardley@bt.com Sent: 22 July 2015 12:43 To: multipathtcp@ietf.org Subject: [multipathtcp] Doodle for Interim MPTCP WG meeting Hi, Please fill in the doodle for when you can make an (audio) interim meeting = of the WG. http://doodle.com/h6v6zyutbrz9ruud In the past we found that 3pm GMT was a good time for people; please say if= this is a bad time for you, as we could see if a different time is now bet= ter for the WG. It was very exciting to hear about all the excellent multipath TCP cativity= during yesterday's meeting. However, we didn't complete the agenda * MPTCP proxy - Xinpeng Wei * Using MPTCP for channel combining for NASA project - Chairs on behalf of = William Ivancic * Deployment use cases - slides presented by Chairs on behalf of A.Palanive= lan There are also several drafts from people who weren't in Prague, at least s= ome of which we should think about how / if to progress (for instance by in= cluding in the protocol bis document). So these should also be considered. We also plan to do the final completion of the Operationl Experiences draft= and create the Implementations WG draft in the next weeks. So the interim meeting will cover the above topics. Best wishes, Phil & Yoshi. --_000_13f21dcf2f1242398d2181afaf53d7c0rew09926dag03bdomain1sy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Let’s fix the date:

Thursday 10th September, 3pm GMT/UTC

 

=3D 4pm UK, 5pm CEST. You can see a few timezon= es here

http://www.timeanddate.com/worldclock/meetingdet= ails.html?year=3D2015&month=3D9&day=3D12&hour=3D15&min=3D0&= amp;sec=3D0&p1=3D1346&p2=3D179&p3=3D37&p4=3D137&p5=3D24= 8&p6=3D33

 

Suggest we aim for 1.5 hours, with a maximum of= 2 hours.

 

We’ll ask the IETF Secretariat to arrange= the audio /webex.

 

Draft agenda etc on the wiki http://trac.tools.ietf.org/wg/mptcp/trac/wiki/Interim_Sept_2015

 

Please let us know topics for the agenda - what= you’d like to present or discuss

 

Thanks

Phil and Yoshi

 

From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: 03 August 2015 11:48
To: multipathtcp@ietf.org
Subject: Re: [multipathtcp] Doodle for Interim MPTCP WG meeting=

 

Just a reminder – please fill in the dood= le

 

thanks

 

 

Hi,

 

Please fill in the doodle for when you can make an (audio) = interim meeting of the WG.

http://doodle.com= /h6v6zyutbrz9ruud

 

In the past we found that 3pm GMT was a good time for people; pl= ease say if this is a bad time for you, as we could see if a different time= is now better for the WG. 

 

It was very exciting to hear about all the excellent multipath T= CP cativity during yesterday's meeting. However, we didn't complete the age= nda

* MPTCP proxy - Xinpeng Wei
* Using MPTCP for channel combining for NASA project - Chairs on behalf of = William Ivancic
* Deployment use cases - slides presented by Chairs on behalf of A.Palanive= lan

 

There are also several drafts from people who weren't in Prague,= at least some of which we should think about how / if to progress (for ins= tance by including in the protocol bis document). So these should also be considered.

 

We also plan to do the final completion of the Operationl Experi= ences draft and create the Implementations WG draft in the next weeks.=

 

So the interim meeting will cover the above topics.

 

Best wishes,

Phil & Yoshi.

 

--_000_13f21dcf2f1242398d2181afaf53d7c0rew09926dag03bdomain1sy_-- From nobody Tue Aug 11 05:18:25 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 14C9D1A8920 for ; Tue, 11 Aug 2015 05:18:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iwuq00IMDMRi for ; Tue, 11 Aug 2015 05:18:20 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B02C1A891E for ; Tue, 11 Aug 2015 05:18:20 -0700 (PDT) Received: by ykeo23 with SMTP id o23so164263440yke.3 for ; Tue, 11 Aug 2015 05:18:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=IHCZ+2yjgZqzDiS2Qcogldy93vrCyzPkE3rUgYnu91g=; b=bgzZaaWG4AqE2Wq0QZSEERXiPehyTPRTHQ5QK6cDaAnKUYsTnt9Rtoq+RApMPkQqXx P7WM+jDEBMjD7joDXNOGc+RqF49Ml75iZyeVusLIBn8XUlYof5h7LnOyY0rlI3ErDA5k qolyVpgyYuUoIFRvaaCbXIWBLqayHLTA4sN+3Z/IXrBvQVgSbai0vQ6IncUsMwHc4n0e AZsnSIJMMifJ52Z1/qNRVXtCUT8DVReZc5T1etWWDEfnPabgZTdhJoh6m+0vzKhw6Ue3 5ZmTpe7E4ippjIP+OdVoebFCcvlEZTQDeDKyczCFWVn2fUmJ4dEZwsI45fuC6GFVXBcP duig== MIME-Version: 1.0 X-Received: by 10.170.156.212 with SMTP id x203mr21998355ykc.125.1439295499981; Tue, 11 Aug 2015 05:18:19 -0700 (PDT) Received: by 10.129.146.206 with HTTP; Tue, 11 Aug 2015 05:18:19 -0700 (PDT) In-Reply-To: <20150810215248.GH9033@da0602a-dhcp119.apple.com> References: <20150804060828.GA14467@Chimay.local> <4B52CD65-B1B9-4F44-B152-0AE96471204B@gmail.com> <20150810215248.GH9033@da0602a-dhcp119.apple.com> Date: Tue, 11 Aug 2015 13:18:19 +0100 Message-ID: From: Alan Ford To: Christoph Paasch Content-Type: multipart/alternative; boundary=001a11395b9600d844051d08194d Archived-At: Cc: multipathtcp Subject: Re: [multipathtcp] q about addr id=0 issue in address management X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 12:18:23 -0000 --001a11395b9600d844051d08194d Content-Type: text/plain; charset=UTF-8 Hi Christoph, On 10 August 2015 at 22:52, Christoph Paasch wrote: > On 07/08/15 - 08:41:05, Alan Ford wrote: > > On 4 Aug 2015, at 07:08, Christoph Paasch wrote: > > > indeed, additional state has to be stored on a per-subflow basis to > make > > > sure that we are able to track the address-id. Storing this additional > state > > > is not a big deal in my opinion. > > > > Surely it's per-connection state not per-subflow? Identifying which of > your subflows has id=0 for this particular connection? > > For each subflows we have to store the local address-id that belongs to the > subflow's local IP-address. Thus, it's a per-subflow state. Why do you need an address ID for every subflow? You can use a global IP-to-ID mapping table in general, but each connection has a value that says that IP/ID foo is in fact ID 0 for this connection. > > The complexity comes rather from the handling of address-events in the > stack > > > as one has to take into account that the initial address does not need > to be > > > advertised again > > > ( > https://github.com/multipath-tcp/mptcp/blob/mptcp_v0.90/net/mptcp/mptcp_fullmesh.c#L1285 > ). > > > > I don't know the code here, but surely this test applies irrespective of > identifier? > > The code I linked is specific to the fact that address-ids of initial > subflows are 0. > > The problem is that we would otherwise announce the same address as the one > from the initial subflow, but with another address-id. From the peer's > point-of-view this then looks like a different address and he will try to > establish a subflow to this address. We will then end up with two subflows > that go over the same path. > > If the address-id of the initial subflow would be explicit, re-announcing > this address would not result in a duplicate subflow on the same path, > because the address-id is already known to the end-host, and thus he will > not try to establish yet another subflow to this IP. > Understood, and yes that is the intended behaviour when using id=0. Is this really a problem? It's a simple check! > If an address came back, how would you know it's the initial one and thus > should have id=0? Well, that's not actually a scenario I had considered so > far in general. The spec is not explicit as to whether the identifiers > should be the same if an interface is removed and later comes back. > > > > Would it add extra problems if, in that case, it was said that new > identifiers could be used? The main reason for the address identifier is > simply to identify subflow ends when the IP address may have bee changed by > a NAT. Plus, implying it would be the same adds extra semantics to an IP > address. If you moved networks, or from wifi to wired, but had the same IP > address, you may actually not want the far end to think it's the same. > > > > In this scenario I think you would be fine issuing a new address ID for > a new interface, even if the IP address is the same as the previously-lost > initial subflow. And then this would go away. I am happy to clarify this in > the spec if you don't think it would cause any additional implementation > issues? > > That's what we do in the implementation. If an address comes back up again, > it gets assigned a different address-id, irregardless of for what it has > been used in the past. > > Yes, from my point-of-view it is fine to clarify this in the spec. > Great thanks I will clarify that. Regards, Alan --001a11395b9600d844051d08194d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Christoph,

On 10 August 2015 at 22:52, Christoph Paasch <cpaasch@app= le.com> wrote:
On 07/08/15 - 08:41:05, Alan Ford wrote:
> On 4 Aug 2015, at 07:08, Christoph Paasch wrote:
> > indeed, additional state has to be stored on a per-subflow basis = to make
> > sure that we are able to track the address-id. Storing this addit= ional state
> > is not a big deal in my opinion.
>
> Surely it's per-connection state not per-subflow? Identifying whic= h of your subflows has id=3D0 for this particular connection?

For each subflows we have to store the local address-id that belongs= to the
subflow's local IP-address. Thus, it's a per-subflow state.

Why do you need an address ID for every subflow? Y= ou can use a global IP-to-ID mapping table in general, but each connection = has a value that says that IP/ID foo is in fact ID 0 for this connection.

> > The complexity comes rather from the handling of address-events i= n the stack
> > as one has to take into account that the initial address does not= need to be
> > advertised again
> > (h= ttps://github.com/multipath-tcp/mptcp/blob/mptcp_v0.90/net/mptcp/mptcp_full= mesh.c#L1285).
>
> I don't know the code here, but surely this test applies irrespect= ive of identifier?

The code I linked is specific to the fact that address-ids of initia= l
subflows are 0.

The problem is that we would otherwise announce the same address as the one=
from the initial subflow, but with another address-id. From the peer's<= br> point-of-view this then looks like a different address and he will try to establish a subflow to this address. We will then end up with two subflows<= br> that go over the same path.

If the address-id of the initial subflow would be explicit, re-announcing this address would not result in a duplicate subflow on the same path,
because the address-id is already known to the end-host, and thus he will not try to establish yet another subflow to this IP.
<= br>
Understood, and yes that is the intended behaviour when using= id=3D0.
=C2=A0
Is this really a problem? It's a si= mple check!

> If an address came back, how would you know it's the initial one a= nd thus should have id=3D0? Well, that's not actually a scenario I had = considered so far in general. The spec is not explicit as to whether the id= entifiers should be the same if an interface is removed and later comes bac= k.
>
> Would it add extra problems if, in that case, it was said that new ide= ntifiers could be used? The main reason for the address identifier is simpl= y to identify subflow ends when the IP address may have bee changed by a NA= T. Plus, implying it would be the same adds extra semantics to an IP addres= s. If you moved networks, or from wifi to wired, but had the same IP addres= s, you may actually not want the far end to think it's the same.
>
> In this scenario I think you would be fine issuing a new address ID fo= r a new interface, even if the IP address is the same as the previously-los= t initial subflow. And then this would go away. I am happy to clarify this = in the spec if you don't think it would cause any additional implementa= tion issues?

That's what we do in the implementation. If an address comes bac= k up again,
it gets assigned a different address-id, irregardless of for what it has been used in the past.

Yes, from my point-of-view it is fine to clarify this in the spec.

=C2=A0Great thanks I will clarify that.

Regards,
Alan

--001a11395b9600d844051d08194d-- From nobody Tue Aug 11 10:57:07 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 976A71ACE44; Tue, 11 Aug 2015 10:57:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.9 X-Spam-Level: X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 38dH2X_ul7wI; Tue, 11 Aug 2015 10:57:05 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D5411ACE2A; Tue, 11 Aug 2015 10:57:05 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF Announcement List" X-Test-IDTracker: no X-IETF-IDTracker: 6.4.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150811175705.8112.76734.idtracker@ietfa.amsl.com> Date: Tue, 11 Aug 2015 10:57:05 -0700 Archived-At: Cc: multipathtcp@ietf.org Subject: [multipathtcp] MPTCP WG Virtual Interim Meeting: 10 September 2015 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Reply-To: ietf@ietf.org List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 11 Aug 2015 17:57:06 -0000 The Multipath TCP (MPTCP) Working Group will hold a virtual interim meeting on Thursday, 10 September 2015, at 1500 UTC. The draft agenda is available at: http://trac.tools.ietf.org/wg/mptcp/trac/wiki/Interim_Sept_2015 Please see below for WebEx details. MPTCP Interim Thursday, September 10, 2015 3:00 pm | Greenwich Time (Reykjavik, GMT) | 1 hr 30 mins Join WebEx meeting: https://ietf.webex.com/ietf/j.php?MTID=me32504895c1b3424384f6232b0d4c58d Meeting number: 642 237 251 Meeting password: 1234 Join by phone 1-877-668-4493 Call-in toll free number (US/Canada) 1-650-479-3208 Call-in toll number (US/Canada) Access code: 642 237 251 Toll-free calling restrictions: http://www.webex.com/pdf/tollfree_restrictions.pdf Add this meeting to your calendar: https://ietf.webex.com/ietf/j.php?MTID=m58dcf6e3bb8a316d934bb501cb68e972 Can't join the meeting? Contact support: https://ietf.webex.com/ietf/mc IMPORTANT NOTICE: Please note that this WebEx service allows audio and other information sent during the session to be recorded, which may be discoverable in a legal matter. By joining this session, you automatically consent to such recordings. If you do not consent to being recorded, discuss your concerns with the host or do not join the session. From nobody Sun Aug 23 22:13:58 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B6E1B2F00 for ; Sun, 23 Aug 2015 22:13:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.915 X-Spam-Level: ** X-Spam-Status: No, score=2.915 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RELAY_IS_203=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mi69TPFDtSfN for ; Sun, 23 Aug 2015 22:13:56 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC8CF1B2EFF for ; Sun, 23 Aug 2015 22:13:56 -0700 (PDT) Received: from mail-ob0-f176.google.com (mail-ob0-f176.google.com [209.85.214.176]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 89DD9278099 for ; Mon, 24 Aug 2015 14:13:54 +0900 (JST) Received: by obbwr7 with SMTP id wr7so103797068obb.2 for ; Sun, 23 Aug 2015 22:13:52 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.39.194 with SMTP id r2mr20139622obk.20.1440393232992; Sun, 23 Aug 2015 22:13:52 -0700 (PDT) Received: by 10.202.195.136 with HTTP; Sun, 23 Aug 2015 22:13:52 -0700 (PDT) Date: Sun, 23 Aug 2015 22:13:52 -0700 Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: multipart/alternative; boundary=001a11c1d8d6fd52c9051e07aec2 Archived-At: Subject: [multipathtcp] discussions on draft-boucadair-mptcp-symmetric-02 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 05:13:58 -0000 --001a11c1d8d6fd52c9051e07aec2 Content-Type: text/plain; charset=UTF-8 Hello, There were several discussions on draft-boucadair-mptcp-symmetric-02.txt I am thinking that we're setting down on these two points. 1: Changing ADD_ADDR formats (replacing IPVer field by Flags field) seems to be a reasonable idea. 2: How to use the flags field seems to need more discussions as this is scarce resource. If this is acceptable for everyone, we can integrate 1: into 6824bis and continue discussions on the draft for the usage of the flags, etc. Please share if you have some thoughts on this. I guess this might be one topic for the interim. Thanks, -- Yoshi --001a11c1d8d6fd52c9051e07aec2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,
There were several discussions on draft-boucada= ir-mptcp-symmetric-02.txt=C2=A0
I am thinking that we're sett= ing down on these two points.

1: Changing ADD_ADDR= formats (replacing IPVer field by Flags field) seems to be a reasonable id= ea.

2: How to use the flags field seems to need mo= re discussions as this is scarce resource.

If this= is acceptable for everyone, we can integrate 1: into 6824bis and continue = discussions on the draft for the usage of the flags, etc.
Please share if you have some thoughts on this.=C2=A0
I guess this might be one topic for the interim.

= Thanks,
--
Yoshi
--001a11c1d8d6fd52c9051e07aec2-- From nobody Sun Aug 23 22:14:28 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6C4181B2F01; Sun, 23 Aug 2015 22:14:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.514 X-Spam-Level: * X-Spam-Status: No, score=1.514 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, RCVD_IN_DNSWL_LOW=-0.7, RELAY_IS_203=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mtbG5vG3sd1A; Sun, 23 Aug 2015 22:14:26 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B9421B2EFF; Sun, 23 Aug 2015 22:14:26 -0700 (PDT) Received: from mail-ob0-f171.google.com (mail-ob0-f171.google.com [209.85.214.171]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 2F66627809A; Mon, 24 Aug 2015 14:14:25 +0900 (JST) Received: by obbwr7 with SMTP id wr7so103804138obb.2; Sun, 23 Aug 2015 22:14:23 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.107.233 with SMTP id hf9mr19957774obb.35.1440393263983; Sun, 23 Aug 2015 22:14:23 -0700 (PDT) Received: by 10.202.195.136 with HTTP; Sun, 23 Aug 2015 22:14:23 -0700 (PDT) In-Reply-To: <20150706131640.19378.74279.idtracker@ietfa.amsl.com> References: <20150706131640.19378.74279.idtracker@ietfa.amsl.com> Date: Sun, 23 Aug 2015 22:14:23 -0700 Message-ID: From: Yoshifumi Nishida To: internet-drafts@ietf.org Content-Type: text/plain; charset=UTF-8 Archived-At: Cc: multipathtcp , i-d-announce@ietf.org Subject: Re: [multipathtcp] I-D Action: draft-ietf-mptcp-experience-02.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Aug 2015 05:14:27 -0000 Hi, Sorry for my slow response. I have read the updated draft and I think the draft addressed many of comments I made. Thank you so much! My very small remaining comment on the draft is I prefer to put "M_" state for the state of mptcp in Section 3.6. I personally don't have more comments on the draft, but if someone (especially who have real deployment experiences) has some comments, please share. Regards, -- Yoshi On Mon, Jul 6, 2015 at 6:16 AM, 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 : Use Cases and Operational Experience with Multipath TCP > Authors : Olivier Bonaventure > Christoph Paasch > Gregory Detal > Filename : draft-ietf-mptcp-experience-02.txt > Pages : 24 > Date : 2015-07-06 > > Abstract: > This document discusses both use cases and operational experience > with Multipath TCP in real world networks. It lists several > prominent use cases for which Multipath TCP has been considered and > is being used. It also gives insight to some heuristics and > decisions that have helped to realize these use cases. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-mptcp-experience/ > > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-ietf-mptcp-experience-02 > > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=draft-ietf-mptcp-experience-02 > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Mon Aug 24 00:53:30 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B6F61A89B9 for ; Mon, 24 Aug 2015 00:53:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SEtWR5vOE_N4 for ; Mon, 24 Aug 2015 00:53:26 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 610F21A89A1 for ; Mon, 24 Aug 2015 00:53:26 -0700 (PDT) Received: from mbpobo.dhcp.info.ucl.ac.be (mbpobo.dhcp.info.ucl.ac.be [130.104.228.16]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 559DB183481; Mon, 24 Aug 2015 09:53:19 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 559DB183481 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1440402799; bh=BEht3KTptG3snSxAsL4fd0dc7oPMAAZWS44ycNdp84A=; h=Reply-To:Subject:References:To:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=D8O/ocD8z5VM5yicObV+5Jc9lZr/awtnIpUSU1Im6ugxMnH4wGdnLHO+D42K5MB7Z p+gag6Wl2K30q6MigFJJXDrdW7D/lLvhEYscqQfTjdlo2RcsjFfrMALHlJUibrmJ9d Fkmg+x72pFho6AQC7uXMKhEZeZ80/z5dx3MZ++xE= References: To: Yoshifumi Nishida , multipathtcp From: Olivier Bonaventure Message-ID: <55DACD75.1040106@uclouvain.be> Date: Mon, 24 Aug 2015 09:53:25 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99-beta1 at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 559DB183481.A0EE8 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Subject: Re: [multipathtcp] discussions on draft-boucadair-mptcp-symmetric-02 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 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: Mon, 24 Aug 2015 07:53:28 -0000 Yoshifumi, > There were several discussions on draft-boucadair-mptcp-symmetric-02.txt > I am thinking that we're setting down on these two points. > > 1: Changing ADD_ADDR formats (replacing IPVer field by Flags field) > seems to be a reasonable idea. I fully support this > 2: How to use the flags field seems to need more discussions as this is > scarce resource. There are several possibly utilisations of these flags beyond draft-boucadair-mptcp-symmetric-02.txt - one flag could be used to indicate that an address is announced as a backup address, i.e. an address that if it is used will lead to a backup sufblow - one flag could be used as an "echo" flag to enable a host to confirm the reception of an ADD_ADDR by echoing it. However, while providing reliable delivery of ADD_ADDR would be useful in some lossy scenarios, this also increases the complexity of the implementation on the host that sends the ADD_ADDR > > If this is acceptable for everyone, we can integrate 1: into 6824bis and > continue discussions on the draft for the usage of the flags, etc. I agree Olivier From nobody Mon Aug 31 23:42:11 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AB891B84C3 for ; Mon, 31 Aug 2015 23:42:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.806 X-Spam-Level: X-Spam-Status: No, score=-0.806 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zi7UaPFIxk7I for ; Mon, 31 Aug 2015 23:42:08 -0700 (PDT) Received: from gpo3.cc.swin.edu.au (gpo3.cc.swin.edu.au [136.186.1.32]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C19C1B84C0 for ; Mon, 31 Aug 2015 23:42:07 -0700 (PDT) Received: from [136.186.242.243] (vpn242-243.cc.swin.edu.au [136.186.242.243]) by gpo3.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id t816g4F4003396 for ; Tue, 1 Sep 2015 16:42:05 +1000 To: multipathtcp@ietf.org From: Nigel Williams Message-ID: <55E548BC.70505@swin.edu.au> Date: Tue, 1 Sep 2015 16:42:04 +1000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Subject: [multipathtcp] Multipath TCP for FreeBSD v0.5 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Sep 2015 06:42:10 -0000 Hi, A new mptcp v0.5 patch is available at http://caia.swin.edu.au/urp/newtcp/mptcp/tools.html. This release represents a near-complete rewrite of the v0.4 implementation and as such there have been a large number of changes (see [1] and [2]). The patch applies against r285254 of FreeBSD-HEAD. Current functionality is slightly advanced of the previous patch, though the new code base should allow for an increased rate of improvement over the next few months. I'm hoping to keep to release incremental updates on a more regular basis over this time period. Along with the patch there are also pre-configured VMs and a pre-built kernel binary available for download, for those who want to try it out without going through the patching/building process. There is also a set of scripts that demonstrate some basic multi-path connections. The patch is still under heavy development and testing so consider this release code to be of alpha quality (expect bugs/panics etc). Currently it supports MPTCP for FreeBSD-to-FreeBSD connections only. Feedback re bugs encountered or suggestions on code/design improvements is welcome. To come in the near future: - A public-facing source repository - A report that details the design of the current implementation This work has been made possible in part by grants from the FreeBSD Foundation, and The Cisco University Research Program Fund at Community Foundation Silicon Valley. cheers, nigel [1] http://caia.swin.edu.au/urp/newtcp/mptcp/tools/v05/mptcp-readme-v0.5.txt [2] http://caia.swin.edu.au/urp/newtcp/mptcp/tools/v05/mptcp-changelog-v0.5.txt