From nobody Wed Sep 2 02:04:51 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 8095D1B43FB for ; Wed, 2 Sep 2015 02:04:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.611 X-Spam-Level: X-Spam-Status: No, score=-4.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_I_INVITATION=-2, 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 T5XPdE6lxlVJ for ; Wed, 2 Sep 2015 02:04:48 -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 ABFC01B4E32 for ; Wed, 2 Sep 2015 02:04:47 -0700 (PDT) Received: from E07HT03-UKBR.domain1.systemhost.net (193.113.197.161) by EVMED03-UKBR.bt.com (10.216.161.33) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 2 Sep 2015 10:04:42 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by E07HT03-UKBR.domain1.systemhost.net (193.113.197.161) with Microsoft SMTP Server (TLS) id 8.3.342.0; Wed, 2 Sep 2015 10:04:45 +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; Wed, 2 Sep 2015 10:04:44 +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; Wed, 2 Sep 2015 10:04:44 +0100 From: To: Thread-Topic: [Recentattendees] IETF 94 - Hackathon Information Thread-Index: AQHQ5DWWhA9HKCavBUu1wJYn+ikf3Z4o9DFA Date: Wed, 2 Sep 2015 09:04:44 +0000 Message-ID: <7ace2f37071e4a33b0280075c0ea2f5b@rew09926dag03b.domain1.systemhost.net> References: <20150831213752.32696.81837.idtracker@ietfa.amsl.com> In-Reply-To: <20150831213752.32696.81837.idtracker@ietfa.amsl.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: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [multipathtcp] FW: [Recentattendees] IETF 94 - Hackathon Information 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, 02 Sep 2015 09:04:50 -0000 Q2ZpIC0gaXMgYW55b25lIGludGVyZXN0ZWQgaW4gdGFraW5nIHBhcnQgaW4gdGhlIFlva29oYW1h IGhhY2thdGhvbj8NCg0KLS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFJlY2VudGF0 dGVuZGVlcyBbbWFpbHRvOnJlY2VudGF0dGVuZGVlcy1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhh bGYgT2YgSUVURiBTZWNyZXRhcmlhdA0KU2VudDogMzEgQXVndXN0IDIwMTUgMjI6MzgNClRvOiBJ RVRGIEFubm91bmNlbWVudCBMaXN0DQpDYzogcmVjZW50YXR0ZW5kZWVzQGlldGYub3JnOyBpZXRm QGlldGYub3JnOyA5NGFsbEBpZXRmLm9yZzsgaGFja2F0aG9uQGlldGYub3JnDQpTdWJqZWN0OiBb UmVjZW50YXR0ZW5kZWVzXSBJRVRGIDk0IC0gSGFja2F0aG9uIEluZm9ybWF0aW9uDQoNCklFVEYg OTQgSGFja2F0aG9uDQoNClRoZSBJbnRlcm5ldCBFbmdpbmVlcmluZyBUYXNrIEZvcmNlIChJRVRG KSBpcyBob2xkaW5nIGEgSGFja2F0aG9uIGF0IElFVEYgOTQgdG8gZW5jb3VyYWdlIGRldmVsb3Bl cnMgdG8gZGlzY3VzcywgY29sbGFib3JhdGUgYW5kIGRldmVsb3AgdXRpbGl0aWVzLCBpZGVhcywg c2FtcGxlIGNvZGUgYW5kIHNvbHV0aW9ucyB0aGF0IHNob3cgcHJhY3RpY2FsIGltcGxlbWVudGF0 aW9ucyBvZiBJRVRGIHN0YW5kYXJkcy4gIA0KDQpXaGVuOiBTYXR1cmRheSBPY3RvYmVyIDMxIGFu ZCBTdW5kYXkgTm92ZW1iZXIgMQ0KV2hlcmU6IFBhY2lmaWNvIFlva29oYW1hLCBSb29tIFRCRA0K U3BvbnNvcmVkIEJ5OiBDaXNjbyBEZXZOZXQNClNpZ251cCBmb3IgdGhlIEhhY2thdGhvbjogaHR0 cHM6Ly93d3cuaWV0Zi5vcmcvcmVnaXN0cmF0aW9uL2lldGY5NC9oYWNrYXRob25yZWdpc3RyYXRp b24ucHkNCk1vcmUgaW5mb3JtYXRpb24gY2FuIGJlIGZvdW5kIGhlcmU6IGh0dHA6Ly9pZXRmLm9y Zy9oYWNrYXRob24vOTQtaGFja2F0aG9uLmh0bWwNCktlZXAgdXAgdG8gZGF0ZSBieSBzdWJzY3Jp YmluZyB0bzogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9oYWNrYXRob24N Cg0KVGhlIEhhY2thdGhvbiBpcyBmcmVlIHRvIGF0dGVuZCBhbmQgb3BlbiB0byBhbGwuIEV4dGVu ZCB0aGUgaW52aXRhdGlvbiB0byBjb2xsZWFndWVzIG91dHNpZGUgdGhlIElFVEYhIA0KDQpIZXJl 4oCZcyB3aGF0IGhhcHBlbmVkIGF0IHRoZSBIYWNrYXRob24gaW4gUHJhZ3VlIGF0IElFVEYgOTM6 DQpCbG9nOiAgaHR0cHM6Ly9jb21tdW5pdGllcy5jaXNjby5jb20vY29tbXVuaXR5L2RldmVsb3Bl ci9vcGVuc291cmNlL2Jsb2cvMjAxNS8wOC8wMw0KVmlkZW86ICBodHRwczovL3d3dy55b3V0dWJl LmNvbS93YXRjaD92PWVtWi1wSUpMRGxnJmZlYXR1cmU9eW91dHUuYmUNCg0KQ3VycmVudGx5IHRo ZSB0ZWNobm9sb2dpZXMgdGhhdCB3aWxsIGJlIGZvY3VzZWQgb24gYXQgdGhlIElFVEYgOTQgSGFj a2F0aG9uIGluY2x1ZGU6DQoqIERIQ1AgNG82DQoqIEkyUlMNCiogSUNFDQoqIE5FVFZDDQoqIFNG Qw0KDQpEZXNjcmlwdGlvbnMgYW5kIGluZm9ybWF0aW9uIHJlZ2FyZGluZyB0aGUgdGVjaG5vbG9n aWVzIGZvciB0aGUgaGFja2F0aG9uIGFyZSBsb2NhdGVkIG9uIHRoZSBJRVRGIDk0IE1lZXRpbmcg V2lraTogDQpodHRwczovL3d3dy5pZXRmLm9yZy9yZWdpc3RyYXRpb24vTWVldGluZ1dpa2kvd2lr aS85NGhhY2thdGhvbg0KDQpEb27igJl0IHNlZSBhbnl0aGluZyB0aGF0IGludGVyZXN0cyB5b3U/ IEZlZWwgZnJlZSB0byBhZGQgeW91ciBwcmVmZXJyZWQgdGVjaG5vbG9neSB0byB0aGUgbGlzdCwg c2lnbiB1cCBhcyBpdHMgQ2hhbXBpb24gYW5kIHNob3cgdXAgdG8gd29yayBvbiBpdC4gTm90ZTog eW91IG11c3QgbG9naW4gdG8gdGhlIHdpa2kgdG8gYWRkIGNvbnRlbnQuIElmIHlvdSBkbyBhZGQg YSBuZXcgdGVjaG5vbG9neSwgd2Ugc3Ryb25nbHkgc3VnZ2VzdCB0aGF0IHlvdSBzZW5kIGFuIGVt YWlsIHRvIGhhY2thdGhvbkBpZXRmLm9yZyB0byBsZXQgb3RoZXJzIGtub3cuIFlvdSBtYXkgZ2Vu ZXJhdGUgaW50ZXJlc3QgaW4geW91ciB0ZWNobm9sb2d5LCBhbmQgZmluZCBvdGhlciBwZW9wbGUg d2hvIHdhbnQgdG8gY29udHJpYnV0ZSB0byBpdC4NCg0KQmUgYSBDaGFtcGlvbiEgIFNlZTogIGh0 dHA6Ly9pZXRmLm9yZy9oYWNrYXRob24vOTQtaGFja2F0aG9uLmh0bWwNCg0KVG8gcmVxdWVzdCBh IHdpa2kgYWNjb3VudCwgcGxlYXNlIGNsaWNrIG9uIHRoZSDigJxsb2dpbuKAnSBidXR0b24gb24g dGhlIGJvdHRvbSByaWdodCBjb3JuZXIgb2YgdGhlIHBhZ2UsIGFuZCBjaG9vc2Ug4oCccmVnaXN0 ZXIu4oCdIElmIHlvdSBuZWVkIGEgbmV3IHBhc3N3b3JkIHBsZWFzZSBjbGljayBvbiB0aGUg4oCc bG9naW7igJ0gYnV0dG9uIG9uIHRoZSBib3R0b20gcmlnaHQgY29ybmVyIG9mIHRoZSBwYWdlIGFu ZCBjaG9vc2Ug4oCcU2VuZCBuZXcgcGFzc3dvcmQu4oCdDQoNClRoZSBJRVRGIGlzIHNlZWtpbmcg SGFja2F0aG9uIHNwb25zb3JzIGZvciBJRVRGIDk1IGFuZCBiZXlvbmQuIElmIHlvdSBhcmUgaW50 ZXJlc3RlZCBpbiBtb3JlIGluZm9ybWF0aW9uLCBwbGVhc2UgY29udGFjdCBEcmV3IER2b3JzaGFr IGF0IGR2b3JzaGFrQGlzb2Mub3JnDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fDQpSZWNlbnRhdHRlbmRlZXMgbWFpbGluZyBsaXN0DQpSZWNlbnRhdHRl bmRlZXNAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vcmVj ZW50YXR0ZW5kZWVzDQo= From nobody Wed Sep 2 06:24:52 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 5EE631B31C6 for ; Wed, 2 Sep 2015 06:24:51 -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 19kElR4NBwPi for ; Wed, 2 Sep 2015 06:24:49 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7886C1B31A5 for ; Wed, 2 Sep 2015 06:24:48 -0700 (PDT) Received: from E07HT04-UKBR.domain1.systemhost.net (193.113.197.162) by EVMED05-UKBR.bt.com (10.216.161.37) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 2 Sep 2015 14:24:41 +0100 Received: from rew09926dag03c.domain1.systemhost.net (10.55.202.26) by E07HT04-UKBR.domain1.systemhost.net (193.113.197.162) with Microsoft SMTP Server (TLS) id 8.3.342.0; Wed, 2 Sep 2015 14:24: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; Wed, 2 Sep 2015 14:24:44 +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; Wed, 2 Sep 2015 14:24:44 +0100 From: To: Thread-Topic: Preparing for the MPTCP interim Thread-Index: AdDlf2e8hmJOGWBxQk+M9b3EIwPDvw== Date: Wed, 2 Sep 2015 13:24:43 +0000 Message-ID: <7344a0ae9fb040268f68495bd0eff0fd@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_7344a0ae9fb040268f68495bd0eff0fdrew09926dag03bdomain1sy_" MIME-Version: 1.0 Archived-At: Subject: [multipathtcp] Preparing for the MPTCP interim 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, 02 Sep 2015 13:24:51 -0000 --_000_7344a0ae9fb040268f68495bd0eff0fdrew09926dag03bdomain1sy_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQpXZSBoYXZlIHRoZSBNUFRDUCBXRyBpbnRlcmltIG1lZXRpbmcgbmV4dCB3ZWVrLiBodHRw czovL3Rvb2xzLmlldGYub3JnL3dnL21wdGNwL3RyYWMvd2lraS9JbnRlcmltX1NlcHRfMjAxNQ0K DQpTbyBmYXIgd2UgaGF2ZSB0aGUgZm9sbG93aW5nIGl0ZW1zIG9uIHRoZSBhZ2VuZGE6DQoNCiog TVBUQ1AgcHJveHkgLSBYaW5wZW5nIFdlaQ0KKiBVc2luZyBNUFRDUCBmb3IgY2hhbm5lbCBjb21i aW5pbmcgZm9yIE5BU0EgcHJvamVjdCAtIFdpbGxpYW0gSXZhbmNpYw0KKiBEZXBsb3ltZW50IHVz ZSBjYXNlcyAtIEEuUGFsYW5pdmVsYW4NCg0KWGlucGVuZyDigJMgZG8geW91IHdhbnQgYSB0aW1l c2xvdCwgb3Igd2FzIHRoZXJlIGVub3VnaCBkaXNjdXNzaW9uIGluIFByYWd1ZT8NCldpbGxpYW0s IEEuUGFsYW5pdmVsYW4g4oCTIHBsZWFzZSBjb25maXJtIHRoYXQgeW914oCZbGwgYmUgcHJlc2Vu dGluZy4NCg0KVGhlcmUgc2hvdWxkIGJlIHBsZW50eSBvZiB0aW1lIGZvciBzb21lIGRpc2N1c3Np b24gb24gb3RoZXIgdG9waWNzLiBTbyBmYXIgd2UgZ290IHRoZSBmb2xsb3dpbmcgcmVxdWVzdHMg ZnJvbSBDaHJpc3RvcGggUGFhc2NoOg0K4oCiZHJhZnQtcGFhc2NoLW1wdGNwLXN5bmNvb2tpZXMN CuKAok1QVENQJ3MgdXNlIGJlaGluZCBsYXllci00IGxvYWRiYWxhbmNlcnMgaW4gc2VydmVyIGZh cm1zIOKAkyBkcmFmdCBzb29uDQoNCk1lZCDigJMgZG8geW91IHdhbnQgYW55IGFnZW5kYSB0aW1l IHRvIGRpc2N1c3MgYW55IG9mIHRoZSBkcmFmdC1ib3VjYWRhaXItbXB0Y3AteHh4IGRyYWZ0cz8N Cg0KV2Ugc2hvdWxkIGFsc28gcmVzb2x2ZSBhbnkgb3RoZXIgb3BlbiBpc3N1ZXMg4oCTIHBsZWFz ZSBsZXQgdXMga25vdyBpZiB0aGVyZSBhcmUgYW55IG90aGVyIG9uZXM6DQrigKJ3ZSBoYXZlIGNv bnNlbnN1cyB0byBhZGQgYW4gZXhwZXJpbWVudGFsIE1QVENQIG9wdGlvbiB0byB0aGUgcHJvdG9j b2wgYmlzIFtzZWUg4oCLaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYm9u YXZlbnR1cmUtbXB0Y3AtZXhwLW9wdGlvbi9dLiBCdXQgd2UgaGF2ZSB0aGUgcXVlc3Rpb24gd2hl dGhlciBpdCBzaG91bGQgYmUgOCBvciAxNiBiaXRzLg0KDQpUaGUgT3BlcmF0aW9uYWwgZXhwZXJp ZW5jZSBkcmFmdCBpcyBub3cgZXhpdGluZyB0aGUgV0cgaW50byBJRVNHLCBzbyB3ZSBjYW4gbm93 IGFsc28gcHJvZ3Jlc3MgdGhlIHByb3RvY29sIGJpcyBkb2N1bWVudC4gU28gaWYgdGhlcmXigJlz IGFueXRoaW5nIGVsc2UgdGhhdCB5b3UgdGhpbmsgbmVlZHMgYWRkaW5nIHRvIHRoZSBwcm90b2Nv bCBiaXMsIHRoZSBpbnRlcmltIG1lZXRpbmcgd291bGQgYmUgYSBnb29kIHRpbWUgdG8gZGlzY3Vz cyB0aGlzLg0KDQpUaGFua3MNClBoaWwgJiBZb3NoaS4NCg== --_000_7344a0ae9fb040268f68495bd0eff0fdrew09926dag03bdomain1sy_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWls eToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0KCWZvbnQtd2VpZ2h0 Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25l O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1m YXJlYXN0LWxhbmd1YWdlOkVOLVVTO30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjYxMi4w cHQgNzkyLjBwdDsNCgltYXJnaW46NzIuMHB0IDcyLjBwdCA3Mi4wcHQgNzIuMHB0O30NCmRpdi5X b3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0 ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEw MjYiIC8+DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNo YXBlbGF5b3V0IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAv Pg0KPC9vOnNoYXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFu Zz0iRU4tR0IiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNl Y3Rpb24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPldlIGhhdmUgdGhlIE1QVENQIFdHIGludGVyaW0gbWVldGluZyBu ZXh0IHdlZWsuDQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL3dnL21wdGNwL3RyYWMv d2lraS9JbnRlcmltX1NlcHRfMjAxNSI+aHR0cHM6Ly90b29scy5pZXRmLm9yZy93Zy9tcHRjcC90 cmFjL3dpa2kvSW50ZXJpbV9TZXB0XzIwMTU8L2E+DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48bzpwPiZuYnNw OzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij5TbyBmYXIgd2UgaGF2ZSB0aGUgZm9sbG93aW5nIGl0ZW1zIG9uIHRoZSBhZ2Vu ZGE6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7 c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+KiBNUFRDUCBwcm94eSAtIFhp bnBlbmcgV2VpDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4qIFVzaW5nIE1QVENQIGZvciBjaGFubmVsIGNvbWJp bmluZyBmb3IgTkFTQSBwcm9qZWN0IC0gV2lsbGlhbSBJdmFuY2ljDQo8bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4q IERlcGxveW1lbnQgdXNlIGNhc2VzIC0gQS5QYWxhbml2ZWxhbjxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2Zv bnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPlhpbnBlbmcg4oCTIGRvIHlvdSB3YW50IGEgdGltZXNsb3QsIG9yIHdh cyB0aGVyZSBlbm91Z2ggZGlzY3Vzc2lvbiBpbiBQcmFndWU/PG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+V2lsbGlh bSwgQS5QYWxhbml2ZWxhbiDigJMgcGxlYXNlIGNvbmZpcm0gdGhhdCB5b3XigJlsbCBiZSBwcmVz ZW50aW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoZXJlIHNob3VsZCBi ZSBwbGVudHkgb2YgdGltZSBmb3Igc29tZSBkaXNjdXNzaW9uIG9uIG90aGVyIHRvcGljcy4gU28g ZmFyIHdlIGdvdCB0aGUgZm9sbG93aW5nIHJlcXVlc3RzIGZyb20gQ2hyaXN0b3BoIFBhYXNjaDo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5z LXNlcmlmJnF1b3Q7Ij7igKJkcmFmdC1wYWFzY2gtbXB0Y3Atc3luY29va2llczxvOnA+PC9vOnA+ PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6 MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVv dDsiPuKAok1QVENQJ3MgdXNlIGJlaGluZCBsYXllci00IGxvYWRiYWxhbmNlcnMgaW4gc2VydmVy IGZhcm1zIOKAkyBkcmFmdCBzb29uICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPk1lZCDigJMgZG8geW91IHdhbnQgYW55IGFnZW5kYSB0aW1lIHRvIGRpc2N1c3MgYW55 IG9mIHRoZSBkcmFmdC1ib3VjYWRhaXItbXB0Y3AteHh4IGRyYWZ0cz88bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5XZSBzaG91bGQgYWxzbyByZXNvbHZlIGFueSBvdGhlciBvcGVu IGlzc3VlcyDigJMgcGxlYXNlIGxldCB1cyBrbm93IGlmIHRoZXJlIGFyZSBhbnkgb3RoZXIgb25l czo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtz YW5zLXNlcmlmJnF1b3Q7Ij7igKJ3ZSBoYXZlIGNvbnNlbnN1cyB0byBhZGQgYW4gZXhwZXJpbWVu dGFsIE1QVENQIG9wdGlvbiB0byB0aGUgcHJvdG9jb2wgYmlzIFtzZWUg4oCLaHR0cHM6Ly9kYXRh dHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYm9uYXZlbnR1cmUtbXB0Y3AtZXhwLW9wdGlvbi9d LiBCdXQgd2UgaGF2ZSB0aGUgcXVlc3Rpb24NCiB3aGV0aGVyIGl0IHNob3VsZCBiZSA4IG9yIDE2 IGJpdHMuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g c3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1 b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhlIE9wZXJhdGlvbmFs IGV4cGVyaWVuY2UgZHJhZnQgaXMgbm93IGV4aXRpbmcgdGhlIFdHIGludG8gSUVTRywgc28gd2Ug Y2FuIG5vdyBhbHNvIHByb2dyZXNzIHRoZSBwcm90b2NvbCBiaXMgZG9jdW1lbnQuIFNvIGlmIHRo ZXJl4oCZcyBhbnl0aGluZyBlbHNlIHRoYXQgeW91IHRoaW5rIG5lZWRzIGFkZGluZw0KIHRvIHRo ZSBwcm90b2NvbCBiaXMsIHRoZSBpbnRlcmltIG1lZXRpbmcgd291bGQgYmUgYSBnb29kIHRpbWUg dG8gZGlzY3VzcyB0aGlzLiA8bzpwPg0KPC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRo YW5rczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPlBoaWwgJmFtcDsgWW9zaGkuDQo8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_7344a0ae9fb040268f68495bd0eff0fdrew09926dag03bdomain1sy_-- From nobody Thu Sep 3 11:41:02 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 174581B3438 for ; Thu, 3 Sep 2015 11:41:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 5iy9_7drNIls for ; Thu, 3 Sep 2015 11:40:59 -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 84E981ACD85 for ; Thu, 3 Sep 2015 11:40:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1441305659; x=2305219259; 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=yBwZIFpy+5E2pMILfGZEi1kCsv8b4WqvpjQBGPcwd2k=; b=XVw+J5tfEl+6Ja3unBz0lvezaM2rKxInBg0kjZh3SJlqsPT33Ftv7e93FimRJWoQ 25HRAu0GE4VgDHSxztYIvtO2El3pz0CLDqSxB64dJXTaJcOMl36TmeLYUzzPURgT NPGup/FOQAbJQziifGeQsm1En0yQu77sOYi9P6aZygoyieoVj+MqHqGD7yUeMl5V K+WVNUgIehtiXd26/ryKZ9KLOEqTCSe9JeJ3BxgMRs/qdeWsP5JSiZUu/ZFujXjE lqXfaBLff71W/0Hhrcj0EA8FeIQwuHq7uqjnnTyTc1gX7907dEO7e2567go06jjB Wa5g7otmsYqEBQ/utPQWJg==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 30.03.24160.A3498E55; Thu, 3 Sep 2015 11:40:58 -0700 (PDT) X-AuditID: 11973e15-f79cb6d000005e60-8b-55e8943a91e2 Received: from cardamom.apple.com (cardamom.apple.com [17.128.115.94]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id F5.8C.14452.7C588E55; Thu, 3 Sep 2015 10:39:20 -0700 (PDT) Received: from localhost ([17.226.23.154]) by cardamom.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NU4002W76KAIJ40@cardamom.apple.com> for multipathtcp@ietf.org; Thu, 03 Sep 2015 11:40:58 -0700 (PDT) Sender: cpaasch@apple.com Date: Thu, 03 Sep 2015 11:40:57 -0700 From: Christoph Paasch To: MultiPath WG Message-id: <20150903184057.GP40993@da0602a-dhcp154.apple.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprJLMWRmVeSWpSXmKPExsUi2FAYpWs15UWowc+zNhafV19nc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxonjcxkLXgtX7Lt6g6mB8Tp/FyMnh4SAicTN9yfZIWwxiQv3 1rN1MXJxCAnsZZT4ueMsM0zRlAWzWSESE5kkjiz9ywKSEBLoZpI4eUobxBYWkJTovnMHrIFF QFXiyMdpTCA2m4CWxNvb7awgtoiAhsTttuVMEPX+EtNm7ALbzCtgJ3F79yxWCFtQ4sfke2Dz mYF61+88zgRhS0s8+jsDrF5UQEXiyoS3UFf/ZJW4saR4AqPgLCTts5C0z0LSvoCReRWjUG5i Zo5uZp6ZXmJBQU6qXnJ+7iZGUFhOtxPdwXhmldUhRgEORiUe3omzn4cKsSaWFVfmHmKU5mBR Eued2wYUEkhPLEnNTk0tSC2KLyrNSS0+xMjEwSnVwOhunrb9X7Dxr3xxRpZvB3vmPG7atOW3 rtve4FKn9peG5hX/g92m3LgpNDUoXL3l666Ch19mBs7Z5fyt54Fgh+z3oryYv/4b/WabahqU M816/mC38PF9x7YHRNyx89i/rOR6ixybIEP87vcLbOYeaL5Z7/wv+IJi+hFu88/L2KfHPlTS 9d68/aESS3FGoqEWc1FxIgBJ9gMbLAIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUi2FAcp3ui9UWowY/JLBafV19nc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxonjcxkLXgtX7Lt6g6mB8Tp/FyMnh4SAicSUBbNZIWwxiQv3 1rN1MXJxCAlMZJI4svQvC0hCSKCbSeLkKW0QW1hAUqL7zh1mEJtFQFXiyMdpTCA2m4CWxNvb 7WCDRAQ0JG63LWeCqPeXmDZjFzuIzStgJ3F79yxWCFtQ4sfke2DzmYF61+88zgRhS0s8+jsD rF5UQEXiyoS37BMY+WYhaZmFpGUWkpYFjMyrGAWKUnMSK830EgsKclL1kvNzNzGCA6kwagdj w3KrQ4wCHIxKPLwNvc9DhVgTy4orcw8xSnAwK4nw7ml/ESrEm5JYWZValB9fVJqTWnyIMRno yYnMUqLJ+cAgzyuJNzQxMTAxNjYzNjY3MSdNWEmcd0450FaB9MSS1OzU1ILUIpgtTBycUg2M 2Y+7DmyewM/xoTTul3T723dT59h7N5jZ7/j3rC6L8e/teRWajferOotnvuHRvteSK53Y679n yUWx+XeP7/eI2S6hudnJli9MaJaP5esPgV//sZ63etX/65mfR8zEq87f514pnsv4yu6Kdnbw 9gVHd9ROSamwNdg+j/2Xn4tCUH2RS2f5IfMaJZbijERDLeai4kQA3KinwWgCAAA= Archived-At: Subject: [multipathtcp] Fwd: New Version Notification for draft-paasch-mptcp-syncookies-01.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: Thu, 03 Sep 2015 18:41:01 -0000 Hello, we updated our SYN-cookies draft. The biggest modification is that the reliable MP_CAPABLE in the third ack enables us to remove the client's key from the SYN-segment. This reduces the size of the MP_CAPABLE option down to 4 bytes, opening the door to future extensions to TCP. We believe that this is a major improvement to MPTCP. We will present this draft during the interim meeting. (thanks to Olivier & Alan for their comments and suggestions on this draft) Cheers, Christoph ----- Forwarded message from internet-drafts@ietf.org ----- From: internet-drafts@ietf.org To: Anumita Biswas , Darren Haas , Anumita Biswas , Christoph Paasch , Darren Haas , Christoph Paasch Date: Thu, 03 Sep 2015 11:33:02 -0700 Subject: New Version Notification for draft-paasch-mptcp-syncookies-01.txt A new version of I-D, draft-paasch-mptcp-syncookies-01.txt has been successfully submitted by Christoph Paasch and posted to the IETF repository. Name: draft-paasch-mptcp-syncookies Revision: 01 Title: Making Multipath TCP robust for stateless webservers Document date: 2015-09-03 Group: Individual Submission Pages: 11 URL: https://www.ietf.org/id/draft-paasch-mptcp-syncookies-01.txt Status: https://datatracker.ietf.org/doc/draft-paasch-mptcp-syncookies/ Htmlized: https://tools.ietf.org/html/draft-paasch-mptcp-syncookies-01 Diff: https://www.ietf.org/rfcdiff?url2=draft-paasch-mptcp-syncookies-01 Abstract: This document proposes a modification of the MPTCP handshake that allows it to work efficiently with stateless servers. We first identify the issues around stateless connection establishment using SYN-cookies. Further, we suggest an extension to Multipath TCP to overcome these issues and discuss alternatives. As a side-effect, the proposed modification to the handshake opens the door to reduce the size of the MP_CAPABLE option in the SYN. This reduces the growing pressure on the TCP-option space in the SYN- segment, giving space for future extensions to TCP. 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. The IETF Secretariat ----- End forwarded message ----- From nobody Mon Sep 7 20:56:01 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 338981A1B00 for ; Mon, 7 Sep 2015 20:56:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 UULk5s4V5wnp for ; Mon, 7 Sep 2015 20:55:58 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B43411A1B0E for ; Mon, 7 Sep 2015 20:55:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1441684557; x=2305598157; 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=85qGhA3keOX/tWbfOGJ1Bb06M553bcwfwSNZdSUTspo=; b=wAM7YcfkzNgvII37nGuS71Gx2kBzQFrGj6iIMwzadA0/FFK3IBr23lEsRtj70Dfv Ik/6hZKAHb1qT2MKEllMfHF1izDZFopC1S/zE7bwv0OBDiAs+7sx/5Wi8LO9RZgo IU16Rw1hYsrvUDFIJlql8B7yyifzUOVH9+Q7Ljed1G+1nMSAGfUFjSMxcxF+f0pH Y5XBz8M9ebnfPGVCvBXVFn1dOJj1NlJLHPBcD5wIUsLMRKxUXeSaJZpAslY+oweQ nofS+4BmSNUA5xmm1f35tw3kSmqRaexTt10nEUPkMmCsYae/zLWV7+xs/Jcpm/US W7gsJGR7nWHtcgeb0HIPKw==; Received: from relay8.apple.com (relay8.apple.com [17.128.113.102]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 3A.D4.24122.D4C5EE55; Mon, 7 Sep 2015 20:55:57 -0700 (PDT) X-AuditID: 11973e16-f79826d000005e3a-0c-55ee5c4d4bf4 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 59.17.00725.D4C5EE55; Mon, 7 Sep 2015 20:55:57 -0700 (PDT) Received: from localhost ([17.153.87.36]) by spicerack.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NUC00GSOAX93260@spicerack.apple.com> for multipathtcp@ietf.org; Mon, 07 Sep 2015 20:55:57 -0700 (PDT) Sender: cpaasch@apple.com Date: Mon, 07 Sep 2015 20:55:57 -0700 From: Christoph Paasch To: MultiPath WG Message-id: <20150908035557.GB73228@Chimay.local> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprNLMWRmVeSWpSXmKPExsUi2FCYpusb8y7U4MpdK4vPq6+zOTB6LFny kymAMYrLJiU1J7MstUjfLoEr4/zKs+wFbQIVW25eZWxg3MnTxcjJISFgItG0ehkLhC0mceHe erYuRi4OIYF9jBLnT9xjhSl6O+ESM0RiMpNEz7c77BBOH5PE970nGEGqhAUkJbrv3GEGsVkE VCUu7H7NBGKzCWhJvL3dDjZJREBD4nbbciaI+mCJ7mUPwVbzChhKbL6zkRHCFpT4MfkeWJwZ qHf9zuNMELa0xKO/M9hBbFEBFYkrE96CHSEh8JNVYtWVacwTGAVnIemfhaR/FpL+BYzMqxiF chMzc3Qz88z1EgsKclL1kvNzNzGCQnO6ndgOxoerrA4xCnAwKvHwani8CxViTSwrrsw9xCjN waIkzttu+ipUSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA+Py9Kcce3sr1lS/fe5UEHvG7mHZ TpYPLp3Che1mxj7ajlscrRS2qLBFPdr88VVAUJazWI6ohUvRVuU0ze3l6w4zVAv8mXW+e+X+ L//XH7DubC872lO3QaiTsXlFTfj6uoIbTQtLOR+/+qJ/4prP2ZsRPS8lpGvNLp7Qfn8zeP1m pbsckvMtRZRYijMSDbWYi4oTAaAJLpQuAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGLMWRmVeSWpSXmKPExsUi2FCsoesb8y7U4P1qY4vPq6+zOTB6LFny kymAMYrLJiU1J7MstUjfLoEr4/zKs+wFbQIVW25eZWxg3MnTxcjJISFgIvF2wiVmCFtM4sK9 9WxdjFwcQgKTmSR6vt1hh3D6mCS+7z3BCFIlLCAp0X3nDlgHi4CqxIXdr5lAbDYBLYm3t9tZ QWwRAQ2J223LmSDqgyW6lz1kAbF5BQwlNt/ZyAhhC0r8mHwPLM4M1Lt+53EmCFta4tHfGewg tqiAisSVCW/ZJzDyzULSMgtJyywkLQsYmVcxChSl5iRWWuglFhTkpOol5+duYgSHUmHaDsam 5VaHGAU4GJV4eDU83oUKsSaWFVfmHmKU4GBWEuG14QMK8aYkVlalFuXHF5XmpBYfYkwGenIi s5Rocj4wzPNK4g1NTAxMjI3NjI3NTcxJE1YS5/2k9CpUSCA9sSQ1OzW1ILUIZgsTB6dUA+O1 6SWHJScvaBA8LxT+Q/0O/92LcVre99mtPn75lTbn4oQFou+5eH4rS/ZZ/PrT3+b7WP7/tHVu X+QiZdc5+ERcuse667Zd4f3rYXWKb5jYdqat2HTtQPpNjyLt91xHo0TX+y3gmKrBdnS9+/nP v6V+hvWLcr4TWif2PWLiFttpSyWSPwZUZ91QYinOSDTUYi4qTgQAvx93uGkCAAA= Archived-At: Subject: [multipathtcp] Fwd: New Version Notification for draft-paasch-mptcp-loadbalancer-00.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: Tue, 08 Sep 2015 03:56:00 -0000 Hello, we have submitted a draft discussing the issues when using MPTCP behind layer-4 loadbalancers. It will be presented during the interim meeting on Thursday. Regards, Christoph ----- Forwarded message from internet-drafts@ietf.org ----- From: internet-drafts@ietf.org Date: Mon, 07 Sep 2015 20:45:11 -0700 Subject: New Version Notification for draft-paasch-mptcp-loadbalancer-00.txt A new version of I-D, draft-paasch-mptcp-loadbalancer-00.txt has been successfully submitted by Christoph Paasch and posted to the IETF repository. Name: draft-paasch-mptcp-loadbalancer Revision: 00 Title: Multipath TCP behind Layer-4 loadbalancers Document date: 2015-09-07 Group: Individual Submission Pages: 8 URL: https://www.ietf.org/id/draft-paasch-mptcp-loadbalancer-00.txt Status: http://datatracker.ietf.org/doc/draft-paasch-mptcp-loadbalancer/ Htmlized: https://tools.ietf.org/html/draft-paasch-mptcp-loadbalancer-00 Abstract: Large webserver farms consist of thousands of frontend proxies that serve as endpoints for the TCP and TLS connection and relay traffic to the (sometimes distant) backend servers. Load-balancing across those server is done by layer-4 loadbalancers that ensure that a TCP flow will always reach the same server. Multipath TCP's use of multiple TCP subflows for the transmission of the data stream requires those loadbalancers to be aware of MPTCP to ensure that all subflows belonging to the same MPTCP connection reach the same frontend proxy. In this document we analyze the challenges related to this and suggest a simple modification to the generation of the MPTCP-token to overcome those challenges. 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. The IETF Secretariat ----- End forwarded message ----- From nobody Mon Sep 7 23:37:12 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 576F71B311F for ; Mon, 7 Sep 2015 23:37:11 -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 ymDgW1ES_tou for ; Mon, 7 Sep 2015 23:37:09 -0700 (PDT) Received: from eesmtp01.ap.verizon.com (eesmtp01.ap.verizon.com [202.130.139.21]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B0D841A88FE for ; Mon, 7 Sep 2015 23:37:07 -0700 (PDT) From: "Appanasamy, Palanivelan" X-IronPort-AV: E=Sophos; i="5.17,488,1437408000"; d="scan'208,217"; a="56325081" Received: from sc-hkg-simr01.ap.verizon.com ([166.45.72.242]) by eesmtp01.ap.verizon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 08 Sep 2015 14:37:05 +0800 Received: from sc-hkg-simr01.ap.verizon.com ([166.45.72.242]:44393) by sc-hkg-simr01.ap.verizon.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1ZZCWf-00054I-3d; Tue, 08 Sep 2015 06:37:05 +0000 Received: from [166.45.22.77] (helo=MS-BAN-E7MB01.intl1.one.verizon.com) by sc-hkg-simr01.ap.verizon.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1ZZCWe-000546-4N; Tue, 08 Sep 2015 06:37:04 +0000 Received: from MS-BAN-E7MB01.intl1.one.verizon.com ([166.45.22.77]) by MS-BAN-E7MB01.intl1.one.verizon.com ([166.45.22.77]) with mapi; Tue, 8 Sep 2015 12:07:02 +0530 To: "philip.eardley@bt.com" , "multipathtcp@ietf.org" Importance: high X-Priority: 1 Date: Tue, 8 Sep 2015 12:07:01 +0530 Thread-Topic: Preparing for the MPTCP interim Thread-Index: AdDlf2e8hmJOGWBxQk+M9b3EIwPDvwEgMt3w Message-ID: <70AEAEC90FCAE0408586E94F491A07EC04C8438D41@MS-BAN-E7MB01.intl1.one.verizon.com> References: <7344a0ae9fb040268f68495bd0eff0fd@rew09926dag03b.domain1.systemhost.net> In-Reply-To: <7344a0ae9fb040268f68495bd0eff0fd@rew09926dag03b.domain1.systemhost.net> Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: multipart/alternative; boundary="_000_70AEAEC90FCAE0408586E94F491A07EC04C8438D41MSBANE7MB01in_" MIME-Version: 1.0 X-VZ-EMEA-INT-SIG: eb2e6f74164d348f8a8956a5cab2e47c X-APAC-E2-SIG: eb2e6f74164d348f8a8956a5cab2e47c Archived-At: Cc: "Harsha, Chetan H" Subject: Re: [multipathtcp] Preparing for the MPTCP interim 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, 08 Sep 2015 06:37:11 -0000 --_000_70AEAEC90FCAE0408586E94F491A07EC04C8438D41MSBANE7MB01in_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgUGhpbCwNCg0KV2Ugd2lsbCBiZSBwYXJ0aWNpcGF0aW5nIGluIHRoZSBpbnRlcmltIGFuZCBw cmVzZW50aW5nIHRoZSBzbGlkZXMuDQpGb2xsb3dpbmcgSUVURjkzIG1lZXRpbmcsIHdlIGRlY2lk ZWQgdG8gZWxpbWluYXRlIHJlZHVuZGFudCBhbmQgb3ZlcmxhcHBpbmcgdXNlIGNhc2VzICh0aGF0 IGFyZSBiZWluZyBkaXNjdXNzZWQgaW4gb3RoZXIgZHJhZnRzKS4NCg0KV2UgaGF2ZSBvdXIgbmV3 IHNsaWRlcyB3aXRoIHVzIGFuZCBJIHdpbGwgYmUgc2VuZGluZyB5b3UgdGhlIHVwZGF0ZWQgdmVy c2lvbiBieSB0b21vcnJvdyAoMDkvMDkvMjAxNSkuIFRoYW5rcy4NCg0KUmVnYXJkcywNCkEuUGFs YW5pdmVsYW4NCg0KRnJvbTogbXVsdGlwYXRodGNwIFttYWlsdG86bXVsdGlwYXRodGNwLWJvdW5j ZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBwaGlsaXAuZWFyZGxleUBidC5jb20NClNlbnQ6IFdl ZG5lc2RheSwgU2VwdGVtYmVyIDAyLCAyMDE1IDY6NTUgUE0NClRvOiBtdWx0aXBhdGh0Y3BAaWV0 Zi5vcmcNClN1YmplY3Q6IFttdWx0aXBhdGh0Y3BdIFByZXBhcmluZyBmb3IgdGhlIE1QVENQIGlu dGVyaW0NCg0KSGksDQpXZSBoYXZlIHRoZSBNUFRDUCBXRyBpbnRlcmltIG1lZXRpbmcgbmV4dCB3 ZWVrLiBodHRwczovL3Rvb2xzLmlldGYub3JnL3dnL21wdGNwL3RyYWMvd2lraS9JbnRlcmltX1Nl cHRfMjAxNQ0KDQpTbyBmYXIgd2UgaGF2ZSB0aGUgZm9sbG93aW5nIGl0ZW1zIG9uIHRoZSBhZ2Vu ZGE6DQoNCiogTVBUQ1AgcHJveHkgLSBYaW5wZW5nIFdlaQ0KKiBVc2luZyBNUFRDUCBmb3IgY2hh bm5lbCBjb21iaW5pbmcgZm9yIE5BU0EgcHJvamVjdCAtIFdpbGxpYW0gSXZhbmNpYw0KKiBEZXBs b3ltZW50IHVzZSBjYXNlcyAtIEEuUGFsYW5pdmVsYW4NCg0KWGlucGVuZyDigJMgZG8geW91IHdh bnQgYSB0aW1lc2xvdCwgb3Igd2FzIHRoZXJlIGVub3VnaCBkaXNjdXNzaW9uIGluIFByYWd1ZT8N CldpbGxpYW0sIEEuUGFsYW5pdmVsYW4g4oCTIHBsZWFzZSBjb25maXJtIHRoYXQgeW914oCZbGwg YmUgcHJlc2VudGluZy4NCg0KVGhlcmUgc2hvdWxkIGJlIHBsZW50eSBvZiB0aW1lIGZvciBzb21l IGRpc2N1c3Npb24gb24gb3RoZXIgdG9waWNzLiBTbyBmYXIgd2UgZ290IHRoZSBmb2xsb3dpbmcg cmVxdWVzdHMgZnJvbSBDaHJpc3RvcGggUGFhc2NoOg0K4oCiZHJhZnQtcGFhc2NoLW1wdGNwLXN5 bmNvb2tpZXMNCuKAok1QVENQJ3MgdXNlIGJlaGluZCBsYXllci00IGxvYWRiYWxhbmNlcnMgaW4g c2VydmVyIGZhcm1zIOKAkyBkcmFmdCBzb29uDQoNCk1lZCDigJMgZG8geW91IHdhbnQgYW55IGFn ZW5kYSB0aW1lIHRvIGRpc2N1c3MgYW55IG9mIHRoZSBkcmFmdC1ib3VjYWRhaXItbXB0Y3AteHh4 IGRyYWZ0cz8NCg0KV2Ugc2hvdWxkIGFsc28gcmVzb2x2ZSBhbnkgb3RoZXIgb3BlbiBpc3N1ZXMg 4oCTIHBsZWFzZSBsZXQgdXMga25vdyBpZiB0aGVyZSBhcmUgYW55IG90aGVyIG9uZXM6DQrigKJ3 ZSBoYXZlIGNvbnNlbnN1cyB0byBhZGQgYW4gZXhwZXJpbWVudGFsIE1QVENQIG9wdGlvbiB0byB0 aGUgcHJvdG9jb2wgYmlzIFtzZWUg4oCLaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv ZHJhZnQtYm9uYXZlbnR1cmUtbXB0Y3AtZXhwLW9wdGlvbi9dLiBCdXQgd2UgaGF2ZSB0aGUgcXVl c3Rpb24gd2hldGhlciBpdCBzaG91bGQgYmUgOCBvciAxNiBiaXRzLg0KDQpUaGUgT3BlcmF0aW9u YWwgZXhwZXJpZW5jZSBkcmFmdCBpcyBub3cgZXhpdGluZyB0aGUgV0cgaW50byBJRVNHLCBzbyB3 ZSBjYW4gbm93IGFsc28gcHJvZ3Jlc3MgdGhlIHByb3RvY29sIGJpcyBkb2N1bWVudC4gU28gaWYg dGhlcmXigJlzIGFueXRoaW5nIGVsc2UgdGhhdCB5b3UgdGhpbmsgbmVlZHMgYWRkaW5nIHRvIHRo ZSBwcm90b2NvbCBiaXMsIHRoZSBpbnRlcmltIG1lZXRpbmcgd291bGQgYmUgYSBnb29kIHRpbWUg dG8gZGlzY3VzcyB0aGlzLg0KDQpUaGFua3MNClBoaWwgJiBZb3NoaS4NCg== --_000_70AEAEC90FCAE0408586E94F491A07EC04C8438D41MSBANE7MB01in_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+PGhlYWQ+PG1ldGEgaHR0cC1lcXVpdj1Db250ZW50LVR5cGUgY29udGVu dD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij48bWV0YSBuYW1lPUdlbmVyYXRvciBjb250ZW50 PSJNaWNyb3NvZnQgV29yZCAxNCAoZmlsdGVyZWQgbWVkaXVtKSI+PHN0eWxlPjwhLS0NCi8qIEZv bnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQt ZmFjZQ0KCXtmb250LWZhbWlseTpUYWhvbWE7DQoJcGFub3NlLTE6MiAxMSA2IDQgMyA1IDQgNCAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsInNhbnMtc2VyaWYiO30N CmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNv bG9yOmJsdWU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQphOnZpc2l0ZWQsIHNwYW4u TXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCWNvbG9yOnB1 cnBsZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJ e21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2Vy aWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7DQoJZm9udC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5 bGU6bm9ybWFsOw0KCXRleHQtZGVjb3JhdGlvbjpub25lIG5vbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxl MTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGli cmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30NCi5Nc29DaHBEZWZhdWx0DQoJe21z by1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29y ZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBp biAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwv c3R5bGU+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpzaGFwZWRlZmF1bHRzIHY6ZXh0PSJl ZGl0IiBzcGlkbWF4PSIxMDI2IiAvPg0KPC94bWw+PCFbZW5kaWZdLS0+PCEtLVtpZiBndGUgbXNv IDldPjx4bWw+DQo8bzpzaGFwZWxheW91dCB2OmV4dD0iZWRpdCI+DQo8bzppZG1hcCB2OmV4dD0i ZWRpdCIgZGF0YT0iMSIgLz4NCjwvbzpzaGFwZWxheW91dD48L3htbD48IVtlbmRpZl0tLT48L2hl YWQ+PGJvZHkgbGFuZz1FTi1VUyBsaW5rPWJsdWUgdmxpbms9cHVycGxlPjxkaXYgY2xhc3M9V29y ZFNlY3Rpb24xPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+ SGkgUGhpbCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0 eWxlPSdjb2xvcjojMUY0OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9 TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz5XZSB3aWxsIGJlIHBhcnRpY2lw YXRpbmcgaW4gdGhlIGludGVyaW0gYW5kIHByZXNlbnRpbmcgdGhlIHNsaWRlcy4gPG86cD48L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3 RCc+Rm9sbG93aW5nIElFVEY5MyBtZWV0aW5nLCB3ZSBkZWNpZGVkIHRvIGVsaW1pbmF0ZSByZWR1 bmRhbnQgYW5kIG92ZXJsYXBwaW5nIHVzZSBjYXNlcyAodGhhdCBhcmUgYmVpbmcgZGlzY3Vzc2Vk IGluIG90aGVyIGRyYWZ0cykuPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1h bD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBzdHlsZT0nY29sb3I6IzFGNDk3RCc+V2UgaGF2ZSBv dXIgbmV3IHNsaWRlcyB3aXRoIHVzIGFuZCBJIHdpbGwgYmUgc2VuZGluZyB5b3UgdGhlIHVwZGF0 ZWQgdmVyc2lvbiBieSB0b21vcnJvdyAoMDkvMDkvMjAxNSkuIFRoYW5rcy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0OTdEJz48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxl PSdjb2xvcjojMUY0OTdEJz5SZWdhcmRzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gc3R5bGU9J2NvbG9yOiMxRjQ5N0QnPkEuUGFsYW5pdmVsYW48bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIHN0eWxlPSdjb2xvcjojMUY0 OTdEJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PGRpdj48ZGl2IHN0eWxlPSdib3JkZXI6 bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGlu IDBpbic+PHAgY2xhc3M9TXNvTm9ybWFsPjxiPjxzcGFuIHN0eWxlPSdmb250LXNpemU6MTAuMHB0 O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIic+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSdmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlm Iic+IG11bHRpcGF0aHRjcCBbbWFpbHRvOm11bHRpcGF0aHRjcC1ib3VuY2VzQGlldGYub3JnXSA8 Yj5PbiBCZWhhbGYgT2YgPC9iPnBoaWxpcC5lYXJkbGV5QGJ0LmNvbTxicj48Yj5TZW50OjwvYj4g V2VkbmVzZGF5LCBTZXB0ZW1iZXIgMDIsIDIwMTUgNjo1NSBQTTxicj48Yj5Ubzo8L2I+IG11bHRp cGF0aHRjcEBpZXRmLm9yZzxicj48Yj5TdWJqZWN0OjwvYj4gW211bHRpcGF0aHRjcF0gUHJlcGFy aW5nIGZvciB0aGUgTVBUQ1AgaW50ZXJpbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD48L2Rpdj48L2Rp dj48cCBjbGFzcz1Nc29Ob3JtYWw+PG86cD4mbmJzcDs8L286cD48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6 IkFyaWFsIiwic2Fucy1zZXJpZiInPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1N c29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdDtmb250LWZh bWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+V2UgaGF2ZSB0aGUgTVBUQ1AgV0cgaW50ZXJpbSBt ZWV0aW5nIG5leHQgd2Vlay4gPGEgaHJlZj0iaHR0cHM6Ly90b29scy5pZXRmLm9yZy93Zy9tcHRj cC90cmFjL3dpa2kvSW50ZXJpbV9TZXB0XzIwMTUiPmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvd2cv bXB0Y3AvdHJhYy93aWtpL0ludGVyaW1fU2VwdF8yMDE1PC9hPiA8bzpwPjwvbzpwPjwvc3Bhbj48 L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZTox Mi4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPjxvOnA+Jm5ic3A7PC9vOnA+ PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9u dC1zaXplOjEyLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+U28gZmFyIHdl IGhhdmUgdGhlIGZvbGxvd2luZyBpdGVtcyBvbiB0aGUgYWdlbmRhOjxvOnA+PC9vOnA+PC9zcGFu PjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXpl OjEyLjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdm b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4qIE1QVENQ IHByb3h5IC0gWGlucGVuZyBXZWkgPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5 OiJBcmlhbCIsInNhbnMtc2VyaWYiJz4qIFVzaW5nIE1QVENQIGZvciBjaGFubmVsIGNvbWJpbmlu ZyBmb3IgTkFTQSBwcm9qZWN0IC0gV2lsbGlhbSBJdmFuY2ljIDxvOnA+PC9vOnA+PC9zcGFuPjwv cD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+KiBEZXBsb3ltZW50IHVzZSBj YXNlcyAtIEEuUGFsYW5pdmVsYW48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9y bWFsPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6 IkFyaWFsIiwic2Fucy1zZXJpZiInPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdDtmb250 LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+WGlucGVuZyDigJMgZG8geW91IHdhbnQgYSB0 aW1lc2xvdCwgb3Igd2FzIHRoZXJlIGVub3VnaCBkaXNjdXNzaW9uIGluIFByYWd1ZT88bzpwPjwv bzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9 J2ZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPldpbGxp YW0sIEEuUGFsYW5pdmVsYW4g4oCTIHBsZWFzZSBjb25maXJtIHRoYXQgeW914oCZbGwgYmUgcHJl c2VudGluZy48bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxh bmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fu cy1zZXJpZiInPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+ PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIic+VGhlcmUgc2hvdWxkIGJlIHBsZW50eSBvZiB0aW1lIGZvciBzb21l IGRpc2N1c3Npb24gb24gb3RoZXIgdG9waWNzLiBTbyBmYXIgd2UgZ290IHRoZSBmb2xsb3dpbmcg cmVxdWVzdHMgZnJvbSBDaHJpc3RvcGggUGFhc2NoOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBj bGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdDtm b250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+4oCiZHJhZnQtcGFhc2NoLW1wdGNwLXN5 bmNvb2tpZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFuIGxh bmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwic2Fu cy1zZXJpZiInPuKAok1QVENQJ3MgdXNlIGJlaGluZCBsYXllci00IGxvYWRiYWxhbmNlcnMgaW4g c2VydmVyIGZhcm1zIOKAkyBkcmFmdCBzb29uICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD48 cCBjbGFzcz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEyLjBw dDtmb250LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9wPjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5NZWQg4oCTIGRvIHlv dSB3YW50IGFueSBhZ2VuZGEgdGltZSB0byBkaXNjdXNzIGFueSBvZiB0aGUgZHJhZnQtYm91Y2Fk YWlyLW1wdGNwLXh4eCBkcmFmdHM/PG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNzPU1zb05v cm1hbD48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5 OiJBcmlhbCIsInNhbnMtc2VyaWYiJz48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+PHAgY2xh c3M9TXNvTm9ybWFsPjxzcGFuIGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7Zm9u dC1mYW1pbHk6IkFyaWFsIiwic2Fucy1zZXJpZiInPldlIHNob3VsZCBhbHNvIHJlc29sdmUgYW55 IG90aGVyIG9wZW4gaXNzdWVzIOKAkyBwbGVhc2UgbGV0IHVzIGtub3cgaWYgdGhlcmUgYXJlIGFu eSBvdGhlciBvbmVzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3JtYWw+PHNw YW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToiQXJpYWwi LCJzYW5zLXNlcmlmIic+4oCid2UgaGF2ZSBjb25zZW5zdXMgdG8gYWRkIGFuIGV4cGVyaW1lbnRh bCBNUFRDUCBvcHRpb24gdG8gdGhlIHByb3RvY29sIGJpcyBbc2VlIOKAizxhIGhyZWY9Imh0dHBz Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWJvbmF2ZW50dXJlLW1wdGNwLWV4cC1v cHRpb24vIj5odHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1ib25hdmVudHVy ZS1tcHRjcC1leHAtb3B0aW9uLzwvYT5dLiBCdXQgd2UgaGF2ZSB0aGUgcXVlc3Rpb24gd2hldGhl ciBpdCBzaG91bGQgYmUgOCBvciAxNiBiaXRzLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFz cz1Nc29Ob3JtYWw+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdDtmb250 LWZhbWlseToiQXJpYWwiLCJzYW5zLXNlcmlmIic+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w PjxwIGNsYXNzPU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5UaGUgT3BlcmF0aW9uYWwgZXhw ZXJpZW5jZSBkcmFmdCBpcyBub3cgZXhpdGluZyB0aGUgV0cgaW50byBJRVNHLCBzbyB3ZSBjYW4g bm93IGFsc28gcHJvZ3Jlc3MgdGhlIHByb3RvY29sIGJpcyBkb2N1bWVudC4gU28gaWYgdGhlcmXi gJlzIGFueXRoaW5nIGVsc2UgdGhhdCB5b3UgdGhpbmsgbmVlZHMgYWRkaW5nIHRvIHRoZSBwcm90 b2NvbCBiaXMsIHRoZSBpbnRlcmltIG1lZXRpbmcgd291bGQgYmUgYSBnb29kIHRpbWUgdG8gZGlz Y3VzcyB0aGlzLiA8bzpwPjwvbzpwPjwvc3Bhbj48L3A+PHAgY2xhc3M9TXNvTm9ybWFsPjxzcGFu IGxhbmc9RU4tR0Igc3R5bGU9J2ZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6IkFyaWFsIiwi c2Fucy1zZXJpZiInPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD48cCBjbGFzcz1Nc29Ob3Jt YWw+PHNwYW4gbGFuZz1FTi1HQiBzdHlsZT0nZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseToi QXJpYWwiLCJzYW5zLXNlcmlmIic+VGhhbmtzPG86cD48L286cD48L3NwYW4+PC9wPjxwIGNsYXNz PU1zb05vcm1hbD48c3BhbiBsYW5nPUVOLUdCIHN0eWxlPSdmb250LXNpemU6MTIuMHB0O2ZvbnQt ZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiJz5QaGlsICZhbXA7IFlvc2hpLiA8bzpwPjwvbzpw Pjwvc3Bhbj48L3A+PC9kaXY+PC9ib2R5PjwvaHRtbD4= --_000_70AEAEC90FCAE0408586E94F491A07EC04C8438D41MSBANE7MB01in_-- From nobody Tue Sep 8 01:55: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 CCEBE1B4085 for ; Tue, 8 Sep 2015 01:55:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.01 X-Spam-Level: X-Spam-Status: No, score=-2.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, 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 0555h4lZsY0N for ; Tue, 8 Sep 2015 01:55:17 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A28701B3F04 for ; Tue, 8 Sep 2015 01:55:16 -0700 (PDT) Received: from EVMHT01-UKBR.domain1.systemhost.net (193.113.108.42) by EVMED05-UKBR.bt.com (10.216.161.37) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 8 Sep 2015 09:55:13 +0100 Received: from rew09926dag03c.domain1.systemhost.net (10.55.202.26) by EVMHT01-UKBR.domain1.systemhost.net (193.113.108.42) with Microsoft SMTP Server (TLS) id 8.3.342.0; Tue, 8 Sep 2015 09:55:14 +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; Tue, 8 Sep 2015 09:55: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; Tue, 8 Sep 2015 09:55:13 +0100 From: To: Thread-Topic: Preparing for the MPTCP interim Thread-Index: AdDlf2e8hmJOGWBxQk+M9b3EIwPDvwEgMt3wAATLxnA= Date: Tue, 8 Sep 2015 08:55:13 +0000 Message-ID: <64af6848f1804b40a597f88974161b39@rew09926dag03b.domain1.systemhost.net> References: <7344a0ae9fb040268f68495bd0eff0fd@rew09926dag03b.domain1.systemhost.net> <70AEAEC90FCAE0408586E94F491A07EC04C8438D41@MS-BAN-E7MB01.intl1.one.verizon.com> In-Reply-To: <70AEAEC90FCAE0408586E94F491A07EC04C8438D41@MS-BAN-E7MB01.intl1.one.verizon.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.243] Content-Type: multipart/alternative; boundary="_000_64af6848f1804b40a597f88974161b39rew09926dag03bdomain1sy_" MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] Preparing for the MPTCP interim 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, 08 Sep 2015 08:55:21 -0000 --_000_64af6848f1804b40a597f88974161b39rew09926dag03bdomain1sy_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGksDQoNClRoYW5rcyB0byBYaW5wZW5nIGFuZCBBLlBhbGFuaXZlbGFuIGZvciB0aGUgc2xpZGVz IC91cGRhdGUuDQoNCldpbGxpYW0sIENocmlzdG9waCDigJMgcGxlYXNlIG1ha2Ugc3VyZSB5b3Ug c2VuZCB5b3VyIHNsaWRlcyB3ZWxsIGluIGFkdmFuY2Ugb2YgdGhlIG1lZXRpbmcuIHdl4oCZbGwg dXBsb2FkIHRoZW0gZmlyc3QgdGhpbmcgb24gVGh1cnNkYXkgKFVLIHRpbWUpLiBTaW5jZSB0aGUg bWVldGluZyBpcyByZW1vdGUsIGl04oCZcyBldmVuIG1vcmUgaW1wb3J0YW50IHRoYW4gdXN1YWwg dGhhdCB3ZSBoYXZlIGV2ZXJ5b25l4oCZcyBzbGlkZXMgd2VsbCBhaGVhZC4NCg0KTWVkIOKAkyB3 ZeKAmWxsIGFzc3VtZSB5b3UgZG9u4oCZdCB3YW50IGFueSB0aW1lICh1bmxlc3MgeW91IHNheSBz byB2ZXJ5IHNvb24pDQoNClBsZWFzZSBsZXQgdXMga25vdyBpZiB0aGVyZSBhcmUgYW55IG90aGVy IGFkZGl0aW9uYWwgdG9waWNzIHRoYXQgbmVlZCBkaXNjdXNzaW5nDQoNClRoYW5rcw0KUGhpbCAm IFlvc2hpDQoNCkZyb206IEFwcGFuYXNhbXksIFBhbGFuaXZlbGFuIFttYWlsdG86cGFsYW5pdmVs YW4uYXBwYW5hc2FteUBpbi52ZXJpem9uLmNvbV0NClNlbnQ6IDA4IFNlcHRlbWJlciAyMDE1IDA3 OjM3DQpUbzogRWFyZGxleSxQTCxQaGlsaXAsVFVCOCBSOyBtdWx0aXBhdGh0Y3BAaWV0Zi5vcmcN CkNjOiBIYXJzaGEsIENoZXRhbiBIOyBzc2VudGhpbEBjaXNjby5jb20NClN1YmplY3Q6IFJFOiBQ cmVwYXJpbmcgZm9yIHRoZSBNUFRDUCBpbnRlcmltDQpJbXBvcnRhbmNlOiBIaWdoDQoNCkhpIFBo aWwsDQoNCldlIHdpbGwgYmUgcGFydGljaXBhdGluZyBpbiB0aGUgaW50ZXJpbSBhbmQgcHJlc2Vu dGluZyB0aGUgc2xpZGVzLg0KRm9sbG93aW5nIElFVEY5MyBtZWV0aW5nLCB3ZSBkZWNpZGVkIHRv IGVsaW1pbmF0ZSByZWR1bmRhbnQgYW5kIG92ZXJsYXBwaW5nIHVzZSBjYXNlcyAodGhhdCBhcmUg YmVpbmcgZGlzY3Vzc2VkIGluIG90aGVyIGRyYWZ0cykuDQoNCldlIGhhdmUgb3VyIG5ldyBzbGlk ZXMgd2l0aCB1cyBhbmQgSSB3aWxsIGJlIHNlbmRpbmcgeW91IHRoZSB1cGRhdGVkIHZlcnNpb24g YnkgdG9tb3Jyb3cgKDA5LzA5LzIwMTUpLiBUaGFua3MuDQoNClJlZ2FyZHMsDQpBLlBhbGFuaXZl bGFuDQoNCkZyb206IG11bHRpcGF0aHRjcCBbbWFpbHRvOm11bHRpcGF0aHRjcC1ib3VuY2VzQGll dGYub3JnXSBPbiBCZWhhbGYgT2YgcGhpbGlwLmVhcmRsZXlAYnQuY29tPG1haWx0bzpwaGlsaXAu ZWFyZGxleUBidC5jb20+DQpTZW50OiBXZWRuZXNkYXksIFNlcHRlbWJlciAwMiwgMjAxNSA2OjU1 IFBNDQpUbzogbXVsdGlwYXRodGNwQGlldGYub3JnPG1haWx0bzptdWx0aXBhdGh0Y3BAaWV0Zi5v cmc+DQpTdWJqZWN0OiBbbXVsdGlwYXRodGNwXSBQcmVwYXJpbmcgZm9yIHRoZSBNUFRDUCBpbnRl cmltDQoNCkhpLA0KV2UgaGF2ZSB0aGUgTVBUQ1AgV0cgaW50ZXJpbSBtZWV0aW5nIG5leHQgd2Vl ay4gaHR0cHM6Ly90b29scy5pZXRmLm9yZy93Zy9tcHRjcC90cmFjL3dpa2kvSW50ZXJpbV9TZXB0 XzIwMTUNCg0KU28gZmFyIHdlIGhhdmUgdGhlIGZvbGxvd2luZyBpdGVtcyBvbiB0aGUgYWdlbmRh Og0KDQoqIE1QVENQIHByb3h5IC0gWGlucGVuZyBXZWkNCiogVXNpbmcgTVBUQ1AgZm9yIGNoYW5u ZWwgY29tYmluaW5nIGZvciBOQVNBIHByb2plY3QgLSBXaWxsaWFtIEl2YW5jaWMNCiogRGVwbG95 bWVudCB1c2UgY2FzZXMgLSBBLlBhbGFuaXZlbGFuDQoNClhpbnBlbmcg4oCTIGRvIHlvdSB3YW50 IGEgdGltZXNsb3QsIG9yIHdhcyB0aGVyZSBlbm91Z2ggZGlzY3Vzc2lvbiBpbiBQcmFndWU/DQpX aWxsaWFtLCBBLlBhbGFuaXZlbGFuIOKAkyBwbGVhc2UgY29uZmlybSB0aGF0IHlvdeKAmWxsIGJl IHByZXNlbnRpbmcuDQoNClRoZXJlIHNob3VsZCBiZSBwbGVudHkgb2YgdGltZSBmb3Igc29tZSBk aXNjdXNzaW9uIG9uIG90aGVyIHRvcGljcy4gU28gZmFyIHdlIGdvdCB0aGUgZm9sbG93aW5nIHJl cXVlc3RzIGZyb20gQ2hyaXN0b3BoIFBhYXNjaDoNCuKAomRyYWZ0LXBhYXNjaC1tcHRjcC1zeW5j b29raWVzDQrigKJNUFRDUCdzIHVzZSBiZWhpbmQgbGF5ZXItNCBsb2FkYmFsYW5jZXJzIGluIHNl cnZlciBmYXJtcyDigJMgZHJhZnQgc29vbg0KDQpNZWQg4oCTIGRvIHlvdSB3YW50IGFueSBhZ2Vu ZGEgdGltZSB0byBkaXNjdXNzIGFueSBvZiB0aGUgZHJhZnQtYm91Y2FkYWlyLW1wdGNwLXh4eCBk cmFmdHM/DQoNCldlIHNob3VsZCBhbHNvIHJlc29sdmUgYW55IG90aGVyIG9wZW4gaXNzdWVzIOKA kyBwbGVhc2UgbGV0IHVzIGtub3cgaWYgdGhlcmUgYXJlIGFueSBvdGhlciBvbmVzOg0K4oCid2Ug aGF2ZSBjb25zZW5zdXMgdG8gYWRkIGFuIGV4cGVyaW1lbnRhbCBNUFRDUCBvcHRpb24gdG8gdGhl IHByb3RvY29sIGJpcyBbc2VlIOKAi2h0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWJvbmF2ZW50dXJlLW1wdGNwLWV4cC1vcHRpb24vXS4gQnV0IHdlIGhhdmUgdGhlIHF1ZXN0 aW9uIHdoZXRoZXIgaXQgc2hvdWxkIGJlIDggb3IgMTYgYml0cy4NCg0KVGhlIE9wZXJhdGlvbmFs IGV4cGVyaWVuY2UgZHJhZnQgaXMgbm93IGV4aXRpbmcgdGhlIFdHIGludG8gSUVTRywgc28gd2Ug Y2FuIG5vdyBhbHNvIHByb2dyZXNzIHRoZSBwcm90b2NvbCBiaXMgZG9jdW1lbnQuIFNvIGlmIHRo ZXJl4oCZcyBhbnl0aGluZyBlbHNlIHRoYXQgeW91IHRoaW5rIG5lZWRzIGFkZGluZyB0byB0aGUg cHJvdG9jb2wgYmlzLCB0aGUgaW50ZXJpbSBtZWV0aW5nIHdvdWxkIGJlIGEgZ29vZCB0aW1lIHRv IGRpc2N1c3MgdGhpcy4NCg0KVGhhbmtzDQpQaGlsICYgWW9zaGkuDQo= --_000_64af6848f1804b40a597f88974161b39rew09926dag03bdomain1sy_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJ e2ZvbnQtZmFtaWx5OlRhaG9tYTsNCglwYW5vc2UtMToyIDExIDYgNCAzIDUgNCA0IDIgNDt9DQov KiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1z b05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNp emU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7fQ0KYTpsaW5r LCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1 ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0K CXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5Nc29BY2V0YXRlLCBsaS5Nc29BY2V0YXRl LCBkaXYuTXNvQWNldGF0ZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkJhbGxvb24gVGV4dCBDaGFyIjsNCgltYXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAw MDFwdDsNCglmb250LXNpemU6OC4wcHQ7DQoJZm9udC1mYW1pbHk6IlRhaG9tYSIsInNhbnMtc2Vy aWYiO30NCnNwYW4uRW1haWxTdHlsZTE3DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv bnQtZmFtaWx5OiJBcmlhbCIsInNhbnMtc2VyaWYiOw0KCWNvbG9yOndpbmRvd3RleHQ7DQoJZm9u dC13ZWlnaHQ6bm9ybWFsOw0KCWZvbnQtc3R5bGU6bm9ybWFsOw0KCXRleHQtZGVjb3JhdGlvbjpu b25lIG5vbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWw7 DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjojMUY0OTdEO30N CnNwYW4uQmFsbG9vblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJCYWxsb29uIFRleHQgQ2hh ciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1zdHlsZS1saW5rOiJCYWxsb29uIFRl eHQiOw0KCWZvbnQtZmFtaWx5OiJUYWhvbWEiLCJzYW5zLXNlcmlmIjt9DQpzcGFuLkVtYWlsU3R5 bGUyMQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQXJp YWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjpibHVlOw0KCWZvbnQtd2VpZ2h0Om5vcm1hbDsNCglm b250LXN0eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lO30NCi5Nc29DaHBE ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7 fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdpbjo3 Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hh cGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlm XS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQi Pg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94 bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1ZSIg dmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5IaSw8bzpwPjwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z aXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlm JnF1b3Q7O2NvbG9yOmJsdWUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZx dW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+VGhhbmtz IHRvIFhpbnBlbmcgYW5kIEEuUGFsYW5pdmVsYW4gZm9yIHRoZSBzbGlkZXMgL3VwZGF0ZS48bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7O2NvbG9yOmJsdWUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5 OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+V2ls bGlhbSwgQ2hyaXN0b3BoIOKAkyBwbGVhc2UgbWFrZSBzdXJlIHlvdSBzZW5kIHlvdXIgc2xpZGVz IHdlbGwgaW4gYWR2YW5jZSBvZiB0aGUgbWVldGluZy4gd2XigJlsbCB1cGxvYWQgdGhlbSBmaXJz dCB0aGluZyBvbiBUaHVyc2RheSAoVUsgdGltZSkuIFNpbmNlIHRoZSBtZWV0aW5nDQogaXMgcmVt b3RlLCBpdOKAmXMgZXZlbiBtb3JlIGltcG9ydGFudCB0aGFuIHVzdWFsIHRoYXQgd2UgaGF2ZSBl dmVyeW9uZeKAmXMgc2xpZGVzIHdlbGwgYWhlYWQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj48 bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz dHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPk1lZCDigJMgd2XigJlsbCBhc3N1bWUgeW91 IGRvbuKAmXQgd2FudCBhbnkgdGltZSAodW5sZXNzIHlvdSBzYXkgc28gdmVyeSBzb29uKTxvOnA+ PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2Vy aWYmcXVvdDs7Y29sb3I6Ymx1ZSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6 JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90Oztjb2xvcjpibHVlIj5QbGVh c2UgbGV0IHVzIGtub3cgaWYgdGhlcmUgYXJlIGFueSBvdGhlciBhZGRpdGlvbmFsIHRvcGljcyB0 aGF0IG5lZWQgZGlzY3Vzc2luZzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDs7Y29sb3I6Ymx1ZSI+PG86cD4mbmJzcDs8 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt c2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJp ZiZxdW90Oztjb2xvcjpibHVlIj5UaGFua3M8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPlBoaWwg JmFtcDsgWW9zaGk8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7O2NvbG9yOmJsdWUiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z cGFuPjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUg MS41cHQ7cGFkZGluZzowY20gMGNtIDBjbSA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9y ZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGNt IDBjbSAwY20iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48L2I+PHNwYW4gbGFuZz0iRU4tVVMiIHN0 eWxlPSJmb250LXNpemU6MTAuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O1RhaG9tYSZxdW90OywmcXVv dDtzYW5zLXNlcmlmJnF1b3Q7Ij4gQXBwYW5hc2FteSwgUGFsYW5pdmVsYW4gW21haWx0bzpwYWxh bml2ZWxhbi5hcHBhbmFzYW15QGluLnZlcml6b24uY29tXQ0KPGJyPg0KPGI+U2VudDo8L2I+IDA4 IFNlcHRlbWJlciAyMDE1IDA3OjM3PGJyPg0KPGI+VG86PC9iPiBFYXJkbGV5LFBMLFBoaWxpcCxU VUI4IFI7IG11bHRpcGF0aHRjcEBpZXRmLm9yZzxicj4NCjxiPkNjOjwvYj4gSGFyc2hhLCBDaGV0 YW4gSDsgc3NlbnRoaWxAY2lzY28uY29tPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJFOiBQcmVwYXJp bmcgZm9yIHRoZSBNUFRDUCBpbnRlcmltPGJyPg0KPGI+SW1wb3J0YW5jZTo8L2I+IEhpZ2g8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkhpIFBoaWwsPG86cD48L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJjb2xvcjoj MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPldlIHdpbGwgYmUgcGFy dGljaXBhdGluZyBpbiB0aGUgaW50ZXJpbSBhbmQgcHJlc2VudGluZyB0aGUgc2xpZGVzLg0KPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4t VVMiIHN0eWxlPSJjb2xvcjojMUY0OTdEIj5Gb2xsb3dpbmcgSUVURjkzIG1lZXRpbmcsIHdlIGRl Y2lkZWQgdG8gZWxpbWluYXRlIHJlZHVuZGFudCBhbmQgb3ZlcmxhcHBpbmcgdXNlIGNhc2VzICh0 aGF0IGFyZSBiZWluZyBkaXNjdXNzZWQgaW4gb3RoZXIgZHJhZnRzKS48bzpwPjwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9ImNv bG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+V2UgaGF2ZSBv dXIgbmV3IHNsaWRlcyB3aXRoIHVzIGFuZCBJIHdpbGwgYmUgc2VuZGluZyB5b3UgdGhlIHVwZGF0 ZWQgdmVyc2lvbiBieSB0b21vcnJvdyAoMDkvMDkvMjAxNSkuIFRoYW5rcy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0iY29sb3I6IzFGNDk3RCI+UmVnYXJk cyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImNvbG9yOiMxRjQ5N0QiPkEuUGFsYW5pdmVsYW48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 ImNvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2 IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGlu ZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPkZyb206PC9zcGFuPjwvYj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9ImZvbnQtc2l6ZToxMC4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7VGFob21h JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPiBtdWx0aXBhdGh0Y3AgWzxhIGhyZWY9Im1h aWx0bzptdWx0aXBhdGh0Y3AtYm91bmNlc0BpZXRmLm9yZyI+bWFpbHRvOm11bHRpcGF0aHRjcC1i b3VuY2VzQGlldGYub3JnPC9hPl0NCjxiPk9uIEJlaGFsZiBPZiA8L2I+PGEgaHJlZj0ibWFpbHRv OnBoaWxpcC5lYXJkbGV5QGJ0LmNvbSI+cGhpbGlwLmVhcmRsZXlAYnQuY29tPC9hPjxicj4NCjxi PlNlbnQ6PC9iPiBXZWRuZXNkYXksIFNlcHRlbWJlciAwMiwgMjAxNSA2OjU1IFBNPGJyPg0KPGI+ VG86PC9iPiA8YSBocmVmPSJtYWlsdG86bXVsdGlwYXRodGNwQGlldGYub3JnIj5tdWx0aXBhdGh0 Y3BAaWV0Zi5vcmc8L2E+PGJyPg0KPGI+U3ViamVjdDo8L2I+IFttdWx0aXBhdGh0Y3BdIFByZXBh cmluZyBmb3IgdGhlIE1QVENQIGludGVyaW08bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N CjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5i c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMt c2VyaWYmcXVvdDsiPkhpLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFs JnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPldlIGhhdmUgdGhlIE1QVENQIFdHIGludGVy aW0gbWVldGluZyBuZXh0IHdlZWsuDQo8YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYub3JnL3dn L21wdGNwL3RyYWMvd2lraS9JbnRlcmltX1NlcHRfMjAxNSI+aHR0cHM6Ly90b29scy5pZXRmLm9y Zy93Zy9tcHRjcC90cmFjL3dpa2kvSW50ZXJpbV9TZXB0XzIwMTU8L2E+DQo8bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5TbyBmYXIgd2UgaGF2ZSB0aGUgZm9sbG93aW5nIGl0ZW1z IG9uIHRoZSBhZ2VuZGE6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwm cXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9u dC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+KiBNUFRD UCBwcm94eSAtIFhpbnBlbmcgV2VpDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVv dDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij4qIFVzaW5nIE1QVENQIGZvciBj aGFubmVsIGNvbWJpbmluZyBmb3IgTkFTQSBwcm9qZWN0IC0gV2lsbGlhbSBJdmFuY2ljDQo8bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij4qIERlcGxveW1lbnQgdXNlIGNhc2VzIC0gQS5QYWxhbml2ZWxhbjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlhpbnBlbmcg4oCTIGRvIHlvdSB3YW50IGEgdGlt ZXNsb3QsIG9yIHdhcyB0aGVyZSBlbm91Z2ggZGlzY3Vzc2lvbiBpbiBQcmFndWU/PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6 ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZx dW90OyI+V2lsbGlhbSwgQS5QYWxhbml2ZWxhbiDigJMgcGxlYXNlIGNvbmZpcm0gdGhhdCB5b3Xi gJlsbCBiZSBwcmVzZW50aW5nLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0Fy aWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRo ZXJlIHNob3VsZCBiZSBwbGVudHkgb2YgdGltZSBmb3Igc29tZSBkaXNjdXNzaW9uIG9uIG90aGVy IHRvcGljcy4gU28gZmFyIHdlIGdvdCB0aGUgZm9sbG93aW5nIHJlcXVlc3RzIGZyb20gQ2hyaXN0 b3BoIFBhYXNjaDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90 OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7igKJkcmFmdC1wYWFzY2gtbXB0Y3Atc3luY29va2ll czxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl PSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3Nh bnMtc2VyaWYmcXVvdDsiPuKAok1QVENQJ3MgdXNlIGJlaGluZCBsYXllci00IGxvYWRiYWxhbmNl cnMgaW4gc2VydmVyIGZhcm1zIOKAkyBkcmFmdCBzb29uICZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0 O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90 O3NhbnMtc2VyaWYmcXVvdDsiPk1lZCDigJMgZG8geW91IHdhbnQgYW55IGFnZW5kYSB0aW1lIHRv IGRpc2N1c3MgYW55IG9mIHRoZSBkcmFmdC1ib3VjYWRhaXItbXB0Y3AteHh4IGRyYWZ0cz88bzpw PjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u dC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNl cmlmJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlh bCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5XZSBzaG91bGQgYWxzbyByZXNvbHZlIGFu eSBvdGhlciBvcGVuIGlzc3VlcyDigJMgcGxlYXNlIGxldCB1cyBrbm93IGlmIHRoZXJlIGFyZSBh bnkgb3RoZXIgb25lczo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZx dW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij7igKJ3ZSBoYXZlIGNvbnNlbnN1cyB0byBhZGQg YW4gZXhwZXJpbWVudGFsIE1QVENQIG9wdGlvbiB0byB0aGUgcHJvdG9jb2wgYmlzIFtzZWUg4oCL PGEgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtYm9uYXZlbnR1 cmUtbXB0Y3AtZXhwLW9wdGlvbi8iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry YWZ0LWJvbmF2ZW50dXJlLW1wdGNwLWV4cC1vcHRpb24vPC9hPl0uDQogQnV0IHdlIGhhdmUgdGhl IHF1ZXN0aW9uIHdoZXRoZXIgaXQgc2hvdWxkIGJlIDggb3IgMTYgYml0cy48bzpwPjwvbzpwPjwv c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEy LjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OywmcXVvdDtzYW5zLXNlcmlmJnF1b3Q7 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEyLjBwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oywm cXVvdDtzYW5zLXNlcmlmJnF1b3Q7Ij5UaGUgT3BlcmF0aW9uYWwgZXhwZXJpZW5jZSBkcmFmdCBp cyBub3cgZXhpdGluZyB0aGUgV0cgaW50byBJRVNHLCBzbyB3ZSBjYW4gbm93IGFsc28gcHJvZ3Jl c3MgdGhlIHByb3RvY29sIGJpcyBkb2N1bWVudC4gU28gaWYgdGhlcmXigJlzIGFueXRoaW5nIGVs c2UgdGhhdCB5b3UgdGhpbmsgbmVlZHMgYWRkaW5nDQogdG8gdGhlIHByb3RvY29sIGJpcywgdGhl IGludGVyaW0gbWVldGluZyB3b3VsZCBiZSBhIGdvb2QgdGltZSB0byBkaXNjdXNzIHRoaXMuIDxv OnA+DQo8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fu cy1zZXJpZiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7 QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhhbmtzPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4w cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+ UGhpbCAmYW1wOyBZb3NoaS4NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9kaXY+ DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_64af6848f1804b40a597f88974161b39rew09926dag03bdomain1sy_-- From nobody Wed Sep 9 01:03: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 457A01B44DB for ; Wed, 9 Sep 2015 01:03:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.115 X-Spam-Level: ** X-Spam-Status: No, score=2.115 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, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, 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 8_xNJuaROTCH for ; Wed, 9 Sep 2015 01:03:36 -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 A67661B44D6 for ; Wed, 9 Sep 2015 01:03:36 -0700 (PDT) Received: from mail-ob0-f172.google.com (mail-ob0-f172.google.com [209.85.214.172]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 9D51127811A for ; Wed, 9 Sep 2015 17:03:34 +0900 (JST) Received: by obqa2 with SMTP id a2so1645855obq.3 for ; Wed, 09 Sep 2015 01:03:32 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.67.33 with SMTP id k1mr25923649oet.62.1441785812151; Wed, 09 Sep 2015 01:03:32 -0700 (PDT) Received: by 10.202.197.15 with HTTP; Wed, 9 Sep 2015 01:03:32 -0700 (PDT) In-Reply-To: <64af6848f1804b40a597f88974161b39@rew09926dag03b.domain1.systemhost.net> References: <7344a0ae9fb040268f68495bd0eff0fd@rew09926dag03b.domain1.systemhost.net> <70AEAEC90FCAE0408586E94F491A07EC04C8438D41@MS-BAN-E7MB01.intl1.one.verizon.com> <64af6848f1804b40a597f88974161b39@rew09926dag03b.domain1.systemhost.net> Date: Wed, 9 Sep 2015 01:03:32 -0700 Message-ID: From: Yoshifumi Nishida To: "philip.eardley" Content-Type: multipart/alternative; boundary=001a11c2e6da2cf9f3051f4bebaa Archived-At: Cc: multipathtcp Subject: Re: [multipathtcp] Preparing for the MPTCP interim 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, 09 Sep 2015 08:03:39 -0000 --001a11c2e6da2cf9f3051f4bebaa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, I have uploaded the slides for Xinpeng and Palanivelan on the wiki page ( https://tools.ietf.org/wg/mptcp/trac/wiki/Interim_Sept_2015 ) Thanks, -- Yoshi On Tue, Sep 8, 2015 at 1:55 AM, wrote: > Hi, > > > > Thanks to Xinpeng and A.Palanivelan for the slides /update. > > > > William, Christoph =E2=80=93 please make sure you send your slides well i= n advance > of the meeting. we=E2=80=99ll upload them first thing on Thursday (UK tim= e). Since > the meeting is remote, it=E2=80=99s even more important than usual that w= e have > everyone=E2=80=99s slides well ahead. > > > > Med =E2=80=93 we=E2=80=99ll assume you don=E2=80=99t want any time (unles= s you say so very soon) > > > > Please let us know if there are any other additional topics that need > discussing > > > > Thanks > > Phil & Yoshi > > > > *From:* Appanasamy, Palanivelan [mailto: > palanivelan.appanasamy@in.verizon.com] > *Sent:* 08 September 2015 07:37 > *To:* Eardley,PL,Philip,TUB8 R; multipathtcp@ietf.org > *Cc:* Harsha, Chetan H; ssenthil@cisco.com > *Subject:* RE: Preparing for the MPTCP interim > *Importance:* High > > > > Hi Phil, > > > > We will be participating in the interim and presenting the slides. > > Following IETF93 meeting, we decided to eliminate redundant and > overlapping use cases (that are being discussed in other drafts). > > > > We have our new slides with us and I will be sending you the updated > version by tomorrow (09/09/2015). Thanks. > > > > Regards, > > A.Palanivelan > > > > *From:* multipathtcp [mailto:multipathtcp-bounces@ietf.org > ] *On Behalf Of *philip.eardley@bt.com > *Sent:* Wednesday, September 02, 2015 6:55 PM > *To:* multipathtcp@ietf.org > *Subject:* [multipathtcp] Preparing for the MPTCP interim > > > > Hi, > > We have the MPTCP WG interim meeting next week. > https://tools.ietf.org/wg/mptcp/trac/wiki/Interim_Sept_2015 > > > > So far we have the following items on the agenda: > > > > * MPTCP proxy - Xinpeng Wei > > * Using MPTCP for channel combining for NASA project - William Ivancic > > * Deployment use cases - A.Palanivelan > > > > Xinpeng =E2=80=93 do you want a timeslot, or was there enough discussion = in Prague? > > William, A.Palanivelan =E2=80=93 please confirm that you=E2=80=99ll be pr= esenting. > > > > There should be plenty of time for some discussion on other topics. So fa= r > we got the following requests from Christoph Paasch: > > =E2=80=A2draft-paasch-mptcp-syncookies > > =E2=80=A2MPTCP's use behind layer-4 loadbalancers in server farms =E2=80= =93 draft soon > > > > Med =E2=80=93 do you want any agenda time to discuss any of the > draft-boucadair-mptcp-xxx drafts? > > > > We should also resolve any other open issues =E2=80=93 please let us know= if there > are any other ones: > > =E2=80=A2we have consensus to add an experimental MPTCP option to the pro= tocol bis > [see =E2=80=8Bhttps://datatracker.ietf.org/doc/draft-bonaventure-mptcp-ex= p-option/]. > But we have the question whether it should be 8 or 16 bits. > > > > The Operational experience draft is now exiting the WG into IESG, so we > can now also progress the protocol bis document. So if there=E2=80=99s an= ything > else that you think needs adding to the protocol bis, the interim meeting > would be a good time to discuss this. > > > > Thanks > > Phil & Yoshi. > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > > --001a11c2e6da2cf9f3051f4bebaa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,

I have uploaded the slides for Xinp= eng and Palanivelan on the wiki page ( https://tools.ietf.org/wg/mptcp/trac/wi= ki/Interim_Sept_2015 )

Thanks,
--
Yoshi

= On Tue, Sep 8, 2015 at 1:55 AM, <philip.eardley@bt.com>= wrote:

Hi,

=C2=A0

Thanks to Xinpeng and A.Palanivelan for the slides /upda= te.

=C2=A0

William, Christoph =E2=80=93 please make sure you send y= our slides well in advance of the meeting. we=E2=80=99ll upload them first = thing on Thursday (UK time). Since the meeting is remote, it=E2=80=99s even more important than usual that we have everyo= ne=E2=80=99s slides well ahead.

=C2=A0

Med =E2=80=93 we=E2=80=99ll assume you don=E2=80=99t wan= t any time (unless you say so very soon)

=C2=A0

Please let us know if there are any other additional top= ics that need discussing

=C2=A0

Thanks

Phil & Yoshi

=C2=A0

From: Appanasamy, Palanivelan [mailt= o:palanivelan.appanasamy@in.verizon.com]
Sent: 08 September 2015 07:37
To: Eardley,PL,Philip,TUB8 R; multipathtcp@ietf.org
Cc: Harsha, Chetan H; ssenthil@cisco.com
Subject: RE: Preparing for the MPTCP interim
Importance: High

=C2=A0

= Hi Phil,

= =C2=A0

= We will be participating in the interim and presenting the slides.

= Following IETF93 meeting, we decided to eliminate redundant and overlapping= use cases (that are being discussed in other drafts).=

= =C2=A0

= We have our new slides with us and I will be sending you the updated versio= n by tomorrow (09/09/2015). Thanks.

= =C2=A0

= Regards,

= A.Palanivelan

= =C2=A0

From: multipathtcp [mailto:multipathtcp-boun= ces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: Wednesday, September 02, 2015 6:55 PM
To: multi= pathtcp@ietf.org
Subject: [multipathtcp] Preparing for the MPTCP interim

=C2=A0

Hi,

We have the MPTCP WG interim meeting next week. https://tools.ietf.org/wg/mptcp/trac/wiki/Interim_Sept_2015<= /a>

=C2=A0

So far we have the following items on the agenda:

=C2=A0

* MPTCP proxy - Xinpeng Wei

* Using MPTCP for channel combining for NASA project - William Ivan= cic

* Deployment use cases - A.Palanivelan

=C2=A0

Xinpeng =E2=80=93 do you want a timeslot, or was there enough discu= ssion in Prague?

William, A.Palanivelan =E2=80=93 please confirm that you=E2=80=99ll= be presenting.

=C2=A0

There should be plenty of time for some discussion on other topics.= So far we got the following requests from Christoph Paasch:<= /span>

=E2=80=A2draft-paasch-mptcp-syncookies

=E2=80=A2MPTCP's use behind layer-4 loadbalancers in server far= ms =E2=80=93 draft soon =C2=A0

=C2=A0

Med =E2=80=93 do you want any agenda time to discuss any of the dra= ft-boucadair-mptcp-xxx drafts?

=C2=A0

We should also resolve any other open issues =E2=80=93 please let u= s know if there are any other ones:

=E2=80=A2we have consensus to add an experimental MPTCP option to t= he protocol bis [see =E2=80=8Bhttps://datatracker.i= etf.org/doc/draft-bonaventure-mptcp-exp-option/]. But we have the question whether it should be 8 or 16 bits.<= /span>

=C2=A0

The Operational experience draft is now exiting the WG into IESG, s= o we can now also progress the protocol bis document. So if there=E2=80=99s= anything else that you think needs adding to the protocol bis, the interim meeting would be a good time to discuss t= his.

=C2=A0

Thanks

Phil & Yoshi.


_______________________________________________
multipathtcp mailing list
multipathtcp@ietf.org
https://www.ietf.org/mailman/listinfo/multipathtcp=


--001a11c2e6da2cf9f3051f4bebaa-- From nobody Wed Sep 9 11:19: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 D4C351B2CE8 for ; Wed, 9 Sep 2015 11:19:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.515 X-Spam-Level: * X-Spam-Status: No, score=1.515 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, 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 iNZISNXlDuTy for ; Wed, 9 Sep 2015 11:18:58 -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 933021B3394 for ; Wed, 9 Sep 2015 11:18:58 -0700 (PDT) Received: from mail-oi0-f45.google.com (mail-oi0-f45.google.com [209.85.218.45]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 69A662780A7 for ; Thu, 10 Sep 2015 03:18:56 +0900 (JST) Received: by oibi136 with SMTP id i136so10683225oib.3 for ; Wed, 09 Sep 2015 11:18:54 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.202.9.132 with SMTP id 126mr24961163oij.4.1441822734935; Wed, 09 Sep 2015 11:18:54 -0700 (PDT) Received: by 10.202.197.15 with HTTP; Wed, 9 Sep 2015 11:18:54 -0700 (PDT) In-Reply-To: <7344a0ae9fb040268f68495bd0eff0fd@rew09926dag03b.domain1.systemhost.net> References: <7344a0ae9fb040268f68495bd0eff0fd@rew09926dag03b.domain1.systemhost.net> Date: Wed, 9 Sep 2015 11:18:54 -0700 Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: multipart/alternative; boundary=001a113d1024f1f029051f548338 Archived-At: Subject: Re: [multipathtcp] Preparing for the MPTCP interim 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, 09 Sep 2015 18:19:05 -0000 --001a113d1024f1f029051f548338 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi, Just in case. You can check webex and audio conference info for the interim at the following URL. https://mailarchive.ietf.org/arch/msg/multipathtcp/o59aNxS_mgKSKSXxohCoHSrq= GtE You can find the same info on the wiki page. Please let us know if you have questions to join the meeting. Thanks, -- Yoshi & Phil On Wed, Sep 2, 2015 at 6:24 AM, wrote: > Hi, > > We have the MPTCP WG interim meeting next week. > https://tools.ietf.org/wg/mptcp/trac/wiki/Interim_Sept_2015 > > > > So far we have the following items on the agenda: > > > > * MPTCP proxy - Xinpeng Wei > > * Using MPTCP for channel combining for NASA project - William Ivancic > > * Deployment use cases - A.Palanivelan > > > > Xinpeng =E2=80=93 do you want a timeslot, or was there enough discussion = in Prague? > > William, A.Palanivelan =E2=80=93 please confirm that you=E2=80=99ll be pr= esenting. > > > > There should be plenty of time for some discussion on other topics. So fa= r > we got the following requests from Christoph Paasch: > > =E2=80=A2draft-paasch-mptcp-syncookies > > =E2=80=A2MPTCP's use behind layer-4 loadbalancers in server farms =E2=80= =93 draft soon > > > > Med =E2=80=93 do you want any agenda time to discuss any of the > draft-boucadair-mptcp-xxx drafts? > > > > We should also resolve any other open issues =E2=80=93 please let us know= if there > are any other ones: > > =E2=80=A2we have consensus to add an experimental MPTCP option to the pro= tocol bis > [see =E2=80=8Bhttps://datatracker.ietf.org/doc/draft-bonaventure-mptcp-ex= p-option/]. > But we have the question whether it should be 8 or 16 bits. > > > > The Operational experience draft is now exiting the WG into IESG, so we > can now also progress the protocol bis document. So if there=E2=80=99s an= ything > else that you think needs adding to the protocol bis, the interim meeting > would be a good time to discuss this. > > > > Thanks > > Phil & Yoshi. > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > > --001a113d1024f1f029051f548338 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi,
Just in case. You can check webex and audio confer= ence info for the interim at the following URL.

https://mailarchive.ietf.org/arch/msg/multipathtcp/o59aNxS_mg= KSKSXxohCoHSrqGtE

You can find the same in= fo on the wiki page. Please let us know if you have questions to join the m= eeting.

Thanks,
--
Yoshi &= Phil


<= br>
On Wed, Sep 2, 2015 at 6:24 AM, <philip= .eardley@bt.com> wrote:

Hi,

We have the MPTCP WG interim meeting next= week. https://tools.ietf.org/wg/mptcp/trac/wiki/Interim_Sept_2015<= /a>

=C2=A0

So far we have the following items on the= agenda:

=C2=A0

* MPTCP proxy - Xinpeng Wei

* Using MPTCP for channel combining for N= ASA project - William Ivancic

* Deployment use cases - A.Palanivelan=

=C2=A0

Xinpeng =E2=80=93 do you want a timeslot,= or was there enough discussion in Prague?

William, A.Palanivelan =E2=80=93 please c= onfirm that you=E2=80=99ll be presenting.

=C2=A0

There should be plenty of time for some d= iscussion on other topics. So far we got the following requests from Christ= oph Paasch:

=E2=80=A2draft-paasch-mptcp-syncookies=

=E2=80=A2MPTCP's use behind layer-4 l= oadbalancers in server farms =E2=80=93 draft soon =C2=A0

=C2=A0

Med =E2=80=93 do you want any agenda time= to discuss any of the draft-boucadair-mptcp-xxx drafts?

=C2=A0

We should also resolve any other open iss= ues =E2=80=93 please let us know if there are any other ones:=

=E2=80=A2we have consensus to add an expe= rimental MPTCP option to the protocol bis [see =E2=80=8Bhttps://datatracker.ietf.org/doc/draft-bonaventure-mptcp-exp-option/]. But we have the question whether it should be 8 or 16 bits.

=C2=A0

The Operational experience draft is now e= xiting the WG into IESG, so we can now also progress the protocol bis docum= ent. So if there=E2=80=99s anything else that you think needs adding to the protocol bis, the interim meeting would be a good time to discuss t= his.

=C2=A0

Thanks

Phil & Yoshi.


_______________________________________________
multipathtcp mailing list
multipathtcp@ietf.org
https://www.ietf.org/mailman/listinfo/multipathtcp=


--001a113d1024f1f029051f548338-- From nobody Wed Sep 9 13:39:02 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 999FE1B3ADE for ; Wed, 9 Sep 2015 13:39:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 ChRDb8jaZxPS for ; Wed, 9 Sep 2015 13:38:59 -0700 (PDT) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id DDC861B384E for ; Wed, 9 Sep 2015 13:38:58 -0700 (PDT) Received: from mbpobo.local (host-78-129-6-94.dynamic.voo.be [78.129.6.94]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id EF3A911E4CD; Wed, 9 Sep 2015 22:38:51 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be EF3A911E4CD DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1441831132; bh=bftYGXu8vN/LL21xYfJPHtmLBz7macLGvWT79UGHFxk=; h=Reply-To:Subject:References:To:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=lbQiTyXbTc6NMRmelHmCTdi4yZqua/YWTSVrKBeeelrJMrFC6Cf5NLJVn8IanR37w EfvxwLjx+YsPzn55x8xLDLG1REe8k+gy1YYj0Mh0xT8PVztxQs3SWKEvnm0GDE8S7Y Gu1uojDQP9o7li3NbbPdN/n7z9NYh5RyfL63CsfM= References: <20150908035557.GB73228@Chimay.local> To: Christoph Paasch , MultiPath WG From: Olivier Bonaventure Message-ID: <55F098DB.8020201@uclouvain.be> Date: Wed, 9 Sep 2015 22:38:51 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150908035557.GB73228@Chimay.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99-beta1 at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: EF3A911E4CD.A3AD7 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Subject: Re: [multipathtcp] Fwd: New Version Notification for draft-paasch-mptcp-loadbalancer-00.txt 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: Wed, 09 Sep 2015 20:39:01 -0000 Christoph, > > we have submitted a draft discussing the issues when using MPTCP behind > layer-4 loadbalancers. Thanks for bringing this to the list. This is indeed an important problem. As I might be late during tomorrow's telco, let me try to answer by email. A first point that we might want to clarify in the document is how ECMP works with Multipath TCP and regular TCP. With regular TCP, some load balancers behave in a purely stateless manner and compute a hash over the five-tuple in each packet to distribute the load among a set of servers. ECMP --- server1 +----- server2 With single homed and single stack clients, this ECMP solution ensures that all the connections sent by one host (i.e. one IP address) will be received by the same server if the hashing is independant of the source port. Otherwise, connections from the same host might hit different servers. If the clients are either multihomed (e.g. smartphones) or dual-stack, then using a hash-based load balancing that does not include the source port in the computation does not ensure that all the connections from one client will hit the same server. With Multipath TCP, a single connection may use different subflows and each subflow has its own five-tuple. When ECMP is used, then subflows from the same Multipath TCP connection might hit different servers. Let us now consider stateful load balancers (LB). For simplicity, we assume that the load balancer maintains a table that maps each TCP connection, identified by a five-tuple on a given server. The table might also be used to perform NAT. The LB can use any technique to build this table (random, RR, load-based solutions, ...). As an example, let us consider a load balancer that resieds in front of N servers as shown below : LB ----- server1 +------- server2 When the LB receives a SYN with the MP_CAPABLE option from a client, it must insert an entry for the corresponding five-tuple inside its table. For regular TCP, this would be sufficient. For Multipath TCP, this is not enough since it needs to ensure that all the subflows that belong to this connection will be forwarded to the same server. In your draft, you propose to change the way tokens are computed and discuss different ways to perform the handshake. Let me suggest a different approach that might be worth to compare. To support Multipath TCP efficiently in this setup, we need to ensure the following properties for the tokens that are used (on the server side) : - tokens are unique (at time t, server1 and server2 cannot use the same token for different connections) - tokens are known by both the LB and the server that is handling for the connection Instead of computing the keys (and thus indirectly the token) on the servers, why not selecting the keys for the MP_CAPABLE option in the load balancer ? Let us consider the following scenario : client LB server SYN + MP_CAPABLE (K_A) -----------------------> (client sends normal key) SYN + MP_CAPABLE (K_A,K_B) -----------------------> (LB computes key for server) SYN/ACK + MP_CAPABLE (K_B) <--------------------------- (normal MPTCP segment) ACK + MP_CAPABLE_ACK (K_A, K_B) --------------------------------> (no change to this ack) Since the LB computes the key that will be used by the server, it can ensure that the (token extracted from the key) is unique and also remember it for future subflows to pin them to the good server. There are probably different techniques that the LB could use to generate these keys on behalf of the server, but I don't think that they need to be specified in an IETF document. It's up to each implementor to find an efficient way to do that. One issue that needs to be discussed is how the LB can convey the key to the server in the SYN packet. There are different techniques that are possible and we should probably select one to ensure the interoperability between a LB and servers : - add K_B to the MP_CAPABLE option, but this is likely to be beyond the maximum length of the TCP options - add K_B in the payload of the SYN segment (but we'll need to check the impact on TFO) - encapsulate the SYN segment inside something, like a UDP segment with a TLV format that has enough space for a SYN segment and the additional key - invent a hack to encode the 64 bits key inside some "unused" fields of the IP/TCP headers (say IP id, TCP ack number, IPv6 flowlabel, TCP timestamp echo, ...) - ... At this stage, I'd opt for an encapsulation which seems to be cleaner to me. It also forces the servers to be aware of the presence of the LB, which seems a useful feature to me. Comments are, of course, welcome Olivier From nobody Wed Sep 9 14:22:46 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 661E51ACDF8 for ; Wed, 9 Sep 2015 14:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 H0t6aNqghDXN for ; Wed, 9 Sep 2015 14:22:43 -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 B208E1A8846 for ; Wed, 9 Sep 2015 14:22:37 -0700 (PDT) Received: from mbpobo.local (host-78-129-6-94.dynamic.voo.be [78.129.6.94]) (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 38CC91C5579 for ; Wed, 9 Sep 2015 23:18:47 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 38CC91C5579 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1441833527; bh=XxnhtRIRgbTPJ7fIYCGwUbm0cm41Qx5ruR9TxGcgjpM=; h=Reply-To:To:From:Subject:Message-ID:Date:MIME-Version: Content-Type:Content-Transfer-Encoding; b=GDMAp9RCQKnllQIOJuzLysTYw5LYgHwbtjx5jG+2BnKxqacuIrJZi8ZCHmUYqCN+j UlE6/iY3WsJdEx4voiTgwIzgbLEqjelE5dviETgq1ZfC+taWBwSHrpRa3M/wyWqaPw 5xsrRfhIb0Gdap3M3McnFrUox8sZcLPFNoPkIrj8= To: multipathtcp From: Olivier Bonaventure Message-ID: <55F0A236.2090402@uclouvain.be> Date: Wed, 9 Sep 2015 23:18:46 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; 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 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: 38CC91C5579.A3790 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Subject: [multipathtcp] Supporting ECMP and load balancers with Multipath TCP 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: Wed, 09 Sep 2015 21:22:44 -0000 Hello, Let me continue the discussion about load balancing with a slightly different viewpoint than in the previous email. In some deployments several load balancers are used and ECMP is deployed to balance the load between them. A simplified architecture would be ECMP ------ LB1 ---- server1 | +------ server2 | +-------- LB2 ----- server3 +------- server4 In this architecture, each LB exposes the same public IP address This architecture poses a challenge for Multipath TCP since the different subflows, typically coming from different source addresses, that belong to the same Multipath TCP connection will not be delivered to the same LB and thus could reach different servers. I think that the only way to support this kind of deployment would be to attach a public address to each server. By "address", I mean either an IP address (in IPv6, this would be easy) or a combination IP address + port (in an IPv4 environment having limited number of available public addresses). If each server has its own public address, then one possibility would be to operate as follows. configuration - each server has a public IP address - all the servers behind one LB belong to the same prefix - each LB advertises the prefix that contains all its attached servers a. The SYN with MP_CAPABLE sent by the client enters the ECMP and is sent to one LB. We assume that the ECMP device ensures that all packets from one TCP connection identified by the classical five tuple are sent to the same LB b. The LB processes the SYN and decides to forward it to one particular server. It may add information to the packet (see previous email) or perform a specific computation for the token (see Christoph's draft) c. The server replies with a SYN+ACK and one bit in the MP_CAPABLE option that indicates that this IP address of the server (i.e. the one of the load balancer) cannot be used to establish subflows d. The client confirms with a third ACK e. The server advertises its public address inside an ADD_ADDR option. This address advertisement includes one bit that indicates that it can be used to establish subflows When a client sends a SYN with MP_JOIN to the address advertised by the server, the routing ensures that it reaches the correct server. ECMP works as usual and the LB does not need to be involved in the processing of this segment. What happens if a client sends a SYN+MP_JOIN towards the address of the load balancer ? The load balancer simply replies with a RST and rejects the subflow. The LB might contact the server that is responsible for this connection and suggest the retransmission of the ADD_ADDR option that might have been lost. Let me know if you think that this idea could work. If so, I can try to document it in more details. Comments and counter examples from load balancing experts are more than welcome Olivier From nobody Wed Sep 9 19:21:55 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 1925F1B54AD for ; Wed, 9 Sep 2015 19:21:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 nLNf9BdmcgRR for ; Wed, 9 Sep 2015 19:21:52 -0700 (PDT) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 629C21B324D for ; Wed, 9 Sep 2015 19:21:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1441851711; x=2305765311; 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=LA7cFnRxhO+GP982Zt/fYYtlo8G+OhmrXre7R97If6I=; b=fpXaY1k1XBGrwUNolJe747/6pegtmM2mr4HqhK8s0B8tW6CwbdGh42q8lBpw1Idq bjbXlgvwEokmbYsY2bxX/dy0H8H414NFr+x7cqs64HdLs1Im1aPo6zVOGsCV00b4 UmDYZtnzB1CnpRDrBh2KcKFp0RrFI0QyaU4Xpu3Z1Y6C+bRnGBlyQpj3g1vSsfNL 226omvnho8ntBJMbJNfp51KGXXCRLZosjhaWJZwrbIH7a6dxdjxaSaKkUCVsU8c3 HWsJ25LQN266H0SO+ZWdkpgRGDkSltPZ3c0eMRWqo8a6Q9H6e8Ww5oVbSEpDMHHb b2Fn1cNVHCGQrDuPUgfXGA==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id F6.62.22968.F39E0F55; Wed, 9 Sep 2015 19:21:51 -0700 (PDT) X-AuditID: 11973e13-f79006d0000059b8-60-55f0e93fb7d2 Received: from marigold.apple.com (marigold.apple.com [17.128.115.132]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id 26.91.22881.F39E0F55; Wed, 9 Sep 2015 19:21:51 -0700 (PDT) Received: from localhost ([17.153.77.168]) by marigold.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NUF0022AVWF0T60@marigold.apple.com> for multipathtcp@ietf.org; Wed, 09 Sep 2015 19:21:51 -0700 (PDT) Sender: cpaasch@apple.com Date: Wed, 09 Sep 2015 19:21:51 -0700 From: Christoph Paasch To: Olivier Bonaventure Message-id: <20150910022151.GF42530@Chimay.local> References: <20150908035557.GB73228@Chimay.local> <55F098DB.8020201@uclouvain.be> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline In-reply-to: <55F098DB.8020201@uclouvain.be> User-Agent: Mutt/1.5.23 (2014-03-12) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNLMWRmVeSWpSXmKPExsUi2FAYpWv/8kOowaO5OhafV19nc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXRsfx/4wF7boV2262MDcwTlTqYuTkkBAwkehYsIkdwhaTuHBv PVsXIxeHkMBeRomzrw+zwRRtWfyUGcQWEpjEJLH4fQ5EUTeTxOztj1hBEsICkhLdd+6AFbEI qEp867zJBGKzCWhJvL3dDlYjImAlcer0dLBtzAIaEpPWHGHpYuQA6k2TaNttAxLmFTCU6Luw hAViV7DEpJMNbBBxQYkfk++xQLRqSazfeZwJwpaWePR3BjvIGE4BHYl3vRUgYVEBFYkrE95C /fWTVWL1xsIJjCKzkEyahWTSLCSTFjAyr2IUyk3MzNHNzDPVSywoyEnVS87P3cQICu3pdsI7 GE+vsjrEKMDBqMTDm3DxQ6gQa2JZcWXuIUZpDhYlcd7P5UAhgfTEktTs1NSC1KL4otKc1OJD jEwcnFINjFUFzl1iEw5Kncm1PLauQPJTUd+qDJ6yijcfUlev2iq3doLJ57WSX37clH/6KuDL zHivM2vyeLmXltRLLe2QOMF7K2fZDJGuuqiizNnHOW/E6PbFcsnda1SVt76bmWP9z5JvzUkz ryDLHWz2Akz56n4Kix727jtXz7Kd2XNn1IP+GcXrt3qcVWIpzkg01GIuKk4EAAp6ITtOAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPLMWRmVeSWpSXmKPExsUi2FDcomv/8kOowYrjmhafV19nc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXRsfx/4wF7boV2262MDcwTlTqYuTkkBAwkdiy+CkzhC0mceHe ejYQW0hgEpPE4vc5XYxcQHY3k8Ts7Y9YQRLCApIS3XfugDWwCKhKfOu8yQRiswloSby93Q5W IyJgJXHq9HR2EJtZQENi0pojLF2MHEC9aRJtu21AwrwChhJ9F5awQOwKlph0soENIi4o8WPy PRaIVi2J9TuPM0HY0hKP/s5gBxnDKaAj8a63AiQsKqAicWXCW/YJjIKzkHTPQtI9C0n3Akbm VYwCRak5iZVmeokFBTmpesn5uZsYwcFYGLWDsWG51SFGAQ5GJR7ehIsfQoVYE8uKK3MPMUpw MCuJ8KZtBwrxpiRWVqUW5ccXleakFh9ilOZgURLnbRB5FSokkJ5YkpqdmlqQWgSTZeLglGpg bPYwlE9t3Zjrwzan2L/SYvlJXkOD/J/H3q1evrpt8c+suL4n3bOnR/4QFNjg/6dow3QxVSfN yguJdactvr4Xyq5PiS6VeDdL6smejyerSpgCEwTbD2yaulQxUu1MsLr1dGn5a5ceOFbvrs3c c1Mx1aRh38QFn8O8BCJ84u5XnHv+c/mEybenKbEUZyQaajEXFScCAHnaFHlCAgAA Archived-At: Cc: MultiPath WG Subject: Re: [multipathtcp] Fwd: New Version Notification for draft-paasch-mptcp-loadbalancer-00.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: Thu, 10 Sep 2015 02:21:54 -0000 Hello Olivier, On 09/09/15 - 22:38:51, Olivier Bonaventure wrote: > >we have submitted a draft discussing the issues when using MPTCP behind > >layer-4 loadbalancers. > > Thanks for bringing this to the list. This is indeed an important problem. > As I might be late during tomorrow's telco, let me try to answer by email. > > A first point that we might want to clarify in the document is how ECMP > works with Multipath TCP and regular TCP. > > With regular TCP, some load balancers behave in a purely stateless manner > and compute a hash over the five-tuple in each packet to distribute the load > among a set of servers. > > ECMP --- server1 > +----- server2 > > > With single homed and single stack clients, this ECMP solution ensures that > all the connections sent by one host (i.e. one IP address) will be received > by the same server if the hashing is independant of the source port. > Otherwise, connections from the same host might hit different servers. > > If the clients are either multihomed (e.g. smartphones) or dual-stack, then > using a hash-based load balancing that does not include the source port in > the computation does not ensure that all the connections from one client > will hit the same server. > > With Multipath TCP, a single connection may use different subflows and each > subflow has its own five-tuple. When ECMP is used, then subflows from the > same Multipath TCP connection might hit different servers. > > Let us now consider stateful load balancers (LB). For simplicity, we assume > that the load balancer maintains a table that maps each TCP connection, > identified by a five-tuple on a given server. The table might also be used > to perform NAT. The LB can use any technique to build this table (random, > RR, load-based solutions, ...). As an example, let us consider a load > balancer that resieds in front of N servers as shown below : > > > LB ----- server1 > +------- server2 > > > When the LB receives a SYN with the MP_CAPABLE option from a client, it must > insert an entry for the corresponding five-tuple inside its table. For > regular TCP, this would be sufficient. For Multipath TCP, this is not enough > since it needs to ensure that all the subflows that belong to this > connection will be forwarded to the same server. In your draft, you propose > to change the way tokens are computed and discuss different ways to perform > the handshake. Let me suggest a different approach that might be worth to > compare. > > To support Multipath TCP efficiently in this setup, we need to ensure the > following properties for the tokens that are used (on the server side) : > - tokens are unique (at time t, server1 and server2 cannot use the same > token for different connections) > - tokens are known by both the LB and the server that is handling for the > connection > > Instead of computing the keys (and thus indirectly the token) on the > servers, why not selecting the keys for the MP_CAPABLE option in the load > balancer ? > > Let us consider the following scenario : > > client LB server > > SYN + MP_CAPABLE (K_A) > -----------------------> > (client sends normal key) > > > SYN + MP_CAPABLE (K_A,K_B) > -----------------------> > (LB computes key for server) > > > SYN/ACK + MP_CAPABLE (K_B) > <--------------------------- > (normal MPTCP segment) > > > ACK + MP_CAPABLE_ACK (K_A, K_B) > --------------------------------> > (no change to this ack) > > > Since the LB computes the key that will be used by the server, it can ensure > that the (token extracted from the key) is unique and also remember it for > future subflows to pin them to the good server. There are probably different > techniques that the LB could use to generate these keys on behalf of the > server, but I don't think that they need to be specified in an IETF > document. It's up to each implementor to find an efficient way to do that. > > One issue that needs to be discussed is how the LB can convey the key to the > server in the SYN packet. There are different techniques that are possible > and we should probably select one to ensure the interoperability between a > LB and servers : > - add K_B to the MP_CAPABLE option, but this is likely to be beyond the > maximum length of the TCP options > - add K_B in the payload of the SYN segment (but we'll need to check the > impact on TFO) > - encapsulate the SYN segment inside something, like a UDP segment with a > TLV format that has enough space for a SYN segment and the additional key > - invent a hack to encode the 64 bits key inside some "unused" fields of the > IP/TCP headers (say IP id, TCP ack number, IPv6 flowlabel, TCP timestamp > echo, ...) > - ... > > At this stage, I'd opt for an encapsulation which seems to be cleaner to me. > It also forces the servers to be aware of the presence of the LB, which > seems a useful feature to me. > > Comments are, of course, welcome I really like this idea. Very often, IP-in-IP encapsulation is done from the loadbalancer to the server. Thus, the key could even be placed in an IP-option. As everything is local to the data-center there shouldn't be an issue with adding a new IP-option. But as you point out in the other mail, when multiple loadbalancers are being used we have an issue again. Maybe, there is a way to generate the key in such a way that we can guarantee uniqueness across the loadbalancers? Cheers, Christoph From nobody Wed Sep 9 19:38:17 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 9763C1B55EF for ; Wed, 9 Sep 2015 19:38:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 HDUgzA9AIJdU for ; Wed, 9 Sep 2015 19:38:13 -0700 (PDT) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9C001B55ED for ; Wed, 9 Sep 2015 19:38:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1441852693; x=2305766293; 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=rAGBnNJaWS/fQXeENFvv3BHqm27VMM5kbxdLWld7FfQ=; b=SbeUlUg1zAKf2bkFISj2JlE1IBDSWut1cDEICSKAjWX9H+U45dp9kv4vDg06MFM1 igs0w2/PveyhqMDMbQtmGmHi7tH2uLJNRk4dXzWwNnbKx1YYNsxbXsdc/oKlh9+S 5J4jnFI2HZH9Nl7hiKL0e4Tv7N9EEF3JnMRK7u+WSU78jFhTc3zOYKgrpy9+YMTe 2tJQ+0usUbGxzVEBuiGQa26a0oegea8J/BEX5e9u12rIhkRRIxwJ1d8E3cLtW1AU +VDyOV7f+P7PayMliZxyX3bUSJIj54BBS1QzrqwA0JykYx+spqEdF0rsyp1Tgz+n 1lZurjbaSrUZkj57yXGHzQ==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 9B.C6.22968.51DE0F55; Wed, 9 Sep 2015 19:38:13 -0700 (PDT) X-AuditID: 11973e13-f79006d0000059b8-99-55f0ed151b53 Received: from marigold.apple.com (marigold.apple.com [17.128.115.132]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id 17.32.22881.51DE0F55; Wed, 9 Sep 2015 19:38:13 -0700 (PDT) Received: from localhost ([17.153.77.168]) by marigold.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NUF002CGWNP0T60@marigold.apple.com> for multipathtcp@ietf.org; Wed, 09 Sep 2015 19:38:13 -0700 (PDT) Sender: cpaasch@apple.com Date: Wed, 09 Sep 2015 19:38:13 -0700 From: Christoph Paasch To: Olivier Bonaventure Message-id: <20150910023813.GG42530@Chimay.local> References: <55F0A236.2090402@uclouvain.be> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline In-reply-to: <55F0A236.2090402@uclouvain.be> User-Agent: Mutt/1.5.23 (2014-03-12) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUi2FAYpSv69kOowabDqhafV19nc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxoQ1D9kKnilUrOk/y97AuECqi5GTQ0LARGLujoPMELaYxIV7 69m6GLk4hAT2Mko0TV/FDFP0as0GZojEJCaJCd/uM0E43UwSLTv2sIJUCQtISnTfuQPWwSKg KnH95Fswm01AS+Lt7XawGhEBK4lTp6ezg9jMAhoS1x82s0H0Bks8WPwDrIZXwFBi3/NWFhBb SEBbYuqMHhaIuKDEj8n3WCB6tSTW7zzOBGFLSzz6OwNsJqeAjsTaKScZQWxRARWJKxPeskN8 sIBNov2vxQRGkVlIRs1CMmoWklELGJlXMQrlJmbm6GbmmeolFhTkpOol5+duYgQF+HQ74R2M p1dZHWIU4GBU4uFNuPghVIg1say4MvcQozQHi5I47+dyoJBAemJJanZqakFqUXxRaU5q8SFG Jg5OqQbGvHOfNpppLNdp/WzClDMz+rDA6Ttzfunfm5QhWsy4+MVMvuuybHz8c598s4y5fN/j aIxWguu9TcF7I3Um+b18Gmvzfs0fj5tGWQ1T+LkXtTGHrg1RlXN15Jv1Yrqj0oWDKWLGqTz9 /lsUz/FNunFs1nyHtY6nwsx35yyf9/dNwiHh0JBreStmKbEUZyQaajEXFScCAJQQATNRAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUi2FDcoiv69kOowbsvShafV19nc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxoQ1D9kKnilUrOk/y97AuECqi5GTQ0LAROLVmg3MELaYxIV7 69m6GLk4hAQmMUlM+HafCcLpZpJo2bGHFaRKWEBSovvOHbAOFgFViesn34LZbAJaEm9vt4PV iAhYSZw6PZ0dxGYW0JC4/rCZDaI3WOLB4h9gNbwChhL7nreygNhCAtoSU2f0sEDEBSV+TL7H AtGrJbF+53EmCFta4tHfGWAzOQV0JNZOOckIYosKqEhcmfCWfQKj4Cwk7bOQtM9C0r6AkXkV o0BRak5ipZleYkFBTqpecn7uJkZwSBZG7WBsWG51iFGAg1GJhzfh4odQIdbEsuLK3EOMEhzM SiK8aduBQrwpiZVVqUX58UWlOanFhxiTgQExkVlKNDkfGC95JfGGJiYGJsbGZsbG5ibmpAkr ifM2iLwKFRJITyxJzU5NLUgtgtnCxMEp1cDIcmy7g+GfF/GWQZcmm32fX959xYf749uLX5yu MbWELJFsenzx5+EHfmLrf0bVM7JuiJq+80bi6ZSlwVvuXXvbMXtSSO67pJZ/mXLTg9dZnHdZ teHKzESLIOGZe0I8NK6naa3OaPWY7O5ofMWO7a6p44QH5m+f3Sr9I5YewjnldligyIf2s/zP lFiKMxINtZiLihMBsBEuk40CAAA= Archived-At: Cc: multipathtcp Subject: Re: [multipathtcp] Supporting ECMP and load balancers 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: Thu, 10 Sep 2015 02:38:15 -0000 Hello, On 09/09/15 - 23:18:46, Olivier Bonaventure wrote: > Let me continue the discussion about load balancing with a slightly > different viewpoint than in the previous email. In some deployments several > load balancers are used and ECMP is deployed to balance the load between > them. A simplified architecture would be > > ECMP ------ LB1 ---- server1 > | +------ server2 > | > +-------- LB2 ----- server3 > +------- server4 > > In this architecture, each LB exposes the same public IP address > > > This architecture poses a challenge for Multipath TCP since the different > subflows, typically coming from different source addresses, that belong to > the same Multipath TCP connection will not be delivered to the same LB and > thus could reach different servers. > > I think that the only way to support this kind of deployment would be to > attach a public address to each server. By "address", I mean either an IP > address (in IPv6, this would be easy) or a combination IP address + port (in > an IPv4 environment having limited number of available public addresses). If > each server has its own public address, then one possibility would be to > operate as follows. > > configuration > > - each server has a public IP address > - all the servers behind one LB belong to the same prefix > - each LB advertises the prefix that contains all its attached servers > > a. The SYN with MP_CAPABLE sent by the client enters the ECMP and is sent to > one LB. We assume that the ECMP device ensures that all packets from one TCP > connection identified by the classical five tuple are sent to the same LB > > b. The LB processes the SYN and decides to forward it to one particular > server. It may add information to the packet (see previous email) or perform > a specific computation for the token (see Christoph's draft) > > c. The server replies with a SYN+ACK and one bit in the MP_CAPABLE option > that indicates that this IP address of the server (i.e. the one of the load > balancer) cannot be used to establish subflows This is similar to the proxy-bit proposed by draft-wei-mptcp-proxy-mechanism. > > d. The client confirms with a third ACK > > e. The server advertises its public address inside an ADD_ADDR option. This > address advertisement includes one bit that indicates that it can be used to > establish subflows > > When a client sends a SYN with MP_JOIN to the address advertised by the > server, the routing ensures that it reaches the correct server. ECMP works > as usual and the LB does not need to be involved in the processing of this > segment. > > What happens if a client sends a SYN+MP_JOIN towards the address of the load > balancer ? The load balancer simply replies with a RST and rejects the > subflow. The LB might contact the server that is responsible for this > connection and suggest the retransmission of the ADD_ADDR option that might > have been lost. > > Let me know if you think that this idea could work. If so, I can try to > document it in more details. Comments and counter examples from load > balancing experts are more than welcome I believe it does work (and actually would be beneficial as it reduces the traffic on the loadbalancer as new subflows are directly routed to the server). One difficulty might be to have enough public IP-addresses, as changing the destination port might have other problems (e.g., ISP's rate-limiting or blocking traffic that looks like bittorrent). Also, a server now becomes directly addressable and might thus be more vulnerable to DDoS attacks. But overall, I think this proposal is also a good tradeoff to solve this loadbalancer-issue. Cheers, Christoph > > > Olivier > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_multipathtcp&d=BQICAg&c=eEvniauFctOgLOKGJOplqw&r=fSuJ9mpJ1IB1Lz-sIp_MCe23kZIFT6UKt4EhsewNEmA&m=7oKUbtxwqMtjY3x9J2hbtuTWFbvWo58BIQoQv7olTFM&s=84qAjYvDXiFPdApf6VriNL8UpACuDalDvI24CxwFnyo&e= From nobody Thu Sep 10 02:45:53 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 3B68B1B5FE8 for ; Thu, 10 Sep 2015 02:45:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 IaWV5SqMugTq for ; Thu, 10 Sep 2015 02:45:49 -0700 (PDT) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id BFFCE1B5FD5 for ; Thu, 10 Sep 2015 02:45:49 -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@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 6DA2EB405B; Thu, 10 Sep 2015 11:45:11 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 6DA2EB405B DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1441878311; bh=Mku/CKIfkVIo/VJYT/OPjAFl4CUn58h9oYZKV+jmlac=; h=Reply-To:Subject:References:To:Cc:From:Message-ID:Date: MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=TMYaM+nlnGL5etZcP8Nt3m5C054Zi4oU7/kL4dYqwghB+54dRhKdNdk3nsu/zhTy7 nY+BH/GBo1kmkAPwGr04/BeSvCubev1KJKxqhrsL9zgiKc//meprMbpBGL48wUoPWD bRivw/DIZtXhDE+ql+wUs+oIQGA140vjbzQw/LLE= References: <55F0A236.2090402@uclouvain.be> <20150910023813.GG42530@Chimay.local> To: Christoph Paasch From: Olivier Bonaventure Message-ID: <55F15126.9080408@uclouvain.be> Date: Thu, 10 Sep 2015 11:45:10 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150910023813.GG42530@Chimay.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99-beta1 at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 6DA2EB405B.A6656 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Cc: multipathtcp Subject: Re: [multipathtcp] Supporting ECMP and load balancers with Multipath TCP 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: Thu, 10 Sep 2015 09:45:51 -0000 Christoph, > > I believe it does work (and actually would be beneficial as it reduces the > traffic on the loadbalancer as new subflows are directly routed to the > server). > > One difficulty might be to have enough public IP-addresses, as changing the > destination port might have other problems (e.g., ISP's rate-limiting or blocking > traffic that looks like bittorrent). This is a difficult with IPv4, but given the growth of IPv6 traffic, we should design for IPv6 and accept to have less features in IPv4. The key application for load balancing with MPTCP will likely be HTTP2 on top of TLS on top of MPTCP over IPv6. This should be our main reference for the design. > Also, a server now becomes directly addressable and might thus be more > vulnerable to DDoS attacks. Yes, but you can think of techniques to mitigate such attacks by changing the IPv6 addresses of the servers when an attack occurs on one of the servers. We have enough addresses in IPv6 to even think about IPv6 addresses that are only used for one connection. Olivier From nobody Thu Sep 10 03:05:48 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 2DD4B1B6418 for ; Thu, 10 Sep 2015 03:05:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.701 X-Spam-Level: X-Spam-Status: No, score=-3.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_66=0.6, 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 tfIzC4_QqFCb for ; Thu, 10 Sep 2015 03:05:45 -0700 (PDT) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 384221B6415 for ; Thu, 10 Sep 2015 03:05:45 -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@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 93E3CB4116; Thu, 10 Sep 2015 12:03:51 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 93E3CB4116 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1441879431; bh=cd3eCX9XGWdXO9h+GUVpil7oHHuodWIEQCakDkkANSQ=; h=Reply-To:Subject:References:To:Cc:From:Message-ID:Date: MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding; b=UGrB07JLeicOOx4Z/akSavmZLLenWYd2A6t8gy+TpwH3d5EbGaBkz/v2zQSUCZfwJ dqUg7K4A723Zy1KS9BzDJE1Tg7oE85kAyWPvb2JYWS6PLkGTtu3oxJYcA6bpRJ43oo cyNBtOjoEwqYSMsex1kN5b6Zj3JK1CHeR5ZYpAOw= References: <20150908035557.GB73228@Chimay.local> <55F098DB.8020201@uclouvain.be> <20150910022151.GF42530@Chimay.local> To: Christoph Paasch From: Olivier Bonaventure Message-ID: <55F15586.3000003@uclouvain.be> Date: Thu, 10 Sep 2015 12:03:50 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <20150910022151.GF42530@Chimay.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99-beta1 at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 93E3CB4116.A4B18 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Cc: MultiPath WG Subject: Re: [multipathtcp] Fwd: New Version Notification for draft-paasch-mptcp-loadbalancer-00.txt 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: Thu, 10 Sep 2015 10:05:47 -0000 Christoph, > > I really like this idea. > > Very often, IP-in-IP encapsulation is done from the loadbalancer to the > server. Thus, the key could even be placed in an IP-option. As everything is > local to the data-center there shouldn't be an issue with adding a new > IP-option. > > > But as you point out in the other mail, when multiple loadbalancers are > being used we have an issue again. Maybe, there is a way to generate the key > in such a way that we can guarantee uniqueness across the loadbalancers? > This is one possibility, but I'm not sure that we need to specify that unless we want load balancers from different vendors to cooperate. The load balancing problem could be an opportunity to rethink the three-way handshake used by Multipath TCP so that it can work well with tomorrow's target protocol stack, likely HTTP/2 / TLS / MPTCP / IPv6 To deal with security issues, we have included keys in clear inside the SYN and SYN+ACK segments. Then the limited TCP option space has forced us to use hash functions to compute the IDSN and the tokens. Using a hash to compute the tokens creates difficulties when one wants to coordinate token allocations between a set of load balancers. I wonder whether we should not explore again the work documented in https://tools.ietf.org/html/draft-paasch-mptcp-lowoverhead-00 and https://tools.ietf.org/html/draft-paasch-mptcp-ssl-00 Let us first ignore the security issues and make the toke explicit in the handshake. Host A Host B ---------- ---------- Address A1 Address B1 ---------- ---------- | | | SYN+MP_CAPABLE(Token-A) | |----------------------------------->| | | |SYN/ACK+MP_CAPABLE(Token-B) | |<-----------------------------------| | | | ACK+MP_CAPABLE(Token-A, Token-B) | |----------------------------------->| It might also be possible to remove Token-A from the initial SYN since there is little benefit from the server to know this token at this stage. The IDSN could be derived as TokenA|TokenB in one direction and TokenB|TokenA in the other or better a hash of these values. The benefit of this approach is that the Token chosen by the server is not explicitelt sent in the SYN/ACK. Load balancers can coordinate to have one pool of tokens for each LB and pass them to the servers. The next step is to authenticate the establishment of subflows. The best approach with HTTP/2 / TLS is clearly to derive MPTCP keys from the master TLS key and use them to authenticate the subflows with the HMAC mechanism already defined. With this, we leverage the security properties of TLS and do not anymore depend on "keys" that are sent in clear in the SYN segments and consume precious option space. Of course, a drawback of this approach is that you cannot create a subflow until the end of the TLS handshake, but TLS is moving towards faster handshakes. Olivier From nobody Thu Sep 10 07:31:18 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 E21841ACF17 for ; Thu, 10 Sep 2015 07:31:17 -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 PB_7Erop0nr6 for ; Thu, 10 Sep 2015 07:31:12 -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 33C261B2BA1 for ; Thu, 10 Sep 2015 07:31:11 -0700 (PDT) Received: from EPDAG01D-UKBR.domain1.systemhost.net (193.113.197.205) by EVMED01-UKBR.bt.com (10.216.161.31) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 10 Sep 2015 15:31:07 +0100 Received: from rew09926dag03a.domain1.systemhost.net (10.55.202.18) by EPDAG01D-UKBR.domain1.systemhost.net (193.113.197.205) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 10 Sep 2015 15:31:09 +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; Thu, 10 Sep 2015 15:31:08 +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; Thu, 10 Sep 2015 15:31:08 +0100 From: To: Thread-Topic: REMINDER: MPTCP Interim in a few minutes Thread-Index: AdDr1SEp+PFNzFr5SF2sWreO9zvvMw== Date: Thu, 10 Sep 2015 14:31:07 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.202.242] Content-Type: multipart/alternative; boundary="_000_f0b8e383e91d424f938fd7d21fc41dcdrew09926dag03bdomain1sy_" MIME-Version: 1.0 Archived-At: Subject: [multipathtcp] REMINDER: MPTCP Interim in a few minutes 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: Thu, 10 Sep 2015 14:31:18 -0000 --_000_f0b8e383e91d424f938fd7d21fc41dcdrew09926dag03bdomain1sy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just a reminder that our audio meeting starts in ~30 minutes (3pm UTC/GMT) Please see the wiki for webex /audio details and for the slides Talk soon! https://tools.ietf.org/wg/mptcp/trac/wiki/Interim_Sept_2015 --_000_f0b8e383e91d424f938fd7d21fc41dcdrew09926dag03bdomain1sy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just a reminder that our audio meeting st= arts in ~30 minutes (3pm UTC/GMT)

 

Please see the wiki for webex /audio deta= ils and for the slides

 

Talk soon!

 

https://tools.ietf.org/wg/mptcp/trac/wiki/In= terim_Sept_2015

--_000_f0b8e383e91d424f938fd7d21fc41dcdrew09926dag03bdomain1sy_-- From nobody Thu Sep 10 07:43:26 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 F25111B68AE for ; Thu, 10 Sep 2015 07:43:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.711 X-Spam-Level: X-Spam-Status: No, score=-3.711 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, J_CHICKENPOX_66=0.6, RCVD_IN_DNSWL_MED=-2.3, 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 glBw3XLR4mEp for ; Thu, 10 Sep 2015 07:43:20 -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 285DB1B68C3 for ; Thu, 10 Sep 2015 07:43:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1441896199; x=2305809799; 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=3MzVAT0Xhzy2qEOAt9ahntlit0Xs7ldPHZIiDcmy6BA=; b=BlBTNRgNmRHiym8p7YZNQ0UOBs451Lyi9DeZdJSw4DoG33B2+9xmR2Ca2Ov98jgA 9NPenHqRdY3a0UuedL2Ccxc/628R+Ld2OMB+LtJN8Z+zhVSkDc3z3hDVSFDY34X0 TEYipJ91Wbma4lvDB024lKY5GORA4b7pJgNLhS3eDmm7t7r96F1VuQ3XvS8q0tmb y+rQ+6kSOrFkE0iXkMOIb0nmy9lzdhrCK6vCCp0WdrgiLScEXccFW28B7wfglOd9 ob2kBlQy0rIguypnDx/RlZCd1Lc3vH45XpXQX3vmrmMGauAsOpQpvLS5jDLpsBeh v+WzAjwY8oMgLHA1VjyFsQ==; Received: from relay5.apple.com (relay5.apple.com [17.128.113.88]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 5C.63.24160.70791F55; Thu, 10 Sep 2015 07:43:19 -0700 (PDT) X-AuditID: 11973e15-f79cb6d000005e60-aa-55f19707bda7 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 83.18.29295.70791F55; Thu, 10 Sep 2015 07:43:19 -0700 (PDT) Received: from localhost ([17.153.41.121]) by sesame.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NUG0095HU86QO80@sesame.apple.com> for multipathtcp@ietf.org; Thu, 10 Sep 2015 07:43:19 -0700 (PDT) Sender: cpaasch@apple.com Date: Thu, 10 Sep 2015 07:43:18 -0700 From: Christoph Paasch To: Olivier Bonaventure Message-id: <20150910144318.GH69323@Chimay.local> References: <20150908035557.GB73228@Chimay.local> <55F098DB.8020201@uclouvain.be> <20150910022151.GF42530@Chimay.local> <55F15586.3000003@uclouvain.be> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline In-reply-to: <55F15586.3000003@uclouvain.be> User-Agent: Mutt/1.5.23 (2014-03-12) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUi2FAYocs+/WOowY3b0hafV19nc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxrWedqaC2+oV8w4vZG5gvCzbxcjJISFgIvHhxVkmCFtM4sK9 9WxdjFwcQgJ7GSWO3VrMDlO0du9EsCIhgT4mibcd+RBF7UwSV84uZwVJCAtISnTfucMMYrMI qEpsuPUOLM4moCXx9nY7mC0iYCVx6vR0sKHMAhoSk9YcYeli5ADqTZNo220DEuYVMJRYuXkW E8T82YwSh479ZYNICEr8mHyPBaJXS2L9zuNMELa0xKO/M8BmcgroSBw83gZmiwqoSFyZ8JYd ZJCEwBI2idMd3xknMIrMQjJrFpJZs5DMWsDIvIpRKDcxM0c3M89ML7GgICdVLzk/dxMjKMCn 24nuYDyzyuoQowAHoxIPb8LFD6FCrIllxZW5hxilOViUxHk/lQOFBNITS1KzU1MLUovii0pz UosPMTJxcEo1MJZNXLfle5lA8wURhsmbb7z//l9oKpPGZnGjVSnpzJXr1HqTr18XtBHxSjzm EBp4N9Doyn2N7tiGTQn2l2+WT/A5/um0z5Rt7Zy+aX6CIWs1nmw+G+XRNJ3Z7Ny90yckfJJu 8Yi9W1BQ3d7X/H7b4kevl0puPLtAZNrS/WopXpEy2196RWV5zVZiKc5INNRiLipOBAD74esK UQIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUi2FDcoMs+/WOowfPbEhafV19nc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxrWedqaC2+oV8w4vZG5gvCzbxcjJISFgIrF270QmCFtM4sK9 9WwgtpBAH5PE2478LkYuILudSeLK2eWsIAlhAUmJ7jt3mEFsFgFViQ233oHF2QS0JN7ebgez RQSsJE6dns4OYjMLaEhMWnOEpYuRA6g3TaJttw1ImFfAUGLl5llMEPNnM0ocOvaXDSIhKPFj 8j0WiF4tifU7jzNB2NISj/7OAJvJKaAjcfB4G5gtKqAicWXCW/YJjIKzkLTPQtI+C0n7Akbm VYwCRak5iZWmeokFBTmpesn5uZsYwQFZGLGD8f8yq0OMAhyMSjy8CRc/hAqxJpYVV+YeYpTg YFYS4TXv+xgqxJuSWFmVWpQfX1Sak1p8iDEZGBATmaVEk/OB0ZJXEm9oYmJgYmxsZmxsbmJO mrCSOO8npVehQgLpiSWp2ampBalFMFuYODilGhgFHjulKewvUCmY/nqt3MuGX6HXJ3DcUuP/ sjen2+Zp3FwTMf3iP5Ya61b+qTbY1rrDpenIxCU98aY5m9tXPr7mJ7eH85dipeSCn3Z9Tm4u d524HjGzdssnbmU2+b41n5E7opn7xXn/w+xZe5UfLagrSOH+fFpglhHzwn9qbEW57m/fGfTO XaHEUpyRaKjFXFScCABsrUoRjAIAAA== Archived-At: Cc: MultiPath WG Subject: Re: [multipathtcp] Fwd: New Version Notification for draft-paasch-mptcp-loadbalancer-00.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: Thu, 10 Sep 2015 14:43:25 -0000 On 10/09/15 - 12:03:50, Olivier Bonaventure wrote: > >I really like this idea. > > > >Very often, IP-in-IP encapsulation is done from the loadbalancer to the > >server. Thus, the key could even be placed in an IP-option. As everything is > >local to the data-center there shouldn't be an issue with adding a new > >IP-option. > > > > > >But as you point out in the other mail, when multiple loadbalancers are > >being used we have an issue again. Maybe, there is a way to generate the key > >in such a way that we can guarantee uniqueness across the loadbalancers? > > > > This is one possibility, but I'm not sure that we need to specify that > unless we want load balancers from different vendors to cooperate. I was more thinking of it in case we do not modify anything in the MPTCP-handshake. In that case, the different loadbalancers will be generating the keys independently. The loadbalancers can easily make sure that they generate different keys, however because the token is a hash of the key, collisions are possible. Thus, we would need a way to guarantee uniqueness of the token across the loadbalancers. > The load balancing problem could be an opportunity to rethink the three-way > handshake used by Multipath TCP so that it can work well with tomorrow's > target protocol stack, likely HTTP/2 / TLS / MPTCP / IPv6 +1 on TLS For IPv6 I'm a bit concerned because we are yet far away from full IPv6 deployment and IPv4 is proably never going away. > To deal with security issues, we have included keys in clear inside the SYN > and SYN+ACK segments. Then the limited TCP option space has forced us to use > hash functions to compute the IDSN and the tokens. Using a hash to compute > the tokens creates difficulties when one wants to coordinate token > allocations between a set of load balancers. > > I wonder whether we should not explore again the work documented in > https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dpaasch-2Dmptcp-2Dlowoverhead-2D00&d=BQIC-g&c=eEvniauFctOgLOKGJOplqw&r=fSuJ9mpJ1IB1Lz-sIp_MCe23kZIFT6UKt4EhsewNEmA&m=d1DAUSnnbQyUTC9DUvPR9YgBw1illvfDq55MXrewq0M&s=2Xd614qho-KOJFy_LZtqx000U8div7FG31UhLM9V6WY&e= > and > https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dpaasch-2Dmptcp-2Dssl-2D00&d=BQIC-g&c=eEvniauFctOgLOKGJOplqw&r=fSuJ9mpJ1IB1Lz-sIp_MCe23kZIFT6UKt4EhsewNEmA&m=d1DAUSnnbQyUTC9DUvPR9YgBw1illvfDq55MXrewq0M&s=SiCZMS9Xpc2g-z1tPdqDgzwTK2evfjTpi-2OBM4Z9R4&e= > > > Let us first ignore the security issues and make the toke explicit in the > handshake. > > > Host A Host B > ---------- ---------- > Address A1 Address B1 > ---------- ---------- > | | > | SYN+MP_CAPABLE(Token-A) | > |----------------------------------->| > | | > |SYN/ACK+MP_CAPABLE(Token-B) | > |<-----------------------------------| > | | > | ACK+MP_CAPABLE(Token-A, Token-B) | > |----------------------------------->| > > > It might also be possible to remove Token-A from the initial SYN since there > is little benefit from the server to know this token at this stage. Yes, if the MP_CAPABLE becomes reliable in the third ACK, we can probably remove the token from the SYN (although we have to be creative for TFO in that case). > The IDSN > could be derived as TokenA|TokenB in one direction and TokenB|TokenA in the > other or better a hash of these values. > > The benefit of this approach is that the Token chosen by the server is not > explicitelt sent in the SYN/ACK. Load balancers can coordinate to have one > pool of tokens for each LB and pass them to the servers. > > The next step is to authenticate the establishment of subflows. The best > approach with HTTP/2 / TLS is clearly to derive MPTCP keys from the master > TLS key and use them to authenticate the subflows with the HMAC mechanism > already defined. With this, we leverage the security properties of TLS and > do not anymore depend on "keys" that are sent in clear in the SYN segments > and consume precious option space. Of course, a drawback of this approach is > that you cannot create a subflow until the end of the TLS handshake, but TLS > is moving towards faster handshakes. I think this is the best way to go (if the working-group is fine with introducing a rather big change to RFC6824bis). It frees up space in the handshake, enables MPTCP behind loadbalancers (independent of IPv4 or IPv6) and also gives incentives to enable TLS/SSL. Additionally to that, it enables low-overhead deployments of MPTCP for data-center environments. Christoph From nobody Thu Sep 10 07:52:19 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 E9DA21B69BE for ; Thu, 10 Sep 2015 07:52:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 qLZCgkZp03SR for ; Thu, 10 Sep 2015 07:52:13 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 880501B69AE for ; Thu, 10 Sep 2015 07:52:13 -0700 (PDT) Received: from EVMHT04-UKBR.domain1.systemhost.net (193.113.108.57) by EVMED05-UKBR.bt.com (10.216.161.37) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 10 Sep 2015 15:52:09 +0100 Received: from rew09926dag03a.domain1.systemhost.net (10.55.202.18) by EVMHT04-UKBR.domain1.systemhost.net (193.113.108.57) with Microsoft SMTP Server (TLS) id 8.3.342.0; Thu, 10 Sep 2015 15:52:11 +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; Thu, 10 Sep 2015 15:52:10 +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; Thu, 10 Sep 2015 15:52:10 +0100 From: To: , Thread-Topic: [multipathtcp] MPTCP Versioning in RFC 6824 Thread-Index: AdApIdVf9IL5zBySSdGJ+vgyxtS6RzCtmrdw Date: Thu, 10 Sep 2015 14:52:10 +0000 Message-ID: <3fd957b17d4b4142a4319cf8e6a68269@rew09926dag03b.domain1.systemhost.net> References: In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.202.242] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] MPTCP Versioning in RFC 6824 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: Thu, 10 Sep 2015 14:52:17 -0000 Added to the agenda for today > -----Original Message----- > From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of > Anumita Biswas > Sent: 05 January 2015 19:42 > To: Alan Ford > Cc: multipathtcp@ietf.org > Subject: Re: [multipathtcp] MPTCP Versioning in RFC 6824 >=20 >=20 >=20 > > On Jan 5, 2015, at 2:25 AM, Alan Ford wrote: > > > > Hi Anumita, > > > > First, sorry for the slow reply! > > > > On 11 Dec 2014, at 21:50, Anumita Biswas wrote: > >> For all this to work, the current MPTCP implementers will have to > add the following support in their version 0 implementation: > >> > >> a. A server must accept a SYN with any version number. > >> b. The server must reply with the version number it supports or > wishes to use, provided it is equal to or lower than the client's > version number, and not fall back to a regular TCP handshake in > SYN/ACK. > >> c. The client must echo the minimum of the versions advertised by > the client and server in the ACK of the 3-way handshake or fallback to > regular TCP if it does not support the server's version. > >> > >> Please let me know your thoughts on this, > > > > I agree with your proposal here, and will wrap it in in the next > revision. I had originally thought we wouldn't need to tackle this > until a newer MPTCP version number was proposed, but for fallback we do > indeed need to specify some of this. From the perspective of a v0 MPTCP > implementation, the one thing we need to actively specify is that it is > still valid to respond to a SYN/MP_CAPABLE with one with a lower > version number. A pleasant side-effect of the stateless handshake > mechanism we have is that this means we don't need to worry about any > contents in that initial SYN/MP_CAPABLE with the higher version number > - all necessary data is echoed in the ACK/MP_CAPABLE. It's up to > implementations of later versions to determine whether they want to be > able to support fallback once the far end offers a lower version > number. > > >=20 > My belief is that implementations will prefer to fallback to the > minimum MPTCP version if its possible to easily maintain/implement > multiple MPTCP versions, than fallback to regular TCP. >=20 > Thank you! > Anumita >=20 > > Best regards, > > Alan > > >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Thu Sep 10 07:54:16 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 C49451B69E3 for ; Thu, 10 Sep 2015 07:54:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.011 X-Spam-Level: X-Spam-Status: No, score=-2.011 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, J_CHICKENPOX_72=0.6, 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 iXkDnJyZZHny for ; Thu, 10 Sep 2015 07:54:13 -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 8EDCE1B69E1 for ; Thu, 10 Sep 2015 07:54:12 -0700 (PDT) Received: from EVMHT01-UKBR.domain1.systemhost.net (193.113.108.42) by EVMED01-UKBR.bt.com (10.216.161.31) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 10 Sep 2015 15:54:08 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by EVMHT01-UKBR.domain1.systemhost.net (193.113.108.42) with Microsoft SMTP Server (TLS) id 8.3.342.0; Thu, 10 Sep 2015 15:54:10 +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; Thu, 10 Sep 2015 15:54:09 +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; Thu, 10 Sep 2015 15:54:09 +0100 From: To: , Thread-Topic: [multipathtcp] MPTCP Versioning in RFC 6824 Thread-Index: AdApIdVf9IL5zBySSdGJ+vgyxtS6RzCtmrdwAAANYaA= Date: Thu, 10 Sep 2015 14:54:08 +0000 Message-ID: <540974bc8de8445fb9ca039398682ef1@rew09926dag03b.domain1.systemhost.net> References: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.202.242] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] MPTCP Versioning in RFC 6824 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: Thu, 10 Sep 2015 14:54:14 -0000 Sorry, my msg was spam. Old msg somehow popped to top of my inbox! > -----Original Message----- > From: Eardley,PL,Philip,TUB8 R > Sent: 10 September 2015 15:52 > To: 'Anumita Biswas'; Alan Ford > Cc: multipathtcp@ietf.org > Subject: RE: [multipathtcp] MPTCP Versioning in RFC 6824 >=20 > Added to the agenda for today >=20 > > -----Original Message----- > > From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf > Of > > Anumita Biswas > > Sent: 05 January 2015 19:42 > > To: Alan Ford > > Cc: multipathtcp@ietf.org > > Subject: Re: [multipathtcp] MPTCP Versioning in RFC 6824 > > > > > > > > > On Jan 5, 2015, at 2:25 AM, Alan Ford wrote: > > > > > > Hi Anumita, > > > > > > First, sorry for the slow reply! > > > > > > On 11 Dec 2014, at 21:50, Anumita Biswas wrote: > > >> For all this to work, the current MPTCP implementers will have to > > add the following support in their version 0 implementation: > > >> > > >> a. A server must accept a SYN with any version number. > > >> b. The server must reply with the version number it supports or > > wishes to use, provided it is equal to or lower than the client's > > version number, and not fall back to a regular TCP handshake in > > SYN/ACK. > > >> c. The client must echo the minimum of the versions advertised by > > the client and server in the ACK of the 3-way handshake or fallback > to > > regular TCP if it does not support the server's version. > > >> > > >> Please let me know your thoughts on this, > > > > > > I agree with your proposal here, and will wrap it in in the next > > revision. I had originally thought we wouldn't need to tackle this > > until a newer MPTCP version number was proposed, but for fallback we > > do indeed need to specify some of this. From the perspective of a v0 > > MPTCP implementation, the one thing we need to actively specify is > > that it is still valid to respond to a SYN/MP_CAPABLE with one with a > > lower version number. A pleasant side-effect of the stateless > > handshake mechanism we have is that this means we don't need to worry > > about any contents in that initial SYN/MP_CAPABLE with the higher > > version number > > - all necessary data is echoed in the ACK/MP_CAPABLE. It's up to > > implementations of later versions to determine whether they want to > be > > able to support fallback once the far end offers a lower version > > number. > > > > > > > My belief is that implementations will prefer to fallback to the > > minimum MPTCP version if its possible to easily maintain/implement > > multiple MPTCP versions, than fallback to regular TCP. > > > > Thank you! > > Anumita > > > > > Best regards, > > > Alan > > > > > > > _______________________________________________ > > multipathtcp mailing list > > multipathtcp@ietf.org > > https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Thu Sep 10 11:15: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 264B01B3E4E for ; Thu, 10 Sep 2015 11:15:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 PD42S7EDD5Th for ; Thu, 10 Sep 2015 11:15:54 -0700 (PDT) Received: from ndjsvnpf104.ndc.nasa.gov (NDJSVNPF104.ndc.nasa.gov [198.117.1.154]) by ietfa.amsl.com (Postfix) with ESMTP id 32D1D1AC432 for ; Thu, 10 Sep 2015 11:15:53 -0700 (PDT) Received: from ndjsppt105.ndc.nasa.gov (ndjsppt105.ndc.nasa.gov [198.117.1.199]) by ndjsvnpf104.ndc.nasa.gov (Postfix) with ESMTP id 642BC4063232 for ; Thu, 10 Sep 2015 13:15:52 -0500 (CDT) Received: from NDJSCHT112.ndc.nasa.gov (ndjscht112-pub.ndc.nasa.gov [198.117.1.212]) by ndjsppt105.ndc.nasa.gov (8.15.0.59/8.15.0.59) with ESMTP id t8AIFqYb010239 for ; Thu, 10 Sep 2015 13:15:52 -0500 Received: from NDJSMBX203.ndc.nasa.gov ([169.254.2.14]) by NDJSCHT112.ndc.nasa.gov ([198.117.1.212]) with mapi id 14.03.0248.002; Thu, 10 Sep 2015 13:15:52 -0500 From: "Ivancic, William D. (GRC-LCA0)" To: "multipathtcp@ietf.org" Thread-Topic: MPTCP Interim September 10 - Meeting Notes Thread-Index: AQHQ6/S51TQ5Yvq/h0mu8e6yQOieJA== Date: Thu, 10 Sep 2015 18:15:51 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.3.150624 x-originating-ip: [139.88.111.195] Content-Type: text/plain; charset="iso-8859-1" Content-ID: <51486B0122A2D34E9A7F5F814C8207A7@mail.nasa.gov> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-09-10_05:, , signatures=0 Archived-At: Subject: [multipathtcp] MPTCP Interim September 10 - Meeting Notes 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: Thu, 10 Sep 2015 18:15:57 -0000 IETF - MPTCPSlides are here at bottom of page: https://tools.ietf.org/wg/mptcp/trac/wiki/Interim_Sept_2015 Note Taker: Will Ivancic Note, I did not try and capture names to questions. * Agenda * Status * Removing Charter item, =B3Implementation advice (Informational) to IESG=B2 * MPTCP use cases - Enhancement Opportunities * Short Flows vs Long Flow - really need to have some strategy / demarcation. * Elastic vs Inelastic Applications * MPTCP path selections * high packet loss and high latency * multiple profiles * roaming * Controlling number of sub flow getting created * Can this be controlled? How? * Security has many open issues - TBD * Discussion * Choice of path selection is interesting area to explore * Some tools already exist in MPTCP - how to use them requires communication of deployment experience * Looking more from ISP point of view than end-user point of view * MPTCP for Channel Bonding - NASA Atmospheric research * Uses 4 Iridium Modems at 2.4 kbps each (9600 bps total) * Discussion * Which kind of stack are you going to use? Existing or otherwise * Will Ivancic - we plan on using the existing implementations. * What is the schedule? * Will - we are currently working with PPP-MP, which has a lot of options that can be tweaked, we will then move on to MPTCP * Matt Sargent - We have not installed a MPTCP stack yet, but we have been seeing that PPP has issue with the length of time needed to detect a loss. So it will be interesting to see how MPTCP handles the same problem of detection of the lost link. * Will - Results will be published. * This is an interesting use case of MPTCP * * Will Ivancic- Yes it should be interesting to see how it compares as it might be tough with the environment. * Chair - Yes it was *really* interesting to hear about the use case as it is a *really* low bit rate. * MPTCP Proxy Considerations * support use of MPTCP when one or both peers are not capable of MPTCP. * Traffic aggregation * Firewalls may disable MPTCP * traffic aggregation could break security deployments * Next Steps * welcome comments * looking for people interested in forming design team * Discussion * Bits to set proxy (should those be in updated MPTCP draft, RFC6825bis?) * Open Issues * 8 bit vs 16 bit for mptcp-exp-option * Original was 16 vs 32 - why so large (32) * 8 bits seems to small, 16 appears fine for vendor experimental options and/or deployments. * Do not want vendor specific deployments - for experimentation, OK, but not operations or no interoperability. * Paasch - 8 bits keeps options down and reduces chance of incompatible implementations * 8-bit will be sent to list * ADD_ADDR2 Flags field format will be sent to mail list. * Making MPTCP robust for stateless webserveres * Used to handle SYN-flooding attacks * Currently loss of third ACK in MPTCP will result in a fallback to regular TCP * Problem for lossy path (where MPTCP would/should provide benefit) * Suggestions - Make MP_CAPABLE reliable * merge MP_CAPABLE with DSS-option * MP_CAPABLE implementation would reduce MP_CAPABLE by 4 bytes * Should this be included in RFC6824bis? * Nigel Wiolliams - should have been in original version but was oversight - in favor of inclusion. * What happens if client does not send data? * Need to look at load balance issues regarding this solution. * Load Balancer and MPTCP * Intro on how load balancers operate. * multiple servers represented by single IP address * adding or removing servers requires different solution then ECMP so stageful layer-4 load balancer (stageful) is used * in reality, multiple layer-4 load balancers are used. * Tutorial on how MPTCP interacts with load balancers. * Layer-4 load balancer need to track mapping * Token collision of different servers are possible * Problem increases of multiple load balancers are used. =20 * MPTCP- session may reach different load balancers * Solution Space * Need to make token-generation locally meaningful * How does one signal the token? Two current proposals * different token generation by splitting MPTCP-key into two 32bit sections. * No wire-change, but reduces entropy by 32 bits. * Explicitly generate token. * Token not related to key * consumes 4 more bytes * server needs to act stately * Conclusion Token should be locally meaningful * Guarantees uniqueness * Enables layer-4 load balancers * Signaling is open question. * Discussion * Paasch - Reuse keys looks promising * Strong assumption on attacker model. assumption is that attacker cannot eves drop on initial handshake. May not be a good assumption. * Take discussion to list and reiterate. From nobody Thu Sep 10 12:09: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 1D4C81B3EC3 for ; Thu, 10 Sep 2015 12:09:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 J8AWANT_rO74 for ; Thu, 10 Sep 2015 12:09:37 -0700 (PDT) Received: from ndmsvnpf102.ndc.nasa.gov (NDMSVNPF102.ndc.nasa.gov [198.117.0.152]) by ietfa.amsl.com (Postfix) with ESMTP id C260A1B3352 for ; Thu, 10 Sep 2015 12:09:37 -0700 (PDT) Received: from ndjsppt103.ndc.nasa.gov (ndjsppt103.ndc.nasa.gov [198.117.1.197]) by ndmsvnpf102.ndc.nasa.gov (Postfix) with ESMTP id 20E164018556 for ; Thu, 10 Sep 2015 14:09:37 -0500 (CDT) Received: from NDJSCHT103.ndc.nasa.gov (ndjscht103-pub.ndc.nasa.gov [198.117.1.203]) by ndjsppt103.ndc.nasa.gov (8.15.0.59/8.15.0.59) with ESMTP id t8AJ9a8X031966 for ; Thu, 10 Sep 2015 14:09:36 -0500 Received: from NDJSMBX203.ndc.nasa.gov ([169.254.2.14]) by NDJSCHT103.ndc.nasa.gov ([198.117.1.203]) with mapi id 14.03.0248.002; Thu, 10 Sep 2015 14:09:36 -0500 From: "Ivancic, William D. (GRC-LCA0)" To: "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] FW: [Recentattendees] IETF 94 - Hackathon Information Thread-Index: AQHQ6/w8sSPi/XhFtUy9AlQX7S5gWA== Date: Thu, 10 Sep 2015 19:09:36 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.5.3.150624 x-originating-ip: [139.88.111.195] Content-Type: text/plain; charset="us-ascii" Content-ID: <1ED0F10A6FA9EC47841F94E7507B4548@mail.nasa.gov> Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2015-09-10_06:, , signatures=0 Archived-At: Subject: Re: [multipathtcp] FW: [Recentattendees] IETF 94 - Hackathon Information 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: Thu, 10 Sep 2015 19:09:39 -0000 Just wondering if a group is considering MPTCP? I'm trying to decide if I want to make the Yokohama IETF- MPTCP meeting or wait until Buenos Aires. Even though November is over a month away, I am getting late for putting in foreign travel. However, attending a Hackathon and looking over some shoulders would be useful. We, NASA, currently plan to try other's implementations rather than being a developer. Regards, Will Ivancic On 9/2/15 5:04 AM, "multipathtcp on behalf of philip.eardley@bt.com" wrote: >Cfi - is anyone interested in taking part in the Yokohama hackathon? > >-----Original Message----- >From: Recentattendees [mailto:recentattendees-bounces@ietf.org] On Behalf >Of IETF Secretariat >Sent: 31 August 2015 22:38 >To: IETF Announcement List >Cc: recentattendees@ietf.org; ietf@ietf.org; 94all@ietf.org; >hackathon@ietf.org >Subject: [Recentattendees] IETF 94 - Hackathon Information > >IETF 94 Hackathon > >The Internet Engineering Task Force (IETF) is holding a Hackathon at IETF >94 to encourage developers to discuss, collaborate and develop utilities, >ideas, sample code and solutions that show practical implementations of >IETF standards. =20 > From nobody Thu Sep 10 12:19:10 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 59C271B3134 for ; Thu, 10 Sep 2015 12:19:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 Bn7JGmtradry for ; Thu, 10 Sep 2015 12:19:07 -0700 (PDT) Received: from mail-in5.apple.com (mail-out5.apple.com [17.151.62.27]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F11BE1AC408 for ; Thu, 10 Sep 2015 12:19:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1441912746; x=2305826346; 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=nGSkuL7h8gFcziV7eMFAzBp7TLA7tez/zc+BqRgYA3M=; b=OfulavHhFKgqxcuX3QvbH/yGnT7Z/mC/rLw4dXqQ9gbSPTRa6eYyZUyogMkpZtjc 3I8o1o8XBo5h0+fttswuqepzFHisbGs7EdUnmkm8yJ89qrvXzBeErpVdjZjesOsn hIUJnwYNWp9cA/YBSAAhNXxM9t91AkcgcOxvodxY8rSZzDhpGlCZ33h28Cqml6FI /8cPVD+Yb6AvYKyZdLk4FxxvP+KAEZYqDpilIkbO5MDH6XTwHfZqXRcdTGSm9Q+d vMXbtNcVaESnok96XYt5MmTC4F7vFiRJsCYHAL4pjKd4rdNxKl45/SRmlmmG4nEw rTl2CIGdCayT6//kwqx0/w==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in5.apple.com (Apple Secure Mail Relay) with SMTP id 18.09.22968.AA7D1F55; Thu, 10 Sep 2015 12:19:06 -0700 (PDT) X-AuditID: 11973e13-f79006d0000059b8-d7-55f1d7aad8c5 Received: from aniseed.apple.com (aniseed.apple.com [17.128.115.23]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id 4C.46.22881.AA7D1F55; Thu, 10 Sep 2015 12:19:06 -0700 (PDT) Received: from localhost ([17.226.23.239]) by aniseed.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NUH009H56ZUMN00@aniseed.apple.com> for multipathtcp@ietf.org; Thu, 10 Sep 2015 12:19:06 -0700 (PDT) Sender: cpaasch@apple.com Date: Thu, 10 Sep 2015 12:19:04 -0700 From: Christoph Paasch To: "Ivancic, William D. (GRC-LCA0)" Message-id: <20150910191904.GL69323@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+NgFtrLLMWRmVeSWpSXmKPExsUi2FAYpbvq+sdQgyv3VCw+r77O5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujAUTtzAX3OKvOPJ8MnsD41TeLkZODgkBE4nDd96yQ9hiEhfu rWfrYuTiEBLYyyjx8PEz1i5GDrCiBT01EPF+Jok3XTuZIZxOJokjmx6zgXQLC0hKdN+5wwxi swioSvw7tI0JxGYT0JJ4e7udFcQWEXCUuDHjDyOIzSwQJ9F4ZwcLRG+wxLtvX8DivAKGEntm djKDLBYSMJdonSILERaU+DH5HgtEq5bE+p3HmSBsaYlHf2eAPcApYCHR8f8+2DmiAioSVyaA PMYFdP8KNon335uZJjCKzEIyaxaSWbOQzFrAyLyKUSg3MTNHNzPPVC+xoCAnVS85P3cTIyi8 p9sJ72A8vcrqEKMAB6MSD2/CxQ+hQqyJZcWVuYcYpTlYlMR5P5cDhQTSE0tSs1NTC1KL4otK c1KLDzEycXBKNTBay/lsbDE2zbPcqZUb0K9cxdooGKJTU/z1QWW/6gqPjL6ktfOvvdl2lFFi ye4VPbtcP5k8z9/qFaNVYqU2PWe6oXvwWdUVTBt4pYulrOsPldj/EdzKkVhveig51PDxnr1c Zxguir5aovhn78So1ksF/Z7VXGWHjnSfYE7u8xF59e3etlOlR5VYijMSDbWYi4oTAVjIpmZQ AgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUi2FAsrrvq+sdQg8unFC0+r77O5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujAUTtzAX3OKvOPJ8MnsD41TeLkYODgkBE4kFPTVdjJxAppjE hXvr2boYuTiEBPqZJN507WSGcDqZJI5seswGUiUsICnRfecOM4jNIqAq8e/QNiYQm01AS+Lt 7XZWEFtEwFHixow/jCA2s0CcROOdHSwQvcES7759AYvzChhK7JnZyQxyhJCAuUTrFFmIsKDE j8n3WCBatSTW7zzOBGFLSzz6O4MdxOYUsJDo+H8f7BxRARWJKxPesk9gFJyFpH0WkvZZSNoX MDKvYhQoSs1JrDTTSywoyEnVS87P3cQIDsfCqB2MDcutDjEKcDAq8fAmXPwQKsSaWFZcmXuI UYKDWUmE17zvY6gQb0piZVVqUX58UWlOavEhxmRgOExklhJNzgfGSl5JvKGJiYGJsbGZsbG5 iTlpwkrivA0ir0KFBNITS1KzU1MLUotgtjBxcEo1MPKezXPc6GIWPf1p1V6dxkUmW1vdHlXM cti287zcbMHZKx4Kz5ohnWPFadD+IPKV+VmmvuWd1ctMyh6+UAxq3WmT8mv3uQWy3b15rpm6 pvvFeftPLjlrualhEzf3j+dH/a/q8v1m4v8mtatg1sJn2cWcXmvMN+loRJoeWPy3T6jn65Gg l4+naymxFGckGmoxFxUnAgBsfK5giwIAAA== Archived-At: Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] FW: [Recentattendees] IETF 94 - Hackathon Information 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: Thu, 10 Sep 2015 19:19:08 -0000 Hello, I will be at the IETF and would consider coming to the hackathon if people want help/advice/... on the Linux Kernel implementation. Maybe we could do an interop with Nigel on FreeBSD? Cheers, Christoph On 10/09/15 - 19:09:36, Ivancic, William D. (GRC-LCA0) wrote: > Just wondering if a group is considering MPTCP? I'm trying to decide if I > want to make the Yokohama IETF- MPTCP meeting or wait until Buenos Aires. > Even though November is over a month away, I am getting late for putting > in foreign travel. However, attending a Hackathon and looking over some > shoulders would be useful. We, NASA, currently plan to try other's > implementations rather than being a developer. > > Regards, > > Will Ivancic > > On 9/2/15 5:04 AM, "multipathtcp on behalf of philip.eardley@bt.com" > wrote: > > >Cfi - is anyone interested in taking part in the Yokohama hackathon? > > > >-----Original Message----- > >From: Recentattendees [mailto:recentattendees-bounces@ietf.org] On Behalf > >Of IETF Secretariat > >Sent: 31 August 2015 22:38 > >To: IETF Announcement List > >Cc: recentattendees@ietf.org; ietf@ietf.org; 94all@ietf.org; > >hackathon@ietf.org > >Subject: [Recentattendees] IETF 94 - Hackathon Information > > > >IETF 94 Hackathon > > > >The Internet Engineering Task Force (IETF) is holding a Hackathon at IETF > >94 to encourage developers to discuss, collaborate and develop utilities, > >ideas, sample code and solutions that show practical implementations of > >IETF standards. > > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_multipathtcp&d=BQICAg&c=eEvniauFctOgLOKGJOplqw&r=fSuJ9mpJ1IB1Lz-sIp_MCe23kZIFT6UKt4EhsewNEmA&m=rr0N4aD3wM-RVdpsb3qEdre3Wnbko44SuLQzlziS43A&s=Nd75GQ_XF1rcAM7ylH_sk5365A0VADTuT_ska0FZMJY&e= From nobody Thu Sep 10 23:25:44 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 E1BAA1A21A1 for ; Thu, 10 Sep 2015 23:25:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 03MR0g_BNloE for ; Thu, 10 Sep 2015 23:25:39 -0700 (PDT) Received: from eesmtp01.ap.verizon.com (eesmtp01.ap.verizon.com [202.130.139.21]) (using TLSv1 with cipher DHE-RSA-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 26DFD1A1A36 for ; Thu, 10 Sep 2015 23:25:38 -0700 (PDT) From: "Appanasamy, Palanivelan" X-IronPort-AV: E=Sophos;i="5.17,510,1437408000"; d="scan'208";a="56400208" Received: from sc-syd-fimr01.ap.verizon.com ([203.166.70.67]) by eesmtp01.ap.verizon.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 11 Sep 2015 14:25:36 +0800 Received: from sc-syd-fimr01.ap.verizon.com ([203.166.70.67]:40684) by sc-syd-fimr01.ap.verizon.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.76) (envelope-from ) id 1ZaHmA-0003hb-4P; Fri, 11 Sep 2015 06:25:34 +0000 Received: from [166.45.22.77] (helo=MS-BAN-E7MB01.intl1.one.verizon.com) by sc-syd-fimr01.ap.verizon.com with esmtps (TLSv1:AES128-SHA:128) (Exim 4.76) (envelope-from ) id 1ZaHm9-0003hM-6A; Fri, 11 Sep 2015 06:25:34 +0000 Received: from MS-BAN-E7MB01.intl1.one.verizon.com ([166.45.22.77]) by MS-BAN-E7MB01.intl1.one.verizon.com ([166.45.22.77]) with mapi; Fri, 11 Sep 2015 11:55:31 +0530 To: "Ivancic, William D. (GRC-LCA0)" , "multipathtcp@ietf.org" Importance: high X-Priority: 1 Date: Fri, 11 Sep 2015 11:55:30 +0530 Thread-Topic: MPTCP Interim September 10 - Meeting Notes Thread-Index: AQHQ6/S51TQ5Yvq/h0mu8e6yQOieJJ423GRg Message-ID: <70AEAEC90FCAE0408586E94F491A07EC04C84E3F94@MS-BAN-E7MB01.intl1.one.verizon.com> References: In-Reply-To: Accept-Language: en-US, en-GB Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US, en-GB Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-VZ-EMEA-INT-SIG: d55074a271358bf64c859d1dc0c346ff X-APAC-E2-SIG: d55074a271358bf64c859d1dc0c346ff Archived-At: Cc: "Harsha, Chetan H" Subject: Re: [multipathtcp] MPTCP Interim September 10 - Meeting Notes 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, 11 Sep 2015 06:25:43 -0000 Thanks all. We will work on detailing the use cases into a draft and have this discusse= d in the next meeting. Chetan confirms that he is attending Yokahama IETF in November.=20 Keep Sharing your feedback or improvements. Thanks. Regards, A.Palanivelan -----Original Message----- From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Ivan= cic, William D. (GRC-LCA0) Sent: Thursday, September 10, 2015 11:46 PM To: multipathtcp@ietf.org Subject: [multipathtcp] MPTCP Interim September 10 - Meeting Notes IETF - MPTCPSlides are here at bottom of page: https://tools.ietf.org/wg/mptcp/trac/wiki/Interim_Sept_2015 Note Taker: Will Ivancic Note, I did not try and capture names to questions. * Agenda * Status * Removing Charter item, =B3Implementation advice (Informational) to I= ESG=B2 * MPTCP use cases - Enhancement Opportunities * Short Flows vs Long Flow - really need to have some strategy / demar= cation. * Elastic vs Inelastic Applications * MPTCP path selections * high packet loss and high latency * multiple profiles * roaming * Controlling number of sub flow getting created * Can this be controlled? How? * Security has many open issues - TBD * Discussion * Choice of path selection is interesting area to explore * Some tools already exist in MPTCP - how to use them requires co= mmunication of deployment experience * Looking more from ISP point of view than end-user point of view * MPTCP for Channel Bonding - NASA Atmospheric research * Uses 4 Iridium Modems at 2.4 kbps each (9600 bps total) * Discussion * Which kind of stack are you going to use? Existing or otherwi= se * Will Ivancic - we plan on using the existing implementatio= ns. * What is the schedule? * Will - we are currently working with PPP-MP, which has a l= ot of options that can be tweaked, we will then move on to MPTCP * Matt Sargent - We have not installed a MPTCP stack yet, bu= t we have been seeing that PPP has issue with the length of time needed to = detect a loss. So it will be interesting to see how MPTCP handles the same= problem of detection of the lost link. * Will - Results will be published. * This is an interesting use case of MPTCP * * Will Ivancic- Yes it should be interesting to see how it compares = as it might be tough with the environment. * Chair - Yes it was *really* interesting to hear about the use case as it = is a *really* low bit rate. * MPTCP Proxy Considerations * support use of MPTCP when one or both peers are not capable of = MPTCP. * Traffic aggregation * Firewalls may disable MPTCP * traffic aggregation could break security deployments * Next Steps * welcome comments * looking for people interested in forming design team * Discussion * Bits to set proxy (should those be in updated MPTCP draft,= RFC6825bis?) * Open Issues * 8 bit vs 16 bit for mptcp-exp-option * Original was 16 vs 32 - why so large (32) * 8 bits seems to small, 16 appears fine for vendor exp= erimental options and/or deployments. * Do not want vendor specific deployments - for ex= perimentation, OK, but not operations or no interoperability. * Paasch - 8 bits keeps options down and reduces chance= of incompatible implementations * 8-bit will be sent to list * ADD_ADDR2 Flags field format will be sent to mail list. * Making MPTCP robust for stateless webserveres * Used to handle SYN-flooding attacks * Currently loss of third ACK in MPTCP will result in a fall= back to regular TCP * Problem for lossy path (where MPTCP would/should prov= ide benefit) * Suggestions - Make MP_CAPABLE reliable * merge MP_CAPABLE with DSS-option * MP_CAPABLE implementation would reduce MP_CAPABLE by 4 bytes * Should this be included in RFC6824bis? * Nigel Wiolliams - should have been in original v= ersion but was oversight - in favor of inclusion. * What happens if client does not send data? * Need to look at load balance issues regarding th= is solution. * Load Balancer and MPTCP * Intro on how load balancers operate. * multiple servers represented by single IP address * adding or removing servers requires different solutio= n then ECMP so stageful layer-4 load balancer (stageful) is used * in reality, multiple layer-4 load balancers are used. * Tutorial on how MPTCP interacts with load balancers. * Layer-4 load balancer need to track = mapping * Token collision of different servers are possible * Problem increases of multiple load balancers are used= . =20 * MPTCP- session may reach different load balancer= s * Solution Space * Need to make token-generation locally meaningful * How does one signal the token? Two current prop= osals * different token generation by splitting MPT= CP-key into two 32bit sections. * No wire-change, but reduces entropy by= 32 bits. * Explicitly generate token. * Token not related to key * consumes 4 more bytes * server needs to act stately * Conclusion Token should be locally meaningf= ul * Guarantees uniqueness * Enables layer-4 load balancers * Signaling is open question. * Discussion * Paasch - Reuse keys looks promising * Strong assumption on attacker model. assumption is that attacker cannot eves drop on initial handshake. May not= be a good assumption. * Take discussion to list and reiterate. _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Fri Sep 11 00:17: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 2389D1B3D72 for ; Fri, 11 Sep 2015 00:17:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.821 X-Spam-Level: * X-Spam-Status: No, score=1.821 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, HTML_MESSAGE=0.001, J_CHICKENPOX_52=0.6, 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 30NoCxse4NTM for ; Fri, 11 Sep 2015 00:17:24 -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 F11421B3D79 for ; Fri, 11 Sep 2015 00:17:23 -0700 (PDT) Received: from mail-ob0-f173.google.com (mail-ob0-f173.google.com [209.85.214.173]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 186B527811B for ; Fri, 11 Sep 2015 16:17:22 +0900 (JST) Received: by obuk4 with SMTP id k4so54301287obu.2 for ; Fri, 11 Sep 2015 00:17:20 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.51.5 with SMTP id g5mr38054082oeo.35.1441955840580; Fri, 11 Sep 2015 00:17:20 -0700 (PDT) Received: by 10.202.197.15 with HTTP; Fri, 11 Sep 2015 00:17:20 -0700 (PDT) In-Reply-To: References: Date: Fri, 11 Sep 2015 00:17:20 -0700 Message-ID: From: Yoshifumi Nishida To: "Ivancic, William D. (GRC-LCA0)" Content-Type: multipart/alternative; boundary=001a11c30caaa8e420051f738197 Archived-At: Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] FW: [Recentattendees] IETF 94 - Hackathon Information 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, 11 Sep 2015 07:17:26 -0000 --001a11c30caaa8e420051f738197 Content-Type: text/plain; charset=UTF-8 Hi Will, Hmm.. It's difficult to answer this at this moment, but yes, we are considering and I personally hope we will have a meeting at Yokohama. We will request a slot and call for agenda at some point. As long as there're enough agenda, we will have a meeting. I think it's totally fine to announce that you're planning to present something beforehand. It might motivate other folks. Thanks, -- Yoshi On Thu, Sep 10, 2015 at 12:09 PM, Ivancic, William D. (GRC-LCA0) < william.d.ivancic@nasa.gov> wrote: > Just wondering if a group is considering MPTCP? I'm trying to decide if I > want to make the Yokohama IETF- MPTCP meeting or wait until Buenos Aires. > Even though November is over a month away, I am getting late for putting > in foreign travel. However, attending a Hackathon and looking over some > shoulders would be useful. We, NASA, currently plan to try other's > implementations rather than being a developer. > > Regards, > > Will Ivancic > > On 9/2/15 5:04 AM, "multipathtcp on behalf of philip.eardley@bt.com" > wrote: > > >Cfi - is anyone interested in taking part in the Yokohama hackathon? > > > >-----Original Message----- > >From: Recentattendees [mailto:recentattendees-bounces@ietf.org] On Behalf > >Of IETF Secretariat > >Sent: 31 August 2015 22:38 > >To: IETF Announcement List > >Cc: recentattendees@ietf.org; ietf@ietf.org; 94all@ietf.org; > >hackathon@ietf.org > >Subject: [Recentattendees] IETF 94 - Hackathon Information > > > >IETF 94 Hackathon > > > >The Internet Engineering Task Force (IETF) is holding a Hackathon at IETF > >94 to encourage developers to discuss, collaborate and develop utilities, > >ideas, sample code and solutions that show practical implementations of > >IETF standards. > > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > --001a11c30caaa8e420051f738197 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Will,
Hmm.. It's difficult to answer= this at this moment, but yes, we are considering and I personally hope we = will have a meeting at Yokohama.=C2=A0
We will request a slot= and call for agenda at some point. As long as there're enough agenda, = we will have a meeting.
I think it's totally fine to announce= that you're planning to present something beforehand. It might motivat= e other folks.

Thanks,
--
= Yoshi=C2=A0

On Thu, Sep 10, 2015 at 12:09 PM, Ivancic, William D. (GRC-LCA0) <william.d.ivancic@nasa.gov> wrote:
Just wondering if a group is considering MPTCP?=C2=A0 I'm= trying to decide if I
want to make the Yokohama IETF- MPTCP meeting or wait until Buenos Aires. Even though November is over a month away, I am getting late for putting in foreign travel.=C2=A0 However, attending a Hackathon and looking over so= me
shoulders would be useful.=C2=A0 We, NASA, currently plan to try other'= s
implementations rather than being a developer.

Regards,

Will Ivancic

On 9/2/15 5:04 AM, "multipathtcp on behalf of philip.eardley@bt.com"
<multipathtcp-bounces@i= etf.org on behalf of philip.ea= rdley@bt.com> wrote:

>Cfi - is anyone interested in taking part in the Yokohama hackathon? >
>-----Original Message-----
>From: Recentattendees [mailto:recentattendees-bounces@ietf.org] On Behalf
>Of IETF Secretariat
>Sent: 31 August 2015 22:38
>To: IETF Announcement List
>Cc: recentattendees@ietf.or= g; ietf@ietf.org; 94all@ietf.org;
>hackathon@ietf.org
>Subject: [Recentattendees] IETF 94 - Hackathon Information
>
>IETF 94 Hackathon
>
>The Internet Engineering Task Force (IETF) is holding a Hackathon at IE= TF
>94 to encourage developers to discuss, collaborate and develop utilitie= s,
>ideas, sample code and solutions that show practical implementations of=
>IETF standards.
>

_______________________________________________
multipathtcp mailing list
multipathtcp@ietf.org
https://www.ietf.org/mailman/listinfo/multipathtcp=

--001a11c30caaa8e420051f738197-- From nobody Fri Sep 11 06:43: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 90F2D1ACD68 for ; Fri, 11 Sep 2015 06:43:28 -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 Cu0AQUSncs-V for ; Fri, 11 Sep 2015 06:43:24 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.136]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ED62F1B308A for ; Fri, 11 Sep 2015 06:43:23 -0700 (PDT) Received: from EVHUB04-UKBR.domain1.systemhost.net (193.113.108.172) by EVMED02-UKBR.bt.com (10.216.161.32) with Microsoft SMTP Server (TLS) id 14.3.195.1; Fri, 11 Sep 2015 14:43:21 +0100 Received: from rew09926dag03a.domain1.systemhost.net (10.55.202.18) by EVHUB04-UKBR.domain1.systemhost.net (193.113.108.172) with Microsoft SMTP Server (TLS) id 14.3.158.1; Fri, 11 Sep 2015 14:43:22 +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; Fri, 11 Sep 2015 14:43:20 +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; Fri, 11 Sep 2015 14:43:20 +0100 From: To: Thread-Topic: Consensus call on 8-bit experimental MPTCP option Thread-Index: AdDslxybw3LeeRUtQdGIBIPX31eHhQ== Date: Fri, 11 Sep 2015 13:43:20 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.202.242] Content-Type: multipart/alternative; boundary="_000_f387f838cb9c4bfcb3b161b3025eb4fcrew09926dag03bdomain1sy_" MIME-Version: 1.0 Archived-At: Subject: [multipathtcp] Consensus call on 8-bit experimental MPTCP 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, 11 Sep 2015 13:43:28 -0000 --_000_f387f838cb9c4bfcb3b161b3025eb4fcrew09926dag03bdomain1sy_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbSBQcmFndWUgd2UgaGFkIGNvbnNlbnN1cyB0byBhZGQgYW4gZXhwZXJpbWVudGFsIE1QVENQ IG9wdGlvbiB0byB0aGUgcHJvdG9jb2wgYmlzIFtzZWUg4oCLaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtYm9uYXZlbnR1cmUtbXB0Y3AtZXhwLW9wdGlvbi9dLg0KVGhlIHF1 ZXN0aW9uIHdhcyByYWlzZWQgd2hldGhlciBpdCBzaG91bGQgYmUgOCBvciAxNiBiaXRzLg0KDQpU aGUgZGlzY3Vzc2lvbnMgZHVyaW5nIHllc3RlcmRheeKAmXMgaW50ZXJpbSByZWFjaGVkIHRoZSBj b25zZW5zdXMgdGhhdCBpdCBzaG91bGQgYmUgOCBiaXRzLiAoc2VlIHRoZSBwcmVsaW1pbmFyeSBt ZWV0aW5nIG5vdGVzLCBlbWFpbCBmcm9tIFdpbGwgSXZhbmNpYykNCg0KVGhpcyBlbWFpbCBpcyB0 byBjaGVjayB0aGlzIGNvbnNlbnN1cy4gSWYgeW91IHdlcmVu4oCZdCBvbiB0aGUgY2FsbCwgcGxl YXNlIHNwZWFrIHVwIGlmIHlvdSBoYXZlIGEgc3Ryb25nIG9waW5pb24sIGVzcGVjaWFsbHkgaWYg eW91IGRpc2FncmVlIHdpdGggdGhlIDggYml0IHByb3Bvc2FsLg0KDQp0aGFua3MNCg== --_000_f387f838cb9c4bfcb3b161b3025eb4fcrew09926dag03bdomain1sy_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTQgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZp bml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXtt YXJnaW46MGNtOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0K CWZvbnQtZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3Vh Z2U6RU4tVVM7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3Jp dHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlz aXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7 DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFp bFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWls eToiQXJpYWwiLCJzYW5zLXNlcmlmIjsNCgljb2xvcjp3aW5kb3d0ZXh0Ow0KCWZvbnQtd2VpZ2h0 Om5vcm1hbDsNCglmb250LXN0eWxlOm5vcm1hbDsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25l O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIiwic2Fucy1zZXJpZiI7DQoJbXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4t VVM7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6NjEyLjBwdCA3OTIuMHB0Ow0KCW1hcmdp bjo3Mi4wcHQgNzIuMHB0IDcyLjBwdCA3Mi4wcHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdl OldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86 c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2Vu ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVk aXQiPg0KPG86aWRtYXAgdjpleHQ9ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+ PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1HQiIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1mYW1pbHk6JnF1 b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+RnJvbSBQcmFndWUgd2UgaGFk IGNvbnNlbnN1cyB0byBhZGQgYW4gZXhwZXJpbWVudGFsIE1QVENQIG9wdGlvbiB0byB0aGUgcHJv dG9jb2wgYmlzIFtzZWUg4oCLaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQt Ym9uYXZlbnR1cmUtbXB0Y3AtZXhwLW9wdGlvbi9dLg0KPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Zm9udC1m YW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssJnF1b3Q7c2Fucy1zZXJpZiZxdW90OyI+VGhlIHF1ZXN0 aW9uIHdhcyByYWlzZWQgd2hldGhlciBpdCBzaG91bGQgYmUgOCBvciAxNiBiaXRzLjxvOnA+PC9v OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp emU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYm cXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1 b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoZSBkaXNjdXNzaW9ucyBkdXJpbmcgeWVzdGVy ZGF54oCZcyBpbnRlcmltIHJlYWNoZWQgdGhlIGNvbnNlbnN1cyB0aGF0IGl0IHNob3VsZCBiZSA4 IGJpdHMuIChzZWUgdGhlIHByZWxpbWluYXJ5IG1lZXRpbmcgbm90ZXMsIGVtYWlsIGZyb20gV2ls bCBJdmFuY2ljKTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7 LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFt aWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsiPlRoaXMgZW1haWwg aXMgdG8gY2hlY2sgdGhpcyBjb25zZW5zdXMuIElmIHlvdSB3ZXJlbuKAmXQgb24gdGhlIGNhbGws IHBsZWFzZSBzcGVhayB1cCBpZiB5b3UgaGF2ZSBhIHN0cm9uZyBvcGluaW9uLCBlc3BlY2lhbGx5 IGlmIHlvdSBkaXNhZ3JlZSB3aXRoIHRoZSA4IGJpdCBwcm9wb3NhbC4NCjxvOnA+PC9vOnA+PC9z cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIu MHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZxdW90O3NhbnMtc2VyaWYmcXVvdDsi PjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LCZx dW90O3NhbnMtc2VyaWYmcXVvdDsiPnRoYW5rczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2 Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_f387f838cb9c4bfcb3b161b3025eb4fcrew09926dag03bdomain1sy_-- From nobody Mon Sep 14 07:45:55 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 34FE71B4212 for ; Mon, 14 Sep 2015 07:45:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, 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 VlErSKfDLSPz for ; Mon, 14 Sep 2015 07:45:46 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.142]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B96DE1B4406 for ; Mon, 14 Sep 2015 07:45:45 -0700 (PDT) Received: from EPDAG01D-UKBR.domain1.systemhost.net (193.113.197.205) by EVMED06-UKBR.bt.com (10.216.161.38) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 14 Sep 2015 15:45:42 +0100 Received: from rew09926dag03d.domain1.systemhost.net (10.55.202.30) by EPDAG01D-UKBR.domain1.systemhost.net (193.113.197.205) with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 14 Sep 2015 15:45:42 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03d.domain1.systemhost.net (10.55.202.30) with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 14 Sep 2015 15:45:41 +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, 14 Sep 2015 15:45:41 +0100 From: To: Thread-Topic: Discussion /Consensus on incrementing the version number of MPTCP Thread-Index: AdDsmBq4q90GsL61QB6aH9aFo+bFSACRdTHQ Date: Mon, 14 Sep 2015 14:45:40 +0000 Message-ID: <7082931042c142fabaa6e88275a56fcf@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.233] Content-Type: multipart/alternative; boundary="_000_7082931042c142fabaa6e88275a56fcfrew09926dag03bdomain1sy_" MIME-Version: 1.0 Archived-At: Subject: [multipathtcp] Discussion /Consensus on incrementing the version number of MPTCP 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, 14 Sep 2015 14:45:54 -0000 --_000_7082931042c142fabaa6e88275a56fcfrew09926dag03bdomain1sy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, During our interim call last week, several discussion points touched on thi= s topic. The implication would be that the MPTCP version number is 1 in the= protocol bis (Standards track), and hence it would be incompatible with th= e current Experimental track protocol (version number is 0). * Making MP-CAPABLE reliable. There was a lot of support for this d= uring the interim, with no-one against. One or two on-going questions were = raised by Yoshi. This requires a new version number. If it's agreed that the standards track RFC will be a different version num= ber, then several other things have been raised * A new Proxy 'P' flag in MP_CAPABLE, https://tools.ietf.org/html/d= raft-wei-mptcp-proxy-mechanism-02 There was some support for this flag dur= ing the interim. * Replacing the IPver field in ADD_ADDR with a set of flags. Severa= l people have supported this (though not yet have an agreed proposal /detai= ls). * Making the MPTCP token locally meaningful, in order that mptcp ca= n work well with load balancers. See the discussion over the last few days = prompted by https://datatracker.ietf.org/doc/draft-paasch-mptcp-loadbalance= r/ * The possibility of leveraging security off TLS (if TLS is being u= sed) The more general point is that - a new version number would mean that we ha= ve the opportunity to re-design MPTCP's signalling, based on the lessons le= arnt from the current implementations and deployments and the new requireme= nts that have emerged. So the first step is to make sure that we have consensus that in principle = the protocol bis will have a new version number. Since we didn't explicitly do a consensus call on this during the meeting, = please send you views, positive or negative, to the list. Thanks Phil & Yoshi --_000_7082931042c142fabaa6e88275a56fcfrew09926dag03bdomain1sy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

During our interim call last week, severa= l discussion points touched on this topic. The implication would be that th= e MPTCP version number is 1 in the protocol bis (Standards track), and hence it would be incompatible with the current Experimental t= rack protocol (version number is 0).

 

·         Making MP-CAPABLE reliable. There= was a lot of support for this during the interim, with no-one against. One= or two on-going questions were raised by Yoshi. This requires a new version number.

 

If it’s agreed that the standards t= rack RFC will be a different version number, then several other things have= been raised

·         A new Proxy ‘P’ flag = in MP_CAPABLE, = https://tools.ietf.org/html/draft-wei-mptc= p-proxy-mechanism-02  There was some support for this flag = during the interim.

·         Replacing the IPver field in ADD_= ADDR with a set of flags. Several people have supported this (though not ye= t have an agreed proposal /details).

·         Making the MPTCP token locally me= aningful, in order that mptcp can work well with load balancers. See the di= scussion over the last few days prompted by https://datatracker.ietf.org/doc/draft-= paasch-mptcp-loadbalancer/

·         The possibility of leveraging sec= urity off TLS (if TLS is being used)

 

The more general point is that - a new ve= rsion number would mean that we have the opportunity to re-design MPTCPR= 17;s signalling, based on the lessons learnt from the current implementations and deployments and the new requirements that have emerged= .

 

So the first step is to make sure that we= have consensus that in principle the protocol bis will have a new version = number.

Since we didn’t explicitly do a con= sensus call on this during the meeting, please send you views, positive or = negative, to the list.

 

Thanks

Phil & Yoshi

--_000_7082931042c142fabaa6e88275a56fcfrew09926dag03bdomain1sy_-- From nobody Mon Sep 14 10:14:01 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 B21081B39B1 for ; Mon, 14 Sep 2015 10:13:59 -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 MCoYTh8P61jS for ; Mon, 14 Sep 2015 10:13:58 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA6351B2FD2 for ; Mon, 14 Sep 2015 10:13:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1442250837; x=2306164437; 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=mWIULdMaxbMpYUOMYgUNoGpOmm4SktXnkO5Lrm5Jrm0=; b=EpKwaFwNTNvRrimpqMYiDVyg5GjlXRPsJqb+DE0gaxj/KbRZzLCTgr8itk9/ovk5 6s4SqKRvQiptt+1frTpEYrdmXyWAH+gDwU7AfvtA0vw/lZCGhxxdTZV1KoZkn6D4 FhIuQY9Y4HUy5uOPYE6aAnE/6B0kl1Mlh8+BkTpad4SCK4enOJ9wX5J8DbL1UUd3 jLKvE7mB5ubFoTpJ1cMDCeSkqYvt7Q7kcULug5GBFhHx4sRz6LC+1q7V/B3upk4Z bgTD8yfukoK07getAdTvB7xgeukGFj2ZLp1GZwyzALNiZzhX3TMUvMBcOjc8gQ5X iPUFqQbDSl1z5FeZPUY+3Q==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id B8.E1.24122.55007F55; Mon, 14 Sep 2015 10:13:57 -0700 (PDT) X-AuditID: 11973e16-f79826d000005e3a-61-55f700555a7a Received: from chicory.apple.com (chicory.apple.com [17.128.115.99]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id E9.EF.22881.55007F55; Mon, 14 Sep 2015 10:13:57 -0700 (PDT) Received: from localhost ([17.153.60.77]) by chicory.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NUO00532FV8WX20@chicory.apple.com> for multipathtcp@ietf.org; Mon, 14 Sep 2015 10:13:57 -0700 (PDT) Sender: cpaasch@apple.com Date: Mon, 14 Sep 2015 10:13:56 -0700 From: Christoph Paasch To: philip.eardley@bt.com Message-id: <20150914171356.GM1981@Chimay.local> References: <7082931042c142fabaa6e88275a56fcf@rew09926dag03b.domain1.systemhost.net> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline In-reply-to: <7082931042c142fabaa6e88275a56fcf@rew09926dag03b.domain1.systemhost.net> User-Agent: Mutt/1.5.23 (2014-03-12) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNLMWRmVeSWpSXmKPExsUi2FAYpRvK8D3UoOOvvMXn1dfZHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV8X3eHMaCJpGKB89XsDYw3hboYuTgkBAwkbj3zLSLkRPIFJO4 cG89G4gtJLCXUeJmpzxE3ESi6247cxcjF1C8n0niwp8udging0ni2Z8LrCBVwgKSEt137jCD DGURUJU4fZELJMwmoCXx9nY7WIkIUMmK7avAFjCD2H8/QbXGS5x6MJMdpJVXwEBi014xiBvC JI4cvckEYvMKCEr8mHyPBaJVS2L9zuNMELa0xKO/M9hBbE6BcImpz/6B1YgKqEhcmfAW7EwJ gQVsEuf2T2KbwCgyC8msWUhmzUIyawEj8ypGodzEzBzdzDxzvcSCgpxUveT83E2MoNCebie2 g/HhKqtDjAIcjEo8vAr3v4YKsSaWFVfmHmKU5mBREue9+PNbqJBAemJJanZqakFqUXxRaU5q 8SFGJg5OqQZGDs29Lru2C6yyfCgSqG/Od09v/fSGsn8pW24KLf62RdL40K2t8n/Fjy+TOXDn qcrbQ5Pm6Z405eO2l/xgJzAveWdCja5V6fJMM/lpc6Q2tQg4VN5/YPR98w2rWS5rfvrvPPXl Uvz7gINFd9QZN5y/bSGpHVjrcXXn3+NtT/JKdWvSdtROO/lhpRJLcUaioRZzUXEiAFRdwSlO AgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUi2FCcrBvK8D3U4OUmQYvPq6+zOTB6LFny kymAMYrLJiU1J7MstUjfLoEr4/u8OYwFTSIVD56vYG1gvC3QxcjJISFgItF1t50ZwhaTuHBv PVsXIxeHkEA/k8SFP13sEE4Hk8SzPxdYQaqEBSQluu/cAerg4GARUJU4fZELJMwmoCXx9nY7 WIkIUMmK7avYQGxmEPvvJ6jWeIlTD2ayg7TyChhIbNorBhIWEgiTOHL0JhOIzSsgKPFj8j0W iFYtifU7jzNB2NISj/7OYAexOQXCJaY++wdWIyqgInFlwlv2CYyCs5C0z0LSPgtJ+wJG5lWM AkWpOYmVZnqJBQU5qXrJ+bmbGMHhWBi1g7FhudUhRgEORiUeXoX7X0OFWBPLiitzDzFKcDAr ifBWn/4WKsSbklhZlVqUH19UmpNafIgxGRgME5mlRJPzgbGSVxJvaGJiYGJsbGZsbG5iTpqw kjhvg8irUCGB9MSS1OzU1ILUIpgtTBycUg2M2S/fmy7u+spkmfzRXePEYye3owdizTUnrThx wJB93YGXHq212mfzW+RVJx/UfvrBrt7i7Le6vFLHvCfV7/kWZXy42cgd6SVzUtXyYFP5pFUB 7opclbNDp744xr5nJuuEq5oGnIH9xndPJb6dv2d91uKLl790mnA12iQV/rzjyNawId6458oR JZbijERDLeai4kQAUs5Y/osCAAA= Archived-At: Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Discussion /Consensus on incrementing the version number of MPTCP 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, 14 Sep 2015 17:13:59 -0000 Hello, On 14/09/15 - 14:45:40, philip.eardley@bt.com wrote: > During our interim call last week, several discussion points touched on this topic. The implication would be that the MPTCP version number is 1 in the protocol bis (Standards track), and hence it would be incompatible with the current Experimental track protocol (version number is 0). > > > * Making MP-CAPABLE reliable. There was a lot of support for this during the interim, with no-one against. One or two on-going questions were raised by Yoshi. This requires a new version number. > > If it's agreed that the standards track RFC will be a different version number, then several other things have been raised > > * A new Proxy 'P' flag in MP_CAPABLE, https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dwei-2Dmptcp-2Dproxy-2Dmechanism-2D02&d=BQIFAg&c=eEvniauFctOgLOKGJOplqw&r=fSuJ9mpJ1IB1Lz-sIp_MCe23kZIFT6UKt4EhsewNEmA&m=jjrPk64oS-oD6jdITVevNLLZE2ZPzHwtivNCIVEU2R0&s=jvyGX0tWdV6396IQtsqvNJQ92kEGWhn-GWUmkWZwHpo&e= There was some support for this flag during the interim. > > * Replacing the IPver field in ADD_ADDR with a set of flags. Several people have supported this (though not yet have an agreed proposal /details). > > * Making the MPTCP token locally meaningful, in order that mptcp can work well with load balancers. See the discussion over the last few days prompted by https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dpaasch-2Dmptcp-2Dloadbalancer_&d=BQIFAg&c=eEvniauFctOgLOKGJOplqw&r=fSuJ9mpJ1IB1Lz-sIp_MCe23kZIFT6UKt4EhsewNEmA&m=jjrPk64oS-oD6jdITVevNLLZE2ZPzHwtivNCIVEU2R0&s=29EQ9N7fXiZSGbwCqBFl-6bDFqOt0TrYNeVUVS1aKsQ&e= > > * The possibility of leveraging security off TLS (if TLS is being used) > > The more general point is that - a new version number would mean that we have the opportunity to re-design MPTCP's signalling, based on the lessons learnt from the current implementations and deployments and the new requirements that have emerged. > > So the first step is to make sure that we have consensus that in principle the protocol bis will have a new version number. > Since we didn't explicitly do a consensus call on this during the meeting, please send you views, positive or negative, to the list. as an author of two of the above drafts, I'm in favor of bumping the version-number. It will allow to fix MPTCP wrt to the above mentioned issues and bring MPTCP one step closer to wide-spread deployment. Christoph From nobody Mon Sep 14 10:55: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 D16F91B40BB for ; Mon, 14 Sep 2015 10:55:09 -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 QMPwq-9MNjTt for ; Mon, 14 Sep 2015 10:55:07 -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 7A7FD1B387A for ; Mon, 14 Sep 2015 10:55:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1442253307; x=2306166907; 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=NnFJdjI62zhSAAjvNniHAKc4kD1yPjAX5H3gHc4wMS0=; b=fRI4MkBH5tqWSEWwUCP9oCArIoTa/HIwSRveagjtxmvXpgnIDxVUSf8nm5Hb6nxN LF+qUC+Wa64Amt/ye1Jy7wGvdRPSCYUoKl+JShupF8xpYH8LHZrz2rKw42kkf3cE ZNP9q6GtTtw7Wknx29YeGp1uWjmynmBrBPz1U//ZCp6d/KJAk3+YE6bV+Aol1RDR o0mVsH6BeNxiC7eW7iDMNS/j3y1HJP22TP9coERo40d8yldYLpibInkbnuQ06mwx x9r9TyzVzOydqg+L+duS1cS9PyiRyW/z+uBz/gwBd2VcL1QvNiviEafuAcV/fHm2 vBBgkDm2WZhHhjmp9oSjeg==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id D2.94.24160.BF907F55; Mon, 14 Sep 2015 10:55:07 -0700 (PDT) X-AuditID: 11973e15-f79cb6d000005e60-e1-55f709fb9dfb Received: from chicory.apple.com (chicory.apple.com [17.128.115.99]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id 8C.D6.22881.AF907F55; Mon, 14 Sep 2015 10:55:06 -0700 (PDT) Received: from ajm-macpro.apple.com (ajm-macpro.apple.com [17.228.11.195]) by chicory.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NUO00FXUHRTAB30@chicory.apple.com> for multipathtcp@ietf.org; Mon, 14 Sep 2015 10:55:06 -0700 (PDT) Sender: anumita_biswas@apple.com Content-type: text/plain; charset=us-ascii MIME-version: 1.0 (Mac OS X Mail 9.0 \(3094\)) From: Anumita Biswas In-reply-to: <20150914171356.GM1981@Chimay.local> Date: Mon, 14 Sep 2015 10:55:05 -0700 Content-transfer-encoding: quoted-printable Message-id: <0EA79B5C-BBCC-47E8-B2CA-7C853296AAE7@apple.com> References: <7082931042c142fabaa6e88275a56fcf@rew09926dag03b.domain1.systemhost.net> <20150914171356.GM1981@Chimay.local> To: Christoph Paasch X-Mailer: Apple Mail (2.3094) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrPLMWRmVeSWpSXmKPExsUi2FAYpfub83uoQe9tJovPq6+zOTB6LFny kymAMYrLJiU1J7MstUjfLoEr493C6WwFP6Uqtm35wN7AeFKsi5GTQ0LARGLBnensELaYxIV7 69m6GLk4hAT2MkrMWveeBaboc89VVohEP5PE4qn7mCGc1UwSS3bMYQapEhZQkPhwZRFYB7OA lsT6nceZQGxeAT2JS1M2MkLUxEucejATbB2bgL7E0Uc3wHo5BQwlrl3pBathEVCV2Pb1JivE HAOJpXMuskPY2hJP3l1ghZhpI9GyfwsbiC0kUCvx58glsL0iAhoSKx9OY4S4Wlbi1tfV7CCH SggsYJPoeP2aaQKjyCwk981Cct8sJDsWMDKvYhTKTczM0c3MM9NLLCjISdVLzs/dxAgK8el2 ojsYz6yyOsQowMGoxMOrcP9rqBBrYllxZe4hRmkOFiVxXnuG76FCAumJJanZqakFqUXxRaU5 qcWHGJk4OKUaGEvu5/d/9Z3ds5L/3qFzyTs/Km5j/6f45Infkuc3L7i1cbGcinRweZZ20HDC tepolX08U3qOMtk8P9Qd0BfW1WL1f274zIyaW8EG+rWy58qqtz3IzhPaoa004Y4s38GNt6z7 Fif9iOVzrms+eFRQ9tCZedyllZurb+n+eP64K/Fuvtgz043bliixFGckGmoxFxUnAgCYvSCD UgIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFLMWRmVeSWpSXmKPExsUi2FCcrPuL83uoQfdWBYvPq6+zOTB6LFny kymAMYrLJiU1J7MstUjfLoEr493C6WwFP6Uqtm35wN7AeFKsi5GTQ0LAROJzz1VWCFtM4sK9 9WxdjFwcQgL9TBKLp+5jhnBWM0ks2TGHGaRKWEBB4sOVRSwgNrOAlsT6nceZQGxeAT2JS1M2 MkLUxEucejCTHcRmE9CXOProBlgvp4ChxLUrvWA1LAKqEtu+3mSFmGMgsXTORXYIW1viybsL rBAzbSRa9m9hA7GFBGol/hy5BLZXREBDYuXDaYwQV8tK3Pq6mn0Co+AsJCfNQnLSLCRjFzAy r2IUKErNSaw000ssKMhJ1UvOz93ECA7JwqgdjA3LrQ4xCnAwKvHwKtz/GirEmlhWXJl7iFGC g1lJhLf69LdQId6UxMqq1KL8+KLSnNTiQ4zJQM9MZJYSTc4HxkteSbyhiYmBibGxmbGxuYk5 acJK4rx3gXEpJJCeWJKanZpakFoEs4WJg1OqgXF2Bp/hng9WHimnZx7I19d9psCybKp/tYh3 l6GloM0PtZWHzGL6tzX0vHXc53PRcVOonvSUkp3XnD7t/x4TkXuabd4UfUvXU7etP3KusAhW T8zYXK4rcbviYAH/EY2+4p4evY18ynPbn3+48S36ve685RezN6er33ONlP/fVaSqunRN8d6S RCWW4oxEQy3mouJEACsjnneNAgAA Archived-At: Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Discussion /Consensus on incrementing the version number of MPTCP 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, 14 Sep 2015 17:55:10 -0000 + 1 for bumping the version number. The proposed changes are big enough that they will cause backward = compatibility issues with existing implementations if added on version = 0. Thanks, Anumita > On Sep 14, 2015, at 10:13 AM, Christoph Paasch = wrote: >=20 > Hello, >=20 > On 14/09/15 - 14:45:40, philip.eardley@bt.com wrote: >> During our interim call last week, several discussion points touched = on this topic. The implication would be that the MPTCP version number is = 1 in the protocol bis (Standards track), and hence it would be = incompatible with the current Experimental track protocol (version = number is 0). >>=20 >>=20 >> * Making MP-CAPABLE reliable. There was a lot of support for = this during the interim, with no-one against. One or two on-going = questions were raised by Yoshi. This requires a new version number. >>=20 >> If it's agreed that the standards track RFC will be a different = version number, then several other things have been raised >>=20 >> * A new Proxy 'P' flag in MP_CAPABLE, = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_html= _draft-2Dwei-2Dmptcp-2Dproxy-2Dmechanism-2D02&d=3DBQIFAg&c=3DeEvniauFctOgL= OKGJOplqw&r=3DfSuJ9mpJ1IB1Lz-sIp_MCe23kZIFT6UKt4EhsewNEmA&m=3DjjrPk64oS-oD= 6jdITVevNLLZE2ZPzHwtivNCIVEU2R0&s=3DjvyGX0tWdV6396IQtsqvNJQ92kEGWhn-GWUmkW= ZwHpo&e=3D There was some support for this flag during the interim. >>=20 >> * Replacing the IPver field in ADD_ADDR with a set of flags. = Several people have supported this (though not yet have an agreed = proposal /details). >>=20 >> * Making the MPTCP token locally meaningful, in order that = mptcp can work well with load balancers. See the discussion over the = last few days prompted by = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ietf.or= g_doc_draft-2Dpaasch-2Dmptcp-2Dloadbalancer_&d=3DBQIFAg&c=3DeEvniauFctOgLO= KGJOplqw&r=3DfSuJ9mpJ1IB1Lz-sIp_MCe23kZIFT6UKt4EhsewNEmA&m=3DjjrPk64oS-oD6= jdITVevNLLZE2ZPzHwtivNCIVEU2R0&s=3D29EQ9N7fXiZSGbwCqBFl-6bDFqOt0TrYNeVUVS1= aKsQ&e=3D=20 >>=20 >> * The possibility of leveraging security off TLS (if TLS is = being used) >>=20 >> The more general point is that - a new version number would mean that = we have the opportunity to re-design MPTCP's signalling, based on the = lessons learnt from the current implementations and deployments and the = new requirements that have emerged. >>=20 >> So the first step is to make sure that we have consensus that in = principle the protocol bis will have a new version number. >> Since we didn't explicitly do a consensus call on this during the = meeting, please send you views, positive or negative, to the list. >=20 > as an author of two of the above drafts, I'm in favor of bumping the > version-number. It will allow to fix MPTCP wrt to the above mentioned = issues > and bring MPTCP one step closer to wide-spread deployment. >=20 >=20 > Christoph >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > = https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma= n_listinfo_multipathtcp&d=3DBQICAg&c=3DeEvniauFctOgLOKGJOplqw&r=3Dis7V2j_7= 7TQ8H500qPvC98gSLwj4K3agvCyq4ChpMmw&m=3DWM3tRORkrsC_jj-T7zcG_vDG4EP3Gmr6Ni= TZSiXyvgw&s=3DG0SQa7T3503a_SZbKUXpdyJ-zdj0w3SPs1ufDxu2QcM&e=3D=20 From nobody Mon Sep 14 17:12:10 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 7662F1B3488 for ; Mon, 14 Sep 2015 17:12:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.906 X-Spam-Level: X-Spam-Status: No, score=-1.906 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_AU=0.377, HOST_EQ_AU=0.327, RCVD_IN_DNSWL_LOW=-0.7, 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 oa3H7XfK9X4t for ; Mon, 14 Sep 2015 17:12:07 -0700 (PDT) Received: from gpo4.cc.swin.edu.au (gpo4.cc.swin.edu.au [136.186.1.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5E3D1B346A for ; Mon, 14 Sep 2015 17:12:06 -0700 (PDT) Received: from Nigels-MacBook-Air.local (vpn242-222.cc.swin.edu.au [136.186.242.222]) by gpo4.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id t8F0BwoN026807; Tue, 15 Sep 2015 10:12:00 +1000 Message-ID: <55F7624E.6000004@swin.edu.au> Date: Tue, 15 Sep 2015 10:11:58 +1000 From: Nigel Williams User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Anumita Biswas , Christoph Paasch References: <7082931042c142fabaa6e88275a56fcf@rew09926dag03b.domain1.systemhost.net> <20150914171356.GM1981@Chimay.local> <0EA79B5C-BBCC-47E8-B2CA-7C853296AAE7@apple.com> In-Reply-To: <0EA79B5C-BBCC-47E8-B2CA-7C853296AAE7@apple.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Discussion /Consensus on incrementing the version number of MPTCP 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, 15 Sep 2015 00:12:09 -0000 I'm also for bumping the version number. cheers, nigel On 15/09/2015 3:55 am, Anumita Biswas wrote: > + 1 for bumping the version number. > > The proposed changes are big enough that they will cause backward compatibility issues with existing implementations if added on version 0. > > Thanks, > Anumita > >> On Sep 14, 2015, at 10:13 AM, Christoph Paasch wrote: >> >> Hello, >> >> On 14/09/15 - 14:45:40, philip.eardley@bt.com wrote: >>> During our interim call last week, several discussion points touched on this topic. The implication would be that the MPTCP version number is 1 in the protocol bis (Standards track), and hence it would be incompatible with the current Experimental track protocol (version number is 0). >>> >>> >>> * Making MP-CAPABLE reliable. There was a lot of support for this during the interim, with no-one against. One or two on-going questions were raised by Yoshi. This requires a new version number. >>> >>> If it's agreed that the standards track RFC will be a different version number, then several other things have been raised >>> >>> * A new Proxy 'P' flag in MP_CAPABLE, https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dwei-2Dmptcp-2Dproxy-2Dmechanism-2D02&d=BQIFAg&c=eEvniauFctOgLOKGJOplqw&r=fSuJ9mpJ1IB1Lz-sIp_MCe23kZIFT6UKt4EhsewNEmA&m=jjrPk64oS-oD6jdITVevNLLZE2ZPzHwtivNCIVEU2R0&s=jvyGX0tWdV6396IQtsqvNJQ92kEGWhn-GWUmkWZwHpo&e= There was some support for this flag during the interim. >>> >>> * Replacing the IPver field in ADD_ADDR with a set of flags. Several people have supported this (though not yet have an agreed proposal /details). >>> >>> * Making the MPTCP token locally meaningful, in order that mptcp can work well with load balancers. See the discussion over the last few days prompted by https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dpaasch-2Dmptcp-2Dloadbalancer_&d=BQIFAg&c=eEvniauFctOgLOKGJOplqw&r=fSuJ9mpJ1IB1Lz-sIp_MCe23kZIFT6UKt4EhsewNEmA&m=jjrPk64oS-oD6jdITVevNLLZE2ZPzHwtivNCIVEU2R0&s=29EQ9N7fXiZSGbwCqBFl-6bDFqOt0TrYNeVUVS1aKsQ&e= >>> >>> * The possibility of leveraging security off TLS (if TLS is being used) >>> >>> The more general point is that - a new version number would mean that we have the opportunity to re-design MPTCP's signalling, based on the lessons learnt from the current implementations and deployments and the new requirements that have emerged. >>> >>> So the first step is to make sure that we have consensus that in principle the protocol bis will have a new version number. >>> Since we didn't explicitly do a consensus call on this during the meeting, please send you views, positive or negative, to the list. >> >> as an author of two of the above drafts, I'm in favor of bumping the >> version-number. It will allow to fix MPTCP wrt to the above mentioned issues >> and bring MPTCP one step closer to wide-spread deployment. >> >> >> Christoph >> >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_multipathtcp&d=BQICAg&c=eEvniauFctOgLOKGJOplqw&r=is7V2j_77TQ8H500qPvC98gSLwj4K3agvCyq4ChpMmw&m=WM3tRORkrsC_jj-T7zcG_vDG4EP3Gmr6NiTZSiXyvgw&s=G0SQa7T3503a_SZbKUXpdyJ-zdj0w3SPs1ufDxu2QcM&e= > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > From nobody Mon Sep 14 23:50:02 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 424E21A6FAE for ; Mon, 14 Sep 2015 23:50:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.515 X-Spam-Level: * X-Spam-Status: No, score=1.515 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, 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 X_np-vQ_n_Y4 for ; Mon, 14 Sep 2015 23:49:58 -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 5F4AD1B44E8 for ; Mon, 14 Sep 2015 23:49:57 -0700 (PDT) Received: from mail-ob0-f180.google.com (mail-ob0-f180.google.com [209.85.214.180]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id D666A278109 for ; Tue, 15 Sep 2015 15:49:55 +0900 (JST) Received: by obbzf10 with SMTP id zf10so71683093obb.2 for ; Mon, 14 Sep 2015 23:49:54 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.60.102.33 with SMTP id fl1mr561706oeb.11.1442299794387; Mon, 14 Sep 2015 23:49:54 -0700 (PDT) Received: by 10.202.197.15 with HTTP; Mon, 14 Sep 2015 23:49:54 -0700 (PDT) In-Reply-To: <55F7624E.6000004@swin.edu.au> References: <7082931042c142fabaa6e88275a56fcf@rew09926dag03b.domain1.systemhost.net> <20150914171356.GM1981@Chimay.local> <0EA79B5C-BBCC-47E8-B2CA-7C853296AAE7@apple.com> <55F7624E.6000004@swin.edu.au> Date: Mon, 14 Sep 2015 23:49:54 -0700 Message-ID: From: Yoshifumi Nishida To: Nigel Williams Content-Type: multipart/alternative; boundary=089e0111b2eae77a02051fc3961a Archived-At: Cc: multipathtcp Subject: Re: [multipathtcp] Discussion /Consensus on incrementing the version number of MPTCP 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, 15 Sep 2015 06:50:01 -0000 --089e0111b2eae77a02051fc3961a Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hello folks, I just would like to check a few points on increasing the version number. I guess this means the followings. If I miss something or have different views, please point it out. 1: The handshake method described in draft-paasch-mptcp-syncookies will be included in 6824bis. This will be a single initial handshake method in mptcp. 2: Version 0 won't be supported after 6824bis has been published. 3: We won't discuss backward compatible mechanisms such as fallback logics (from version 1 to version 0) Thanks, -- Yoshi On Mon, Sep 14, 2015 at 5:11 PM, Nigel Williams wrote: > I'm also for bumping the version number. > > cheers, > nigel > > > On 15/09/2015 3:55 am, Anumita Biswas wrote: > >> + 1 for bumping the version number. >> >> The proposed changes are big enough that they will cause backward >> compatibility issues with existing implementations if added on version 0= . >> >> Thanks, >> Anumita >> >> On Sep 14, 2015, at 10:13 AM, Christoph Paasch wrote= : >>> >>> Hello, >>> >>> On 14/09/15 - 14:45:40, philip.eardley@bt.com wrote: >>> >>>> During our interim call last week, several discussion points touched o= n >>>> this topic. The implication would be that the MPTCP version number is = 1 in >>>> the protocol bis (Standards track), and hence it would be incompatible= with >>>> the current Experimental track protocol (version number is 0). >>>> >>>> >>>> * Making MP-CAPABLE reliable. There was a lot of support for >>>> this during the interim, with no-one against. One or two on-going ques= tions >>>> were raised by Yoshi. This requires a new version number. >>>> >>>> If it's agreed that the standards track RFC will be a different versio= n >>>> number, then several other things have been raised >>>> >>>> * A new Proxy 'P' flag in MP_CAPABLE, >>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org_= html_draft-2Dwei-2Dmptcp-2Dproxy-2Dmechanism-2D02&d=3DBQIFAg&c=3DeEvniauFct= OgLOKGJOplqw&r=3DfSuJ9mpJ1IB1Lz-sIp_MCe23kZIFT6UKt4EhsewNEmA&m=3DjjrPk64oS-= oD6jdITVevNLLZE2ZPzHwtivNCIVEU2R0&s=3DjvyGX0tWdV6396IQtsqvNJQ92kEGWhn-GWUmk= WZwHpo&e=3D >>>> There was some support for this flag during the interim. >>>> >>>> * Replacing the IPver field in ADD_ADDR with a set of flags. >>>> Several people have supported this (though not yet have an agreed prop= osal >>>> /details). >>>> >>>> * Making the MPTCP token locally meaningful, in order that >>>> mptcp can work well with load balancers. See the discussion over the l= ast >>>> few days prompted by >>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.iet= f.org_doc_draft-2Dpaasch-2Dmptcp-2Dloadbalancer_&d=3DBQIFAg&c=3DeEvniauFctO= gLOKGJOplqw&r=3DfSuJ9mpJ1IB1Lz-sIp_MCe23kZIFT6UKt4EhsewNEmA&m=3DjjrPk64oS-o= D6jdITVevNLLZE2ZPzHwtivNCIVEU2R0&s=3D29EQ9N7fXiZSGbwCqBFl-6bDFqOt0TrYNeVUVS= 1aKsQ&e=3D >>>> >>>> * The possibility of leveraging security off TLS (if TLS is >>>> being used) >>>> >>>> The more general point is that - a new version number would mean that >>>> we have the opportunity to re-design MPTCP's signalling, based on the >>>> lessons learnt from the current implementations and deployments and th= e new >>>> requirements that have emerged. >>>> >>>> So the first step is to make sure that we have consensus that in >>>> principle the protocol bis will have a new version number. >>>> Since we didn't explicitly do a consensus call on this during the >>>> meeting, please send you views, positive or negative, to the list. >>>> >>> >>> as an author of two of the above drafts, I'm in favor of bumping the >>> version-number. It will allow to fix MPTCP wrt to the above mentioned >>> issues >>> and bring MPTCP one step closer to wide-spread deployment. >>> >>> >>> Christoph >>> >>> _______________________________________________ >>> multipathtcp mailing list >>> multipathtcp@ietf.org >>> >>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mai= lman_listinfo_multipathtcp&d=3DBQICAg&c=3DeEvniauFctOgLOKGJOplqw&r=3Dis7V2j= _77TQ8H500qPvC98gSLwj4K3agvCyq4ChpMmw&m=3DWM3tRORkrsC_jj-T7zcG_vDG4EP3Gmr6N= iTZSiXyvgw&s=3DG0SQa7T3503a_SZbKUXpdyJ-zdj0w3SPs1ufDxu2QcM&e=3D >>> >> >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp >> >> > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > --089e0111b2eae77a02051fc3961a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello folks,

I just would like to = check a few points on increasing the version number.
I guess this= means the followings. If I miss something or have different views, please = point it out.

1: The handshake method described in= draft-paasch-mptcp-syncookies will be included in 6824bis. This will be a = single initial handshake method in mptcp.
2: Version 0 won't = be supported after 6824bis has been published.=C2=A0
3: We won= 9;t discuss backward compatible mechanisms such as fallback logics (from ve= rsion 1 to version 0)=C2=A0

Thanks,
= --
Yoshi


On Mon, Sep 14, 2015 at 5:11 PM, Nigel Williams <nj= williams@swin.edu.au> wrote:
I'm also= for bumping the version number.

cheers,
nigel


On 15/09/2015 3:55 am, Anumita Biswas wrote:
+ 1 for bumping the version number.

The proposed changes are big enough that they will cause backward compatibi= lity issues with existing implementations if added on version 0.

Thanks,
Anumita

On Sep 14, 2015, at 10:13 AM, Christoph Paasch <cpaasch@apple.com> wrote:

Hello,

On 14/09/15 - 14:45:40, philip.eardley@bt.com wrote:
During our interim call last week, several discussion points touched on thi= s topic. The implication would be that the MPTCP version number is 1 in the= protocol bis (Standards track), and hence it would be incompatible with th= e current Experimental track protocol (version number is 0).


*=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Making MP-CAPABLE reliable. There was a = lot of support for this during the interim, with no-one against. One or two= on-going questions were raised by Yoshi. This requires a new version numbe= r.

If it's agreed that the standards track RFC will be a different version= number, then several other things have been raised

*=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A new Proxy 'P' flag in MP_CAPAB= LE, https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.= org_html_draft-2Dwei-2Dmptcp-2Dproxy-2Dmechanism-2D02&d=3DBQIFAg&c= =3DeEvniauFctOgLOKGJOplqw&r=3DfSuJ9mpJ1IB1Lz-sIp_MCe23kZIFT6UKt4EhsewNE= mA&m=3DjjrPk64oS-oD6jdITVevNLLZE2ZPzHwtivNCIVEU2R0&s=3DjvyGX0tWdV63= 96IQtsqvNJQ92kEGWhn-GWUmkWZwHpo&e=3D=C2=A0 =C2=A0There was some sup= port for this flag during the interim.

*=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Replacing the IPver field in ADD_ADDR wi= th a set of flags. Several people have supported this (though not yet have = an agreed proposal /details).

*=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Making the MPTCP token locally meaningfu= l, in order that mptcp can work well with load balancers. See the discussio= n over the last few days prompted by https://urldefense.proofpoint.com= /v2/url?u=3Dhttps-3A__datatracker.ietf.org_doc_draft-2Dpaasch-2Dmptcp-2Dloa= dbalancer_&d=3DBQIFAg&c=3DeEvniauFctOgLOKGJOplqw&r=3DfSuJ9mpJ1I= B1Lz-sIp_MCe23kZIFT6UKt4EhsewNEmA&m=3DjjrPk64oS-oD6jdITVevNLLZE2ZPzHwti= vNCIVEU2R0&s=3D29EQ9N7fXiZSGbwCqBFl-6bDFqOt0TrYNeVUVS1aKsQ&e=3D=

*=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The possibility of leveraging security o= ff TLS (if TLS is being used)

The more general point is that - a new version number would mean that we ha= ve the opportunity to re-design MPTCP's signalling, based on the lesson= s learnt from the current implementations and deployments and the new requi= rements that have emerged.

So the first step is to make sure that we have consensus that in principle = the protocol bis will have a new version number.
Since we didn't explicitly do a consensus call on this during the meeti= ng, please send you views, positive or negative, to the list.

as an author of two of the above drafts, I'm in favor of bumping the version-number. It will allow to fix MPTCP wrt to the above mentioned issue= s
and bring MPTCP one step closer to wide-spread deployment.


Christoph

_______________________________________________
multipathtcp mailing list
multipathtcp@iet= f.org
https://urldefens= e.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_multipa= thtcp&d=3DBQICAg&c=3DeEvniauFctOgLOKGJOplqw&r=3Dis7V2j_77TQ8H50= 0qPvC98gSLwj4K3agvCyq4ChpMmw&m=3DWM3tRORkrsC_jj-T7zcG_vDG4EP3Gmr6NiTZSi= Xyvgw&s=3DG0SQa7T3503a_SZbKUXpdyJ-zdj0w3SPs1ufDxu2QcM&e=3D

_______________________________________________
multipathtcp mailing list
multipathtcp@iet= f.org
https://www.ietf.org/mailman/listinfo/multipathtcp=


_______________________________________________
multipathtcp mailing list
multipathtcp@iet= f.org
https://www.ietf.org/mailman/listinfo/multipathtcp=

--089e0111b2eae77a02051fc3961a-- From nobody Tue Sep 15 02:23:18 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 341351AD06E for ; Tue, 15 Sep 2015 02:23:17 -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 JQetT9mlCJPB for ; Tue, 15 Sep 2015 02:23:14 -0700 (PDT) Received: from mail-yk0-x22a.google.com (mail-yk0-x22a.google.com [IPv6:2607:f8b0:4002:c07::22a]) (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 1E8F51A6F17 for ; Tue, 15 Sep 2015 02:23:14 -0700 (PDT) Received: by ykft14 with SMTP id t14so27248024ykf.0 for ; Tue, 15 Sep 2015 02:23:13 -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=HaZLl3s3eZfc/jgvqGdSkXOskK4UrmkoGXEUFgFAinI=; b=UgZd2dfBddhPke0pPX6WKbUAc6X0F8o2iaYzWAjczqwNVKUdC5239K0XWvvlkbEp7D YhAzjBgQqYkFXkJ5bsoUsx+4NrNBSqv+fZCLpd8G0wyzROkX9D0prk1e/E9BiVdUwUSj g+4dDcpjrFUm0ZQc2j+b5RvwAWjBsUG4vJLjbeE6wrk/j/oi9PCUs6V+zhy52zu4vthu 9jNMjF6NlXDq4GHplALghoRDQN4nS/LDtOUGVgRb/a+FKmLH8f2ErCwG1iXfmMHGEuAf Okh7E/RI4cBLFdqOlNQlFGVIB61STwIXr7dqQ6MlXasf1FL/yXWmK+cZh6gP9GrgTiWb MOSw== MIME-Version: 1.0 X-Received: by 10.13.254.3 with SMTP id o3mr19316061ywf.161.1442308993355; Tue, 15 Sep 2015 02:23:13 -0700 (PDT) Received: by 10.129.104.131 with HTTP; Tue, 15 Sep 2015 02:23:13 -0700 (PDT) In-Reply-To: References: <7082931042c142fabaa6e88275a56fcf@rew09926dag03b.domain1.systemhost.net> <20150914171356.GM1981@Chimay.local> <0EA79B5C-BBCC-47E8-B2CA-7C853296AAE7@apple.com> <55F7624E.6000004@swin.edu.au> Date: Tue, 15 Sep 2015 10:23:13 +0100 Message-ID: From: Alan Ford To: Yoshifumi Nishida Content-Type: multipart/alternative; boundary=94eb2c054c903498d3051fc5bbba Archived-At: Cc: multipathtcp Subject: Re: [multipathtcp] Discussion /Consensus on incrementing the version number of MPTCP 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, 15 Sep 2015 09:23:17 -0000 --94eb2c054c903498d3051fc5bbba Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Yoshifumi, all, I too am in favour of bumping the version number. I am in favour of including the syncookies handshake mechanism (or something similar, in order to facilitate the token signalling - for further discussion). @Nigel - something you'd mentioned some time ago was a little hack on the ISDN generation - zeroing the most significant bit - in order to remove any chance of early sequence number wrapping. I don't know if this is something you'd still like considered for 6824bis? Given a version number bump it's entirely feasible to add this now. As regards backward compatibility, we already discuss the fallback mechanism in 6824bis - if a device supported both version numbers, it could try both 1 and fall back to 0 if it wanted. But there's no expectation any device will. Regards, Alan On 15 September 2015 at 07:49, Yoshifumi Nishida wrote: > Hello folks, > > I just would like to check a few points on increasing the version number. > I guess this means the followings. If I miss something or have different > views, please point it out. > > 1: The handshake method described in draft-paasch-mptcp-syncookies will b= e > included in 6824bis. This will be a single initial handshake method in > mptcp. > 2: Version 0 won't be supported after 6824bis has been published. > 3: We won't discuss backward compatible mechanisms such as fallback logic= s > (from version 1 to version 0) > > Thanks, > -- > Yoshi > > > On Mon, Sep 14, 2015 at 5:11 PM, Nigel Williams > wrote: > >> I'm also for bumping the version number. >> >> cheers, >> nigel >> >> >> On 15/09/2015 3:55 am, Anumita Biswas wrote: >> >>> + 1 for bumping the version number. >>> >>> The proposed changes are big enough that they will cause backward >>> compatibility issues with existing implementations if added on version = 0. >>> >>> Thanks, >>> Anumita >>> >>> On Sep 14, 2015, at 10:13 AM, Christoph Paasch >>>> wrote: >>>> >>>> Hello, >>>> >>>> On 14/09/15 - 14:45:40, philip.eardley@bt.com wrote: >>>> >>>>> During our interim call last week, several discussion points touched >>>>> on this topic. The implication would be that the MPTCP version number= is 1 >>>>> in the protocol bis (Standards track), and hence it would be incompat= ible >>>>> with the current Experimental track protocol (version number is 0). >>>>> >>>>> >>>>> * Making MP-CAPABLE reliable. There was a lot of support for >>>>> this during the interim, with no-one against. One or two on-going que= stions >>>>> were raised by Yoshi. This requires a new version number. >>>>> >>>>> If it's agreed that the standards track RFC will be a different >>>>> version number, then several other things have been raised >>>>> >>>>> * A new Proxy 'P' flag in MP_CAPABLE, >>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.org= _html_draft-2Dwei-2Dmptcp-2Dproxy-2Dmechanism-2D02&d=3DBQIFAg&c=3DeEvniauFc= tOgLOKGJOplqw&r=3DfSuJ9mpJ1IB1Lz-sIp_MCe23kZIFT6UKt4EhsewNEmA&m=3DjjrPk64oS= -oD6jdITVevNLLZE2ZPzHwtivNCIVEU2R0&s=3DjvyGX0tWdV6396IQtsqvNJQ92kEGWhn-GWUm= kWZwHpo&e=3D >>>>> There was some support for this flag during the interim. >>>>> >>>>> * Replacing the IPver field in ADD_ADDR with a set of flags. >>>>> Several people have supported this (though not yet have an agreed pro= posal >>>>> /details). >>>>> >>>>> * Making the MPTCP token locally meaningful, in order that >>>>> mptcp can work well with load balancers. See the discussion over the = last >>>>> few days prompted by >>>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__datatracker.ie= tf.org_doc_draft-2Dpaasch-2Dmptcp-2Dloadbalancer_&d=3DBQIFAg&c=3DeEvniauFct= OgLOKGJOplqw&r=3DfSuJ9mpJ1IB1Lz-sIp_MCe23kZIFT6UKt4EhsewNEmA&m=3DjjrPk64oS-= oD6jdITVevNLLZE2ZPzHwtivNCIVEU2R0&s=3D29EQ9N7fXiZSGbwCqBFl-6bDFqOt0TrYNeVUV= S1aKsQ&e=3D >>>>> >>>>> * The possibility of leveraging security off TLS (if TLS is >>>>> being used) >>>>> >>>>> The more general point is that - a new version number would mean that >>>>> we have the opportunity to re-design MPTCP's signalling, based on the >>>>> lessons learnt from the current implementations and deployments and t= he new >>>>> requirements that have emerged. >>>>> >>>>> So the first step is to make sure that we have consensus that in >>>>> principle the protocol bis will have a new version number. >>>>> Since we didn't explicitly do a consensus call on this during the >>>>> meeting, please send you views, positive or negative, to the list. >>>>> >>>> >>>> as an author of two of the above drafts, I'm in favor of bumping the >>>> version-number. It will allow to fix MPTCP wrt to the above mentioned >>>> issues >>>> and bring MPTCP one step closer to wide-spread deployment. >>>> >>>> >>>> Christoph >>>> >>>> _______________________________________________ >>>> multipathtcp mailing list >>>> multipathtcp@ietf.org >>>> >>>> https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_ma= ilman_listinfo_multipathtcp&d=3DBQICAg&c=3DeEvniauFctOgLOKGJOplqw&r=3Dis7V2= j_77TQ8H500qPvC98gSLwj4K3agvCyq4ChpMmw&m=3DWM3tRORkrsC_jj-T7zcG_vDG4EP3Gmr6= NiTZSiXyvgw&s=3DG0SQa7T3503a_SZbKUXpdyJ-zdj0w3SPs1ufDxu2QcM&e=3D >>>> >>> >>> _______________________________________________ >>> multipathtcp mailing list >>> multipathtcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/multipathtcp >>> >>> >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp >> > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > > --94eb2c054c903498d3051fc5bbba Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Yoshifumi, all,

I too am in favour o= f bumping the version number. I am in favour of including the syncookies ha= ndshake mechanism (or something similar, in order to facilitate the token s= ignalling - for further discussion).

@Nigel - some= thing you'd mentioned some time ago was a little hack on the ISDN gener= ation - zeroing the most significant bit - in order to remove any chance of= early sequence number wrapping. I don't know if this is something you&= #39;d still like considered for 6824bis? Given a version number bump it'= ;s entirely feasible to add this now.

As regards b= ackward compatibility, we already discuss the fallback mechanism in 6824bis= - if a device supported both version numbers, it could try both 1 and fall= back to 0 if it wanted. But there's no expectation any device will.

Regards,
Alan

On 15 September 2015 at 07:49, Yos= hifumi Nishida <nishida@sfc.wide.ad.jp> wrote:
Hello folks,

=
I just would like to check a few points on increasing the version numb= er.
I guess this means the followings. If I miss something or hav= e different views, please point it out.

1: The han= dshake method described in draft-paasch-mptcp-syncookies will be included i= n 6824bis. This will be a single initial handshake method in mptcp.
2: Version 0 won't be supported after 6824bis has been published.=C2= =A0
3: We won't discuss backward compatible mechanisms such a= s fallback logics (from version 1 to version 0)=C2=A0

<= div>Thanks,
--
Yoshi


On Mon, Se= p 14, 2015 at 5:11 PM, Nigel Williams <njwilliams@swin.edu.au>= wrote:
I'm also for bumping the version num= ber.

cheers,
nigel


On 15/09/2015 3:55 am, Anumita Biswas wrote:
+ 1 for bumping the version number.

The proposed changes are big enough that they will cause backward compatibi= lity issues with existing implementations if added on version 0.

Thanks,
Anumita

On Sep 14, 2015, at 10:13 AM, Christoph Paasch <cpaasch@apple.com> wrote:

Hello,

On 14/09/15 - 14:45:40, philip.eardley@bt.com wrote:
During our interim call last week, several discussion points touched on thi= s topic. The implication would be that the MPTCP version number is 1 in the= protocol bis (Standards track), and hence it would be incompatible with th= e current Experimental track protocol (version number is 0).


*=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Making MP-CAPABLE reliable. There was a = lot of support for this during the interim, with no-one against. One or two= on-going questions were raised by Yoshi. This requires a new version numbe= r.

If it's agreed that the standards track RFC will be a different version= number, then several other things have been raised

*=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0A new Proxy 'P' flag in MP_CAPAB= LE, https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ietf.= org_html_draft-2Dwei-2Dmptcp-2Dproxy-2Dmechanism-2D02&d=3DBQIFAg&c= =3DeEvniauFctOgLOKGJOplqw&r=3DfSuJ9mpJ1IB1Lz-sIp_MCe23kZIFT6UKt4EhsewNE= mA&m=3DjjrPk64oS-oD6jdITVevNLLZE2ZPzHwtivNCIVEU2R0&s=3DjvyGX0tWdV63= 96IQtsqvNJQ92kEGWhn-GWUmkWZwHpo&e=3D=C2=A0 =C2=A0There was some sup= port for this flag during the interim.

*=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Replacing the IPver field in ADD_ADDR wi= th a set of flags. Several people have supported this (though not yet have = an agreed proposal /details).

*=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Making the MPTCP token locally meaningfu= l, in order that mptcp can work well with load balancers. See the discussio= n over the last few days prompted by https://urldefense.proofpoint.com= /v2/url?u=3Dhttps-3A__datatracker.ietf.org_doc_draft-2Dpaasch-2Dmptcp-2Dloa= dbalancer_&d=3DBQIFAg&c=3DeEvniauFctOgLOKGJOplqw&r=3DfSuJ9mpJ1I= B1Lz-sIp_MCe23kZIFT6UKt4EhsewNEmA&m=3DjjrPk64oS-oD6jdITVevNLLZE2ZPzHwti= vNCIVEU2R0&s=3D29EQ9N7fXiZSGbwCqBFl-6bDFqOt0TrYNeVUVS1aKsQ&e=3D=

*=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0The possibility of leveraging security o= ff TLS (if TLS is being used)

The more general point is that - a new version number would mean that we ha= ve the opportunity to re-design MPTCP's signalling, based on the lesson= s learnt from the current implementations and deployments and the new requi= rements that have emerged.

So the first step is to make sure that we have consensus that in principle = the protocol bis will have a new version number.
Since we didn't explicitly do a consensus call on this during the meeti= ng, please send you views, positive or negative, to the list.

as an author of two of the above drafts, I'm in favor of bumping the version-number. It will allow to fix MPTCP wrt to the above mentioned issue= s
and bring MPTCP one step closer to wide-spread deployment.


Christoph

_______________________________________________
multipathtcp mailing list
multipathtcp@iet= f.org
https://urldefens= e.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailman_listinfo_multipa= thtcp&d=3DBQICAg&c=3DeEvniauFctOgLOKGJOplqw&r=3Dis7V2j_77TQ8H50= 0qPvC98gSLwj4K3agvCyq4ChpMmw&m=3DWM3tRORkrsC_jj-T7zcG_vDG4EP3Gmr6NiTZSi= Xyvgw&s=3DG0SQa7T3503a_SZbKUXpdyJ-zdj0w3SPs1ufDxu2QcM&e=3D

_______________________________________________
multipathtcp mailing list
multipathtcp@iet= f.org
https://www.ietf.org/mailman/listinfo/multipathtcp=


_______________________________________________
multipathtcp mailing list
multipathtcp@iet= f.org
https://www.ietf.org/mailman/listinfo/multipathtcp=


_______________________________________________
multipathtcp mailing list
multipathtcp@ietf.org
https://www.ietf.org/mailman/listinfo/multipathtcp=


--94eb2c054c903498d3051fc5bbba-- From nobody Mon Sep 21 06:38:24 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 6C1B41B31B0 for ; Mon, 21 Sep 2015 06:38:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 ylsoQS3BeQv5 for ; Mon, 21 Sep 2015 06:38:22 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A86551B31AF for ; Mon, 21 Sep 2015 06:38:21 -0700 (PDT) Received: from omfeda07.si.francetelecom.fr (unknown [xx.xx.xx.200]) by omfeda10.si.francetelecom.fr (ESMTP service) with ESMTP id 667D73740F8 for ; Mon, 21 Sep 2015 15:38:20 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.57]) by omfeda07.si.francetelecom.fr (ESMTP service) with ESMTP id 3E06015805B for ; Mon, 21 Sep 2015 15:38:20 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3%19]) with mapi id 14.03.0248.002; Mon, 21 Sep 2015 15:38:18 +0200 From: To: "multipathtcp@ietf.org" Thread-Topic: I-D Action: draft-boucadair-mptcp-plain-mode-00.txt Thread-Index: AQHQ9HHB3fpTFznHNkK0dJpkvhFPqZ5G/HKw Date: Mon, 21 Sep 2015 13:38:17 +0000 Message-ID: <2ee2c401-fad6-4585-b8f5-12c43979d3c4@OPEXCLILM23.corporate.adroot.infra.ftgroup> References: <20150921133037.9675.64744.idtracker@ietfa.amsl.com> In-Reply-To: <20150921133037.9675.64744.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.9.8.133616 Archived-At: Subject: [multipathtcp] TR: I-D Action: draft-boucadair-mptcp-plain-mode-00.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, 21 Sep 2015 13:38:23 -0000 Dear all, We submitted this new draft.=20 Comments are more than welcome.=20 Cheers, Med > -----Message d'origine----- > De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de > internet-drafts@ietf.org > Envoy=E9=A0: lundi 21 septembre 2015 15:31 > =C0=A0: i-d-announce@ietf.org > Objet=A0: I-D Action: draft-boucadair-mptcp-plain-mode-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > Title : An MPTCP Option for Network-Assisted MPTCP > Deployments: Plain Transport Mode > Authors : Mohamed Boucadair > Christian Jacquenet > Filename : draft-boucadair-mptcp-plain-mode-00.txt > Pages : 12 > Date : 2015-09-21 >=20 > Abstract: > One of the promising deployment scenarios for Multipath TCP (MPTCP) > is to enable a Customer Premises Equipment (CPE) that is connected to > multiple networks (e.g., DSL, LTE, WLAN) to optimize the usage of its > network attachments. Because of the lack of MPTCP support at the > server side, some service providers now consider a "network-assisted > mode" that relies upon the activation of a dedicated function called > MPTCP Concentrator. This document focuses on a deployment scheme > where the identity of the MPTCP Concentrator(s) is explicitly > configured on connected hosts. >=20 > This document specifies an MPTCP option that is used to get rid of an > encapsulation scheme between the CPE and the MPTCP Concentrator. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-boucadair-mptcp-plain-mode/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-boucadair-mptcp-plain-mode-00 >=20 >=20 > 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. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Tue Sep 22 01:13:55 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 ECDB51A0263 for ; Tue, 22 Sep 2015 01:13:53 -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 sTMciI_qddfz for ; Tue, 22 Sep 2015 01:13:52 -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 06BB41A0248 for ; Tue, 22 Sep 2015 01:13:51 -0700 (PDT) Received: from mail-oi0-f53.google.com (mail-oi0-f53.google.com [209.85.218.53]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 9CCD12780A4 for ; Tue, 22 Sep 2015 17:13:49 +0900 (JST) Received: by oiev17 with SMTP id v17so1175063oie.1 for ; Tue, 22 Sep 2015 01:13:48 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.202.96.5 with SMTP id u5mr13741798oib.115.1442909628102; Tue, 22 Sep 2015 01:13:48 -0700 (PDT) Received: by 10.202.197.15 with HTTP; Tue, 22 Sep 2015 01:13:48 -0700 (PDT) Date: Tue, 22 Sep 2015 01:13:48 -0700 Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: multipart/alternative; boundary=001a113d520ad388ad052051932a Archived-At: Subject: [multipathtcp] comments on draft-paasch-mptcp-syncookies 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, 22 Sep 2015 08:13:54 -0000 --001a113d520ad388ad052051932a Content-Type: text/plain; charset=UTF-8 Hello, I have several comments on draft-paasch-mptcp-syncookies. Please point out if I miss some points. 1: I personally would like to ask authors to clarify the cases where clients don't send the first data packet or clients cannot fit the option in the first data packet in this draft so that we can make sure not to miss corner cases. 2: This scheme presumes that the server behaves statelessly in mptcp level. But, I think the server doesn't have to be stateless in tcp level. Or, this method should be applied to stateless tcp server only? I think the draft needs to clarify this point. 3: In Section 3.1.3 "Coalescing segments: the second half of the payload is not covered by a mapping. Thus, the server will do a seamless fallback to regular TCP as defined by RFC6824" Is this true? RFC6824 says: "Therefore, even if a mapping does not exist from the subflow space to the data-level space, the data SHOULD still be ACKed at the subflow. This data cannot, however, be acknowledged at the data level" Also, when MP_CAPABLE_ACK option is missing, if server is not stateless in tcp level, I am wondering if we can ask the sender to resend the first data by sending an ack for seq 1 (with SACK block if possible). I know this is suboptimal, but maybe better than resetting. Thanks, -- Yoshi Thanks, -- Yoshi --001a113d520ad388ad052051932a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,
I have several comments on=C2=A0draf= t-paasch-mptcp-syncookies. Please point out if I miss some points.

1: =C2=A0I personally would like to ask authors to clarify= the cases where clients don't send the first data packet or clients ca= nnot fit the option in the first data packet in this draft so that we can m= ake sure not to miss corner cases.

2: This scheme = presumes that the server behaves statelessly in mptcp level. But, I think t= he server doesn't have to be stateless in tcp level. Or, this method sh= ould be applied to stateless tcp server only? I think the draft needs to cl= arify this point.

3: In Section 3.1.3
= =C2=A0 =C2=A0 "Coalescing segments:=C2=A0
=C2=A0 =C2=A0 =C2= =A0 the second half of the payload is not covered by a mapping. Thus, the s= erver will do a seamless fallback to regular TCP as defined by RFC6824"= ;

=C2=A0 =C2=A0=C2=A0 Is this true? RFC6824 says:
=C2=A0 =C2=A0 =C2=A0"T= herefore,=C2=A0= even if a mapping does not exist from the subflow space to the data-= level space, the data = SHOULD still be ACKed at the subflow.=C2=A0This data cannot, however, be acknowledged at t= he data=C2=A0le= vel"
=C2=A0 =C2=A0 =C2=A0 =C2=A0
=C2=A0 =C2=A0 =C2=A0Also, when MP_CAPABLE_ACK o= ption is missing, if server is not stateless in tcp level, I am wondering i= f we can ask the sender to resend the first data by sending an ack for seq = 1 (with SACK block if possible). I know this is suboptimal, but maybe bette= r than resetting.

Thanks,
--
Yoshi




Thanks,
--
Yoshi
--001a113d520ad388ad052051932a-- From nobody Tue Sep 22 23:17:20 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 692391A0358 for ; Tue, 22 Sep 2015 23:17:19 -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 GOevHcwLvko2 for ; Tue, 22 Sep 2015 23:17:18 -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 2E1131A0069 for ; Tue, 22 Sep 2015 23:17:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1442989037; x=2306902637; 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=+NoakHiCS50xSXPF54uhW0B7IOdrPhMzB1gJCsnP2F8=; b=ajWPrNdu31xsPSUBAC7ht1a9AV6+iZYeqmfjMR/+11vYNAai2P4jePSf6XZ1PbSf BLwLV5V39b/1F7oXRnzbJMqteyZAN0RW0gGvLiDvoozg4A9EmGzyfaPHokXIg8Iq F4/IUosNSNVqTFgLfuH13s5eSah6OTSHSPzm/VKCCYcjtQWT0AnfIoAZJyZ8y2aO iscaKq4GOUjy5BFZn8AVr0adIG92rkI8hWT+DOYw2ChQe+tdJPJjbiSKQBeNONxl c7ALWIkJTY9HJGmGJS5JsY+e2rj8GUrYzNAJFQ9UL9i7Cb6bsDcoPTayShjefVhv 7s/i/grm0BQCEoOgX+2Byg==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in6.apple.com (Apple Secure Mail Relay) with SMTP id 28.93.24160.DE342065; Tue, 22 Sep 2015 23:17:17 -0700 (PDT) X-AuditID: 11973e15-f79cb6d000005e60-31-560243edd800 Received: from aniseed.apple.com (aniseed.apple.com [17.128.115.23]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id B9.81.22881.DE342065; Tue, 22 Sep 2015 23:17:17 -0700 (PDT) Received: from localhost ([17.149.233.188]) by aniseed.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NV40046E9GTVV60@aniseed.apple.com> for multipathtcp@ietf.org; Tue, 22 Sep 2015 23:17:17 -0700 (PDT) Sender: cpaasch@apple.com Date: Tue, 22 Sep 2015 23:17:17 -0700 From: Christoph Paasch To: Yoshifumi Nishida Message-id: <20150923061717.GC1818@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+NgFtrHLMWRmVeSWpSXmKPExsUi2FAYpfvWmSnMYGW7nsXn1dfZHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMePLGfaCLcIVn77cYGlgnMXfxcjJISFgIvHlzRxmCFtM4sK9 9WxdjFwcQgJ7GSU6dz9khSm6dGYVC0Sin0li0dYWKKeLSWLPnx9gVcICkhLdd+6AjWIRUJU4 2NLHCGKzCWhJvL3dDlYjIqAn8eH7RyYQm1lAQ+L6w2agdRxAva4S9z5FgYR5BQwkTrybzAJi CwkESLQ+f8sIEReU+DH5HgtEq5bE+p3HocZISzz6O4MdxOYUCJZ4O3kb2AmiAioSVya8ZQe5 U0LgJ6vEp0nPWScwisxCMmsWklmzkMxawMi8ilEoNzEzRzczz0wvsaAgJ1UvOT93EyMowKfb ie5gPLPK6hCjAAejEg+vxXfGMCHWxLLiytxDjNIcLErivGFFDGFCAumJJanZqakFqUXxRaU5 qcWHGJk4OKUaGCMPFe1bV/vnfa/cDlXleU/ZDq/meH8svWvrh+/T+bKLBcIi/xmutljqqvV1 17dUJq5l5szZmrf5n62ff+B+hfFh6fefNLPfsM2sbLnFd6SqU+jlDqHGRVK2pxe/Y7e85bSs p1JF4Gfg7xtxm5rTppvOP9jOyhxgEm/iETLR9P3CSdN/VxdEqiqxFGckGmoxFxUnAgBkFJO0 UQIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrILMWRmVeSWpSXmKPExsUi2FAsrvvWmSnM4PNxbYvPq6+zOTB6LFny kymAMYrLJiU1J7MstUjfLoErY8aXM+wFW4QrPn25wdLAOIu/i5GTQ0LAROLSmVUsELaYxIV7 69m6GLk4hAT6mSQWbW1hgXC6mCT2/PnBClIlLCAp0X3nDjOIzSKgKnGwpY8RxGYT0JJ4e7sd rEZEQE/iw/ePTCA2s4CGxPWHzUBTOYB6XSXufYoCCfMKGEiceDcZbLGQQIBE6/O3jBBxQYkf k++xQLRqSazfeRxqjLTEo78z2EFsToFgibeTt4GdICqgInFlwlv2CYyCs5C0z0LSPgtJ+wJG 5lWMAkWpOYmVZnqJBQU5qXrJ+bmbGMEBWRi1g7FhudUhRgEORiUe3gdfGMOEWBPLiitzDzFK cDArifBGOjKFCfGmJFZWpRblxxeV5qQWH2KU5mBREufd/fdvqJBAemJJanZqakFqEUyWiYNT qoFR98rzOxLlni/tVobLGSS1SN6ZqL1eKOnZXL8YuV/pm5J0F1Ww/PvfPSf7vVKbmq/stA0S ltrmC3QcUx8qxlQmpzXes4wUOiK8o2vbSZtk3patjrUnj4bEcfAwhM9gfZZV5vtJPTfc9f1p 5+50ceb5ebbPOGXDsrRemH++kz0hVs77/nr7GiWW4oxEQy3mouJEAEcaGaREAgAA Archived-At: Cc: multipathtcp Subject: Re: [multipathtcp] comments on draft-paasch-mptcp-syncookies 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, 23 Sep 2015 06:17:19 -0000 Hello Yoshifumi, On 22/09/15 - 01:13:48, Yoshifumi Nishida wrote: > Hello, > I have several comments on draft-paasch-mptcp-syncookies. Please point out > if I miss some points. thanks for your comments. Please see my replies below. > 1: I personally would like to ask authors to clarify the cases where > clients don't send the first data packet or clients cannot fit the option > in the first data packet in this draft so that we can make sure not to miss > corner cases. When the server is the first to send data, he either disables SYN-cookies (to be sure to actually receive the third ACK, because he will be retransmitting the SYN/ACK), or if he doesn't disables SYN-cookies then he is vulnerable to never establish the state (which is the same issue in regular TCP). I will clarify this in the draft more in detail. > 2: This scheme presumes that the server behaves statelessly in mptcp level. > But, I think the server doesn't have to be stateless in tcp level. Or, this > method should be applied to stateless tcp server only? I think the draft > needs to clarify this point. That's actually an interesting point. One could actually setup a server that behaves statefully at the TCP-level and stateless at the MPTCP-level. We can discuss this as well in the draft. > 3: In Section 3.1.3 > "Coalescing segments: > the second half of the payload is not covered by a mapping. Thus, the > server will do a seamless fallback to regular TCP as defined by RFC6824" > > Is this true? RFC6824 says: > "Therefore, even if a mapping does not exist from the subflow space to > the data-level space, the data SHOULD still be ACKed at the subflow. This > data cannot, however, be acknowledged at the data level" Indeed, but during the first window worth of data on the initial subflow, every segment must contain a DSS-option to "proof" that the path is fully MPTCP capable and DSS-options get through also after the SYN. This is explained in Section 3.6 of the RFC6824. We will cite this section more explicitly in the draft. > Also, when MP_CAPABLE_ACK option is missing, if server is not > stateless in tcp level, I am wondering if we can ask the sender to resend > the first data by sending an ack for seq 1 (with SACK block if possible). I > know this is suboptimal, but maybe better than resetting. I'm not sure I understand what you mean. Can you elaborate? Thanks, Christoph From nobody Wed Sep 23 16:41:52 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 2A1191B33A8 for ; Wed, 23 Sep 2015 16:41:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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 b1lYcjN1kgcU for ; Wed, 23 Sep 2015 16:41:48 -0700 (PDT) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6EE571B33A6 for ; Wed, 23 Sep 2015 16:41:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1443051707; x=2306965307; 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=ubyfC9Eq6SMlzoA7ukJSvHvQIQ6pbbr2Mw56PpMFHVM=; b=orYLZowhoqlOZPpG/A2bF9ytWQ3UF40uatQx+dZmHbj5frh7u/10koxmoAz2oIYg 3vq4+PI97YltwMzN6HkI4q291lZNvUGeei/PWOU737AP0PimEBZqliVOTzvwDfas PQyrltyAUscm72BFc4fqCoMJM5Hz5SuSIbAvMERkLVPgc4YVVvbyZlr8vB0J/681 CwVPskL64r3MDVIbToGmlOiT/sOwD4h0C3U1XMXQ/r5CRzUP/R1jotN82LWqxp8h 6+Tq99rplTXoiopA4o/3ZH3t93DZkMB1LTDeoLoTs3/UjUc+rVoiDVlAAklypOap XSf/zaGhEq2hPmZMP/ylNA==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id 3C.B2.04166.BB833065; Wed, 23 Sep 2015 16:41:47 -0700 (PDT) X-AuditID: 11973e12-f792c6d000001046-93-560338bbcbff Received: from cardamom.apple.com (cardamom.apple.com [17.128.115.94]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id DD.C2.22881.BB833065; Wed, 23 Sep 2015 16:41:47 -0700 (PDT) Received: from localhost ([17.226.23.238]) by cardamom.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NV500NJZLTN2A30@cardamom.apple.com> for multipathtcp@ietf.org; Wed, 23 Sep 2015 16:41:47 -0700 (PDT) Sender: cpaasch@apple.com Date: Wed, 23 Sep 2015 16:41:47 -0700 From: Christoph Paasch To: MultiPath WG Message-id: <20150923234147.GG1818@Chimay.local> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline User-Agent: Mutt/1.5.23 (2014-03-12) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprFLMWRmVeSWpSXmKPExsUi2FAYpbvbgjnM4OEVE4vPq6+zOTB6LFny kymAMYrLJiU1J7MstUjfLoErY9U97YITchWzPjazNTBOkOhi5OSQEDCRmPn3CCOELSZx4d56 ti5GLg4hgb2MEpd+XGCEKTrz7ywrRGIik8T0f4+ZIJxuJomTj1cwg1QJC0hKdN+5A2azCKhK nG3sALPZBLQk3t5uZwWxRQQ0JG63LWeCqLeXuLF6KguIzStgINHxbjYjhC0o8WPyPbA4M1Dv +p3HmSBsaYlHf2ewg9iiAioSVya8ZQc5QkLgK6vE0W3/mCcwCs5C0j8LSf8sJP0LGJlXMQrl Jmbm6GbmmeglFhTkpOol5+duYgQF5nQ7oR2Mp1ZZHWIU4GBU4uGdocMcJsSaWFZcmXuIUZqD RUmc981HpjAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjNE7orfqtdpctJ2T+9pT0645KM3G zLa58Ov+GQV8h869ENrq9/XLs09qL5jF8n7PnHkwicnC/dOVS8qVv1ZujPditVX+cMzczYzh hvjRSK10qZc7XNaWtdzV7eePL/8SsPfCNdOcST+LnU6JTf0p/+tT14HILykHOFJqQmdlaiV8 Oblrzz3WLCWW4oxEQy3mouJEAAfydFMtAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrKLMWRmVeSWpSXmKPExsUi2FAcp7vbgjnMYHuzocXn1dfZHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVseqedsEJuYpZH5vZGhgnSHQxcnJICJhInPl3lhXCFpO4cG89 WxcjF4eQwEQmien/HjNBON1MEicfr2AGqRIWkJTovnMHzGYRUJU429gBZrMJaEm8vd0ONklE QEPidttyJoh6e4kbq6eygNi8AgYSHe9mM0LYghI/Jt8DizMD9a7feZwJwpaWePR3BjuILSqg InFlwlv2CYx8s5C0zELSMgtJywJG5lWMAkWpOYmVZnqJBQU5qXrJ+bmbGMGBVBi1g7FhudUh RgEORiUe3hk6zGFCrIllxZW5hxglOJiVRHhF5YBCvCmJlVWpRfnxRaU5qcWHGJOBnpzILCWa nA8M8rySeEMTEwMTY2MzY2NzE3PShJXEeXf//RsqJJCeWJKanZpakFoEs4WJg1OqgbG97+ys DcvrNd0ZbuxrmzLvmBLbFvu1rGw/DwSHPp/s92SLyoVlZj8djV03dniVrP6+Zq5x148H/pvZ tlopcZ0qeHf08/k3dhf2tp/Snee+b0fbgQZnyfR+tuaERT1POdkyXjarHt396KG2UlOal+sj s8i3Gy/cE1X9tORRadh19Su9sxTWbw9UYinOSDTUYi4qTgQAoCiKcGgCAAA= Archived-At: Subject: [multipathtcp] Adding two new sections to draft-ietf-mptcp-experience 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, 23 Sep 2015 23:41:50 -0000 Hello, draft-ietf-mptcp-experience has gone through the WG LC some time ago. Phil asked for updates to the experiences [1] before we progress the document to the AD & IESG. We would like to ask the working group whether information about the SYN-cookies issue (described in draft-paasch-mptcp-syncookies) and MPTCP behind loadbalancers (draft-paasch-mptcp-loadbalancer) should be included in the experience draft. We suggest two new sections: 3.11. Stateless webservers MPTCP has been designed to interoperate with webservers that benefit from SYN-cookies to protect against SYN-flooding attacks [RFC4987]. MPTCP achieves this by echoing the keys negotiated during the MP_CAPABLE handshake in the third ACK of the 3-way handshake. Reception of this third ACK then allows the server to reconstruct the state specific to MPTCP. However, one caveat to this mechanism is the non-reliable nature of the third ACK. Indeed, when the third ACK gets lost, the server will not be able to reconstruct the MPTCP-state. MPTCP will fallback to regular TCP in this case. This is in contrast to regular TCP, as clients usually start the application's transaction by sending data to the server. This data-segment (that is sent reliably by TCP) enables stateless servers to create the TCP-related state, even in case the third ACK has been lost. This issue might be considered as a minor one for MPTCP. Losing the third ACK should only happen when packet loss is high. However, when packet-loss is high MPTCP provides a lot of benefits as it can move traffic away from the lossy link. It is undesirable that MPTCP has a higher chance to fall back to regular TCP in those lossy environments. [I-D.paasch-mptcp-syncookies] discusses this issue and suggests a modified handshake mechanism that ensures reliable delivery of the MP_CAPABLE, following the 3-way handshake. This modification will make MPTCP reliable, even in lossy environments when servers need to use SYN-cookies to protect against SYN-flooding attacks. 3.12. Loadbalanced serverfarms Large-scale serverfarms typically deploy thousands of servers behind a single virtual IP (VIP). Steering traffic to these servers is done through layer-4 loadbalancers that ensure that a TCP-flow will always be routed to the same server [Presto08]. As Multipath TCP uses multiple different TCP subflows to steer the traffic across the different paths, loadbalancers need to ensure that all these subflows are routed to the same server. This implies that the loadbalancers need to track the MPTCP-related state, allowing them to parse the token in the MP_JOIN and assign those subflows to the appropriate server. However, serverfarms typically deploy multiple of these loadbalancers for reliability and capacity reasons. As a TCP subflow might get routed to any of these loadbalancers, they would need to synchronize the MPTCP-related state - a solution that is not feasible at large scale. The token (carried in the MP_JOIN) contains the information indicating which MPTCP-session the subflow belongs to. As the token is a hash of the key, servers are not able to generate the token in such a way that the token can provide the necessary information to the loadbalancers which would allow them to route TCP subflows to the appropriate server. [I-D.paasch-mptcp-loadbalancer] discusses this issue in detail and suggests two alternative MP_CAPABLE handshakes to overcome these. As of September 2015, it is not yet clear how MPTCP might accomodate such use-case to enable its deployment within loadbalanced serverfarms. Christoph [1] https://mailarchive.ietf.org/arch/msg/multipathtcp/XNO9Hqca-XGY7H3izwQs5Ou3-Kk From nobody Thu Sep 24 19:06:33 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 53E6F1B34A4 for ; Thu, 24 Sep 2015 19:06:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.221 X-Spam-Level: * X-Spam-Status: No, score=1.221 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, 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 yFCu5N0V4qjN for ; Thu, 24 Sep 2015 19:06:29 -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 AF1F61B34A3 for ; Thu, 24 Sep 2015 19:06:28 -0700 (PDT) Received: from mail-ob0-f174.google.com (mail-ob0-f174.google.com [209.85.214.174]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 445DB278105 for ; Fri, 25 Sep 2015 11:06:26 +0900 (JST) Received: by obbmp4 with SMTP id mp4so72533860obb.3 for ; Thu, 24 Sep 2015 19:06:24 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.221.134 with SMTP id qe6mr1151854obc.56.1443146784564; Thu, 24 Sep 2015 19:06:24 -0700 (PDT) Received: by 10.202.197.15 with HTTP; Thu, 24 Sep 2015 19:06:24 -0700 (PDT) In-Reply-To: <20150923061717.GC1818@Chimay.local> References: <20150923061717.GC1818@Chimay.local> Date: Thu, 24 Sep 2015 19:06:24 -0700 Message-ID: From: Yoshifumi Nishida To: Christoph Paasch Content-Type: multipart/alternative; boundary=001a11c3040873ee66052088cb9e Archived-At: Cc: multipathtcp Subject: Re: [multipathtcp] comments on draft-paasch-mptcp-syncookies 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, 25 Sep 2015 02:06:31 -0000 --001a11c3040873ee66052088cb9e Content-Type: text/plain; charset=UTF-8 Hi Christoph, On Tue, Sep 22, 2015 at 11:17 PM, Christoph Paasch wrote: > Hello Yoshifumi, > > On 22/09/15 - 01:13:48, Yoshifumi Nishida wrote: > > Hello, > > I have several comments on draft-paasch-mptcp-syncookies. Please point > out > > if I miss some points. > > thanks for your comments. Please see my replies below. > > > 1: I personally would like to ask authors to clarify the cases where > > clients don't send the first data packet or clients cannot fit the option > > in the first data packet in this draft so that we can make sure not to > miss > > corner cases. > > When the server is the first to send data, he either disables SYN-cookies > (to be sure to actually receive the third ACK, because he will be > retransmitting the SYN/ACK), or if he doesn't disables SYN-cookies then he > is vulnerable to never establish the state (which is the same issue in > regular TCP). I will clarify this in the draft more in detail. > Thanks. My concern here is it's a bit difficult for a TCP stack to tell if it's going to send data first or not. So, the applications must tell their intentions to TCP before it starts a connection, which might be a bit tricky to do. > > > 2: This scheme presumes that the server behaves statelessly in mptcp > level. > > But, I think the server doesn't have to be stateless in tcp level. Or, > this > > method should be applied to stateless tcp server only? I think the draft > > needs to clarify this point. > > That's actually an interesting point. One could actually setup a server > that > behaves statefully at the TCP-level and stateless at the MPTCP-level. > > We can discuss this as well in the draft. > I think that some implementations don't support or don't activate syn-cookie by default. If this negotiation method will be the standard way for mptcp, I think we need to think about this kind of situations. > > > 3: In Section 3.1.3 > > "Coalescing segments: > > the second half of the payload is not covered by a mapping. Thus, > the > > server will do a seamless fallback to regular TCP as defined by RFC6824" > > > > Is this true? RFC6824 says: > > "Therefore, even if a mapping does not exist from the subflow space > to > > the data-level space, the data SHOULD still be ACKed at the subflow. This > > data cannot, however, be acknowledged at the data level" > > Indeed, but during the first window worth of data on the initial subflow, > every segment must contain a DSS-option to "proof" that the path is fully > MPTCP capable and DSS-options get through also after the SYN. > > This is explained in Section 3.6 of the RFC6824. > > We will cite this section more explicitly in the draft. > I see. But, the difference between DSS and MP_CAPABLE_ACK is not big from my point of view. So, I'm thinking that it might not violate the split of the RFC6824 even if we relax this rule a bit. > > > Also, when MP_CAPABLE_ACK option is missing, if server is not > > stateless in tcp level, I am wondering if we can ask the sender to resend > > the first data by sending an ack for seq 1 (with SACK block if > possible). I > > know this is suboptimal, but maybe better than resetting. > > I'm not sure I understand what you mean. Can you elaborate? > Sorry. although I might be misunderstanding something here, please let me explain. I was thinking about TCP level stateful server. Even if middlebox coalesces the first and the second data segment and removes MP_CAPABLE_ACK, I believe this is not a problem at TCP level. So, I guess it might be possible for the server to ack for seq 1 (TCP level) to urge the retransmission of the first data packet. This might be a pretty adhoc logic, however, I didn't want to see what is fine for 6824 is not fine for this proposal. Thanks, -- Yoshi --001a11c3040873ee66052088cb9e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Christoph,

On Tue, Sep 22, 2015 at 11:17 PM, Christoph Paasch <cpaa= sch@apple.com> wrote:
Hello Yoshifumi,
On 22/09/15 - 01:13:48, Yoshifumi Nishida wrote:
> Hello,
> I have several comments on draft-paasch-mptcp-syncookies. Please point= out
> if I miss some points.

thanks for your comments. Please see my replies below.

> 1:=C2=A0 I personally would like to ask authors to clarify the cases w= here
> clients don't send the first data packet or clients cannot fit the= option
> in the first data packet in this draft so that we can make sure not to= miss
> corner cases.

When the server is the first to send data, he either disables SYN-co= okies
(to be sure to actually receive the third ACK, because he will be
retransmitting the SYN/ACK), or if he doesn't disables SYN-cookies then= he
is vulnerable to never establish the state (which is the same issue in
regular TCP).
I will clarify this in the draft more in detail.

<= /div>
Thanks. My concern here is it's a bit difficult for a TCP sta= ck to tell if it's going to send data first or not.
So, the a= pplications must tell their intentions to TCP before it starts a connection= , which might be a bit tricky to do.

> 2: This scheme presumes that the server behaves statelessly in mptcp l= evel.
> But, I think the server doesn't have to be stateless in tcp level.= Or, this
> method should be applied to stateless tcp server only? I think the dra= ft
> needs to clarify this point.

That's actually an interesting point. One could actually setup a= server that
behaves statefully at the TCP-level and stateless at the MPTCP-level.

We can discuss this as well in the draft.

I think that some implementations don't support or don't activat= e syn-cookie by default.
If this negotiation method will be the s= tandard way for mptcp, I think we need to think about this kind of situatio= ns.

> 3: In Section 3.1.3
>=C2=A0 =C2=A0 =C2=A0"Coalescing segments:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0the second half of the payload is not covere= d by a mapping. Thus, the
> server will do a seamless fallback to regular TCP as defined by RFC682= 4"
>
>=C2=A0 =C2=A0 =C2=A0 Is this true? RFC6824 says:
>=C2=A0 =C2=A0 =C2=A0 "Therefore, even if a mapping does not exist = from the subflow space to
> the data-level space, the data SHOULD still be ACKed at the subflow. T= his
> data cannot, however, be acknowledged at the data level"

Indeed, but during the first window worth of data on the initial sub= flow,
every segment must contain a DSS-option to "proof" that the path = is fully
MPTCP capable and DSS-options get through also after the SYN.

This is explained in Section 3.6 of the RFC6824.

We will cite this section more explicitly in the draft.

I see. But, the difference between DSS and MP_CAPABLE_ACK = is not big from my point of view.
So, I'm thinking that it mi= ght not violate the split of the RFC6824 even if we relax this rule a bit.<= /div>

>=C2=A0 =C2=A0 =C2=A0 Also, when MP_CAPABLE_ACK option is missing, if se= rver is not
> stateless in tcp level, I am wondering if we can ask the sender to res= end
> the first data by sending an ack for seq 1 (with SACK block if possibl= e). I
> know this is suboptimal, but maybe better than resetting.

I'm not sure I understand what you mean. Can you elaborate?
<= /blockquote>

Sorry. although I might be misunderstanding= something here, please let me explain. I was thinking about TCP level stat= eful server.
Even if middlebox coalesces the first and the second= data segment and removes MP_CAPABLE_ACK, I believe this is not a problem a= t TCP level.=C2=A0
So, I guess it might be possible for the serve= r to ack for seq 1 (TCP level) to urge the retransmission of the first data= packet.
This might be a pretty adhoc logic, however, I didn'= t want to see what is fine for 6824 is not fine for this proposal.

Thanks,
--
Yoshi
--001a11c3040873ee66052088cb9e-- From nobody Fri Sep 25 21:15:46 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 9334B1AD2C4 for ; Fri, 25 Sep 2015 21:15:44 -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 cEWlGGkVlWMU for ; Fri, 25 Sep 2015 21:15:42 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E18631AD2C0 for ; Fri, 25 Sep 2015 21:15:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1443240942; x=2307154542; 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=5KQ+/X/iK+lI80IWv5LHVifqIKgU7wmRDZoARO4B/zU=; b=KywPDAUfVbIYmbvWAI6+CtIQ5pPBWuhNJ5UT4w5m0yLPzDIDICQ6jHNLd/m/d2If +BFmVHtjnUHaFdqazviBHc3zoZs51D+JX/3LmcGv3cfUR1RO58tlDQYXi1ASInrA wmmf6x/2qrYdRy8k9NB1H43BN9Og+zQQW3mXOzFzXzhuFJhgamQtdfgCBdvVKoj/ 6BqjWVKZiVYlk3f2aNeeR4U2UG0EBaWezWvtlxCnk1t7T2qYowqt6lGmjGUWNl9j vdZ0880Kf8dCqno/Wp5g6PzseULXQUpDEOJigB2AVgseO95XtGbE8l+V7lEFvekB 6AVEXwZbVNm6Y9i6tHP3gQ==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id EE.B2.24122.EEB16065; Fri, 25 Sep 2015 21:15:42 -0700 (PDT) X-AuditID: 11973e16-f79826d000005e3a-ac-56061beee6a8 Received: from orrisroot.apple.com (orrisroot.apple.com [17.128.115.106]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id 67.F0.22881.EEB16065; Fri, 25 Sep 2015 21:15:42 -0700 (PDT) Received: from localhost ([17.149.238.73]) by orrisroot.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NV900L10NU59F30@orrisroot.apple.com> for multipathtcp@ietf.org; Fri, 25 Sep 2015 21:15:42 -0700 (PDT) Sender: cpaasch@apple.com Date: Fri, 25 Sep 2015 21:15:41 -0700 From: Christoph Paasch To: Yoshifumi Nishida Message-id: <20150926041541.GP77547@Chimay.local> References: <20150923061717.GC1818@Chimay.local> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline In-reply-to: User-Agent: Mutt/1.5.24 (08e81162482f) (2015-08-30) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUi2FAYpftOmi3M4PphKYvPq6+zOTB6LFny kymAMYrLJiU1J7MstUjfLoErY87J48wFn7Uqmjc+Ym1gbFHsYuTgkBAwkTi9xbaLkRPIFJO4 cG89WxcjF4eQwF5GiUMvLrNDJEwkvnY+g0pMYZKYfPEIK4TTzySxe0IjM0iVsICkRPedO2A2 i4CqxO69zawgNpuAlsTb2+1gtoiAnsSH7x+ZQGxmAQ2J6w+b2UCuEBZwlbj3KQokzCtgKNG0 7hgjxPwDjBL310xkhUgISvyYfI8FoldLYv3O41BzpCUe/Z0BdimnQLDE1GVPwOKiAsYSTUfm MIMMkhD4yipx69VMxgmMIrOQzJqFZNYsJLMWMDKvYhTKTczM0c3MM9dLLCjISdVLzs/dxAgK 8Ol2YjsYH66yOsQowMGoxMOr8Ic1TIg1say4MvcQozQHi5I479IbQCGB9MSS1OzU1ILUovii 0pzU4kOMTBycUg2MgT8emE/29Xbqu9P11rFSr/vZm88m+Vfu7qteKjA9vetLaOX6k6LSwd8V VvXJ8oSK7Q9K2t9S4hYWLNCp8Hv1t2xdzQkrVhR77gmK7Vab9+bvGkHXCXO0X37n7rmuyjB5 PWNY6tSA9t11/AvMMxe1M3XpFxxdWOS6xbXt9v/sP6naG2r7Ao2UWIozEg21mIuKEwESc8nh UQIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUi2FCcpftOmi3MYGqzhMXn1dfZHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVMefkceaCz1oVzRsfsTYwtih2MXJySAiYSHztfMYGYYtJXLi3 Hsjm4hASmMIkMfniEVYIp59JYveERmaQKmEBSYnuO3fAbBYBVYnde5tZQWw2AS2Jt7fbwWwR AT2JD98/MoHYzAIaEtcfNgNN5QDqdZW49ykKJMwrYCjRtO4YI8T8A4wS99dMZIVICEr8mHyP BaJXS2L9zuNQc6QlHv2dwQ5icwoES0xd9gQsLipgLNF0ZA7zBEbBWUjaZyFpn4WkfQEj8ypG gaLUnMRKM73EgoKcVL3k/NxNjOCQLIzawdiw3OoQowAHoxIPr8If1jAh1sSy4srcQ4wSHMxK Irzp+4FCvCmJlVWpRfnxRaU5qcWHGKU5WJTEeRU1gFIC6YklqdmpqQWpRTBZJg5OqQbGIpvz 0kK+NUIGWxQ5JOOnKK4M+rqlfNZX61U9upadrbc5Al5tXXT2l4vXXJWZb06sfrxG8tWdfP1Y u8hVqqWKKX/fvLzs6bSG69HCpOJHXcftBASnPP2w980rxcvLCqZ5BUcU2fyTyHOeLPSmktGN 48G/nSsC/xy+lxfAre0UtTZo2so7P3vilFiKMxINtZiLihMB0pt/XEUCAAA= Archived-At: Cc: multipathtcp Subject: Re: [multipathtcp] comments on draft-paasch-mptcp-syncookies 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: Sat, 26 Sep 2015 04:15:44 -0000 Hello, On 24/09/15 - 19:06:24, Yoshifumi Nishida wrote: > On Tue, Sep 22, 2015 at 11:17 PM, Christoph Paasch > > On 22/09/15 - 01:13:48, Yoshifumi Nishida wrote: > > > 1: I personally would like to ask authors to clarify the cases where > > > clients don't send the first data packet or clients cannot fit the option > > > in the first data packet in this draft so that we can make sure not to > > miss > > > corner cases. > > > > When the server is the first to send data, he either disables SYN-cookies > > (to be sure to actually receive the third ACK, because he will be > > retransmitting the SYN/ACK), or if he doesn't disables SYN-cookies then he > > is vulnerable to never establish the state (which is the same issue in > > regular TCP). > > I will clarify this in the draft more in detail. > > > > Thanks. My concern here is it's a bit difficult for a TCP stack to tell if > it's going to send data first or not. > So, the applications must tell their intentions to TCP before it starts a > connection, which might be a bit tricky to do. from the client's point-of-view he does not need to change the behavior when it is not the first one to send data. And on the server side (if the sys-admin enabled SYN-cookies), he is indeed vulnerable to this if the server initiates the transfer. But that's the case for regular TCP as well. As most app-protocols start with the client initiating the transfer, I think that's fine. > > > 2: This scheme presumes that the server behaves statelessly in mptcp > > level. > > > But, I think the server doesn't have to be stateless in tcp level. Or, > > this > > > method should be applied to stateless tcp server only? I think the draft > > > needs to clarify this point. > > > > That's actually an interesting point. One could actually setup a server > > that > > behaves statefully at the TCP-level and stateless at the MPTCP-level. > > > > We can discuss this as well in the draft. > > > > I think that some implementations don't support or don't activate > syn-cookie by default. > If this negotiation method will be the standard way for mptcp, I think we > need to think about this kind of situations. Oh, I see now. I think I misunderstood your question originally. I think that the handshake we are suggesting does not imply that the server has to operate in a stateless way at the TCP-level (nor at the MPTCP-level). The handshake will still work even if both layers (TCP and MPTCP) are stateful. > > > 3: In Section 3.1.3 > > > "Coalescing segments: > > > the second half of the payload is not covered by a mapping. Thus, > > the > > > server will do a seamless fallback to regular TCP as defined by RFC6824" > > > > > > Is this true? RFC6824 says: > > > "Therefore, even if a mapping does not exist from the subflow space > > to > > > the data-level space, the data SHOULD still be ACKed at the subflow. This > > > data cannot, however, be acknowledged at the data level" > > > > Indeed, but during the first window worth of data on the initial subflow, > > every segment must contain a DSS-option to "proof" that the path is fully > > MPTCP capable and DSS-options get through also after the SYN. > > > > This is explained in Section 3.6 of the RFC6824. > > > > We will cite this section more explicitly in the draft. > > > > I see. But, the difference between DSS and MP_CAPABLE_ACK is not big from > my point of view. > So, I'm thinking that it might not violate the split of the RFC6824 even if > we relax this rule a bit. > > > > Also, when MP_CAPABLE_ACK option is missing, if server is not > > > stateless in tcp level, I am wondering if we can ask the sender to resend > > > the first data by sending an ack for seq 1 (with SACK block if > > possible). I > > > know this is suboptimal, but maybe better than resetting. > > > > I'm not sure I understand what you mean. Can you elaborate? > > > > Sorry. although I might be misunderstanding something here, please let me > explain. I was thinking about TCP level stateful server. > Even if middlebox coalesces the first and the second data segment and > removes MP_CAPABLE_ACK, I believe this is not a problem at TCP level. > So, I guess it might be possible for the server to ack for seq 1 (TCP > level) to urge the retransmission of the first data packet. > This might be a pretty adhoc logic, however, I didn't want to see what is > fine for 6824 is not fine for this proposal. Let me try to draw of packet-flow of what you mean (please correct me if I'm wrong). You suggest the following: Client Server (the coalesced segment whose MP_CAPABLE_ACK has been removed) TCP-seq: 1, Len: 100 DSS-option: Dseq X, subseq 50, len 50 --------------------------------> TCP-ack: 1, SACK: 50-100 <-------------------------------- TCP-seq: 1, Len 50 MP_CAPABLE_ACK --------------------------------> This would be a change in behavior compared to RFC6824 as well, because as of today the server would fallback to regular TCP in this case (fallback without sending a RST, just seamlessly stop using MPTCP-options). He does this because he does not have a mapping for seq 1 to 50. I think we could do this above behavior, but it has downsides as well, as it increases latency (we need one more RTT in case this happens). Christoph From nobody Sun Sep 27 20:37:23 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 4574C1A1B57 for ; Sun, 27 Sep 2015 20:37:21 -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 prJnE-mjgOiv for ; Sun, 27 Sep 2015 20:37:17 -0700 (PDT) Received: from gpo2.cc.swin.edu.au (gpo2.cc.swin.edu.au [136.186.1.31]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB9C81A1B64 for ; Sun, 27 Sep 2015 20:37:16 -0700 (PDT) Received: from [136.186.242.182] (vpn242-182.cc.swin.edu.au [136.186.242.182]) by gpo2.cc.swin.edu.au (8.14.3/8.14.3) with ESMTP id t8S3b2Bf008020; Mon, 28 Sep 2015 13:37:04 +1000 To: Alan Ford , Yoshifumi Nishida References: <7082931042c142fabaa6e88275a56fcf@rew09926dag03b.domain1.systemhost.net> <20150914171356.GM1981@Chimay.local> <0EA79B5C-BBCC-47E8-B2CA-7C853296AAE7@apple.com> <55F7624E.6000004@swin.edu.au> From: Nigel Williams Message-ID: <5608B5DE.2070606@swin.edu.au> Date: Mon, 28 Sep 2015 13:37:02 +1000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Archived-At: Cc: multipathtcp Subject: Re: [multipathtcp] Discussion /Consensus on incrementing the version number of MPTCP 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, 28 Sep 2015 03:37:21 -0000 Hi Alan, Sorry, somehow I completely missed this... On 15/09/15 19:23, Alan Ford wrote: > Hi Yoshifumi, all, > > I too am in favour of bumping the version number. I am in favour of > including the syncookies handshake mechanism (or something similar, in > order to facilitate the token signalling - for further discussion). > > @Nigel - something you'd mentioned some time ago was a little hack on > the ISDN generation - zeroing the most significant bit - in order to > remove any chance of early sequence number wrapping. I don't know if > this is something you'd still like considered for 6824bis? Given a > version number bump it's entirely feasible to add this now. > I did use a similar sequence number hack earlier on to help with some debugging, though I'm not using anything like that now. I haven't given it much thought since then however, so as of now I'm not sure how useful it might be. cheers, nigel > As regards backward compatibility, we already discuss the fallback > mechanism in 6824bis - if a device supported both version numbers, it > could try both 1 and fall back to 0 if it wanted. But there's no > expectation any device will. > > Regards, > Alan > > On 15 September 2015 at 07:49, Yoshifumi Nishida > wrote: > > Hello folks, > > I just would like to check a few points on increasing the version > number. > I guess this means the followings. If I miss something or have > different views, please point it out. > > 1: The handshake method described in draft-paasch-mptcp-syncookies > will be included in 6824bis. This will be a single initial handshake > method in mptcp. > 2: Version 0 won't be supported after 6824bis has been published. > 3: We won't discuss backward compatible mechanisms such as fallback > logics (from version 1 to version 0) > > Thanks, > -- > Yoshi > > > On Mon, Sep 14, 2015 at 5:11 PM, Nigel Williams > > wrote: > > I'm also for bumping the version number. > > cheers, > nigel > > > On 15/09/2015 3:55 am, Anumita Biswas wrote: > > + 1 for bumping the version number. > > The proposed changes are big enough that they will cause > backward compatibility issues with existing implementations > if added on version 0. > > Thanks, > Anumita > > On Sep 14, 2015, at 10:13 AM, Christoph Paasch > > wrote: > > Hello, > > On 14/09/15 - 14:45:40, philip.eardley@bt.com > wrote: > > During our interim call last week, several > discussion points touched on this topic. The > implication would be that the MPTCP version number > is 1 in the protocol bis (Standards track), and > hence it would be incompatible with the current > Experimental track protocol (version number is 0). > > > * Making MP-CAPABLE reliable. There was a > lot of support for this during the interim, with > no-one against. One or two on-going questions were > raised by Yoshi. This requires a new version number. > > If it's agreed that the standards track RFC will be > a different version number, then several other > things have been raised > > * A new Proxy 'P' flag in MP_CAPABLE, > https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dwei-2Dmptcp-2Dproxy-2Dmechanism-2D02&d=BQIFAg&c=eEvniauFctOgLOKGJOplqw&r=fSuJ9mpJ1IB1Lz-sIp_MCe23kZIFT6UKt4EhsewNEmA&m=jjrPk64oS-oD6jdITVevNLLZE2ZPzHwtivNCIVEU2R0&s=jvyGX0tWdV6396IQtsqvNJQ92kEGWhn-GWUmkWZwHpo&e= > There was some support for this flag during the > interim. > > * Replacing the IPver field in ADD_ADDR with > a set of flags. Several people have supported this > (though not yet have an agreed proposal /details). > > * Making the MPTCP token locally meaningful, > in order that mptcp can work well with load > balancers. See the discussion over the last few days > prompted by > https://urldefense.proofpoint.com/v2/url?u=https-3A__datatracker.ietf.org_doc_draft-2Dpaasch-2Dmptcp-2Dloadbalancer_&d=BQIFAg&c=eEvniauFctOgLOKGJOplqw&r=fSuJ9mpJ1IB1Lz-sIp_MCe23kZIFT6UKt4EhsewNEmA&m=jjrPk64oS-oD6jdITVevNLLZE2ZPzHwtivNCIVEU2R0&s=29EQ9N7fXiZSGbwCqBFl-6bDFqOt0TrYNeVUVS1aKsQ&e= > > * The possibility of leveraging security off > TLS (if TLS is being used) > > The more general point is that - a new version > number would mean that we have the opportunity to > re-design MPTCP's signalling, based on the lessons > learnt from the current implementations and > deployments and the new requirements that have emerged. > > So the first step is to make sure that we have > consensus that in principle the protocol bis will > have a new version number. > Since we didn't explicitly do a consensus call on > this during the meeting, please send you views, > positive or negative, to the list. > > > as an author of two of the above drafts, I'm in favor of > bumping the > version-number. It will allow to fix MPTCP wrt to the > above mentioned issues > and bring MPTCP one step closer to wide-spread deployment. > > > Christoph > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_multipathtcp&d=BQICAg&c=eEvniauFctOgLOKGJOplqw&r=is7V2j_77TQ8H500qPvC98gSLwj4K3agvCyq4ChpMmw&m=WM3tRORkrsC_jj-T7zcG_vDG4EP3Gmr6NiTZSiXyvgw&s=G0SQa7T3503a_SZbKUXpdyJ-zdj0w3SPs1ufDxu2QcM&e= > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > > From nobody Mon Sep 28 22:25: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 312091A1A60 for ; Mon, 28 Sep 2015 22:25:39 -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_40=-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 Z3O2Uv8bQd0c for ; Mon, 28 Sep 2015 22:25:36 -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 14EA91A1A57 for ; Mon, 28 Sep 2015 22:25:35 -0700 (PDT) Received: from mail-oi0-f42.google.com (mail-oi0-f42.google.com [209.85.218.42]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 7D4B72780B9 for ; Tue, 29 Sep 2015 14:25:33 +0900 (JST) Received: by oiev17 with SMTP id v17so102281069oie.1 for ; Mon, 28 Sep 2015 22:25:32 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.202.202.14 with SMTP id a14mr12571826oig.73.1443504332010; Mon, 28 Sep 2015 22:25:32 -0700 (PDT) Received: by 10.202.197.15 with HTTP; Mon, 28 Sep 2015 22:25:31 -0700 (PDT) In-Reply-To: <20150926041541.GP77547@Chimay.local> References: <20150923061717.GC1818@Chimay.local> <20150926041541.GP77547@Chimay.local> Date: Mon, 28 Sep 2015 22:25:31 -0700 Message-ID: From: Yoshifumi Nishida To: Christoph Paasch Content-Type: multipart/alternative; boundary=001a113523baf0fea70520dc0a29 Archived-At: Cc: multipathtcp Subject: Re: [multipathtcp] comments on draft-paasch-mptcp-syncookies 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, 29 Sep 2015 05:25:39 -0000 --001a113523baf0fea70520dc0a29 Content-Type: text/plain; charset=UTF-8 Hi Christoph, Thanks for the response and sorry for my slow response. On Fri, Sep 25, 2015 at 9:15 PM, Christoph Paasch wrote: > Hello, > > On 24/09/15 - 19:06:24, Yoshifumi Nishida wrote: > > On Tue, Sep 22, 2015 at 11:17 PM, Christoph Paasch > > > On 22/09/15 - 01:13:48, Yoshifumi Nishida wrote: > > > > 1: I personally would like to ask authors to clarify the cases where > > > > clients don't send the first data packet or clients cannot fit the > option > > > > in the first data packet in this draft so that we can make sure not > to > > > miss > > > > corner cases. > > > > > > When the server is the first to send data, he either disables > SYN-cookies > > > (to be sure to actually receive the third ACK, because he will be > > > retransmitting the SYN/ACK), or if he doesn't disables SYN-cookies > then he > > > is vulnerable to never establish the state (which is the same issue in > > > regular TCP). > > > > I will clarify this in the draft more in detail. > > > > > > > Thanks. My concern here is it's a bit difficult for a TCP stack to tell > if > > it's going to send data first or not. > > So, the applications must tell their intentions to TCP before it starts a > > connection, which might be a bit tricky to do. > > from the client's point-of-view he does not need to change the behavior > when > it is not the first one to send data. > > And on the server side (if the sys-admin enabled SYN-cookies), he is indeed > vulnerable to this if the server initiates the transfer. But that's the > case > for regular TCP as well. > As most app-protocols start with the client initiating the transfer, I > think > that's fine. > It seems you're saying that sending MPCAPABLE_ACK is not mandatory when the server initiates data transfer. I hope you can elaborate this part in the next version. > > > > 2: This scheme presumes that the server behaves statelessly in mptcp > > > level. > > > > But, I think the server doesn't have to be stateless in tcp level. > Or, > > > this > > > > method should be applied to stateless tcp server only? I think the > draft > > > > needs to clarify this point. > > > > > > That's actually an interesting point. One could actually setup a server > > > that > > > behaves statefully at the TCP-level and stateless at the MPTCP-level. > > > > > > We can discuss this as well in the draft. > > > > > > > I think that some implementations don't support or don't activate > > syn-cookie by default. > > If this negotiation method will be the standard way for mptcp, I think we > > need to think about this kind of situations. > > Oh, I see now. I think I misunderstood your question originally. > > I think that the handshake we are suggesting does not imply that the server > has to operate in a stateless way at the TCP-level (nor at the > MPTCP-level). > The handshake will still work even if both layers (TCP and MPTCP) are > stateful. > OK. I personally think this is an important point. I hope you'll add more texts to clarify it. > > > 3: In Section 3.1.3 > > > > "Coalescing segments: > > > > the second half of the payload is not covered by a mapping. > Thus, > > > the > > > > server will do a seamless fallback to regular TCP as defined by > RFC6824" > > > > > > > > Is this true? RFC6824 says: > > > > "Therefore, even if a mapping does not exist from the subflow > space > > > to > > > > the data-level space, the data SHOULD still be ACKed at the subflow. > This > > > > data cannot, however, be acknowledged at the data level" > > > > > > Indeed, but during the first window worth of data on the initial > subflow, > > > every segment must contain a DSS-option to "proof" that the path is > fully > > > MPTCP capable and DSS-options get through also after the SYN. > > > > > > This is explained in Section 3.6 of the RFC6824. > > > > > > We will cite this section more explicitly in the draft. > > > > > > > I see. But, the difference between DSS and MP_CAPABLE_ACK is not big from > > my point of view. > > So, I'm thinking that it might not violate the split of the RFC6824 even > if > > we relax this rule a bit. > > > > > > Also, when MP_CAPABLE_ACK option is missing, if server is not > > > > stateless in tcp level, I am wondering if we can ask the sender to > resend > > > > the first data by sending an ack for seq 1 (with SACK block if > > > possible). I > > > > know this is suboptimal, but maybe better than resetting. > > > > > > I'm not sure I understand what you mean. Can you elaborate? > > > > > > > Sorry. although I might be misunderstanding something here, please let me > > explain. I was thinking about TCP level stateful server. > > Even if middlebox coalesces the first and the second data segment and > > removes MP_CAPABLE_ACK, I believe this is not a problem at TCP level. > > So, I guess it might be possible for the server to ack for seq 1 (TCP > > level) to urge the retransmission of the first data packet. > > This might be a pretty adhoc logic, however, I didn't want to see what is > > fine for 6824 is not fine for this proposal. > > Let me try to draw of packet-flow of what you mean (please correct me if > I'm > wrong). > > You suggest the following: > > > Client Server > > (the coalesced segment whose MP_CAPABLE_ACK has been removed) > TCP-seq: 1, Len: 100 > DSS-option: Dseq X, subseq 50, len 50 > --------------------------------> > > TCP-ack: 1, SACK: 50-100 > <-------------------------------- > > TCP-seq: 1, Len 50 > MP_CAPABLE_ACK > --------------------------------> > > > This would be a change in behavior compared to RFC6824 as well, because as > of today the server would fallback to regular TCP in this case (fallback > without sending a RST, just seamlessly stop using MPTCP-options). > He does this because he does not have a mapping for seq 1 to 50. > > I think we could do this above behavior, but it has downsides as well, as > it > increases latency (we need one more RTT in case this happens). Yes. This is what I meant. Thanks. As I said earlier, this would be suboptimal. But, I thought it might be better than resetting a connection. I am hoping someone bring a more sophisticated solution here or some evidences to neglect this case. Thanks, -- Yoshi --001a113523baf0fea70520dc0a29 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Christoph,

Thanks for the response a= nd sorry for my slow response.

On Fri, Sep 25, 2015 at 9:15 PM, Christoph Paasch <cpaasc= h@apple.com> wrote:
Hello,<= br>
On 24/09/15 - 19:06:24, Yoshifumi Nishida wrote:
> On Tue, Sep 22, 2015 at 11:17 PM, Christoph Paasch <cpaasch@apple.com>
> > On 22/09/15 - 01:13:48, Yoshifumi Nishida= wrote:
> > > 1:=C2=A0 I personally would like to = ask authors to clarify the cases where
> > > clients don't send the first data packet or clients cann= ot fit the option
> > > in the first data packet in this draft so that we can make s= ure not to
> > miss
> > > corner cases.
> >
> > When the server is the first to send data, he either disables SYN= -cookies
> > (to be sure to actually receive the third ACK, because he will be=
> > retransmitting the SYN/ACK), or if he doesn't disables SYN-co= okies then he
> > is vulnerable to never establish the state (which is the same iss= ue in
> > regular TCP).
>
> I will clarify this in the draft more in detail.
> >
>
> Thanks. My concern here is it's a bit difficult for a TCP stack to= tell if
> it's going to send data first or not.
> So, the applications must tell their intentions to TCP before it start= s a
> connection, which might be a bit tricky to do.

from the client's point-of-view he does not need to change the b= ehavior when
it is not the first one to send data.

And on the server side (if the sys-admin enabled SYN-cookies), he is indeed=
vulnerable to this if the server initiates the transfer. But that's the= case
for regular TCP as well.
As most app-protocols start with the client initiating the transfer, I thin= k
that's fine.

It seems you're sa= ying that sending MPCAPABLE_ACK is not mandatory when the server initiates = data transfer.
I hope you can elaborate this part in the next ver= sion.


> > > 2: This scheme presumes that the server behaves statelessly = in mptcp
> > level.
> > > But, I think the server doesn't have to be stateless in = tcp level. Or,
> > this
> > > method should be applied to stateless tcp server only? I thi= nk the draft
> > > needs to clarify this point.
> >
> > That's actually an interesting point. One could actually setu= p a server
> > that
> > behaves statefully at the TCP-level and stateless at the MPTCP-le= vel.
> >
> > We can discuss this as well in the draft.
> >
>
> I think that some implementations don't support or don't activ= ate
> syn-cookie by default.
> If this negotiation method will be the standard way for mptcp, I think= we
> need to think about this kind of situations.

Oh, I see now. I think I misunderstood your question originally.

I think that the handshake we are suggesting does not imply that the server=
has to operate in a stateless way at the TCP-level (nor at the MPTCP-level)= .
The handshake will still work even if both layers (TCP and MPTCP) are state= ful.

OK. I personally think this is an = important point. I hope you'll add more texts to clarify it.
=
> > > 3: In Section 3.1.3
> > >=C2=A0 =C2=A0 =C2=A0"Coalescing segments:
> > >=C2=A0 =C2=A0 =C2=A0 =C2=A0the second half of the payload is = not covered by a mapping. Thus,
> > the
> > > server will do a seamless fallback to regular TCP as defined= by RFC6824"
> > >
> > >=C2=A0 =C2=A0 =C2=A0 Is this true? RFC6824 says:
> > >=C2=A0 =C2=A0 =C2=A0 "Therefore, even if a mapping does = not exist from the subflow space
> > to
> > > the data-level space, the data SHOULD still be ACKed at the = subflow. This
> > > data cannot, however, be acknowledged at the data level"= ;
> >
> > Indeed, but during the first window worth of data on the initial = subflow,
> > every segment must contain a DSS-option to "proof" that= the path is fully
> > MPTCP capable and DSS-options get through also after the SYN.
> >
> > This is explained in Section 3.6 of the RFC6824.
> >
> > We will cite this section more explicitly in the draft.
> >
>
> I see. But, the difference between DSS and MP_CAPABLE_ACK is not big f= rom
> my point of view.
> So, I'm thinking that it might not violate the split of the RFC682= 4 even if
> we relax this rule a bit.
>
> > >=C2=A0 =C2=A0 =C2=A0 Also, when MP_CAPABLE_ACK option is miss= ing, if server is not
> > > stateless in tcp level, I am wondering if we can ask the sen= der to resend
> > > the first data by sending an ack for seq 1 (with SACK block = if
> > possible). I
> > > know this is suboptimal, but maybe better than resetting. > >
> > I'm not sure I understand what you mean. Can you elaborate? > >
>
> Sorry. although I might be misunderstanding something here, please let= me
> explain. I was thinking about TCP level stateful server.
> Even if middlebox coalesces the first and the second data segment and<= br> > removes MP_CAPABLE_ACK, I believe this is not a problem at TCP level.<= br> > So, I guess it might be possible for the server to ack for seq 1 (TCP<= br> > level) to urge the retransmission of the first data packet.
> This might be a pretty adhoc logic, however, I didn't want to see = what is
> fine for 6824 is not fine for this proposal.

Let me try to draw of packet-flow of what you mean (please corr= ect me if I'm
wrong).

You suggest the following:


Client=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 =C2=A0Server

=C2=A0 =C2=A0(the coalesced segment whose MP_CAPABLE_ACK has been removed)<= br> =C2=A0 =C2=A0TCP-seq: 1, Len: 100
=C2=A0 =C2=A0DSS-option: Dseq X, subseq 50, len 50
=C2=A0 =C2=A0-------------------------------->

=C2=A0 =C2=A0TCP-ack: 1, SACK: 50-100
=C2=A0 =C2=A0<--------------------------------

=C2=A0 =C2=A0TCP-seq: 1, Len 50
=C2=A0 =C2=A0MP_CAPABLE_ACK
=C2=A0 =C2=A0-------------------------------->


This would be a change in behavior compared to RFC6824 as well, because as<= br> of today the server would fallback to regular TCP in this case (fallback without sending a RST, just seamlessly stop using MPTCP-options).
He does this because he does not have a mapping for seq 1 to 50.

I think we could do this above behavior, but it has downsides as well, as i= t
increases latency (we need one more RTT in case this happens).
=

Yes. This is what I meant. Thanks.
As I said= earlier, this would be suboptimal. But, I thought it might be better than = resetting a connection.
I am hoping s= omeone bring a more sophisticated solution here or some evidences to neglec= t this case.

Thanks,
--
Yoshi
--001a113523baf0fea70520dc0a29-- From nobody Wed Sep 30 00:16:56 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 EA04C1A1A82 for ; Wed, 30 Sep 2015 00:16:54 -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 XdtcfpJJxOmz for ; Wed, 30 Sep 2015 00:16:53 -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 4771C1A1A80 for ; Wed, 30 Sep 2015 00:16:52 -0700 (PDT) Received: from mail-ob0-f181.google.com (mail-ob0-f181.google.com [209.85.214.181]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 47CF42780D2 for ; Wed, 30 Sep 2015 16:16:51 +0900 (JST) Received: by obbbh8 with SMTP id bh8so24691507obb.0 for ; Wed, 30 Sep 2015 00:16:49 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.221.134 with SMTP id qe6mr1284042obc.56.1443597409783; Wed, 30 Sep 2015 00:16:49 -0700 (PDT) Received: by 10.202.197.15 with HTTP; Wed, 30 Sep 2015 00:16:49 -0700 (PDT) Date: Wed, 30 Sep 2015 00:16:49 -0700 Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: multipart/alternative; boundary=001a11c30408cf18780520f1b6ad Archived-At: Subject: [multipathtcp] minutes for interim 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: Wed, 30 Sep 2015 07:16:55 -0000 --001a11c30408cf18780520f1b6ad Content-Type: text/plain; charset=UTF-8 Hello, Sorry for the long delay. We have uploaded the minute for the interim meeting on 9/10. Please check the following URL and please let us know if you have corrections or comments. https://www.ietf.org/proceedings/interim/2015/09/10/mptcp/minutes/minutes-interim-2015-mptcp-1 We appreciate Will for note taking! Thanks, -- Yoshi & Phil --001a11c30408cf18780520f1b6ad Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hello,
Sorry for the long delay. We have up= loaded the minute for the interim meeting on 9/10.=C2=A0
Please c= heck the following URL and please let us know if you have corrections or co= mments.

https://www.iet= f.org/proceedings/interim/2015/09/10/mptcp/minutes/minutes-interim-2015-mpt= cp-1

We appreciate Will for note taking!

Thanks,
--
Yoshi & Phil
--001a11c30408cf18780520f1b6ad--