From nobody Mon Sep 4 05:17:15 2017 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 238EF1320DC for ; Mon, 4 Sep 2017 05:17:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de 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 u3cGIIV4dJ4u for ; Mon, 4 Sep 2017 05:17:11 -0700 (PDT) Received: from mailout14.telekom.de (MAILOUT14.telekom.de [80.149.113.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8D36612ECEC for ; Mon, 4 Sep 2017 05:17:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1504527430; x=1536063430; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=IOeR0cfFnUozYkwgvHzgCEzMrem8uW5W/XpDQn/5qqk=; b=E22evJ25S6siH0juIUyyXivqGMweN0O1mZcCQSwtSGYBP01d83iDCy8Z 5t8lg2O8TGPrKlb69XGvWUh0jvCdERG627NEdFZvBfyIxNdWmZ6e5qtyi OEJiWthPzrlSLBPkCn6PLqgJB70TG0zZ2xVtHSl4tqXoM9TVBJ+PLF+yZ 9yuRW2UE+5URLOAxzTEfwQzbgIuZ0V9C3WU/SCq9RqwWkQzpXLR3yEqYc zjBHrCs6Y7QLm4cF50QPm/boCIDjMQ7I2p9R4yNuk4BySWczWCIcz/4yu IzR3huJTFWSU43X4Xc77XuAFsyIVrj7rRzkNByjnorf1864uVo5hlkGiy w==; Received: from qdec94.de.t-internal.com ([10.171.255.41]) by MAILOUT11.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Sep 2017 14:17:06 +0200 X-IronPort-AV: E=Sophos;i="5.41,474,1498514400"; d="scan'208";a="30900496" Received: from he105831.emea1.cds.t-internal.com ([10.169.119.34]) by QDEC97.de.t-internal.com with ESMTP/TLS/AES256-SHA; 04 Sep 2017 14:17:06 +0200 Received: from HE105686.EMEA1.cds.t-internal.com (10.169.119.48) by HE105831.emea1.cds.t-internal.com (10.169.119.34) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Mon, 4 Sep 2017 14:17:06 +0200 Received: from HE105686.EMEA1.cds.t-internal.com ([fe80::a951:f05b:3de5:32d9]) by HE105686.emea1.cds.t-internal.com ([fe80::a951:f05b:3de5:32d9%26]) with mapi id 15.00.1293.002; Mon, 4 Sep 2017 14:17:06 +0200 From: To: Thread-Topic: [multipathtcp] A proposal for MPTCP Robust session Establishment (MPTCP RobE) Thread-Index: AdL5l2p+5KDR4ahqRJeh9onNd2ThSgBn5kmAACWZiyAKaI2ZkA== Date: Mon, 4 Sep 2017 12:17:06 +0000 Message-ID: <23a53bae94134ba6aa3a090689eeab3a@HE105686.emea1.cds.t-internal.com> References: <64f1b27aee214f6b99b5c474158d7426@HE105686.emea1.cds.t-internal.com> <79ac6cb307784db3a6d8ae1550a49573@HE105686.emea1.cds.t-internal.com> In-Reply-To: <79ac6cb307784db3a6d8ae1550a49573@HE105686.emea1.cds.t-internal.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.36.11] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] A proposal for MPTCP Robust session Establishment (MPTCP RobE) X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 04 Sep 2017 12:17:14 -0000 RGVhciBhbGwsDQoNCkJhc2VkIG9uIGZlZWRiYWNrIGF0IElFVEY5OSwgcmVnYXJkaW5nIE1QVENQ IFJvYkUgcHJvcG9zYWwgKGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvbWVldGluZy85OS9t YXRlcmlhbHMvc2xpZGVzLTk5LW1wdGNwLWEtcHJvcG9zYWwtZm9yLW1wdGNwLXJvYnVzdC1zZXNz aW9uLWVzdGFibGlzaG1lbnQtbXB0Y3Atcm9iZSksIEkgY29tcGxldGVseSByZWNvbnNpZGVyIHRo ZSBvcmlnaW5hbCBhcHByb2FjaCwgSSBwcmVzZW50ZWQuIFJlbWVtYmVyLCB0aGUgIkRvd25ncmFk ZSItYXBwcm9hY2ggKHNlZSBzbGlkZXMpIHdhcyBwcmVmZXJyZWQgZnJvbSBteSBzaWRlLCBiZWNh dXNlIGl0IGNvbWJpbmVzIHJvYnVzdG5lc3MgYW5kIGEgaHVnZSBsYXRlbmN5IHJlZHVjdGlvbi4N Cg0KVGhlIG1haW4gZmVlZGJhY2sgSSBnb3Qgd2FzOg0KDQogICgxKSBSZWx5aW5nIG9uIFNZTi1L ZXktQSBhcyBpZGVudGlmaWVyIHRvIGNvbWJpbmUgcG90ZW50aWFsIGluaXRpYWwgZmxvd3MsIHJh aXNlIHNldmVyYWwgaXNzdWVzDQogICAgKDEuMSkgbm90IGF2YWlsYWJsZSBpbiBSRkM2ODI0Ymlz IGFueW1vcmUNCiAgICAoMS4yKSBzZWN1cml0eSwgYmVjYXVzZQ0KICAgICAgICAoMS4yLjEpIEtl eS1BIGlzIHRyYW5zbWl0dGVkIG1hbnkgdGltZXMNCiAgICAgICAgKDEuMi4yKSBjYW4gYmUgYWJ1 c2VkIGJ5IGFjY2lkZW50L2ludGVuZA0KICAoMikgU2VwYXJhdGUgcm9idXN0bmVzcyBhbmQgbGF0 ZW5jeSBmdW5jdGlvbmFsaXR5DQogICgzKSBUbyBtdWNoIGNvbXB1dGluZyByZXNvdXJjZXMgbmVl ZGVkIG9uIHJlY2VpdmVyIHNpZGUgdG8gZGV0ZWN0IGR1cGxpY2F0ZSBLZXktQQ0KICAoNCkgRG8g aXQgaW4gdGhlIGFwcGxpY2F0aW9uIGxheWVyIGxpYnJhcnkgKGJ1aWxkIGEgc2hpbSBsYXllcik7 IG5vdCBpbiB0aGUgTVBUQ1Agc3RhbmRhcmQgYW5kL29yIGltcGxlbWVudGF0aW9uIHRvIHJlZHVj ZSBjb21wbGV4aXR5DQoNCldpdGggdGhlIGZvbGxvd2luZyByZXdvcmtlZCBwcm9wb3NhbCAoYmFz ZWQgb24gdGhlICJEb3duZ3JhZGUiIGFwcHJvYWNoLCBzZWUgc2xpZGVzKSwgSSB0cnkgdG8gYWRk cmVzcyBhbGwgb2YgdGhlIHBvaW50cyBhYm92ZS4NCg0KV2l0aCBGaWcuIDEsIHRoZSBmbG93IGRp YWdyYW0gZm9yIHRoZSBuZXcgcHJvcG9zYWwgaXMgZGVwaWN0ZWQuIEl0IGlzIHJlZmVycmVkIHRv IE1QVENQIHZlcnNpb24gMCwgYnV0IHNob3VsZCBiZSBlcXVpdmFsZW50IHRvIHByb2JhYmxlIHZl cnNpb24gMSAoUkZDNjI4NGJpcyksIGp1c3Qgd2l0aG91dCBhIFNZTi1NUF9DQVBBQkxFIGNvbnRh aW5pbmcgS2V5LUEuDQpUbyByZWFjaCByb2J1c3RuZXNzLCBzZXZlcmFsIHNlcGFyYXRlIE1QVENQ IGluaXRpYWwgZmxvd3MgYXJlIGluaXRpYXRlZCBhdCB0aGUgYmVnaW5uaW5nLCBpbiB0aGUgZm9s bG93aW5nIGRlbm90ZWQgYXMgInBvdGVudGlhbCBpbml0aWFsIGZsb3dzIi4gSW4gc3RlcCBTQTEg YW5kIFNBMiwgcmVzcGVjdGl2ZWx5IFNCMyBhbmQgU0I0LCBzdGFuZGFyZCBNUFRDUCBpbml0aWFs IGZsb3cgcHJvY2VkdXJlIGlzIGFwcGxpZWQsIHNvIG5vIGNoYW5nZSBzbyBmYXIuIFdpdGggb2Nj dXJyaW5nIFNBMy9TQTQgdGhlIHJlcXVlc3RlciAiSG9zdCBBIiBoYXMgdG8gZGVjaWRlIHdoaWNo IHBvdGVudGlhbCBpbml0aWFsIGZsb3cgd2lsbCBiZSB1c2VkIGZ1cnRoZXIgYXMgaW5pdGlhbCBm bG93IChlLmcuIHRoZSBmaXJzdCB3aGljaCByZXR1cm5zKSBhbmQgd2hhdCBzaGFsbCBoYXBwZW4g d2l0aCB0aGUgb3RoZXIgcG90ZW50aWFsIGZsb3dzLiBFaXRoZXIgaXQgY2FuIGJyZWFrIGFsbCBi dXQgb25lIChlLmcuIHNlbmRpbmcgUlNUIGF0IFNBNi4xKSBPUiByZWN5Y2xlIHRoZW0gKHN0ZXAg U0E2LjIpLiBUaGVyZWJ5LCBpdCBpcyBhIGZ1bGwgY2xpZW50IHNpZGUgZGVjaXNpb24gdG8gdXNl IHJvYnVzdG5lc3Mgb25seSBvciBiZW5lZml0IGZyb20gbGF0ZW5jeSByZWR1Y3Rpb24gYXMgd2Vs bCBhbmQgY2FuIGJlIHRvZ2dsZWQgc2VwYXJhdGVseSBieSBlLmcuIHN5c2N0bCBnbG9iYWxseSBh bmQvb3Igc29ja2V0IG9wdGlvbi4NClVudGlsIFNBNi4xLCBpdCBkb2Vzbid0IHJlcXVpcmUgYW55 IE1QVENQIHN0YW5kYXJkIG1vZGlmaWNhdGlvbiENCg0KICAgICAgICAgICAgICBIb3N0IEEgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgSG9zdCBCDQogICAgIC0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLSAgICAgICAgICAgICAgICAgICAgICAgLS0tLS0tLS0tLQ0KICAgICBBZGRyZXNz IEExICAgIEFkZHJlc3MgQTIgICAgICAgICAgICAgICAgICAgICAgIEFkZHJlc3MgQjENCiAgICAg LS0tLS0tLS0tLSAgICAtLS0tLS0tLS0tICAgICAgICAgICAgICAgICAgICAgICAtLS0tLS0tLS0t DQogICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg IHwNCiAgICAgICAgIHwgICAgICAgICAgICBTWU4gKyBNUF9DQVBBQkxFKEtleS1BKSAgICAgICAg ICAgfA0KIChTQTEpICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLT58ICAoU0IxKQ0KICAgICAgICAgfCAgICAgICAgICAgICB8ICAgIFNZTiArIE1QX0NBUEFC TEUoS2V5LUEnKSAgICB8DQogKFNBMikgICB8ICAgICAgICAgICAgIHwtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tPnwgIChTQjIpDQogICAgICAgICB8ICAgICAgICAgICAgIHwgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwgDQogKFNBMykgICB8PC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLXwgIChTQjMpDQogICAgICAgICB8ICAgICAgICAg IFNZTi9BQ0sgKyBNUF9DQVBBQkxFKEtleS1CKSAgICAgICAgIHwNCiAoU0E0KSAgIHwgICAgICAg ICAgICAgfDwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tfCAgKFNCNCkNCiAgICAgICAg IHwgICAgICAgICAgICAgfCAgIFNZTi9BQ0sgKyBNUF9DQVBBQkxFKEtleS1CJykgfA0KICAgICAg ICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQogICAg ICAgICB8ICAgICAgICBBQ0sgKyBNUF9DQVBBQkxFKEtleS1BLCBLZXktQikgICAgICAgIHwNCiAo U0E1KSAgIHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+fCAg KFNCNSkNCiAgICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgICBSU1QgICAgICAgICAg ICAgICAgfA0KIChTQTYuMSkgfCAgICAgICAgICAgICB8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLT58ICAoU0I2LjEpDQpyb2J1c3QgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIHwNCm5lc3MgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgfCANCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gICAgICAgICANCmxhdGVuY3kgIHwg ICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfCANCnJlZC4gICAg IHwgICAgICAgICAgICAgfCBBQ0sgKyBNUF9KT0lOX0NBUChLZXktQSwgSE1BQykgfA0KIChTQTYu MikgfCAgICAgICAgICAgICB8LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLT58ICAoU0I2 LjIpDQoNCiAgIEtleS1CX2Zhc3RfaGFzaCA9IGNyYzE2KEtleS1CKSAmIDB4M0ZGICAgICAgICAg ICAgICAgLT4gKDEwYml0KQ0KICAgSE1BQ19rZXlzID0gIEhNQUMoS2V5LUErS2V5LUIrS2V5LUIn KSAgICAgICAgICAgICAgICAtPiAoPj05NmJpdCkNCiAgIEhNQUMgPSAgKEhNQUNfa2V5cyAmIH4w eDNGRikgfCBLZXktQl9mYXN0X2hhc2ggICAgICAgLT4gKHNpemUgc2FtZSBhcyBITUFDX2tleXMp DQoNCkZpZ3VyZSAxOiBFeGFtcGxlIFVzZSBvZiBNUFRDUCBSb2JFIChmb3IgTVBUQ1AgdmVyc2lv biAwKQ0KDQpGb3Igbm90IHdhc3RpbmcgcmVzb3VyY2VzIGJ5IGJyZWFraW5nIGFsbCBidXQgb25l IGFuZCBiZW5lZml0IGluIGFkZGl0aW9uIGZyb20gYSBodWdlIGxhdGVuY3kgcmVkdWN0aW9uIChz ZWUgTVBUQ1AgUm9iRSBwcm9wb3NhbCwgcC4xMiwxNCsxNSwxNyksIG9uZSBjYW4gbWFrZSB1c2Ug b2YgYSBuZXcgcHJvcG9zZWQgTVBUQ1Agb3B0aW9uICJNUF9KT0lOX0NBUCIsIGlsbHVzdHJhdGVk IGluIEZpZy4gMi4gQWNjb3JkaW5nIHRvIEZpZy4gMSwgQTE8LT5CMSBpcyBhc3N1bWVkIGFzIGlu aXRpYWwgZmxvdyBhdCBTQTMgYW5kIEEyPC0+QjEgc2hhbGwgYmUgcmVjeWNsZWQgYXQgU0E2LjIg KFNBNi4xIGlzIHNraXBwZWQgdGhlcmVmb3JlKS4gSW5zdGVhZCBvZiBzZW5kaW5nIGFuIE1QX0NB UEFCTEUgaW4gdGhlIHRoaXJkIEFDSywgYW4gTVBfSk9JTl9DQVAgaXMgc2VudCwgd2hpY2ggaW5j bHVkZXMgS2V5LUEgb2YgdGhlIHNlbGVjdGVkIGluaXRpYWwgZmxvdyBBMTwtPkIxIGFuZCBhbiBI TUFDLCBjb2RpbmcgS2V5LUEsIEtleS1CLCBLZXktQicgaW4gYSBkZXRlcm1pbmVkIHdheSAoc2Vl IEZpZy4gMSBib3R0b20pLg0KDQogICAgICAgICAgICAgICAgICAgMSAgICAgICAgICAgICAgICAg ICAyICAgICAgICAgICAgICAgICAgIDMNCiAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1 IDYgNyA4IDkgMCAxIDIgMyA0IDUgNiA3IDggOSAwIDENCistLS0tLS0tLS0tLS0tLS0rLS0tLS0t LS0tLS0tLS0tKy0tLS0tLS0rLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rDQp8ICAgICBLaW5kICAg ICAgfCAgICBMZW5ndGggICAgIHxTdWJ0eXBlfCAgICAgICB8ICAgIEFERFJfSUQgICAgfA0KKy0t LS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0tLS0t LS0tLSsNCnwgICAgICAgICAgICAgICAgICAgIFNlbmRlcidzIEtleS1BICg2NCBiaXRzKSAgICAg ICAgICAgICAgICAgICB8DQp8ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgfA0KfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCistLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0rDQp8ICAgICAgICAg ICAgICAgICAgICAgICAgSE1BQyAoPj05NiBiaXRzKSAgICAgICAgICAgICAgICAgICAgICAgfA0K fCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIHwNCnwgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICB8DQo6ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgOg0KKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCkZpZ3VyZSAyOiBNdWx0aXBh dGggSm9pbiBDYXBhYmxlIChNUF9KT0lOX0NBUCkgT3B0aW9uIChmb3IgVGhpcmQgTVBfQ0FQQUJM RSBBQ0spDQoNCkZvciB0aGUgTVBfQ0FQQUJMRSwgQUREUl9JRCBpcyBzZXQgdG8gemVybyAobGlr ZSBSRkM2ODI0KSBhbmQgZm9yIE1QX0pPSU5fQ0FQIGl0IGlzIHNlbnQgd2l0aC4NCg0KV2hpY2gg Ym91bmRhcnkgY29uZGl0aW9ucyBjYW4gaGFwcGVuOg0KDQoxLiBMaWtlIEZpZy4gMSwgQTE8LT5C MSBpcyBhc3N1bWVkIGFzIGluaXRpYWwgZmxvdyBhbmQgTVBfQ0FQQUJMRSByZWNlaXZlcyBmaXJz dCBhdCBIb3N0IEIgKFNCNSksIEEyPC0+QjEgc2hhbGwgYmUgcmVjeWNsZWQgYW5kIEFDSyBpcyBz ZW50IHdpdGggTVBfSk9JTl9DQVANCiAgIElmIE1QX0pPSU5fQ0FQIGlzIHJlY2VpdmVkIGl0IGhh cyB0byBpdGVyYXRlIG9uY2UgKGxpa2UgTVBfSk9JTikgdGhlIGNvbm5lY3Rpb24gbGlzdCBhbmQg Y2hlY2sgZm9yIEtleS1BIGF2YWlsYWJpbGl0eS4gSWYgYSBLZXktQSBjb25uZWN0aW9uIGlzIGZv dW5kLCBpdCBpcyB2YWxpZGF0ZWQgYWdhaW5zdCBITUFDIHZhbHVlLiBUaGUgdmFsaWRhdGlvbiBo YXMgdHdvIHJlYXNvbnMsIGZpcnN0bHkgc2V2ZXJhbCBLZXktQSBjYW4gZXhpc3QsIGJlY2F1c2Ug ZGlmZmVyZW50IEhvc3RzIGNob29zZSBzYW1lIEtleS1BIGJ5IGFjY2lkZW50LiBGdXJ0aGVybW9y ZSBubyBvbmUgY2FuIGpvaW4gYSBjb25uZWN0aW9uIGJ5IGp1c3QgcmVjb3JkaW5nL2JydXRlLWZv cmNpbmcgS2V5LUEgYW5kIGR1cGxpY2F0ZSB0aGUgcmVxdWVzdC4gKHNvbHZlcyBwb2ludCAoMSkg ZnJvbSB0aGUgZmVlZGJhY2spDQoNCjIuIExpa2UgMS4sIGJ1dCBNUF9KT0lOX0NBUCBhcnJpdmVz IGJlZm9yZSB0aGUgTVBfQ0FQQUJMRSBhdCBIb3N0IEINCg0KICAgIDIuMSBkcmFmdC1pZXRmLW1w dGNwLXJmYzY4MjRiaXMtMDkNCiAgICAgICAgQmFzZWQgb24gS2V5LUEsIGl0IHdpbGwgaXRlcmF0 ZSBvdmVyIHRoZSBjb25uZWN0aW9uIGxpc3QsIGJ1dCBpdCB3aWxsIG5vdCBtYXRjaCwgYmVjYXVz ZSBLZXktQSBmcm9tIGZvcm1lcmx5IHNlbGVjdGVkIGluaXRpYWwgZmxvdyBoYXNuJ3QgYXJyaXZl ZCB5ZXQuIFNvIGl0IHdpbGwgY29udGludWUgd2l0aCBhIGZhc3QgaXRlcmF0ZSBvbmx5IG92ZXIg dGhlIGNvbm5lY3Rpb25zLCB3aGljaCBhcmUgc3RpbGwgaW4gZXN0YWJsaXNobWVudCBwaGFzZSwg dXNpbmcgdGhlIDEwYml0IEtleS1CX2Zhc3RfaGFzaCAoY3JjMTYoS2V5LUIpICYgMHgzRkYpLiBJ ZiBpdCBtYXRjaGVzIGFnYWluc3QgYSAocHJlY29tcHV0ZWQpIGV4aXN0aW5nIEtleS1CX2Zhc3Rf aGFzaCBpbiB0aGUgY29ubmVjdGlvbiBsaXN0LCBpdCB3aWxsIHZhbGlkYXRlIHdpdGggdGhlIEhN QUMoS2V5LUErS2V5LUIrS2V5LUInKSBhZ2FpbiB0byBlbnN1cmUgbGVnaXRpbWF0aW9uLiBJZiBz dWNjZXNzZnVsLCBib3RoLCB0aGUgaW5pdGlhbCBmbG93IGFuZCB0aGUgTVBfSk9JTl9DQVAgZmxv dywgY2FuIGJlIGltbWVkaWF0ZWx5IGVzdGFibGlzaGVkLiBUaGlzIGlzIHRydWUsIGJlY2F1c2Ug d2l0aG91dCB0aGUga25vd2xlZGdlIG9mIEtleS1CLCBIb3N0IEEgY291bGRuJ3QgY2FsY3VsYXRl IHRoZSBITUFDLiBTbyBpdCBpcyBjbGVhciwgdGhhdCBob3N0IEEgaGFkIHJlY2VpdmVkIHRoZSBT WU4vQUNLIChTQjMpLiANClRoaXMgYWxzbyBtaXRpZ2F0ZXMgdGhlIHJlcXVpcmVtZW50IG9mIGEg cmVsaWFibGUgQUNLIChkcmFmdC1pZXRmLW1wdGNwLXJmYzY4MjRiaXMtMDksIHAuMTUpIGV4Y2hh bmdlLCBiZWNhdXNlIG9ubHkgb25lIE1QX0NBUEFCTEUvTVBfSk9JTl9DQVAgbmVlZHMgdG8gcmVh Y2ggcmVjZWl2ZXIgc2lkZS4NCg0KICAgIDIuMiBNUFRDUCB2ZXJzaW9uIDAgKFJGQzY4MjQpDQog ICAgICAgIENhbiBtYXRjaCBiYXNlZCBvbiBLZXktQSwgbGlrZSAxLiwgc2FtZSBlZmZvcnQgYXMg Zm9yIGEgTVBfSk9JTi4NCg0KMy4gQTI8LT5CMSBpcyBzZWxlY3RlZCBhcyBpbml0aWFsIGZsb3cs IGJlY2F1c2UgYWNjb3JkaW5nIFNZTi9BQ0sgcmV0dXJucyBlYXJsaWVyIGF0IEhvc3QgQS4NCiAg ICBJdCBpcyB0aGUgc2FtZSBhcyAxLiBhbmQgMi4sIGp1c3QgdGhlIG90aGVyIHdheSByb3VuZCA6 LSkNCg0KV2l0aCB0aGVzZSBib3VuZGFyeSBjb25kaXRpb25zIGl0IGhhcyBiZWVuIHNob3duLCB0 aGF0IG5vIGFkZGl0aW9uYWwgY29tcHV0aW5nIHJlc291cmNlcyBhcmUgcmVxdWlyZWQgKHNlZSBm ZWVkYmFjayAoMykpLCBjb21wYXJlZCB0byB0b2RheXMgTVBUQ1AsIHdpdGggYSBtaW5pbWFsIGV4 Y2VwdGlvbiBvZiAyLjEuDQoNCldpdGggc3VjaCBhIHNpbXBsZSBhcHByb2FjaCwgYW5kIGJ5IGFk ZGluZyBhbiBpbmNvbnNwaWN1b3VzIHNpbXBsZSBNUFRDUCBvcHRpb24gTVBfSk9JTl9DQVAsIE1Q VENQIHdvdWxkIGJlIGV4dGVuZGVkIHRvd2FyZHMgcm9idXN0bmVzcyBhbmQgaWYgZGVzaXJlZCwg bGF0ZW5jeSByZWR1Y3Rpb24gY2FuIGJlIGVuYWJsZWQgb24gdG9wLCBidXQgb2J2aW91c2x5IHJl cXVpcmVzIHJlY2VpdmVyIHN1cHBvcnQuIE5lZ290aWF0aW9uIGlzIGluaGVyZW50bHkgZ2l2ZW4g YnkgdGhlIG5ldyBNUF9KT0lOX0NBUCB3aGljaCBpcyBlaXRoZXIgYWNjZXB0ZWQgb3Igbm90LiBJ ZiBub3QsIHRoZSBzdGFuZGFyZCBNUF9KT0lOIHByb2Nlc3MgY2FuIGJlIGFwcGxpZWQuDQoNCkJl Y2F1c2Ugb2Ygc3VjaCBhIHNpbXBsaWNpdHkgYW5kIHRoZSBtYXNzaXZlIGJlbmVmaXQgYnkgb3B0 aW9uYWwgbGF0ZW5jeSByZWR1Y3Rpb24sIEkgc3RpbGwgYmVsaWV2ZSBpdCBmaXRzIGJlc3QgaW4g dGhlIE1QVENQIGxheWVyIGl0c2VsZiBhbmQgbm90IGluIGFuIGFwcGxpY2F0aW9uIHNoaW0gbGF5 ZXIgKHNlZSBmZWVkYmFjayAoNCkpLg0KDQpEdWUgdG8gdGhlIHNlcGFyYXRpb24gb2Ygcm9idXN0 bmVzcyBhbmQgbGF0ZW5jeSByZWR1Y3Rpb24gZnVuY3Rpb25hbGl0eSwgaXQgb2ZmZXJzIHRoZSBj aGFuY2UgdG8gaW1wbGVtZW50ICJyb2J1c3RuZXNzIiBpbiBwbGFpbiBUQ1AgYXMgd2VsbC4gSXQg Y291bGQgbG9vayB0aGUgc2FtZSBsaWtlIGluIEZpZy4gMSwgKFNBMSktKFNBNi4xKSwganVzdCB3 aXRob3V0IE1QX0NBUEFCTEUgb3B0aW9uLiBCdXQgYmUgYXdhcmUsIGl0IG5lZWRzIHNvbWUga2lu ZCBvZiBwYXRoIG1hbmFnZW1lbnQsIHdoaWNoIGlzIGFscmVhZHkgcHJlc2VudCBpbiBNUFRDUCwg YnV0IG5vdCBpbiBUQ1AuIEZ1cnRoZXJtb3JlIEkgYXNzdW1lICJyb2J1c3RuZXNzIiBpcyBhIHRv cGljIG1vcmUgcmVsYXRlZCB0byB0YXBzIHdvcmtpbmcgZ3JvdXAsIHdoZXJlYXMgImxhdGVuY3kg cmVkdWN0aW9uIiBpcyByZWxhdGVkIHRvIE1QVENQIG9idmlvdXNseSBhbmQgZGVwZW5kcyBvbiAi cm9idXN0bmVzcyIhDQoNCkJSDQoNCk1hcmt1cw0K From nobody Tue Sep 5 01:17:53 2017 Return-Path: X-Original-To: multipathtcp@ietf.org Delivered-To: multipathtcp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id E7C0C132644; Tue, 5 Sep 2017 01:17:51 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: multipathtcp@ietf.org, ietf@kuehlewind.net, philip.eardley@bt.com, mptcp-chairs@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.59.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <150459947192.28674.7149204113748374138.idtracker@ietfa.amsl.com> Date: Tue, 05 Sep 2017 01:17:51 -0700 Archived-At: Subject: [multipathtcp] mptcp - New Meeting Session Request for IETF 100 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 08:17:52 -0000 A new meeting session request has just been submitted by Philip Eardley, a Chair of the mptcp working group. --------------------------------------------------------- Working Group Name: Multipath TCP Area Name: Transport Area Session Requester: Philip Eardley Number of Sessions: 1 Length of Session(s): 2 Hours Number of Attendees: 60 Conflicts to Avoid: First Priority: ippm tcpinc tcpm tsvarea tsvwg tls banana Second Priority: taps iccrg rtcweb manet Third Priority: nfvrg quic maprg People who must be present: Yoshifumi Nishida Philip Eardley Mirja Kuehlewind Resources Requested: Special Requests: please avoid any transport area BoFs --------------------------------------------------------- From nobody Tue Sep 5 09:31:50 2017 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C5B06132D86 for ; Tue, 5 Sep 2017 09:31:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.618 X-Spam-Level: X-Spam-Status: No, score=-2.618 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, WEIRD_PORT=0.001] autolearn=ham autolearn_force=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 067NRNrQCeQg for ; Tue, 5 Sep 2017 09:31:46 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.138]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F58F132D6F for ; Tue, 5 Sep 2017 09:31:45 -0700 (PDT) Received: from EPDAG01D-UKBR.domain1.systemhost.net (193.113.197.205) by EVMED04-UKBR.bt.com (10.216.161.34) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 5 Sep 2017 17:31:42 +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.1293.2; Tue, 5 Sep 2017 17:31:41 +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.1293.2; Tue, 5 Sep 2017 17:31: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.1293.004; Tue, 5 Sep 2017 17:31:40 +0100 From: To: , Thread-Topic: Changes to RFC6824bis Thread-Index: AdMF4tNWzyK6qEchQXuzuihLvNQscwggXS1g Date: Tue, 5 Sep 2017 16:31:40 +0000 Message-ID: <7a02a641ed684b3c8aa8e7899e5624ee@rew09926dag03b.domain1.systemhost.net> References: <6ad50c5f057742c096fdd1f9088e551d@rew09926dag03b.domain1.systemhost.net> In-Reply-To: <6ad50c5f057742c096fdd1f9088e551d@rew09926dag03b.domain1.systemhost.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.202.233] Content-Type: multipart/alternative; boundary="_000_7a02a641ed684b3c8aa8e7899e5624eerew09926dag03bdomain1sy_" MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] Changes to RFC6824bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Sep 2017 16:31:49 -0000 --_000_7a02a641ed684b3c8aa8e7899e5624eerew09926dag03bdomain1sy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Just wanted to check where we are re these 3 changes. #1 - thanks to Alan for making this change #2 - Christoph, Olivier - any news? #3 - Quentin - any news? Thanks! Phil From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of phil= ip.eardley@bt.com Sent: 26 July 2017 08:51 To: multipathtcp@ietf.org Subject: [multipathtcp] Changes to RFC6824bis Hi, During the discussions in Prague, we had good agreement about the following= change to the bis. This is a change to the wire protocol. Please say as so= on as possible if you disagree with this change, otherwise we'll go ahead a= nd make this change:- Remove address identifier from MP-PRIO, as it can be used as an attack. Explanation at https://mailarchive.ietf.org/arch/msg/multipathtcp/WWWaQ3AKW= EMgsBSPKc_R9Ct_YoI and follow up emails. The issue was briefly summarised d= uring the Friday meeting in Prague - eg see the etherpad for a summary http= ://etherpad.tools.ietf.org:9000/p/notes-ietf-99-mptcp?useMonospaceFont=3Dtr= ue Alan - are you ok to make this change please? -- In addition, we agreed in principle to the following (informational) change= s to the bis - exact text to be proposed. 2. Guidance about MPTCP & TFP interactions, based on https://www.ietf= .org/proceedings/99/slides/slides-99-mptcp-sessb-mptcp-tfo-00.pdf - Christo= ph & Olivier, please propose text. 3. There was a suggestion, arising from the hackathon, to discuss on = the list whether clarifications or extra 'reason codes' would be useful in = the context of reset option. Quentin (& others), please make a proposal. Best wishes, Phil & Yoshi --_000_7a02a641ed684b3c8aa8e7899e5624eerew09926dag03bdomain1sy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Just wanted to check whe= re we are re these 3 changes.

#1 – thanks to Ala= n for making this change

#2 – Christoph, Ol= ivier – any news?

#3 – Quentin ̵= 1; any news?

Thanks!

Phil

 = ;

From: = multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of philip.eardley@bt.com
Sent: 26 July 2017 08:51
To: multipathtcp@ietf.org
Subject: [multipathtcp] Changes to RFC6824bis

 

Hi,

During the discussions in Prague, we had good agreement about the = following change to the bis. This is a change to the wire protocol. Please = say as soon as possible if you disagree with this change, otherwise we’ll go ahead and make this change:-

Remove= address identifier from MP-PRIO, as it can be used as an attack.

Explan= ation at https://mailarchive.ietf.org/arch/msg/multipathtcp/WWWaQ3AKWEMgsBSPKc_R9Ct_= YoI and follow up emails. The issue was briefly summarised during the F= riday meeting in Prague – eg see the etherpad for a summary http://etherpad.tools.ietf.org:9000/p/notes-ietf-99-mptcp?useMonospaceFont= =3Dtrue

Alan &= #8211; are you ok to make this change please?

--

In add= ition, we agreed in principle to the following (informational) changes to t= he bis – exact text to be proposed.

2.    &nbs= p;  Guidance about MPTCP & TFP interactio= ns, based on https://www.ietf.org/proceedings/99/slides/slides-99-mptcp-sessb-mptcp-tfo-= 00.pdf - Christoph & Olivier, please propose text.

3.    &nbs= p;  There was a suggestion, arising from the hackathon= , to discuss on the list whether clarifications or extra ‘reason code= s’ would be useful in the context of reset option. Quentin (& oth= ers), please make a proposal.

Best wishes,

Phil & Yoshi

 

--_000_7a02a641ed684b3c8aa8e7899e5624eerew09926dag03bdomain1sy_-- From nobody Fri Sep 8 04:22:20 2017 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 371F8132396 for ; Fri, 8 Sep 2017 04:22:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.621 X-Spam-Level: X-Spam-Status: No, score=-2.621 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=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 qBXytSrdinZ1 for ; Fri, 8 Sep 2017 04:22:16 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.137]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E88EF132339 for ; Fri, 8 Sep 2017 04:22:15 -0700 (PDT) Received: from EVMHT04-UKBR.domain1.systemhost.net (193.113.108.57) by EVMED03-UKBR.bt.com (10.216.161.33) with Microsoft SMTP Server (TLS) id 14.3.319.2; Fri, 8 Sep 2017 12:22:10 +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; Fri, 8 Sep 2017 12:22:13 +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.1293.2; Fri, 8 Sep 2017 12:22:12 +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.1293.004; Fri, 8 Sep 2017 12:22:12 +0100 From: To: Thread-Topic: mptcp - New Meeting Session Request for IETF 100 Thread-Index: AQHTJh95ZKD14zaqukO7qceXS5oaY6Kq3E6A Date: Fri, 8 Sep 2017 11:22:12 +0000 Message-ID: <1504869731213.54234@bt.com> References: <150459947192.28674.7149204113748374138.idtracker@ietfa.amsl.com> In-Reply-To: <150459947192.28674.7149204113748374138.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.187.101.39] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] mptcp - New Meeting Session Request for IETF 100 X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Sep 2017 11:22:18 -0000 We've requested 1 session of 2 hours in Singapore.=0A= =0A= Please could you let us know if you think you'll need presentation /discuss= ion time in the meeting - if we get a lot of requests, we'll ask for a seco= nd timeslot. =0A= =0A= We added Banana to the conflicts list - if other adjustments are needed, pl= ease let us know.=0A= =0A= thanks=0A= Phil & Yoshi=0A= ________________________________________=0A= From: IETF Meeting Session Request Tool =0A= Sent: 05 September 2017 09:17=0A= To: session-request@ietf.org=0A= Cc: multipathtcp@ietf.org; ietf@kuehlewind.net; Eardley,PL,Philip,TUD1 R; m= ptcp-chairs@ietf.org=0A= Subject: mptcp - New Meeting Session Request for IETF 100=0A= =0A= A new meeting session request has just been submitted by Philip Eardley, a = Chair of the mptcp working group.=0A= =0A= =0A= ---------------------------------------------------------=0A= Working Group Name: Multipath TCP=0A= Area Name: Transport Area=0A= Session Requester: Philip Eardley=0A= =0A= Number of Sessions: 1=0A= Length of Session(s): 2 Hours=0A= Number of Attendees: 60=0A= Conflicts to Avoid:=0A= First Priority: ippm tcpinc tcpm tsvarea tsvwg tls banana=0A= Second Priority: taps iccrg rtcweb manet=0A= Third Priority: nfvrg quic maprg=0A= =0A= =0A= People who must be present:=0A= Yoshifumi Nishida=0A= Philip Eardley=0A= Mirja Kuehlewind=0A= =0A= Resources Requested:=0A= =0A= Special Requests:=0A= please avoid any transport area BoFs=0A= ---------------------------------------------------------=0A= =0A= From nobody Mon Sep 11 01:12:19 2017 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 30CC6133020 for ; Mon, 11 Sep 2017 01:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 8NxjHVcMBOkz for ; Mon, 11 Sep 2017 01:12:16 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.141]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B447613301E for ; Mon, 11 Sep 2017 01:12:15 -0700 (PDT) Received: from EVHUB05-UKBR.domain1.systemhost.net (193.113.108.173) by EVMED05-UKBR.bt.com (10.216.161.37) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 11 Sep 2017 09:12:09 +0100 Received: from rew09926dag03a.domain1.systemhost.net (10.55.202.18) by EVHUB05-UKBR.domain1.systemhost.net (193.113.108.173) with Microsoft SMTP Server (TLS) id 14.3.158.1; Mon, 11 Sep 2017 09:12:13 +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.1293.2; Mon, 11 Sep 2017 09:12:12 +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.1293.004; Mon, 11 Sep 2017 09:12:11 +0100 From: To: Thread-Topic: [Recentattendees] IETF 100 Hackathon and Code Sprint Registrations Open! Thread-Index: AQHTKBolhz0TpA2HP0+h1JdKF/PUZaKvWwmg Date: Mon, 11 Sep 2017 08:12:11 +0000 Message-ID: References: <150481695959.7958.3408667118577609439.idtracker@ietfa.amsl.com> In-Reply-To: <150481695959.7958.3408667118577609439.idtracker@ietfa.amsl.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.202.242] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [multipathtcp] FW: [Recentattendees] IETF 100 Hackathon and Code Sprint Registrations Open! X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 11 Sep 2017 08:12:18 -0000 QW55IGludGVyZXN0IGluIGpvaW5pbmcgdGhlIGhhY2thdGhvbiB0aGlzIHRpbWU/DQoNCi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBSZWNlbnRhdHRlbmRlZXMgW21haWx0bzpyZWNl bnRhdHRlbmRlZXMtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mIElFVEYgU2VjcmV0YXJp YXQNClNlbnQ6IDA3IFNlcHRlbWJlciAyMDE3IDIxOjQzDQpUbzogSUVURiBBbm5vdW5jZW1lbnQg TGlzdCA8aWV0Zi1hbm5vdW5jZUBpZXRmLm9yZz4NCkNjOiAxMDBhbGxAaWV0Zi5vcmc7IHJlY2Vu dGF0dGVuZGVlc0BpZXRmLm9yZzsgaWV0ZkBpZXRmLm9yZw0KU3ViamVjdDogW1JlY2VudGF0dGVu ZGVlc10gSUVURiAxMDAgSGFja2F0aG9uIGFuZCBDb2RlIFNwcmludCBSZWdpc3RyYXRpb25zIE9w ZW4hDQoNCklFVEYgMTAwIA0KU2luZ2Fwb3JlDQpOb3ZlbWJlciAxMS0xNywgMjAxNw0KSG9zdDog Q2lzY28NCg0KSUVURiAxMDAgSW5mb3JtYXRpb246IGh0dHBzOi8vaWV0Zi5vcmcvbWVldGluZy8x MDAvaW5kZXguaHRtbA0KUmVnaXN0ZXIgb25saW5lIGF0OiBodHRwczovL2lldGYub3JnL21lZXRp bmcvcmVnaXN0ZXIuaHRtbA0KSG90ZWwgSW5mb3JtYXRpb246IGh0dHA6Ly93d3cuaWV0Zi5vcmcv bWVldGluZy8xMDAvaG90ZWwuaHRtbA0KDQoxLiBDb2RlIFNwcmludAkNCg0KCVRoZSBJRVRGIDEw MCBDb2RlIFNwcmludCBpbiBTaW5nYXBvcmUgd2lsbCwgYXMNCglhbHdheXMsIGxldCB5b3Ugd29y ayBvbiBmaXhpbmcgdGhvc2UgdGhpbmdzIGFib3V0IHRoZSBkYXRhdHJhY2tlcg0KCXdoaWNoIHlv dSBtb3N0IHVyZ2VudGx5IGRlc2lyZSB0byBkbyBzb21ldGhpbmcgYWJvdXQuDQoNCglXaGVuOiBT YXR1cmRheSwgTm92ZW1iZXIgMTEgZnJvbSAwOTozMCB0byAxODowMA0KCVdoZXJlOiBSYWZmbGVz IENpdHkgQ29udmVudGlvbiBDZW50ZXIsIFJvb20gVEJEDQoJU2lnbnVwOiBodHRwczovL3RyYWMu dG9vbHMuaWV0Zi5vcmcvdG9vbHMvaWV0ZmRiL3dpa2kvSUVURjEwMFNwcmludFNpZ25VcA0KCU1v cmUgaW5mb3JtYXRpb246IGh0dHBzOi8vdHJhYy50b29scy5pZXRmLm9yZy90b29scy9pZXRmZGIv d2lraS9JRVRGMTAwU3ByaW50DQoNCjIuIEhhY2thdGhvbg0KCQ0KCVRoZSBJRVRGIGlzIGhvbGRp bmcgYSBIYWNrYXRob24gYXQgSUVURiAxMDAgdG8gZW5jb3VyYWdlDQoJZGV2ZWxvcGVycyB0byBk aXNjdXNzLCBjb2xsYWJvcmF0ZSBhbmQgZGV2ZWxvcCB1dGlsaXRpZXMsIGlkZWFzLA0KCXNhbXBs ZSBjb2RlIGFuZCBzb2x1dGlvbnMgdGhhdCBzaG93IHByYWN0aWNhbCBpbXBsZW1lbnRhdGlvbnMg b2YNCglJRVRGIHN0YW5kYXJkcy4NCg0KCVdoZW46IFNhdHVyZGF5IE5vdmVtYmVyIDExIGFuZCBT dW5kYXkgTm92ZW1iZXIgMTINCglXaGVyZTogUmFmZmxlcyBDaXR5IENvbnZlbnRpb24gQ2VudGVy LCBSb29tIFRCRA0KCVNpZ251cDogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcmVnaXN0cmF0aW9uL2ll dGYxMDAvaGFja2F0aG9ucmVnaXN0cmF0aW9uLnB5DQoJTW9yZSBpbmZvcm1hdGlvbjogaHR0cDov L2lldGYub3JnL2hhY2thdGhvbi8xMDAtaGFja2F0aG9uLmh0bWwgDQoJS2VlcCB1cCB0byBkYXRl IGJ5IHN1YnNjcmliaW5nIHRvOiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZv L2hhY2thdGhvbg0KDQoJVGhlIEhhY2thdGhvbiBpcyBmcmVlIHRvIGF0dGVuZCBhbmQgb3BlbiB0 byBhbGwuIEV4dGVuZA0KCXRoZSBpbnZpdGF0aW9uIHRvIGNvbGxlYWd1ZXMgb3V0c2lkZSB0aGUg SUVURiENCg0KCURlc2NyaXB0aW9ucyBhbmQgaW5mb3JtYXRpb24gcmVnYXJkaW5nIHRoZSB0ZWNo bm9sb2dpZXMNCglmb3IgdGhlIGhhY2thdGhvbiBhcmUgbG9jYXRlZCBvbiB0aGUgSUVURiAxMDAg TWVldGluZyBXaWtpOg0KCWh0dHBzOi8vd3d3LmlldGYub3JnL3JlZ2lzdHJhdGlvbi9NZWV0aW5n V2lraS93aWtpLzEwMGhhY2thdGhvbg0KDQoJRG9u4oCZdCBzZWUgYW55dGhpbmcgdGhhdCBpbnRl cmVzdHMgeW91PyBGZWVsIGZyZWUgdG8gYWRkDQoJeW91ciBwcmVmZXJyZWQgdGVjaG5vbG9neSB0 byB0aGUgbGlzdCwgc2lnbiB1cCBhcyBpdHMNCglDaGFtcGlvbiBhbmQgc2hvdyB1cCB0byB3b3Jr IG9uIGl0LiBOb3RlOiB5b3UgbXVzdCBsb2dpbiB0bw0KCXRoZSB3aWtpIHRvIGFkZCBjb250ZW50 LiBJZiB5b3UgZG8gYWRkIGEgbmV3IHRlY2hub2xvZ3ksIHdlDQoJc3Ryb25nbHkgc3VnZ2VzdCB0 aGF0IHlvdSBzZW5kIGFuIGVtYWlsIHRvIGhhY2thdGhvbkBpZXRmLm9yZw0KCXRvIGxldCBvdGhl cnMga25vdy4gWW91IG1heSBnZW5lcmF0ZSBpbnRlcmVzdCBpbiB5b3VyDQoJdGVjaG5vbG9neSwg YW5kIGZpbmQgb3RoZXIgcGVvcGxlIHdobyB3YW50IHRvIGNvbnRyaWJ1dGUgdG8NCglpdC4NCg0K CVRvIHJlcXVlc3QgYSB3aWtpIGFjY291bnQsIHBsZWFzZSBjbGljayBvbiB0aGUg4oCcbG9naW7i gJ0NCglidXR0b24gb24gdGhlIGJvdHRvbSByaWdodCBjb3JuZXIgb2YgdGhlIHBhZ2UsIGFuZCBj aG9vc2UNCgnigJxyZWdpc3Rlci7igJ0gSWYgeW91IG5lZWQgYSBuZXcgcGFzc3dvcmQgcGxlYXNl IGNsaWNrIG9uIHRoZQ0KCeKAnGxvZ2lu4oCdIGJ1dHRvbiBvbiB0aGUgYm90dG9tIHJpZ2h0IGNv cm5lciBvZiB0aGUgcGFnZSBhbmQNCgljaG9vc2Ug4oCcU2VuZCBuZXcgcGFzc3dvcmQu4oCdDQoN CkltcG9ydGFudCBEYXRlczogaHR0cHM6Ly9pZXRmLm9yZy9tZWV0aW5nL2ltcG9ydGFudC1kYXRl cy5odG1sI2lldGYxMDANCg0KNjUgZGF5cyB1bnRpbCBJRVRGIDEwMCENCg0KX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NClJlY2VudGF0dGVuZGVlcyBtYWls aW5nIGxpc3QNClJlY2VudGF0dGVuZGVlc0BpZXRmLm9yZw0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcv bWFpbG1hbi9saXN0aW5mby9yZWNlbnRhdHRlbmRlZXMNCg== From nobody Wed Sep 13 06:39:28 2017 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71225133041 for ; Wed, 13 Sep 2017 06:39:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tessares-net.20150623.gappssmtp.com 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 UlJ701nQsW9u for ; Wed, 13 Sep 2017 06:39:24 -0700 (PDT) Received: from mail-wm0-x229.google.com (mail-wm0-x229.google.com [IPv6:2a00:1450:400c:c09::229]) (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 5FEEE132D44 for ; Wed, 13 Sep 2017 06:39:24 -0700 (PDT) Received: by mail-wm0-x229.google.com with SMTP id i189so7092303wmf.1 for ; Wed, 13 Sep 2017 06:39:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=rqZpCkfC818TX1tWPCKT1MIiiwRBtdzvAhW+ovsVdc4=; b=1Lo2geIW0eWcRQc8Z4fhLjV3fNG/nCWez9MWXQCWySErMCnolAcD16ky1pNk69gF9c w9y7mqVrwXBF2ulaCVoBU+79BHxfSlTN5PqxL/8iMvE/P4a1r1nrylJXl778BMySlgW4 05lrgh0j78Filaay2YytR4iEcZ+mH2ZiZ2LJh9HnXDj7nWV7X+Dl97I4+FhdZLURZOdw sOZEk7BrP8s1LvGAikCKYK+Mkbjad+N0Tb+WnuFVaRpkF3W7PFzIfdIGvPvHY1k5l0wF /q1K2hUavNgrsrILKVChpamNsxQzvFCbmsyZkIx10Gds5905HuAh9aMi8tEwcgMOVKeh 2BHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:message-id:date:user-agent :mime-version:content-language:content-transfer-encoding; bh=rqZpCkfC818TX1tWPCKT1MIiiwRBtdzvAhW+ovsVdc4=; b=TzZQfvIpgxZNrAL9ww+9uw+KY+c+J/LP61pKs2boFkzkws0CM/V/5JuZMFDuZM8Hz4 QmLLrla4uel8HtVe4+VxNxKpV3JVM+AhEUNqQkx9fkVBTSx9tMmfAvO11F9oF7g8lof6 F5nLVdc2UvuAbxoWqfCj6C/RWrhgpurpDwSYm+kDN0mfXQmn7JKHsv1hA5HO42NI4vPy Px8Bt4CBN3TXztY2cyLhnbSaqlJ0SdSAKWZwpIzinmSgDSyzbXIp7QmJ3dwwFTWL0nyL OaTQWVSYkJHBuwSj030qyXA3k7z1sTMdBFn511p5I2X/CWcQig2L51ThHsjDP+/bfr/0 d58w== X-Gm-Message-State: AHPjjUjhCQiVPC5K4aqX1vih5Rm43TrE2sg5ckZEo/MkHSxe+Egxxf8j 1+H7kAv5w5SDxnd9B+2ZIPYRfZilWoadMxrJ8/8X48YVL2XAIh3/Gokbdrhutj4bw/DBuSTRKKA cPqxF X-Google-Smtp-Source: ADKCNb5MYsMPGx31Q7IBHKFlULsmRyi6tgdfzDuqlKvO5j+8Bp0zohceoB35iw2mNKsOBEQ/cPps+Q== X-Received: by 10.80.147.193 with SMTP id o59mr7063152eda.88.1505309962868; Wed, 13 Sep 2017 06:39:22 -0700 (PDT) Received: from [192.168.2.2] ([87.66.241.164]) by smtp.gmail.com with ESMTPSA id r13sm6768299edk.40.2017.09.13.06.39.21 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 13 Sep 2017 06:39:22 -0700 (PDT) From: =?UTF-8?Q?Fran=c3=a7ois_Finfe?= To: multipathtcp@ietf.org Cc: Olivier Bonaventure Message-ID: Date: Wed, 13 Sep 2017 15:39:20 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: [multipathtcp] Multipath TCP FAST_CLOSE - abrupt closing X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 13:39:27 -0000 Hi, RFC6824 and RFC6824bis use the FAST_CLOSE option to abruptly close a Multipath TCP connection. The motivation for the procedure defined in section 3.5 is to enable a host to quickly terminate a Multipath TCP connection without being forced to send DATA_FINs. The current procedure defined in section 3.5 is that the host that wishes to abruptly terminate a connection must send a RST on all subflows except one where it sends an ACK with the FAST_CLOSE option and waits for a RST before closing the Multipath TCP connection. The FAST_CLOSE option includes the receiver=E2=80=99s key to authenticate the a= brupt release of the subflow. This prevents attacks where a remote attacker could send spoofed packets that would terminate the Multipath TCP connection. Unfortunately, the procedure defined in section 3.5 has a very important drawback. Although the host wants to abruptly close the Multipath TCP connection, it needs to maintain state for this connection until the other host has confirmed (with a RST) the termination of the connection. This goes against the idea of abruptly closing connections due to lack of ressources for example. We have faced some issues with applications using SO_LINGER set to zero that were expecting the socket to have disappeared after an abrupt release while it did not disappear. It would make sense to reconsider the abrupt connection termination procedure defined in section 3.5 to enable a host to immediately terminate a Multipath TCP connection and release the associated data structures. One possibility would be to work as follows. Consider a Multipath TCP connection established between a client and a server. There are two subflows, A and B. The server wants to abruptly close the connection. For this, we propose to continue to use the FAST_CLOSE option, but place it inside the RST packet sent over all subflows. By using a RST instead of an ACK as in section 3.5, the server does not need to maintain any state and can remove the data structures associated with the closed connection immediately. If one of the RST packets reaches the client, it will know that the entire connection has been closed by the server. The only issue with this new approach is when none of the RST packets sent by the server reach the client. We would be in a situation where the client considers that the Multipath TCP is active while it does not exist anymore on the server. After some time, the client will send a packet to the server over one of the subflows. Since the Multipath TCP connection does not exist anymore on the server, it will reply with a RST packet that will close this subflow. The client will receive the same RST over all the established subflows. When all subflows have been closed, the client should try to establish a new subflow to the server by sending a SYN with MP_JOIN. Upon reception of this SYN, the server will try to match the connection token with the established Multipath TCP connection and will find that there is no matching connection. According to RFC6824, the server should reply with a RST packet to close the subflow. We could add to this RST packet a new MP_TCPRST option indicating that the server could not match the received token with an existing connection. Upon reception of a RST carrying this option, the client would know that the corresponding connection has been closed by the server and would close it itself. We believe that this approach is simpler on the server side while still allowing clients to detect closed Multipath TCP connections. The abrupt closing (e.g. socket option SO_LINGER with zero timeout) is also properly implemented. In contrast with the current approach, it places the burden on the client instead of on the server, but we believe this is beneficial for servers that often need to abruptly close connections. Fran=C3=A7ois --=20 ------------------------------ DISCLAIMER. This email and any files transmitted with it are confidential and intended= =20 solely for the use of the individual or entity to whom they are addressed.= =20 If you have received this email in error please notify the system manager.= =20 This message contains confidential information and is intended only for the= =20 individual named. If you are not the named addressee you should not=20 disseminate, distribute or copy this e-mail. Please notify the sender=20 immediately by e-mail if you have received this e-mail by mistake and=20 delete this e-mail from your system. If you are not the intended recipient= =20 you are notified that disclosing, copying, distributing or taking any=20 action in reliance on the contents of this information is strictly=20 prohibited. From nobody Wed Sep 13 08:02:01 2017 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C4F351326ED; Wed, 13 Sep 2017 08:01:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 8IiI74Q9DOwU; Wed, 13 Sep 2017 08:01:45 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.135]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA8F01321C7; Wed, 13 Sep 2017 08:01:43 -0700 (PDT) Received: from EVHUB03-UKBR.domain1.systemhost.net (193.113.108.185) by EVMED01-UKBR.bt.com (10.216.161.31) with Microsoft SMTP Server (TLS) id 14.3.319.2; Wed, 13 Sep 2017 16:01:28 +0100 Received: from rew09926dag03d.domain1.systemhost.net (10.55.202.30) by EVHUB03-UKBR.domain1.systemhost.net (193.113.108.185) with Microsoft SMTP Server (TLS) id 14.3.158.1; Wed, 13 Sep 2017 16:01:24 +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.1293.2; Wed, 13 Sep 2017 16:01:22 +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.1293.004; Wed, 13 Sep 2017 16:01:22 +0100 From: To: , , Thread-Topic: Progressing the MPTCP proxy work Thread-Index: AdMsoSjtjzHKadusSUOFh+9ZCBbgfw== Date: Wed, 13 Sep 2017 15:01:21 +0000 Message-ID: <2efd30edab0647dda78246734f89a3f1@rew09926dag03b.domain1.systemhost.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.202.233] Content-Type: multipart/alternative; boundary="_000_2efd30edab0647dda78246734f89a3f1rew09926dag03bdomain1sy_" MIME-Version: 1.0 Archived-At: Subject: [multipathtcp] Progressing the MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Sep 2017 15:01:48 -0000 --_000_2efd30edab0647dda78246734f89a3f1rew09926dag03bdomain1sy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, At the IETF we discussed (in MPTCP WG) a new proposal on MPTCP proxy, "0-RT= T TCP converters" https://tools.ietf.org/html/draft-bonaventure-mptcp-conve= rters This seemed to get a good reception, and had taken on board the feed= back about the "plain mode" draft. We believe the next steps are: * WGs - TCPM & MPTCP - please send any further initial comments= , especially if you believe it hasn't dealt with technical concerns that we= re raised about the "plain mode" draft, or if you have fresh concerns * Authors - please rev the document to deal with comments so fa= r. Please include TCPM & tsvarea mailing lists. * Chairs - assuming these steps go well, we'll be looking to do= a consensus call on adopting as a WG doc (ADs to confirm MPTCP WG; TCPM is= the other possibility) Thanks, Best wishes, Phil & Yoshi --_000_2efd30edab0647dda78246734f89a3f1rew09926dag03bdomain1sy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

At the IETF we discussed (in MPTCP WG) a new proposal on MPTCP pro= xy, “0-RTT TCP converters” https://tools.ietf.org/html/draft-bonaventure-mptcp-converters&n= bsp; This seemed to get a good reception, and had taken on board the feedba= ck about the “plain mode” draft.

We believe the next steps are:

•       =       WGs – TCPM & MPTCP - please send a= ny further initial comments, especially if you believe it hasn’t deal= t with technical concerns that were raised about the “plain mode̶= 1; draft, or if you have fresh concerns

•       =       Authors – please rev the document to d= eal with comments so far. Please include TCPM & tsvarea mailing lists.<= o:p>

•       =       Chairs – assuming these steps go well,= we’ll be looking to do a consensus call on adopting as a WG doc (ADs= to confirm MPTCP WG; TCPM is the other possibility)

Thanks,

Best wishes= ,

Phil & = Yoshi

 

--_000_2efd30edab0647dda78246734f89a3f1rew09926dag03bdomain1sy_-- From nobody Wed Sep 13 21:16:19 2017 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 03ABC1330A5 for ; Wed, 13 Sep 2017 21:16:18 -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 autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=apple.com 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 1p-x4SJYtnC9 for ; Wed, 13 Sep 2017 21:16:16 -0700 (PDT) Received: from mail-in24.apple.com (mail-out24.apple.com [17.171.2.34]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D245132D89 for ; Wed, 13 Sep 2017 21:16:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1505362575; 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=4GTJXRtaHTnXp+lWgeYQiB0HW+7Fz6tqHbhX/LGCv8E=; b=YPUsEmvtdRk0VENbdSbWvkfrRjEjXS8iNGo+ZhdCYMcqjeQydmgq0/f3OkhUVdu+ G9P5PB8GB7RNFvJ1Axe381k4JaFcBRNulQO+JchKJXZxn6Le8mQFlwMYDvO4tl4i t48KvxI2dI0gr/glJdN5GrRW2Bnk4Nez+QuAypi3YFwduTJi4ETeMCeJMfbwu6ZZ r/oUMTTSnyXpXxuv7le526JwrwcfPIp78v4NE2nFWpws8sHhpVo9eYnEleMcU5F6 fTsh3FABiM85kyH32RNDgzSDvGxrO6SynjeC9u3bvixPcy70rx9asAULrANBDIiC x+yCpwK1CHHSnCG5X1x2ZQ==; Received: from relay4.apple.com (relay4.apple.com [17.128.113.87]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mail-in24.apple.com (Apple Secure Mail Relay) with SMTP id 5F.47.25405.F820AB95; Wed, 13 Sep 2017 21:16:15 -0700 (PDT) X-AuditID: 11ab0218-27bff7000000633d-ba-59ba028f02f0 Received: from nwk-mmpp-sz11.apple.com (nwk-mmpp-sz11.apple.com [17.128.115.155]) by relay4.apple.com (Apple SCV relay) with SMTP id 0B.46.06992.E820AB95; Wed, 13 Sep 2017 21:16:14 -0700 (PDT) MIME-version: 1.0 Content-transfer-encoding: 8BIT Content-disposition: inline Content-type: text/plain; charset=utf-8 Received: from localhost ([17.150.209.193]) by nwk-mmpp-sz11.apple.com (Oracle Communications Messaging Server 8.0.1.3.20170825 64bit (built Aug 25 2017)) with ESMTPSA id <0OW9000V5572PU20@nwk-mmpp-sz11.apple.com>; Wed, 13 Sep 2017 21:16:14 -0700 (PDT) Sender: cpaasch@apple.com Date: Wed, 13 Sep 2017 21:16:14 -0700 From: Christoph Paasch To: =?iso-8859-1?Q?Fran=E7ois?= Finfe Cc: multipathtcp@ietf.org, Olivier Bonaventure Message-id: <20170914041614.GK4453@Chimay.local> References: In-reply-to: User-Agent: Mutt/1.8.3 (2017-05-23) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrOLMWRmVeSWpSXmKPExsUi2FAYrtvPtCvS4OozfYutEzYxWXxefZ3N YnbjcRYHZo8lS34yedxpms4cwBTFZZOSmpNZllqkb5fAlfF27Ur2gs1KFbdff2RrYLwl3cXI ySEhYCLxqG0vaxcjF4eQwBomiYeXtzLBJFo2HIJKHGKUaHv4kxkkwSsgKPFj8j2WLkYODmYB eYkjl7JBwswC0hKP/s5ghwirS0yZkgvR2sQkseftOhaQGmEBSYnuO3fAxrAIqEq8XN7LCmKz CWhJvL3dDmaLCDhLrFn8nhViZrDE5F07oXpdJR53/GCHOMFA4vqd92BxIQF7iX1L7oLZnAIO Envvn2EEsUUFlCXm7VvFBnKEhMAMNolNW7+yTWAUmYXkhVkIL8xC8sIshBcWMLKsYhTOTczM 0c3MMzLRSywoyEnVS87P3cQIionVTBI7GL+8NjzEKMDBqMTDa2GzM1KINbGsuDL3EKM0B4uS OO/y2UAhgfTEktTs1NSC1KL4otKc1OJDjEwcnFINjFkpChk7zzTx/AvVe3/O0e3Qv9/dJyb8 /qC468w0GY8HAY2vg6vYDx1M/h+T+E3q2DtD3yATISdZvzrblHsr63g01P/mRp8+yHHAPIZj Zc79qYddWs935vp3ys8tW3Pw+VFJr6oDt9jOnljzakP92TgT+d+F5YdYXqtebUvaLhjVXJ37 gdEyU4mlOCPRUIu5qDgRAJq2ZjpqAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrJLMWRmVeSWpSXmKPExsUi2FA8W7ePaVekwazDphZbJ2xisvi8+jqb xezG4ywOzB5Llvxk8rjTNJ05gCmKyyYlNSezLLVI3y6BK+Pt2pXsBZuVKm6//sjWwHhLuouR k0NCwESiZcMh1i5GLg4hgUOMEm0PfzKDJHgFBCV+TL7H0sXIwcEsIC9x5FI2SJhZQFri0d8Z 7BBhdYkpU3IhWpuYJPa8XccCUiMsICnRfecO2BgWAVWJl8t7WUFsNgEtibe328FsEQFniTWL 37NCzAyWmLxrJ1Svq8Tjjh/sECcYSFy/8x4sLiRgL7FvyV0wm1PAQWLv/TOMILaogLLEvH2r 2CYwCs5CcvUshKtnIbl6FsLVCxhZVjEKFKXmJFaa6CUWFOSk6iXn525iBAdwYfgOxn/LrA4x CnAwKvHwPrDcGSnEmlhWXJkLDCEOZiUR3vA3QCHelMTKqtSi/Pii0pzU4kOM0hwsSuK8xU+A UgLpiSWp2ampBalFMFkmDk6pBsY7V6+y6+0O0wm6d2LCn7b1TvUcmwOijQvWMUaErYy6mrVT 83Dj50ftsXclb70Lkm3bx70peI208+p3XprHrnXeMbTs5k1fMstZVfzQdPliQ8P4eJf/Lo+v d2x8v/CNt//tlm3sAuGL7t/QueCgVJg/keWbbN6TeKtTp45uVijnLLc5rD2dabISS3FGoqEW c1FxIgBSu7gAXAIAAA== Archived-At: Subject: Re: [multipathtcp] Multipath TCP FAST_CLOSE - abrupt closing X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 04:16:18 -0000 Hello, On 13/09/17 - 15:39:20, François Finfe wrote: > Hi, > > > RFC6824 and RFC6824bis use the FAST_CLOSE option to abruptly close a > Multipath TCP connection. The motivation for the procedure defined in > section 3.5 is to enable a host to quickly terminate a Multipath TCP > connection without being forced to send DATA_FINs. > > The current procedure defined in section 3.5 is that the host that > wishes to abruptly terminate a connection must send a RST on all > subflows except one where it sends an ACK with the FAST_CLOSE option and > waits for a RST before closing the Multipath TCP connection. The > FAST_CLOSE option includes the receiver’s key to authenticate the abrupt > release of the subflow. This prevents attacks where a remote attacker > could send spoofed packets that would terminate the Multipath TCP > connection. > > Unfortunately, the procedure defined in section 3.5 has a very important > drawback. Although the host wants to abruptly close the Multipath TCP > connection, it needs to maintain state for this connection until the > other host has confirmed (with a RST) the termination of the connection. > This goes against the idea of abruptly closing connections due to lack > of ressources for example. We have faced some issues with applications > using SO_LINGER set to zero that were expecting the socket to have > disappeared after an abrupt release while it did not disappear. > > It would make sense to reconsider the abrupt connection termination > procedure defined in section 3.5 to enable a host to immediately > terminate a Multipath TCP connection and release the associated data > structures. One possibility would be to work as follows. > > Consider a Multipath TCP connection established between a client and a > server. There are two subflows, A and B. The server wants to abruptly > close the connection. For this, we propose to continue to use the > FAST_CLOSE option, but place it inside the RST packet sent over all > subflows. By using a RST instead of an ACK as in section 3.5, the server > does not need to maintain any state and can remove the data structures > associated with the closed connection immediately. If one of the RST > packets reaches the client, it will know that the entire connection has > been closed by the server. > > The only issue with this new approach is when none of the RST packets > sent by the server reach the client. We would be in a situation where > the client considers that the Multipath TCP is active while it does not > exist anymore on the server. After some time, the client will send a > packet to the server over one of the subflows. Since the Multipath TCP > connection does not exist anymore on the server, it will reply with a > RST packet that will close this subflow. The client will receive the > same RST over all the established subflows. When all subflows have been > closed, the client should try to establish a new subflow to the server > by sending a SYN with MP_JOIN. Upon reception of this SYN, the server > will try to match the connection token with the established Multipath > TCP connection and will find that there is no matching connection. > According to RFC6824, the server should reply with a RST packet to close > the subflow. We could add to this RST packet a new MP_TCPRST option > indicating that the server could not match the received token with an > existing connection. Upon reception of a RST carrying this option, the > client would know that the corresponding connection has been closed by > the server and would close it itself. > > We believe that this approach is simpler on the server side while still > allowing clients to detect closed Multipath TCP connections. The abrupt > closing (e.g. socket option SO_LINGER with zero timeout) is also > properly implemented. In contrast with the current approach, it places > the burden on the client instead of on the server, but we believe this > is beneficial for servers that often need to abruptly close connections. I strongly support this proposal. Whenever the stack decides to force-fully close a connection due to resource-limitations, it is important for the scalability of the system to get rid of the state as quickly as possible. Otherwise, servers accumulate huge numbers of these lingering connections. Christoph From nobody Thu Sep 14 15:33:56 2017 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C01C4132355 for ; Thu, 14 Sep 2017 15:33:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.401 X-Spam-Level: X-Spam-Status: No, score=-1.401 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=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 8h5dinxHyoQb for ; Thu, 14 Sep 2017 15:33: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 4FFC8126DD9 for ; Thu, 14 Sep 2017 15:33:51 -0700 (PDT) Received: from mail-yw0-f181.google.com (mail-yw0-f181.google.com [209.85.161.181]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 1B68727840A for ; Fri, 15 Sep 2017 07:33:50 +0900 (JST) Received: by mail-yw0-f181.google.com with SMTP id r85so481031ywg.1 for ; Thu, 14 Sep 2017 15:33:50 -0700 (PDT) X-Gm-Message-State: AHPjjUhsomw+dMQi+UaEfQChR7iy2/aeLZqTBFF4CLZQ0MZ9WIcZip/+ S83zv0iDcHYaSBg2vEbawP+NaR5j6O0QztO99pE= X-Google-Smtp-Source: ADKCNb5To1hp5rO9uMAWn2snDHUrfRTzoGdvaYF2obJDxxH54saaACA8rIWFcUcQcN5ClVt6k6cDc9MWPmAqPhN4rXQ= X-Received: by 10.13.216.80 with SMTP id a77mr19842198ywe.83.1505428427386; Thu, 14 Sep 2017 15:33:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.64.145 with HTTP; Thu, 14 Sep 2017 15:33:46 -0700 (PDT) In-Reply-To: References: From: Yoshifumi Nishida Date: Thu, 14 Sep 2017 15:33:46 -0700 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?Fran=C3=A7ois_Finfe?= Cc: multipathtcp , Olivier Bonaventure Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [multipathtcp] Multipath TCP FAST_CLOSE - abrupt closing X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Sep 2017 22:33:55 -0000 Hi Francois, This is an interesting proposal for the bis draft. But, I guess the receiver of FAST_CLOSE (will be clients in most cases) may need to wait longer time in some cases. I am thinking that the main motivation of SO_LINGER with zero timeout approach is to avoid going into time_wait. I think MPTCP's FAST_CLOSE already takes care of this point to some extent and senders don't go into M_TIMEWAIT, although it requires at least 1 RTT. So, I am still not very sure if we should save this 1 RTT or should avoid unfortunate cases for long waiting. BTW, I happened to find that the state transition diagram in the draft doesn't contain M_FASTCLOSE state, although it is mentioned in Section 3.5. Is this OK? Thanks, -- Yoshi On Wed, Sep 13, 2017 at 6:39 AM, Fran=C3=A7ois Finfe wrote: > Hi, > > > RFC6824 and RFC6824bis use the FAST_CLOSE option to abruptly close a > Multipath TCP connection. The motivation for the procedure defined in > section 3.5 is to enable a host to quickly terminate a Multipath TCP > connection without being forced to send DATA_FINs. > > The current procedure defined in section 3.5 is that the host that > wishes to abruptly terminate a connection must send a RST on all > subflows except one where it sends an ACK with the FAST_CLOSE option and > waits for a RST before closing the Multipath TCP connection. The > FAST_CLOSE option includes the receiver=E2=80=99s key to authenticate the= abrupt > release of the subflow. This prevents attacks where a remote attacker > could send spoofed packets that would terminate the Multipath TCP > connection. > > Unfortunately, the procedure defined in section 3.5 has a very important > drawback. Although the host wants to abruptly close the Multipath TCP > connection, it needs to maintain state for this connection until the > other host has confirmed (with a RST) the termination of the connection. > This goes against the idea of abruptly closing connections due to lack > of ressources for example. We have faced some issues with applications > using SO_LINGER set to zero that were expecting the socket to have > disappeared after an abrupt release while it did not disappear. > > It would make sense to reconsider the abrupt connection termination > procedure defined in section 3.5 to enable a host to immediately > terminate a Multipath TCP connection and release the associated data > structures. One possibility would be to work as follows. > > Consider a Multipath TCP connection established between a client and a > server. There are two subflows, A and B. The server wants to abruptly > close the connection. For this, we propose to continue to use the > FAST_CLOSE option, but place it inside the RST packet sent over all > subflows. By using a RST instead of an ACK as in section 3.5, the server > does not need to maintain any state and can remove the data structures > associated with the closed connection immediately. If one of the RST > packets reaches the client, it will know that the entire connection has > been closed by the server. > > The only issue with this new approach is when none of the RST packets > sent by the server reach the client. We would be in a situation where > the client considers that the Multipath TCP is active while it does not > exist anymore on the server. After some time, the client will send a > packet to the server over one of the subflows. Since the Multipath TCP > connection does not exist anymore on the server, it will reply with a > RST packet that will close this subflow. The client will receive the > same RST over all the established subflows. When all subflows have been > closed, the client should try to establish a new subflow to the server > by sending a SYN with MP_JOIN. Upon reception of this SYN, the server > will try to match the connection token with the established Multipath > TCP connection and will find that there is no matching connection. > According to RFC6824, the server should reply with a RST packet to close > the subflow. We could add to this RST packet a new MP_TCPRST option > indicating that the server could not match the received token with an > existing connection. Upon reception of a RST carrying this option, the > client would know that the corresponding connection has been closed by > the server and would close it itself. > > We believe that this approach is simpler on the server side while still > allowing clients to detect closed Multipath TCP connections. The abrupt > closing (e.g. socket option SO_LINGER with zero timeout) is also > properly implemented. In contrast with the current approach, it places > the burden on the client instead of on the server, but we believe this > is beneficial for servers that often need to abruptly close connections. > > > Fran=C3=A7ois > > -- > > ------------------------------ > DISCLAIMER. > This email and any files transmitted with it are confidential and intende= d > solely for the use of the individual or entity to whom they are addressed= . > If you have received this email in error please notify the system manager= . > This message contains confidential information and is intended only for t= he > individual named. If you are not the named addressee you should not > disseminate, distribute or copy this e-mail. Please notify the sender > immediately by e-mail if you have received this e-mail by mistake and > delete this e-mail from your system. If you are not the intended recipien= t > you are notified that disclosing, copying, distributing or taking any > action in reliance on the contents of this information is strictly > prohibited. > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Fri Sep 15 01:25:54 2017 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6CE8213306B for ; Fri, 15 Sep 2017 01:25:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tessares-net.20150623.gappssmtp.com 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 sqJ6AL1DIX-7 for ; Fri, 15 Sep 2017 01:25:51 -0700 (PDT) Received: from mail-wm0-x230.google.com (mail-wm0-x230.google.com [IPv6:2a00:1450:400c:c09::230]) (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 9A2D71201F8 for ; Fri, 15 Sep 2017 01:25:51 -0700 (PDT) Received: by mail-wm0-x230.google.com with SMTP id v142so6208424wmv.5 for ; Fri, 15 Sep 2017 01:25:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=ViVKKNZnr3IthyDJQj0qTDaZNndJyuwmS2UTCx895r8=; b=Iw6rUPt4HToTKrOZT6GwQwhfhFulxM/G16YM1NBptbXmQGgz2tOeAOSLIXo2tsfze/ 5VjGn/MTgZBd1eSDCgEUQzYMI+HKg8wewmS3W0PlyO/lWf0mCrrXeIKn5MbdtKsmKme8 2slIdx+7ofD4feZOWGN9uWHUTc0LEoCsrRwq6+MCKET56eRVkl1uENpX1TPGem0UK2gv CpmKs5X3uNh+/5dWpxOGEjFeaP4x+FGFE+7GYlXpqeVd1NhovzTzFCQggoISwydZlRNq 5H0Z65GRngL9ftIGh4k9XdfLn+X5PmALDubb/UCBvofZY3QfoDXudqro2p6GCPQ6QSCq p9AA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=ViVKKNZnr3IthyDJQj0qTDaZNndJyuwmS2UTCx895r8=; b=V3UhjR9TX4UwNlQIuJJUzq2XooXUJCRkRNF4Ia7whg5+KzCW+ZbzNgP0UiGH/lJct+ ky6iII0cl8UdCPmeIt7/kaUYapdGlPI+AziJSGhlbtxt+21af5V9nl83nPtYKtEs2ScM U/YgTE/KEb7X3mveuAWhVaz3DWWstSsN8T5Ymj/5bE2OhJAUml+rLXZGlxZI5K7cYuyP FAkvuEQbdvk6kiy9BYriAoe5OwsjketOV59B9Ek1cWMq8c6mxWtetH2D8PAQrCLKm4wB Sje0TxapUbhbAdl50D0mZofC/BudEv+AhCPQPQOp6DqtsZk2w/eWLvB9A8trYfIfzrdO YQ1A== X-Gm-Message-State: AHPjjUjQXaLsZgyJxUclZPDVFogV531IzKNKezq17TRWGbK0wPwnr4wF iGOAVlp90rpSNNre+LehLxdCd3d+ExKUI+7Fu1Mid1zbMtWpTpj5+GySfHdyL084F8/RHCSqt7a cSCw2 X-Google-Smtp-Source: ADKCNb5U40EiR2aHwV70WIKfRyexkYCSIlMdpM0Xr2rAc9a0PB0mnFzzuS6FACKNRzwbo2TAA8SJRA== X-Received: by 10.80.181.86 with SMTP id z22mr18862986edd.58.1505463949847; Fri, 15 Sep 2017 01:25:49 -0700 (PDT) Received: from mbpobo.local ([5.149.142.22]) by smtp.gmail.com with ESMTPSA id j5sm307672edd.54.2017.09.15.01.25.48 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Sep 2017 01:25:49 -0700 (PDT) To: Yoshifumi Nishida , =?UTF-8?Q?Fran=c3=a7ois_Finfe?= Cc: multipathtcp References: From: Olivier Bonaventure Message-ID: Date: Fri, 15 Sep 2017 10:25:49 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Language: fr-classic Archived-At: Subject: Re: [multipathtcp] Multipath TCP FAST_CLOSE - abrupt closing X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 08:25:53 -0000 Hi Yoshifumi, > > This is an interesting proposal for the bis draft. But, I guess the > receiver of FAST_CLOSE (will be clients in most cases) may need to > wait longer time in some cases. > > I am thinking that the main motivation of SO_LINGER with zero timeout > approach is to avoid going into time_wait. I totally agree > I think MPTCP's FAST_CLOSE already takes care of this point to some > extent and senders don't go into M_TIMEWAIT, although it requires at > least 1 RTT. This requires one RTT when there are no packet losses. Unfortunately, with mobile nodes, there is no guarantee that the ACK packet sent with the FAST_CLOSE option will reach the client. If this packet is lost, the server needs to wait for the expiration of its timer to retransmit the ACK with the FAST_CLOSE option. This ACK could again be lost as well... > So, I am still not very sure if we should save this 1 RTT or should > avoid unfortunate cases for long waiting. The issue if when there is no reply to the ACK sent by the server. This forces the server to maintain state for a potentially long duration to retransmit the ACK with FAST_CLOSE. Francois' proposal avoids this and forces the client to retransmit a SYN later to verify that the connection does not exist anymore. When there are no packet losses, the client is informed immediately with the RST that includes FAST_CLOSE. Olivier -- ------------------------------ DISCLAIMER. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From nobody Fri Sep 15 12:55:41 2017 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B810F133207 for ; Fri, 15 Sep 2017 12:55:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.199 X-Spam-Level: X-Spam-Status: No, score=-4.199 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=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 sw7xFfrVQMPG for ; Fri, 15 Sep 2017 12:55:37 -0700 (PDT) Received: from lnx500.hrz.tu-darmstadt.de (mailout.hrz.tu-darmstadt.de [130.83.156.225]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D95531331F5 for ; Fri, 15 Sep 2017 12:55:36 -0700 (PDT) Received: from paris2.dvs.informatik.tu-darmstadt.de (paris2.dvs.informatik.tu-darmstadt.de [130.83.166.130]) by lnx500.hrz.tu-darmstadt.de (8.14.4/8.14.4/HRZ/PMX) with ESMTP id v8FJqwS6024891; Fri, 15 Sep 2017 21:52:58 +0200 (envelope-from froemmge@dvs.tu-darmstadt.de) Received: from DESKTOPJEETH19 (203-137-067-156.ip-addr.inexio.net [156.67.137.203]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by paris2.dvs.informatik.tu-darmstadt.de (Postfix) with ESMTPSA id 7884D841460; Fri, 15 Sep 2017 21:55:30 +0200 (CEST) From: =?utf-8?Q?Alexander_Fr=C3=B6mmgen?= To: , References: <150481695959.7958.3408667118577609439.idtracker@ietfa.amsl.com> In-Reply-To: Date: Fri, 15 Sep 2017 21:55:30 +0200 Message-ID: <023b01d32e5c$957e07d0$c07a1770$@dvs.tu-darmstadt.de> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJfTjmKlACNNDNv6oUPoYm22Nc+KgLglBTIoYcT+YA= Content-Language: de X-PMX-TU: seen v1.2 by 5.6.1.2065439, Antispam-Engine: 2.7.2.376379, Antispam-Data: 2017.9.15.195116 X-PMX-RELAY: outgoing Archived-At: Subject: Re: [multipathtcp] FW: [Recentattendees] IETF 100 Hackathon and Code Sprint Registrations Open! X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Sep 2017 19:55:40 -0000 Hello, we recently developed ProgMP (https://progmp.net), a domain specific = programming language for Multipath TCP scheduling to foster rapid = development, evaluation and deployment of Multipath TCP schedulers. = ProgMP enables a convenient specification of a wide range of Multipath = TCP schedulers, e.g., to consider subflow preferences (only use LTE if = WiFi RTT is above a certain threshold, only use LTE if WiFi throughput = is below a certain threshold) and to use application hints (use = redundancy for certain packets, use redundancy at the informed end of = the flow, use different scheduling strategies for different parts of = HTTP traffic...). I think a Hackathon session would be a great opportunity to illustrate, = discuss and evaluate the expressiveness and usefulness of ProgMP with = the community.=20 Is anybody interested in a MPTCP / ProgMP hackathon? Regards, Alexander --=20 ___________________________________________________________ Alexander Fr=C3=B6mmgen, M.Sc. Multimedia Communications Lab (KOM) http://www.kom.tu-darmstadt.de Technische Universitaet Darmstadt Dept. of Electrical Engineering & Information Technology tel: +49 6151 16 20857=20 E-Mail: alexander.froemmgen@kom.tu-darmstadt.de postal address: TU Darmstadt, FB 18, KOM, Rundeturmstr. 10, D-64283 Darmstadt, Germany location: S3|20 216 -----Urspr=C3=BCngliche Nachricht----- Von: multipathtcp [mailto:multipathtcp-bounces@ietf.org] Im Auftrag von = philip.eardley@bt.com Gesendet: Montag, 11. September 2017 10:12 An: multipathtcp@ietf.org Betreff: [multipathtcp] FW: [Recentattendees] IETF 100 Hackathon and = Code Sprint Registrations Open! Any interest in joining the hackathon this time? -----Original Message----- From: Recentattendees [mailto:recentattendees-bounces@ietf.org] On = Behalf Of IETF Secretariat Sent: 07 September 2017 21:43 To: IETF Announcement List Cc: 100all@ietf.org; recentattendees@ietf.org; ietf@ietf.org Subject: [Recentattendees] IETF 100 Hackathon and Code Sprint = Registrations Open! IETF 100=20 Singapore November 11-17, 2017 Host: Cisco IETF 100 Information: https://ietf.org/meeting/100/index.html Register online at: https://ietf.org/meeting/register.html Hotel Information: http://www.ietf.org/meeting/100/hotel.html 1. Code Sprint=09 The IETF 100 Code Sprint in Singapore will, as always, let you work on fixing those things about the datatracker which you most urgently desire to do something about. When: Saturday, November 11 from 09:30 to 18:00 Where: Raffles City Convention Center, Room TBD Signup: = https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF100SprintSignUp More information: = https://trac.tools.ietf.org/tools/ietfdb/wiki/IETF100Sprint 2. Hackathon =09 The IETF is holding a Hackathon at IETF 100 to encourage developers to discuss, collaborate and develop utilities, ideas, sample code and solutions that show practical implementations of IETF standards. When: Saturday November 11 and Sunday November 12 Where: Raffles City Convention Center, Room TBD Signup: = https://www.ietf.org/registration/ietf100/hackathonregistration.py More information: http://ietf.org/hackathon/100-hackathon.html=20 Keep up to date by subscribing to: = https://www.ietf.org/mailman/listinfo/hackathon The Hackathon is free to attend and open to all. Extend the invitation to colleagues outside the IETF! Descriptions and information regarding the technologies for the hackathon are located on the IETF 100 Meeting Wiki: https://www.ietf.org/registration/MeetingWiki/wiki/100hackathon Don=E2=80=99t see anything that interests you? Feel free to add your preferred technology to the list, sign up as its Champion and show up to work on it. Note: you must login to the wiki to add content. If you do add a new technology, we strongly suggest that you send an email to hackathon@ietf.org to let others know. You may generate interest in your technology, and find other people who want to contribute to it. To request a wiki account, please click on the =E2=80=9Clogin=E2=80=9D button on the bottom right corner of the page, and choose =E2=80=9Cregister.=E2=80=9D If you need a new password please click on = the =E2=80=9Clogin=E2=80=9D button on the bottom right corner of the page = and choose =E2=80=9CSend new password.=E2=80=9D Important Dates: https://ietf.org/meeting/important-dates.html#ietf100 65 days until IETF 100! _______________________________________________ Recentattendees mailing list Recentattendees@ietf.org https://www.ietf.org/mailman/listinfo/recentattendees _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Sat Sep 16 11:54:30 2017 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F6A81326F3 for ; Sat, 16 Sep 2017 11:54:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 FaVwf7ZvSWP7 for ; Sat, 16 Sep 2017 11:54:15 -0700 (PDT) Received: from mail-qt0-x236.google.com (mail-qt0-x236.google.com [IPv6:2607:f8b0:400d:c0d::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 560E0133048 for ; Sat, 16 Sep 2017 11:54:13 -0700 (PDT) Received: by mail-qt0-x236.google.com with SMTP id m35so4664351qte.1 for ; Sat, 16 Sep 2017 11:54:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=MiWA1Lpc4m3x7BWeskfkPqELF/c9Isl3YW+Qpq1wV+8=; b=bsDitQMQvtmFpY5rSGc0Sdta/PvoTLQagfTBuFfpZUfifcPtPyNrPVE8apjaUPMwNu EgBOtB3cTnoVm+zNabgpT7FZscQCjJdx9JjORR1IXsXJhxtBHVGV/vncCxDPsR678Ye8 RamXNMm/MQFXNbEGmETJEB5YtqmJW+IDA9MSIHYMIGmek8N550SGNUDM4eKLPaTK+hh1 d5KO7nDw8enkfPH0a2u37FFdHwLwHxepzo+X8cliAKosE2o4qaYiyUHMhgRIkB/iaCQM VLEIC81TG/qNe8JYAmlG/KYdH763G3iJLGncWn+LOU4EXrJoOP4uSHUUNg5CogO+GPX9 tmMg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=MiWA1Lpc4m3x7BWeskfkPqELF/c9Isl3YW+Qpq1wV+8=; b=YtOPbX7KF5lQf6CCIiWyZQ/qFM3AlGDYzTz6hMmdVkNBO25Ewmi8Q3NQTvBY6nBOgI Llpq41MfBr/9Vq0VcWBnLGmgHRZR/WpltR2ybULq44B7vh/u8oQVJ09YAezA6slao0Zi Rkih84TnORRwp5Y1WSRMgVpa0a00p0gJ2Kq5RxsBLFUcDVdLdhis79ZLSiPdpfGZ6Vem bOow/yGSiwNwKucCubldOH0JIaGg39iwH0ow8MXqSwDVpB8xJD93BgKLhb5JBhq86Gnb XCXbdwL6NHgsAs0hPedBsJ+4Xte1YQ5fsmjOjIKFMUxfdwCYAft8dYdIfKITLN6bcc3Q Rgtg== X-Gm-Message-State: AHPjjUi62Jy/HfcqrqzoMG+vllJmPicGFSa3iQjfd6JAin88aSSdT2I+ 7wxJQQQ37lAYXdsf2Rdk/ehSoSmxx9O4B3o+TcLIcg== X-Google-Smtp-Source: AOwi7QB1KGyh98Y0rNEGVR+WVHKGYBKvSTje2B64qaHdcf2Ob2kJA3BSRUeJgFpAhoUMLX0g1P6UQSi8VOqJ4zb0DDU= X-Received: by 10.200.43.140 with SMTP id m12mr23128316qtm.58.1505588052155; Sat, 16 Sep 2017 11:54:12 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.61.196 with HTTP; Sat, 16 Sep 2017 11:54:11 -0700 (PDT) In-Reply-To: <2efd30edab0647dda78246734f89a3f1@rew09926dag03b.domain1.systemhost.net> References: <2efd30edab0647dda78246734f89a3f1@rew09926dag03b.domain1.systemhost.net> From: Tom Herbert Date: Sat, 16 Sep 2017 11:54:11 -0700 Message-ID: To: philip.eardley@bt.com Cc: multipathtcp@ietf.org, tcpm@ietf.org, tsv-area@ietf.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [multipathtcp] Progressing the MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 16 Sep 2017 18:54:17 -0000 On Wed, Sep 13, 2017 at 8:01 AM, wrote: > Hi, > > At the IETF we discussed (in MPTCP WG) a new proposal on MPTCP proxy, =E2= =80=9C0-RTT > TCP converters=E2=80=9D > https://tools.ietf.org/html/draft-bonaventure-mptcp-converters This seem= ed > to get a good reception, and had taken on board the feedback about the > =E2=80=9Cplain mode=E2=80=9D draft. > > We believe the next steps are: > > =E2=80=A2 WGs =E2=80=93 TCPM & MPTCP - please send any furthe= r initial comments, > especially if you believe it hasn=E2=80=99t dealt with technical concerns= that were > raised about the =E2=80=9Cplain mode=E2=80=9D draft, or if you have fresh= concerns > Hello, I have some concerns about both the motivation and solution described in the draft. The primary motivation stated for this protocol seems to be that "deploying those extensions on both a wide range of clients and servers remains difficult". That's a pretty general and subjective rationalization. The argument that things take too long to deploy can be applied to nearly any protocol; for instance, a similar argument was recently given in 6man to justify the need for IPv10 since IPv6 is taking too long to deploy. The typical problems with this argument are three fold: 1) it presumes that development and deployment of an interim solution will take less time than to deploy the protocol being fixed 2) it doesn't address the root cause of why a protocol is taking long to deploy in the first place 3) the interim solution likely creates new problems and incompatibilities that need to be dealt with. For this draft I think these should be considered in the specific context of MPTCP. For #1 the assumption, the key assertion in the draft is "There are some situations where the transport stack used on clients (resp. servers) can be upgraded at a faster pace than the transport stack running on servers (resp. clients)."-- I think the reality of this is quite debatable. Major content provider providers that make up the bulk Internet traffic, such as Google and Facebook, upgrade their front end web server software at a much faster rate than clients typically do. There a good examples, TFO for instance, where there was support for new TCP features on servers long before clients. The other part of this is that the solution assumes client support of MPTCP. AFAIK Android (which represents a huge number of clients) does not ship with an MPTCP implementation even though its been part of IOS since 2013. So, the real question that should be asked is why isn't MPTCP being deployed which leads to problem #2. I suspect a major reason that MPTCP is not deployed in Android or servers is that fact that upstream Linux has not adopted the implementation. There was an effort a while back to get it into the stack, however there was pushback because of the invasiveness of the code (it was 1000's of lines of core TCP code change). Unfortunately, the developers didn't followup and continue working on reducing the complexity of implementation. I think with enough persistence in addressing the feedback the code would eventually make it in. Even so, acceptance into Linux is not a requirement for deployment. Google and Facebook could be running MPTCP on their servers, and Android could shipped with MPTCP support. I suspect the reason they're not doing that is motivation. If they were convinced that MPTCP is a great value to users, they can make deployment happen quickly. For #3, the problems of the interim solution need to be elaborated. TCP is an end to end protocol, and we know that whenever a middlebox attempts to transparently process TCP some things will break. As section 5 states "The Converter protocol was designed to be used in networks that do not contain middleboxes that interfere with TCP." -- the irony of this statement is that the converter itself becomes a middlebox that interferes with TCP. The converter has many of the same issues of other middlebox solutions (proxies, firewalls) in the network that are invasive at the transport layer. For instance E2E security (e.g. TCP-AO) is likely broken. Also, I have to wonder about the case where the client and server support an option that is unknown to the converter-- say for instance that an experimental option is being used for a new feature such as we did with TFO. In this case I don't see how the converter can deal with the option, passing it through between MPTCP and non-MPTCP may or may not be correct. So probably the only reasonable behavior is to drop unknown options. But, then that means the endpoints would be bound to using only TCP options that the converter supports, so ultimately the converter is an obstacle not a facilitator for deploying new options. Perhaps the biggest irony of this proposal is that the converter is stateful for a connection, so all packets must flow through a single point in the network. Like stateful firewalls, this inevitably becomes a bottleneck and a single point of failure. I believe that is nearly the exact opposite of what MPTCP endeavors to provide. A few comments about the text: In several places the term "TCP extensions" is used, I think "TCP options" is the more correct term. In Section 2.1: The arguments that SOCKS can't be used are not entirely convincing to me. "the converter protocol leverages the TFO option [RFC7413] to place all its control information inside the SYN and SYN+ACK packets." I'm not sure what "control information" means here. Is this referring to TCP options, an inband control protocol, or something else? It seems to me that support for SOCKS to use TFO should be straightforward, in fact the draft even states that has been proposed for SOCKS. "A second difference is that the converter protocol takes the TCP extensions explicitly into account." Per #3 above, the converter can only take into account TCP options that it understands and it can't deal with options like TCP-AO that must be truly end to end. Given these limitations, and the fact that a SOCKS should be running on an modern TCP stack that supports all the common options, I'm not sure how much tangible value there is in this difference. The third argument may have merit, but I would point out that this difference applies to all proxies and they are ubiquitous in deployment. Also, we are adding kProxy (in kernel proxy) for the Linux stack which actually would allow SYN forwarding in proxies without finishing client side connection establishment to give the same effect of the solution in the draft. Tom From nobody Sun Sep 17 13:25:01 2017 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C20A2133343; Sun, 17 Sep 2017 13:24:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.32 X-Spam-Level: X-Spam-Status: No, score=-4.32 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uclouvain.be 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 QrTZ7dDgK0ut; Sun, 17 Sep 2017 13:24:48 -0700 (PDT) Received: from smtp1.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 21FB6133342; Sun, 17 Sep 2017 13:24:45 -0700 (PDT) Received: from mbpobo.local (host-78-129-6-94.dynamic.voo.be [78.129.6.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp1.sgsi.ucl.ac.be) by smtp1.sgsi.ucl.ac.be (Postfix) with ESMTPSA id B474C67DC38; Sun, 17 Sep 2017 22:24:29 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 smtp1.sgsi.ucl.ac.be B474C67DC38 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1505679870; bh=FfVqVOsKbvTDmVjMw+gxo1B0gwc/DYXC8l+GlA8A9RI=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=H0zi98nTEg2y2+5HHfpu43ZeyQ74jfEXqlZ9UaVbHeA6PASSHzwuKNoFN2IkjZccb Dgkg4lp40p+yn4Wk1rItRSM6bxezjJcWEtVhnP4OvpFKzZjHd1xzE5eO8DnlF9t612 AwjycdxoArhp7Y48XzQsQ1mbiFQ5W6Ahtt3AfHjs= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99.2 at smtp-1 Reply-To: Olivier.Bonaventure@uclouvain.be To: Tom Herbert , philip.eardley@bt.com Cc: multipathtcp@ietf.org, tcpm@ietf.org, tsv-area@ietf.org References: <2efd30edab0647dda78246734f89a3f1@rew09926dag03b.domain1.systemhost.net> From: Olivier Bonaventure Message-ID: <9ae40aa4-2780-a3ce-5b31-bafacf983730@uclouvain.be> Date: Sun, 17 Sep 2017 22:24:29 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr-classic Content-Transfer-Encoding: 7bit X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-Information: X-SGSI-MailScanner-ID: B474C67DC38.A5FD9 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Subject: Re: [multipathtcp] Progressing the MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Sep 2017 20:24:53 -0000 Tom, Thanks for your comments. > For #1 the assumption, the key assertion in the draft is "There are > some situations where the transport stack used on clients (resp. > servers) can be upgraded at a faster pace than the transport stack > running on servers (resp. clients)."-- I think the reality of this is > quite debatable. Major content provider providers that make up the > bulk Internet traffic, such as Google and Facebook, upgrade their > front end web server software at a much faster rate than clients > typically do. Major content providers are one part of the Internet, but not the entire Internet. Many companies are still using old servers running Linux 2.x > There a good examples, TFO for instance, where there was > support for new TCP features on servers long before clients. Looking at TFO servers for example, a recent paper showed that TFO is enabled on only 0.1% of the web sites https://irtf.org/anrw/2017/anrw17-final16.pdf and 80% of these sites are part of Google's AS. > The other > part of this is that the solution assumes client support of MPTCP. > AFAIK Android (which represents a huge number of clients) does not > ship with an MPTCP implementation even though its been part of IOS > since 2013. So, the real question that should be asked is why isn't > MPTCP being deployed which leads to problem #2. In Korea, Samsung and LG have deployed MPTCP on various types of Android smartphones. > I suspect a major reason that MPTCP is not deployed in Android or > servers is that fact that upstream Linux has not adopted the > implementation. There was an effort a while back to get it into the > stack, however there was pushback because of the invasiveness of the > code (it was 1000's of lines of core TCP code change). Unfortunately, > the developers didn't followup and continue working on reducing the > complexity of implementation. I think with enough persistence in > addressing the feedback the code would eventually make it in. I agree, there is engineering effort to bring MPTCP in the mainline Linux kernel, but this is outside the scope of IETF. > Even so, > acceptance into Linux is not a requirement for deployment. Google and > Facebook could be running MPTCP on their servers, and Android could > shipped with MPTCP support. I suspect the reason they're not doing > that is motivation. If they were convinced that MPTCP is a great value > to users, they can make deployment happen quickly. Apple is using MPTCP on both their clients and their servers. Starting with iOS11, all applications will be able to use MPTCP. This is a reasonable deployment AFAIK. Korea is another example. > > For #3, the problems of the interim solution need to be elaborated. > TCP is an end to end protocol, and we know that whenever a middlebox > attempts to transparently process TCP some things will break. As > section 5 states "The Converter protocol was designed to be used in > networks that do not contain middleboxes that interfere with TCP." -- > the irony of this statement is that the converter itself becomes a > middlebox that interferes with TCP. The converter has many of the same > issues of other middlebox solutions (proxies, firewalls) in the > network that are invasive at the transport layer. Agreed, but note that the converter was designed to enable the client to detect when the server supports the required extension (e.g. MPTCP) so that it can stop using the converter to reach this particular server. This means that as a particular extension gets deployed, the utilisation of the converter will diminish. > For instance E2E > security (e.g. TCP-AO) is likely broken. If a client requests TCP-AO, then it's clear that this TCP connection should not go through a converter. > Also, I have to wonder about > the case where the client and server support an option that is unknown > to the converter-- say for instance that an experimental option is > being used for a new feature such as we did with TFO. In this case I > don't see how the converter can deal with the option, passing it > through between MPTCP and non-MPTCP may or may not be correct. So > probably the only reasonable behavior is to drop unknown options. The client can detect which options are supported by the converter. If the client wants to use an option that is not supported by a specific converter, it should not use this particular converter. > But, > then that means the endpoints would be bound to using only TCP options > that the converter supports, so ultimately the converter is an > obstacle not a facilitator for deploying new options. No because the client can decide to not use the converter. > Perhaps the > biggest irony of this proposal is that the converter is stateful for a > connection, so all packets must flow through a single point in the > network. Like stateful firewalls, this inevitably becomes a bottleneck > and a single point of failure. This is a drawback of using a converter, but one needs to compare this drawback with the benefits of using the option on a part of the end-to-end path. > I believe that is nearly the exact > opposite of what MPTCP endeavors to provide. It depends where the converter is located. If you consider a smartphone use case, a converter placed in an ISP backbone could enable its users to combine WiFi and 4G to reach any server with MPTCP. There is a real benefit in doing this as shown by the deployments in Korea, Turkey or Thailand. Hybrid access networks that combine xDSL and LTE are another example where the client benefits from combining different networks with MPTCP. > A few comments about the text: > > In several places the term "TCP extensions" is used, I think "TCP > options" is the more correct term. Thanks, I will reread the document again to catch those. > In Section 2.1: > > The arguments that SOCKS can't be used are not entirely convincing to me. > > "the converter protocol leverages the TFO option [RFC7413] to place > all its control information inside the SYN and SYN+ACK packets." > > I'm not sure what "control information" means here. Is this referring > to TCP options, an inband control protocol, or something else? This relates to the TLV messages of the converter protocol. > > It seems to me that support for SOCKS to use TFO should be > straightforward, in fact the draft even states that has been proposed > for SOCKS. > > "A second difference is that the converter protocol takes the TCP > extensions explicitly into account." > > Per #3 above, the converter can only take into account TCP options > that it understands and it can't deal with options like TCP-AO that > must be truly end to end. Given these limitations, and the fact that a > SOCKS should be running on an modern TCP stack that supports all the > common options, I'm not sure how much tangible value there is in this > difference. The converter enables the client to detect which options are supported by the final server so that the client can bypass the converter if the server supports the required options. > > The third argument may have merit, but I would point out that this > difference applies to all proxies and they are ubiquitous in > deployment. Also, we are adding kProxy (in kernel proxy) for the Linux > stack which actually would allow SYN forwarding in proxies without > finishing client side connection establishment to give the same effect > of the solution in the draft. Excellent Thanks Olivier From nobody Sun Sep 17 19:05:20 2017 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E765713234B for ; Sun, 17 Sep 2017 19:05:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 4ZAM7D4uO1yz for ; Sun, 17 Sep 2017 19:05:16 -0700 (PDT) Received: from mail-qk0-x22f.google.com (mail-qk0-x22f.google.com [IPv6:2607:f8b0:400d:c09::22f]) (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 61DC113232C for ; Sun, 17 Sep 2017 19:05:16 -0700 (PDT) Received: by mail-qk0-x22f.google.com with SMTP id o77so6074266qke.9 for ; Sun, 17 Sep 2017 19:05:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vPxj2YVDMLdfgEWtS/Ugo2b4QIPlD7eaTPr6/Myu7AE=; b=DSrBV5xdlGgOcb48sgvdwX6y+ff5PnOjU0mkzbbyZU8a+Fv3FbGJbbTk7MsztjQ/by /iQbLz9prSpGDSmSqimkvJZKAYBFjrzYbE4/XP/7ETJ7HsjwIA5rFJHGBZIdso55xO5G x480VK+Iaopv+nh5EzMQtPlyZ4QvwnhXu6IPX5+ka+HwSK85S+8GZo8puCTSw46UDXtL 4csHuX9xrtqCjnDT1xpye80RxBSByJa4NTWmPDK1sFR1ea9gjZSAlqF2sZrxXsTkBNzJ khak+TNd9p3hkMdgGVnjo70bZGfyv/0bBh74RKWiYsARh0GmWNjwAMYYarlPml/P0UTK B4sw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vPxj2YVDMLdfgEWtS/Ugo2b4QIPlD7eaTPr6/Myu7AE=; b=m07ix9D/NHnmrFTj+m07Df7Amq494wH8MMeMUfxaRimFbL8WSWi8lsVHhkom+i/A5l rN5el6sM8+0+SuH5mkzdFVTep0Zg0qoxCMWeX87C1UNbwdqcWSdsj5v2jzicVnhzdCH9 7SDzg1DYXXtAhoi5xGCTBhDO+Z4QIne79rrn7ZEajZP6YoqM0GEiSoAwdZkYdF++0byy TP+Q75fp3L95tnSjpZpz2816Rg4KsgCkBEKmZXwiJAzeXMJBK5dgV/o+6jP/8PySjsrX w10XmfuoMotctDGDPWP+4XlM3LHws8HfxEod4natFCBJrPyM8NBJuZH/uPVJFtASyDkO uPtg== X-Gm-Message-State: AHPjjUiaARE9Yxl8kEkIix0hq4xEV9R2aFjWIg2mBYIebLoWdixOOPyL 4BT2JpmieVE181jwQVs5Dmwcs0s7al2yNddGapWQ8g== X-Google-Smtp-Source: AOwi7QBrg354BKYKqe2yibMaQztH72stdPVnolk2Bdw4dhSzLqhVS/SqoYatVw3kmVX1QcnaoOfcq/4UODRKmG92KN8= X-Received: by 10.55.102.73 with SMTP id a70mr17188922qkc.345.1505700315280; Sun, 17 Sep 2017 19:05:15 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.61.196 with HTTP; Sun, 17 Sep 2017 19:05:14 -0700 (PDT) In-Reply-To: <9ae40aa4-2780-a3ce-5b31-bafacf983730@uclouvain.be> References: <2efd30edab0647dda78246734f89a3f1@rew09926dag03b.domain1.systemhost.net> <9ae40aa4-2780-a3ce-5b31-bafacf983730@uclouvain.be> From: Tom Herbert Date: Sun, 17 Sep 2017 19:05:14 -0700 Message-ID: To: Olivier.Bonaventure@uclouvain.be Cc: philip.eardley@bt.com, multipathtcp@ietf.org, tcpm@ietf.org, tsv-area@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [multipathtcp] Progressing the MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 02:05:19 -0000 On Sun, Sep 17, 2017 at 1:24 PM, Olivier Bonaventure wrote: > Tom, > > Thanks for your comments. > >> For #1 the assumption, the key assertion in the draft is "There are >> some situations where the transport stack used on clients (resp. >> servers) can be upgraded at a faster pace than the transport stack >> running on servers (resp. clients)."-- I think the reality of this is >> quite debatable. Major content provider providers that make up the >> bulk Internet traffic, such as Google and Facebook, upgrade their >> front end web server software at a much faster rate than clients >> typically do. > > > Major content providers are one part of the Internet, but not the entire > Internet. Many companies are still using old servers running Linux 2.x > >> There a good examples, TFO for instance, where there was >> support for new TCP features on servers long before clients. > > > Looking at TFO servers for example, a recent paper showed that TFO is > enabled on only 0.1% of the web sites > > https://irtf.org/anrw/2017/anrw17-final16.pdf > > and 80% of these sites are part of Google's AS. > >> The other >> part of this is that the solution assumes client support of MPTCP. >> AFAIK Android (which represents a huge number of clients) does not >> ship with an MPTCP implementation even though its been part of IOS >> since 2013. So, the real question that should be asked is why isn't >> MPTCP being deployed which leads to problem #2. > > > In Korea, Samsung and LG have deployed MPTCP on various types of Android > smartphones. > >> I suspect a major reason that MPTCP is not deployed in Android or >> servers is that fact that upstream Linux has not adopted the >> implementation. There was an effort a while back to get it into the >> stack, however there was pushback because of the invasiveness of the >> code (it was 1000's of lines of core TCP code change). Unfortunately, >> the developers didn't followup and continue working on reducing the >> complexity of implementation. I think with enough persistence in >> addressing the feedback the code would eventually make it in. > > > I agree, there is engineering effort to bring MPTCP in the mainline Linux > kernel, but this is outside the scope of IETF. > Oliver, I disagree, discussions about deployment and implementation are in scope. The primary argument for necessity that this draft makes is that MPTCP is being deployed too slowly. If we are to consider that argument then we need to understand _why_ deployment of MPTCP is slow, so the details about current deployment state and implementation are pertinent. Also, while there is significant engineering needed to get MPTCP into Linux or other systems, we cannot ignore the significant (possibly more) engineering effort to define, standardize, develop and deploy an interim solution on clients and converters. In the end, if the problem can be solved without creating a new complex and invasive protocol that is the better path forward. Tom >> Even so, >> acceptance into Linux is not a requirement for deployment. Google and >> Facebook could be running MPTCP on their servers, and Android could >> shipped with MPTCP support. I suspect the reason they're not doing >> that is motivation. If they were convinced that MPTCP is a great value >> to users, they can make deployment happen quickly. > > > Apple is using MPTCP on both their clients and their servers. Starting with > iOS11, all applications will be able to use MPTCP. This is a reasonable > deployment AFAIK. Korea is another example. >> >> >> For #3, the problems of the interim solution need to be elaborated. >> TCP is an end to end protocol, and we know that whenever a middlebox >> attempts to transparently process TCP some things will break. As >> section 5 states "The Converter protocol was designed to be used in >> networks that do not contain middleboxes that interfere with TCP." -- >> the irony of this statement is that the converter itself becomes a >> middlebox that interferes with TCP. The converter has many of the same >> issues of other middlebox solutions (proxies, firewalls) in the >> network that are invasive at the transport layer. > > > Agreed, but note that the converter was designed to enable the client to > detect when the server supports the required extension (e.g. MPTCP) so that > it can stop using the converter to reach this particular server. This means > that as a particular extension gets deployed, the utilisation of the > converter will diminish. > >> For instance E2E >> security (e.g. TCP-AO) is likely broken. > > > If a client requests TCP-AO, then it's clear that this TCP connection should > not go through a converter. > >> Also, I have to wonder about >> the case where the client and server support an option that is unknown >> to the converter-- say for instance that an experimental option is >> being used for a new feature such as we did with TFO. In this case I >> don't see how the converter can deal with the option, passing it >> through between MPTCP and non-MPTCP may or may not be correct. So >> probably the only reasonable behavior is to drop unknown options. > > > The client can detect which options are supported by the converter. If the > client wants to use an option that is not supported by a specific converter, > it should not use this particular converter. > >> But, >> then that means the endpoints would be bound to using only TCP options >> that the converter supports, so ultimately the converter is an >> obstacle not a facilitator for deploying new options. > > > No because the client can decide to not use the converter. > >> Perhaps the >> biggest irony of this proposal is that the converter is stateful for a >> connection, so all packets must flow through a single point in the >> network. Like stateful firewalls, this inevitably becomes a bottleneck >> and a single point of failure. > > > This is a drawback of using a converter, but one needs to compare this > drawback with the benefits of using the option on a part of the end-to-end > path. > >> I believe that is nearly the exact >> opposite of what MPTCP endeavors to provide. > > > It depends where the converter is located. If you consider a smartphone use > case, a converter placed in an ISP backbone could enable its users to > combine WiFi and 4G to reach any server with MPTCP. There is a real benefit > in doing this as shown by the deployments in Korea, Turkey or Thailand. > Hybrid access networks that combine xDSL and LTE are another example where > the client benefits from combining different networks with MPTCP. > >> A few comments about the text: >> >> In several places the term "TCP extensions" is used, I think "TCP >> options" is the more correct term. > > > Thanks, I will reread the document again to catch those. > >> In Section 2.1: >> >> The arguments that SOCKS can't be used are not entirely convincing to me. >> >> "the converter protocol leverages the TFO option [RFC7413] to place >> all its control information inside the SYN and SYN+ACK packets." >> >> I'm not sure what "control information" means here. Is this referring >> to TCP options, an inband control protocol, or something else? > > > This relates to the TLV messages of the converter protocol. >> >> >> It seems to me that support for SOCKS to use TFO should be >> straightforward, in fact the draft even states that has been proposed >> for SOCKS. >> >> "A second difference is that the converter protocol takes the TCP >> extensions explicitly into account." >> >> Per #3 above, the converter can only take into account TCP options >> that it understands and it can't deal with options like TCP-AO that >> must be truly end to end. Given these limitations, and the fact that a >> SOCKS should be running on an modern TCP stack that supports all the >> common options, I'm not sure how much tangible value there is in this >> difference. > > > The converter enables the client to detect which options are supported by > the final server so that the client can bypass the converter if the server > supports the required options. >> >> >> The third argument may have merit, but I would point out that this >> difference applies to all proxies and they are ubiquitous in >> deployment. Also, we are adding kProxy (in kernel proxy) for the Linux >> stack which actually would allow SYN forwarding in proxies without >> finishing client side connection establishment to give the same effect >> of the solution in the draft. > > > Excellent > > > Thanks > > > Olivier > From nobody Sun Sep 17 20:33:34 2017 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 53FF3126B6E; Sun, 17 Sep 2017 20:33:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com 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 OX5DSvsfJfwl; Sun, 17 Sep 2017 20:33:30 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 68B49132930; Sun, 17 Sep 2017 20:33:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=5GQ/xH5qsoL6hZHc0R3cqRm1+oZFh+0eiI5EsNpHVzY=; b=Tol/octz7ybfC+27ui9q+rnnb UjohET9vfKhkCOf3ejPmsta1TLSa5zuSXUIQKoluRUhW9W8zv4EH8q/SgIHqH9XtoK4/4muTJnRnU yPnUxSrMsy6TI9yyUTcRSoTEYYzVuNjlxggiEUzQ5CqlftSYSq3eqieFlIGVoI2JEWJ0ZWrFZrdYT wFozGU2jN5gbJMGuj25HesukUiS5xQnkVlybTrPLAsMWGGx9+Uv6ATSqkge++h7HZhvomjJgHkLYn cOXLYdp12V9AYZjBQuSyrZI6nUOrWNfTyXhC6OnKKQGsn+pyA7SDVr7dPXHXZXaHkErCUTsVAZZT4 NQQznwnWw==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:58546 helo=[192.168.1.189]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1dtmoK-000gNg-8L; Sun, 17 Sep 2017 23:33:28 -0400 To: Tom Herbert , Olivier.Bonaventure@uclouvain.be Cc: multipathtcp@ietf.org, tcpm@ietf.org, tsv-area@ietf.org References: <2efd30edab0647dda78246734f89a3f1@rew09926dag03b.domain1.systemhost.net> <9ae40aa4-2780-a3ce-5b31-bafacf983730@uclouvain.be> From: Joe Touch Message-ID: <32265da4-1694-7aff-6ffc-378bc6265d32@strayalpha.com> Date: Sun, 17 Sep 2017 20:33:26 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------1E58ADB19747459EF73373DD" Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [multipathtcp] [tcpm] Progressing the MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 03:33:32 -0000 This is a multi-part message in MIME format. --------------1E58ADB19747459EF73373DD Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 9/17/2017 7:05 PM, Tom Herbert wrote: >> I agree, there is engineering effort to bring MPTCP in the mainline Linux >> kernel, but this is outside the scope of IETF. >> > Oliver, > > I disagree, discussions about deployment and implementation are in > scope. The primary argument for necessity that this draft makes is > that MPTCP is being deployed too slowly. If we are to consider that > argument then we need to understand _why_ deployment of MPTCP is slow, > so the details about current deployment state and implementation are > pertinent. Also, while there is significant engineering needed to get > MPTCP into Linux or other systems, we cannot ignore the significant > (possibly more) engineering effort to define, standardize, develop and > deploy an interim solution on clients and converters. Additionally, this would leave in place a solution that complicates the design space for MPTCP for the future. That sort of cruft can be difficult to get rid of. > In the end, if > the problem can be solved without creating a new complex and invasive > protocol that is the better path forward. +1. There are no "urgent" problems in the IETF for which short-term solutions are needed, IMO. We need to take the long view of our actions. Joe > > Tom > --------------1E58ADB19747459EF73373DD Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit



On 9/17/2017 7:05 PM, Tom Herbert wrote:
I agree, there is engineering effort to bring MPTCP in the mainline Linux
kernel, but this is outside the scope of IETF.


Oliver,

I disagree, discussions about deployment and implementation are in
scope. The primary argument for necessity that this draft makes is
that MPTCP is being deployed too slowly. If we are to consider that
argument then we need to understand _why_ deployment of MPTCP is slow,
so the details about current deployment state and implementation are
pertinent. Also, while there is significant engineering needed to get
MPTCP into Linux or other systems, we cannot ignore the significant
(possibly more) engineering effort to define, standardize, develop and
deploy an interim solution on clients and converters.
Additionally, this would leave in place a solution that complicates the design space for MPTCP for the future. That sort of cruft can be difficult to get rid of.

In the end, if
the problem can be solved without creating a new complex and invasive
protocol that is the better path forward.
+1.

There are no "urgent" problems in the IETF for which short-term solutions are needed, IMO. We need to take the long view of our actions.

Joe


Tom

--------------1E58ADB19747459EF73373DD-- From nobody Mon Sep 18 02:18:54 2017 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F30631320CF; Mon, 18 Sep 2017 02:18:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uclouvain.be 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 DfAkQHZmXYUK; Mon, 18 Sep 2017 02:18:41 -0700 (PDT) Received: from smtp3.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD018126B6E; Mon, 18 Sep 2017 02:18:40 -0700 (PDT) Received: from mbpobo.local (unknown [130.104.228.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp3.sgsi.ucl.ac.be) by smtp3.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 7775667E0FC; Mon, 18 Sep 2017 11:18:29 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 smtp3.sgsi.ucl.ac.be 7775667E0FC DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1505726309; bh=yw5mVO1ppzR4YueSr3BYCQuPNyQ2EUcUp6AZVbXQ/j8=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=q3vOCPe4DrIVQtyGPQarc9A3LbOyjsjZHDPNJpHHTpcD7PIhMKETkdQQzvUaDYLYT AQBidY+V2Jzav9aaFJc33ysuGE71ef0POFspuRpiNQOvr279RAS9WOGvO3xP+UvDXT Uo5aJePIi4cFDZJcMkf1C6FIFZ4jRolVYGkpZhxQ= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99.2 at smtp-3 Reply-To: Olivier.Bonaventure@uclouvain.be To: Tom Herbert Cc: philip.eardley@bt.com, multipathtcp@ietf.org, tcpm@ietf.org, tsv-area@ietf.org References: <2efd30edab0647dda78246734f89a3f1@rew09926dag03b.domain1.systemhost.net> <9ae40aa4-2780-a3ce-5b31-bafacf983730@uclouvain.be> From: Olivier Bonaventure Message-ID: <0fa089ba-444b-01ec-1eba-83159147b141@uclouvain.be> Date: Mon, 18 Sep 2017 11:18:29 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr-classic Content-Transfer-Encoding: 7bit X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-Information: X-SGSI-MailScanner-ID: 7775667E0FC.A37AD X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Subject: Re: [multipathtcp] Progressing the MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 09:18:43 -0000 Tom, > > I disagree, discussions about deployment and implementation are in > scope. The primary argument for necessity that this draft makes is > that MPTCP is being deployed too slowly. The main argument of the draft is that deployment on client and servers does not go at the same pace. This is the motivation for having a converter. There *is* significant deployement of Multipath TCP today on clients and in some specific use cases. If we ignore the very large providers like Google or Facebook, deployment of new TCP features on servers takes more time. This does not depend only on the availability of a particular feature in the mainline Linux kernel but on many other factors. Server administrators are usually rather conservative and they favor stability and only deploy new features when they are strictly required. Looking at operating systems, they also tend to deploy stable releases that have been well tested and rarely deploy cutting edge features. Table 2 in https://irtf.org/anrw/2017/anrw17-final16.pdf shows that TFO has similar deployment issues than MPTCP. It has been enabled on client devices (Linux, iOS/Macos, soon Windows), but Brian Trammel and his colleagues could only find 578 servers (IP address) in Oct 2016 and 866 in Jan 2017 that negotiated TFO. Most of them where in a single AS. > If we are to consider that > argument then we need to understand _why_ deployment of MPTCP is slow, This is true for any TCP extension. Client and servers migrate at their own pace and it takes many years to deploy any TCP extension. MPTCP is not different from RFC1323, SACK or TFO > so the details about current deployment state and implementation are > pertinent. Also, while there is significant engineering needed to get > MPTCP into Linux or other systems, we cannot ignore the significant > (possibly more) engineering effort to define, standardize, develop and > deploy an interim solution on clients and converters. This cost will be on the devices that will benefit from the extension. The deployment of MPTCP in Korea to bond WiFi and LTE shows that there is a benefit for this type of service. > In the end, if > the problem can be solved without creating a new complex and invasive > protocol that is the better path forward. Olivier From nobody Mon Sep 18 04:59:02 2017 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 46331134239 for ; Mon, 18 Sep 2017 04:59:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tessares-net.20150623.gappssmtp.com 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 Qyi56sQWAsXm for ; Mon, 18 Sep 2017 04:58:57 -0700 (PDT) Received: from mail-wm0-x22d.google.com (mail-wm0-x22d.google.com [IPv6:2a00:1450:400c:c09::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44D0D134288 for ; Mon, 18 Sep 2017 04:58:57 -0700 (PDT) Received: by mail-wm0-x22d.google.com with SMTP id r68so1934380wmg.3 for ; Mon, 18 Sep 2017 04:58:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=from:subject:to:references:cc:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=xe2eVdO1MKqu89JEAZ8NB+cV/SzSfOQwBkofDhUO+Ng=; b=G9gmEKb8i/mZzWT/oaXIRkNZLkJHFrgOgK2oidWWotB7NgEl5fjEnutVmU+oEPcKFV BX9nu9AbSy2l1oGTB1bqD0aeGp0eTeQYFuVoPtsPhq8gJvvQzamdqydMKeHIrNl71CHd PhgvAGtfVJWp4B0iQQKOyr33hPOdLR3/od2KNEDiSrW/+5SZta/Hung8mnATgw2r0zqF jr5CMJSwurqq3qZIUIar4o89nt61TcMCN3KL0jrfI58xGre52CoH5nfq3g660v28F8Bd ArS0y7+aM8cPdHUARYCJCtolfgVVAq3yt/rrgNkQ2ubPTSIjvWkrApds7a3NmnmK/53O fD4Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:cc:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=xe2eVdO1MKqu89JEAZ8NB+cV/SzSfOQwBkofDhUO+Ng=; b=PyXW/a1ZITiJaOHXPn63tEmuVPWtDHmdL98aiVs7Qi5V8E2UDrulTtzHi8ego3xkCo fsGO5xE7yBbO+u7WlyH7hsjvvSCJebQ23On+lNmAkcURtp5IJ4wjFOkrSKwVgGsv72Ju k+gwzbjr0M6RcUXXGk9CX5ILGIGrXAtdl9Lym/RvtAsRUrN5V1BA826BgIDo/TxS5+gB owE7iHAGrYyXo8FzNFOC+kVYVtdQEE589E6j5CJ0lA2Y61ALBB7ZFt5o2TshuHeJcCW8 zoWcMKDiBDTUm6c2a9nnFofzttFZIymssThFFEOVBLhosjLp815DVpVQQty8MFaT56Nr xycA== X-Gm-Message-State: AHPjjUiu5q3vaDxgxx61WUR/ZoWXi3Vmvb1xM5IFndJ/uNzJlDCIsC8e W4HzBTu6q/zOZo5OgzRfygar8OhJj62ygMX6pMTy5N5VI1qSlagHlwJ5G6VuRJOOHZE6p8jW3uP +iC6F X-Google-Smtp-Source: ADKCNb5U5bl5p3Is+/dLdtRHNUi2zIwo6AgeA5jsxhZMCSVT53LMvEolLaZJNfuy3wwhlgpluh5ifQ== X-Received: by 10.80.204.217 with SMTP id b25mr26718214edj.44.1505735935397; Mon, 18 Sep 2017 04:58:55 -0700 (PDT) Received: from [10.3.76.108] ([5.149.142.22]) by smtp.gmail.com with ESMTPSA id s14sm4086155edk.89.2017.09.18.04.58.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Sep 2017 04:58:54 -0700 (PDT) From: =?UTF-8?Q?Fran=c3=a7ois_Finfe?= To: Yoshifumi Nishida References: Cc: multipathtcp , Olivier Bonaventure Message-ID: <804577f3-f2a7-0726-08b3-717abe43f9c8@tessares.net> Date: Mon, 18 Sep 2017 13:58:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="UTF-8" Content-Language: en-US Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [multipathtcp] Multipath TCP FAST_CLOSE - abrupt closing X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 11:59:00 -0000 Hi Yoshi, On 2017-09-15 00:33, Yoshifumi Nishida wrote: > Hi Francois, >=20 > This is an interesting proposal for the bis draft. But, I guess the > receiver of FAST_CLOSE (will be clients in most cases) may need to > wait longer time in some cases. >=20 > I am thinking that the main motivation of SO_LINGER with zero timeout > approach is to avoid going into time_wait. > I think MPTCP's FAST_CLOSE already takes care of this point to some > extent and senders don't go into M_TIMEWAIT, although it requires at > least 1 RTT. > So, I am still not very sure if we should save this 1 RTT or should > avoid unfortunate cases for long waiting. Yes, in most likely cases, it will last 1 RTT. In worst case, with 3 retransmissions and exp. backoff enabled, it will linger 8 RTO's. 1 RTT is relatively very high compared to the time to send an MP_FASTCLOSE. On the current linux MPTCP implementation and on my computer, the time required to fast close a MPTCP connection (send MP_FASTCLOSE and RST's, without taking account the retransmissions or waiting for RST from the other peer) is 1 ms. This time depends of a lot of factor but it is quite small compared to typical values of RTT for DSL/LTE. In the case of the SO_LINGER with zero timeout, the user space will expect that "all queued messages for the socket have been successfully sent or the linger timeout has been reached" and nothing is done on background. By waiting for a RST in response to a MP_FASTCLOSE, it is not possible to match the timing requirement, or it must be done it in the background. Abrupt connection closing can be explicitly set by the user space software explicitly. But, it can be tacitly set as well: - on GNU/Linux, if a process is killed, all the established connection will be abruptly closed. - Other scenarii are when the system is under pressure. In these cases, quickly close a connection is important. >=20 >=20 > BTW, I happened to find that the state transition diagram in the draft > doesn't contain M_FASTCLOSE state, although it is mentioned in Section > 3.5. I don't know why it's not mentioned. Maybe, it is omitted for the sake of clarity, because you can switch from a lot of state (not only established) to closed via fast close. On most TCP state transition diagram, this transition (via a RST instead of a fast close) is not mentioned either. Fran=C3=A7ois > Is this OK? >=20 > Thanks, > -- > Yoshi >=20 >=20 > On Wed, Sep 13, 2017 at 6:39 AM, Fran=C3=A7ois Finfe > wrote: >> Hi, >> >> >> RFC6824 and RFC6824bis use the FAST_CLOSE option to abruptly close a >> Multipath TCP connection. The motivation for the procedure defined in >> section 3.5 is to enable a host to quickly terminate a Multipath TCP >> connection without being forced to send DATA_FINs. >> >> The current procedure defined in section 3.5 is that the host that >> wishes to abruptly terminate a connection must send a RST on all >> subflows except one where it sends an ACK with the FAST_CLOSE option and >> waits for a RST before closing the Multipath TCP connection. The >> FAST_CLOSE option includes the receiver=E2=80=99s key to authenticate th= e abrupt >> release of the subflow. This prevents attacks where a remote attacker >> could send spoofed packets that would terminate the Multipath TCP >> connection. >> >> Unfortunately, the procedure defined in section 3.5 has a very important >> drawback. Although the host wants to abruptly close the Multipath TCP >> connection, it needs to maintain state for this connection until the >> other host has confirmed (with a RST) the termination of the connection. >> This goes against the idea of abruptly closing connections due to lack >> of ressources for example. We have faced some issues with applications >> using SO_LINGER set to zero that were expecting the socket to have >> disappeared after an abrupt release while it did not disappear. >> >> It would make sense to reconsider the abrupt connection termination >> procedure defined in section 3.5 to enable a host to immediately >> terminate a Multipath TCP connection and release the associated data >> structures. One possibility would be to work as follows. >> >> Consider a Multipath TCP connection established between a client and a >> server. There are two subflows, A and B. The server wants to abruptly >> close the connection. For this, we propose to continue to use the >> FAST_CLOSE option, but place it inside the RST packet sent over all >> subflows. By using a RST instead of an ACK as in section 3.5, the server >> does not need to maintain any state and can remove the data structures >> associated with the closed connection immediately. If one of the RST >> packets reaches the client, it will know that the entire connection has >> been closed by the server. >> >> The only issue with this new approach is when none of the RST packets >> sent by the server reach the client. We would be in a situation where >> the client considers that the Multipath TCP is active while it does not >> exist anymore on the server. After some time, the client will send a >> packet to the server over one of the subflows. Since the Multipath TCP >> connection does not exist anymore on the server, it will reply with a >> RST packet that will close this subflow. The client will receive the >> same RST over all the established subflows. When all subflows have been >> closed, the client should try to establish a new subflow to the server >> by sending a SYN with MP_JOIN. Upon reception of this SYN, the server >> will try to match the connection token with the established Multipath >> TCP connection and will find that there is no matching connection. >> According to RFC6824, the server should reply with a RST packet to close >> the subflow. We could add to this RST packet a new MP_TCPRST option >> indicating that the server could not match the received token with an >> existing connection. Upon reception of a RST carrying this option, the >> client would know that the corresponding connection has been closed by >> the server and would close it itself. >> >> We believe that this approach is simpler on the server side while still >> allowing clients to detect closed Multipath TCP connections. The abrupt >> closing (e.g. socket option SO_LINGER with zero timeout) is also >> properly implemented. In contrast with the current approach, it places >> the burden on the client instead of on the server, but we believe this >> is beneficial for servers that often need to abruptly close connections. >> >> >> Fran=C3=A7ois >> >> -- >> >> ------------------------------ >> DISCLAIMER. >> This email and any files transmitted with it are confidential and intend= ed >> solely for the use of the individual or entity to whom they are addresse= d. >> If you have received this email in error please notify the system manage= r. >> This message contains confidential information and is intended only for = the >> individual named. If you are not the named addressee you should not >> disseminate, distribute or copy this e-mail. Please notify the sender >> immediately by e-mail if you have received this e-mail by mistake and >> delete this e-mail from your system. If you are not the intended recipie= nt >> you are notified that disclosing, copying, distributing or taking any >> action in reliance on the contents of this information is strictly >> prohibited. >> >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp --=20 ------------------------------ DISCLAIMER. This email and any files transmitted with it are confidential and intended= =20 solely for the use of the individual or entity to whom they are addressed.= =20 If you have received this email in error please notify the system manager.= =20 This message contains confidential information and is intended only for the= =20 individual named. If you are not the named addressee you should not=20 disseminate, distribute or copy this e-mail. Please notify the sender=20 immediately by e-mail if you have received this e-mail by mistake and=20 delete this e-mail from your system. If you are not the intended recipient= =20 you are notified that disclosing, copying, distributing or taking any=20 action in reliance on the contents of this information is strictly=20 prohibited. From nobody Mon Sep 18 09:22:34 2017 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F0F31320BD for ; Mon, 18 Sep 2017 09:22:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 ryR1g0uJ-_63 for ; Mon, 18 Sep 2017 09:22:22 -0700 (PDT) Received: from mail-qt0-x22c.google.com (mail-qt0-x22c.google.com [IPv6:2607:f8b0:400d:c0d::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D2F9133063 for ; Mon, 18 Sep 2017 09:22:20 -0700 (PDT) Received: by mail-qt0-x22c.google.com with SMTP id b1so1098330qtc.4 for ; Mon, 18 Sep 2017 09:22:20 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=0TGIE0qTFQRODe/wtnq+Qa1EMxGUpK75eMe55i3W94s=; b=RDpxKlkxq95wplzbB22mHLumgbJQSirxwurPlsXCWrFzB9zBxaCrROG5LSstaFALza myV9v8HGqTxtgb/QSskKVed6ImYngaSht4nrAw6OTQk6ebD0yy7yZpfNEbhAaOYCkLKk x571FPcrGb1gidvi9OsnSkmLFcu7XJbNrgiPBz3m1bWyvyZAz5Qw+nL38aUBtfYn/wf8 Q5aW9eYIinrha01gUOOAaZyMhPi16Cf7mm5cFpMENoMpb5Bv+8/oBHR30fbs/XWoL3lM AmdRJXbg+hVBcxrZP8b2Ob2qV4N84UGiDDxYt8umzE/BPU4sS6c4j59xkDEyU7oPGBUe 8d/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=0TGIE0qTFQRODe/wtnq+Qa1EMxGUpK75eMe55i3W94s=; b=PtDmfFYSctiv1pRBxKTVVXtk/sjqa/+iwMGsZhnC9jKPdj2KV02hCOf+sgD8frtr2n dKv2qA1hdIh/FXPlcodNRyhozWLVPhFMFsbXUyZqGBoqD4u4Lkkp31xquP1zOlYolBCx 5Xd4JJ97QGdZPRVnIdYVSWas+KrNMjQZoUP/jE9IeJeKpamHaygECqdqIEHTkX8mCTwJ uWdNUd1+eHFTybzTeEe6HE/rKBykPG3RdVeygCP2p90lonmTUsDyzoDLYp4V1LVCJeZM hFGTh/JZqeTk56eoS6R8kKdjQXexolSfcvnGeyfcjq1P5oj+lV07N81+IkxaLP4p0M5w ux9Q== X-Gm-Message-State: AHPjjUielGUaK0KSErS6gUbIAun8VME+psnmHnXafkZse7dYPCv9ImQP IBmYfNrAhHITmXgVZ9PKeGyTyUD3nhFQqMy+4ktXQQ== X-Google-Smtp-Source: AOwi7QDkXmvpCW+hRbXmJ6X23c57YEDXthQoa9u2qo3ZNcuRYAPLd5rJgMKRJZoLDeXn4IsPF4qx39wWjz+SFRNadYM= X-Received: by 10.237.59.221 with SMTP id s29mr52445750qte.27.1505751739198; Mon, 18 Sep 2017 09:22:19 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.61.196 with HTTP; Mon, 18 Sep 2017 09:22:18 -0700 (PDT) In-Reply-To: <0fa089ba-444b-01ec-1eba-83159147b141@uclouvain.be> References: <2efd30edab0647dda78246734f89a3f1@rew09926dag03b.domain1.systemhost.net> <9ae40aa4-2780-a3ce-5b31-bafacf983730@uclouvain.be> <0fa089ba-444b-01ec-1eba-83159147b141@uclouvain.be> From: Tom Herbert Date: Mon, 18 Sep 2017 09:22:18 -0700 Message-ID: To: Olivier Bonaventure Cc: philip.eardley@bt.com, multipathtcp@ietf.org, tcpm@ietf.org, tsv-area@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [multipathtcp] Progressing the MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 16:22:23 -0000 On Mon, Sep 18, 2017 at 2:18 AM, Olivier Bonaventure wrote: > Tom, >> >> >> I disagree, discussions about deployment and implementation are in >> scope. The primary argument for necessity that this draft makes is >> that MPTCP is being deployed too slowly. > > > The main argument of the draft is that deployment on client and servers does > not go at the same pace. This is the motivation for having a converter. > There *is* significant deployement of Multipath TCP today on clients and in > some specific use cases. > > If we ignore the very large providers like Google or Facebook, deployment of Olivier, Why ignore the large content providers? If you want MPTCP to be a success, these (e.g. FANG) are exactly who you should be engaging. Once they're on board that covers a lot of user experience and others are likely to follow their lead. > new TCP features on servers takes more time. This does not depend only on > the availability of a particular feature in the mainline Linux kernel but on > many other factors. Server administrators are usually rather conservative > and they favor stability and only deploy new features when they are strictly > required. Looking at operating systems, they also tend to deploy stable > releases that have been well tested and rarely deploy cutting edge features. > Table 2 in > > https://irtf.org/anrw/2017/anrw17-final16.pdf > > shows that TFO has similar deployment issues than MPTCP. It has been enabled > on client devices (Linux, iOS/Macos, soon Windows), but Brian Trammel and > his colleagues could only find 578 servers (IP address) in Oct 2016 and 866 > in Jan 2017 that negotiated TFO. Most of them where in a single AS. > That says nothing about MPTCP. I think you're making broad generalizations about deployment based on a few select data points. Not all TCP features take a long time to get significant deployment (e.g., ICW=10, congestion avoidance improvements, retrans. improvements). And more than that, QUIC is entirely new transport protocol that has gotten significant deployment in a relatively short amount of time. The particulars of each protocol or feature need to be considered if a perceived deployment issue is to be addressed. TFO and MPTCP differ in some critical ways. TFO has good kernel support, but the server applications need to be fixed to support it. This dependency makes deployment longer. Also, TFO is a nice feature, but is only relevant at the beginning of a connection, and until zero-RTT TLS gets deployed it is of limited value. MPTCP does not currently have kernel support (i.e. not accepted by Linux), however shouldn't require server application layer changes-- the latter characteristic is an important simplification. This means if there were good kernel support then when the servers are updated (in cycles of 2-3 yrs. for a major content provider) they will get support and the value of MPTCP without additional work or action. Honestly, had the support gotten into Linux fours years ago when that was proposed we probably wouldn't be having this conversation! > >> If we are to consider that >> argument then we need to understand _why_ deployment of MPTCP is slow, > > > This is true for any TCP extension. Client and servers migrate at their own > pace and it takes many years to deploy any TCP extension. MPTCP is not > different from RFC1323, SACK or TFO > As I said above, the deployment and implementation characteristics of all of these is different and need to be considered for each feature. >> so the details about current deployment state and implementation are >> pertinent. Also, while there is significant engineering needed to get >> MPTCP into Linux or other systems, we cannot ignore the significant >> (possibly more) engineering effort to define, standardize, develop and >> deploy an interim solution on clients and converters. > > > This cost will be on the devices that will benefit from the extension. The > deployment of MPTCP in Korea to bond WiFi and LTE shows that there is a > benefit for this type of service. > Please elaborate on the cost of this solution. Specifically, please explain why the cost of doing this interim solution is less than the cost of figuring out how to get servers to support MPTCP. Also, the cost analysis should take into account any negative effects on nodes outside of the devices being touched-- this solution is not transparent to the outside world (similar to how NAT isn't really transparent to end hosts). Thanks, Tom From nobody Mon Sep 18 11:02:19 2017 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0EC761342CB; Mon, 18 Sep 2017 11:02:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uclouvain.be 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 7dgaPLkXtnYi; Mon, 18 Sep 2017 11:02:04 -0700 (PDT) Received: from smtp4.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 851BA133075; Mon, 18 Sep 2017 11:02:04 -0700 (PDT) Received: from mbpobo.local (host-78-129-6-94.dynamic.voo.be [78.129.6.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp4.sgsi.ucl.ac.be) by smtp4.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 87B7A67E075; Mon, 18 Sep 2017 20:01:55 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 smtp4.sgsi.ucl.ac.be 87B7A67E075 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1505757715; bh=GGbl75DEWFNd29ZIHUWPS+uqi9ym9a65T6L/gjl9xm8=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=nMF35AmflWTK4lfjUSEJrrJurmJDuU+yiwoCPdTewS/z8PH6N27uynIU5jELoRvXl GKAAGE2dZ+jsrPgXUqXd5jBnKUzHkf5gZI0/C1Glb7ymR/w9UunLSpDzMP3NiHtQsd 3EMIkzLz1zwKSW/iNK7+vZoQR8HCYnDsJMZ7r1iw= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99.2 at smtp-4 Reply-To: Olivier.Bonaventure@uclouvain.be To: Tom Herbert Cc: philip.eardley@bt.com, multipathtcp@ietf.org, tcpm@ietf.org, tsv-area@ietf.org References: <2efd30edab0647dda78246734f89a3f1@rew09926dag03b.domain1.systemhost.net> <9ae40aa4-2780-a3ce-5b31-bafacf983730@uclouvain.be> <0fa089ba-444b-01ec-1eba-83159147b141@uclouvain.be> From: Olivier Bonaventure Message-ID: Date: Mon, 18 Sep 2017 20:01:55 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr-classic Content-Transfer-Encoding: 7bit X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-Information: X-SGSI-MailScanner-ID: 87B7A67E075.A43D4 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Subject: Re: [multipathtcp] Progressing the MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 18:02:11 -0000 Tom, >>> >>> >>> I disagree, discussions about deployment and implementation are in >>> scope. The primary argument for necessity that this draft makes is >>> that MPTCP is being deployed too slowly. >> >> >> The main argument of the draft is that deployment on client and servers does >> not go at the same pace. This is the motivation for having a converter. >> There *is* significant deployement of Multipath TCP today on clients and in >> some specific use cases. >> >> If we ignore the very large providers like Google or Facebook, deployment of > > Olivier, > > Why ignore the large content providers? If you want MPTCP to be a > success, these (e.g. FANG) are exactly who you should be engaging. I don't ignore them. Apple uses MPTCP on iOS11 for all applications. > Once they're on board that covers a lot of user experience and others > are likely to follow their lead. With the availability of MPTCP on ios11 for any applications, we'll see a growth in usage of MPTCP on iphones. > >> new TCP features on servers takes more time. This does not depend only on >> the availability of a particular feature in the mainline Linux kernel but on >> many other factors. Server administrators are usually rather conservative >> and they favor stability and only deploy new features when they are strictly >> required. Looking at operating systems, they also tend to deploy stable >> releases that have been well tested and rarely deploy cutting edge features. >> Table 2 in >> >> https://irtf.org/anrw/2017/anrw17-final16.pdf >> >> shows that TFO has similar deployment issues than MPTCP. It has been enabled >> on client devices (Linux, iOS/Macos, soon Windows), but Brian Trammel and >> his colleagues could only find 578 servers (IP address) in Oct 2016 and 866 >> in Jan 2017 that negotiated TFO. Most of them where in a single AS. >> > That says nothing about MPTCP. I think you're making broad > generalizations about deployment based on a few select data points. I'm simply showing that the deployment of a recent TCP extension takes time. Another datapoint is https://link.springer.com/chapter/10.1007/978-3-642-20305-3_3 Figure 7 shows the evolution of the negotations of SACK, WSCALE and TIMESTAMP options over a decade of passive measurements. SACK, despite its clear benefits took almost ten years to be widely deployed In 2010, WSCALE and Timestamp were only supported by half of the observed TCP connections. > Not all TCP features take a long time to get significant deployment > (e.g., ICW=10, congestion avoidance improvements, retrans. > improvements). These are features that reside on a single host and do not require cooperation between client and server to be used. > And more than that, QUIC is entirely new transport > protocol that has gotten significant deployment in a relatively short > amount of time. The particulars of each protocol or feature need to be > considered if a perceived deployment issue is to be addressed. QUIC is a different beast. Coming back to TCP, extensions that provide benefits with a change on the sender or the receiver side only are easier to deploy because they provide immediate benefit on the stack that implements them. All the examples that you mention above are in this category. Congestion control algorithms are another example. Extensions that require a negotiation (SACK, WSCALE, TFO, MPTCP, ...) require support on both sender and receiver which takes much more time. I see that as a generic trend looking at the measurement papers that have studied this problem. I'd be interested in any measurement study that shows a new significant TCP option being quickly deployed on both clients and servers. > > TFO and MPTCP differ in some critical ways. TFO has good kernel > support, but the server applications need to be fixed to support it. > This dependency makes deployment longer. Also, TFO is a nice feature, > but is only relevant at the beginning of a connection, and until > zero-RTT TLS gets deployed it is of limited value. MPTCP does not > currently have kernel support The MPTCP patch released on http://www.multipath-tcp.org is well tested and stable. It is used in various deployments. > (i.e. not accepted by Linux), however > shouldn't require server application layer changes-- the latter > characteristic is an important simplification. This means if there > were good kernel support then when the servers are updated (in cycles > of 2-3 yrs. for a major content provider) they will get support and > the value of MPTCP without additional work or action. > Honestly, had > the support gotten into Linux fours years ago when that was proposed > we probably wouldn't be having this conversation! That's another story which mainly depends on the engineering ressources that the core MPTCP developpers could dedicate to refactoring the MPTCP patch to include it in the official Linux kernel. >> >>> If we are to consider that >>> argument then we need to understand _why_ deployment of MPTCP is slow, >> >> >> This is true for any TCP extension. Client and servers migrate at their own >> pace and it takes many years to deploy any TCP extension. MPTCP is not >> different from RFC1323, SACK or TFO >> > As I said above, the deployment and implementation characteristics of > all of these is different and need to be considered for each feature. A key concern is whether the extension must be negotiated during the three-way handshake. If yes, then deployment will be much more difficult than if there is no negotiation. >>> so the details about current deployment state and implementation are >>> pertinent. Also, while there is significant engineering needed to get >>> MPTCP into Linux or other systems, we cannot ignore the significant >>> (possibly more) engineering effort to define, standardize, develop and >>> deploy an interim solution on clients and converters. >> >> >> This cost will be on the devices that will benefit from the extension. The >> deployment of MPTCP in Korea to bond WiFi and LTE shows that there is a >> benefit for this type of service. >> > Please elaborate on the cost of this solution. Specifically, please > explain why the cost of doing this interim solution is less than the > cost of figuring out how to get servers to support MPTCP. There are different actors that have different incentives in the deployment of MPTCP. Let's consider the MPTCP deployment in Korea as an example. Their current solution is roughly to install a SOCKS client on MPTCP-enabled smartphones. Those smartphones interact with an MPTCP-enabled SOCKS server to reach remote servers. From the viewpoint of the enduser, there is a benefit in using MPTCP on her smartphone because she can combine LTE and WiFi to achieve higher bandwidth or have seamless handovers. From the viewpoint of the network operator, this is an added value service that they provide to their customers. If all Internet servers supported MPTCP, they would not have had to deploy and support the SOCKS servers in their network. > Also, the > cost analysis should take into account any negative effects on nodes > outside of the devices being touched-- this solution is not > transparent to the outside world (similar to how NAT isn't really > transparent to end hosts). The negative effect is that the smartphone needs to include MPTCP and the SOCKS client. The SOCKS server is a single-point of failure inside the ISP network. It is not totally transparent since the smartphone needs to be configured with a SOCKS server, but there are clear benefits since this kind of solution is deployed by several ISPs in several countries. Olivier From nobody Mon Sep 18 11:51:51 2017 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1660132D4B for ; Mon, 18 Sep 2017 11:51:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 rOupc8StEjq6 for ; Mon, 18 Sep 2017 11:51:33 -0700 (PDT) Received: from mail-qk0-x235.google.com (mail-qk0-x235.google.com [IPv6:2607:f8b0:400d:c09::235]) (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 58EDD133061 for ; Mon, 18 Sep 2017 11:51:32 -0700 (PDT) Received: by mail-qk0-x235.google.com with SMTP id u7so1465967qku.13 for ; Mon, 18 Sep 2017 11:51:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=rr304Dvz7Q5pHyyiSzK0pmDBS8k5xWkiq8QXUqIXyvc=; b=PI5bLb5dIQ8Aux5Eh//L8UQC9Q9xT8bjJ8IozsDM5sRXfSItdUDt7y38qL0mn0h5iI SjjHz72O5rTJwqJ36M5C/ly6EId2/y2mTwBDssg7x7mnehadv6YhvKJVZxhPJL8MXuNu 343rELnbKznkSgvrxRV2iraJwsEFjUDb5s5QlkkpjLGFH+RmLJDJe/cmmp++sja0iBt9 cImolyrWplzIl9wwdJ7xTjpItf58ANCPhXVCfiAtNigeTXDwufuaJMTg7AatmH+zPaXl BGz6J/XPQ688LXYw+z4DuYSMMgUT8yNm4cWCIgIXKxklyE4xPqdkrgGqInd96L/NWH+S 8LHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=rr304Dvz7Q5pHyyiSzK0pmDBS8k5xWkiq8QXUqIXyvc=; b=Dg+HjdICMbrHMJ+vcS4vtyOvufvd9BzjxlUEKolg0ifiE8slfCDEXXG5WnQwgJF1b4 TqhP2sPEaEYQ4WM3zHa0iLCSP911R/i9Ig53YeQCYOOoE0m5dCBO6qqozpIEzcnecgZJ bGCfLaSxwArxLcET612nwSINlqW+F+S9K3K89JZseUPKmxpfPrkZrBt6eq8QuxUcTcad PCSz0uNQZCbnwhBoeCDkl5j18DkwV4YI6ELKZj9l//focWSmiNoLJhBeiRpFWRh+dipf k3IsFXUJvfZ8/sorlKZUDtcloJP3FUjHj5GpiMkTzxqVvTygCggIf86kJakmFtfGhXgG 7k3A== X-Gm-Message-State: AHPjjUjeso3sLyUpmCvojcalqYAQR3Fw5jxSCtWHZnG77Wqf6nAO/fEh jLVGayi8m05tJAM0mav38fedO/3HvWs7luLqCKJ81Q== X-Google-Smtp-Source: AOwi7QDIdekd5bKh7gIqzWfRAdJQcCtuZJpjPdQj0eeWi7ksLqPKinozWHzUH8e3XpYoU2h994TDdZJ4hNueJXTIBxU= X-Received: by 10.55.167.135 with SMTP id q129mr21203453qke.311.1505760691306; Mon, 18 Sep 2017 11:51:31 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.61.196 with HTTP; Mon, 18 Sep 2017 11:51:30 -0700 (PDT) In-Reply-To: References: <2efd30edab0647dda78246734f89a3f1@rew09926dag03b.domain1.systemhost.net> <9ae40aa4-2780-a3ce-5b31-bafacf983730@uclouvain.be> <0fa089ba-444b-01ec-1eba-83159147b141@uclouvain.be> From: Tom Herbert Date: Mon, 18 Sep 2017 11:51:30 -0700 Message-ID: To: Olivier Bonaventure Cc: philip.eardley@bt.com, multipathtcp@ietf.org, tcpm@ietf.org, tsv-area@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [multipathtcp] Progressing the MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 18:51:35 -0000 > From the viewpoint of the enduser, there is a benefit in using MPTCP on her > smartphone because she can combine LTE and WiFi to achieve higher bandwidth > or have seamless handovers. From the viewpoint of the network operator, this > is an added value service that they provide to their customers. If all > Internet servers supported MPTCP, they would not have had to deploy and > support the SOCKS servers in their network. > Olivier, The benefits of using MPTCP are understood. The question is cost of this solution. As you mention above MPTCP requires client and server cooperation, but this solution requires cooperation between clients and middleboxes, and middlebox and server. The number of cooperating parties is not be reduced, and effectively turns TCP connection negotiation into a three-way negotiation. The server/middlebox interaction may be mostly transparent, but not the former. The clients and middlebox support requires new protocol which means new software needs to be deployed on clients and middleboxes. This takes time and engineering effort. And there are a lot more network carriers than there are significant content providers or client vendor, so that is more parties to deal with in deployment. Given this, please provide the details on why this path is going to be faster than working directly with the content providers to start support MPTCP. WIth the right motivation and effort, I believe that most major content providers could have good support for MPTCP within 3 years. What is your time and effort estimate for deploying this solution across all clients and bringing up the converter in a significant number of networks? Tom >> Also, the >> cost analysis should take into account any negative effects on nodes >> outside of the devices being touched-- this solution is not >> transparent to the outside world (similar to how NAT isn't really >> transparent to end hosts). > > > The negative effect is that the smartphone needs to include MPTCP and the > SOCKS client. The SOCKS server is a single-point of failure inside the ISP > network. It is not totally transparent since the smartphone needs to be > configured with a SOCKS server, but there are clear benefits since this kind > of solution is deployed by several ISPs in several countries. > > > Olivier From nobody Mon Sep 18 13:06:14 2017 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80A951321CB; Mon, 18 Sep 2017 13:06:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=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 EN1JcLdG0Ie2; Mon, 18 Sep 2017 13:06:05 -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 C261E12421A; Mon, 18 Sep 2017 13:06:04 -0700 (PDT) Received: from mail-yw0-f174.google.com (mail-yw0-f174.google.com [209.85.161.174]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 5850827844A; Tue, 19 Sep 2017 05:06:02 +0900 (JST) Received: by mail-yw0-f174.google.com with SMTP id o143so1136889ywd.12; Mon, 18 Sep 2017 13:06:02 -0700 (PDT) X-Gm-Message-State: AHPjjUioPF5FC4sJTfVki2lgVq4GIcUvqky/t86zIvQGqv7zAKMOEomz uni9zXGAG3PW6ASamGv8QaEk1PD9sV6NWa4bm5U= X-Google-Smtp-Source: AOwi7QBLWLHKU4vC5PT0AMI7eeNTqOGVYecIjhHwPyNdEKm91ZJpdyASM3QXPmN6cfToyUi3VRsIiHJgOEaKSV10/2M= X-Received: by 10.37.220.72 with SMTP id y69mr27722662ybe.314.1505765160775; Mon, 18 Sep 2017 13:06:00 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.64.145 with HTTP; Mon, 18 Sep 2017 13:06:00 -0700 (PDT) In-Reply-To: References: <2efd30edab0647dda78246734f89a3f1@rew09926dag03b.domain1.systemhost.net> <9ae40aa4-2780-a3ce-5b31-bafacf983730@uclouvain.be> <0fa089ba-444b-01ec-1eba-83159147b141@uclouvain.be> From: Yoshifumi Nishida Date: Mon, 18 Sep 2017 13:06:00 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Tom Herbert Cc: Olivier Bonaventure , multipathtcp , "tcpm@ietf.org" , tsv-area@ietf.org Content-Type: multipart/alternative; boundary="94eb2c18f38486119605597c453a" Archived-At: Subject: Re: [multipathtcp] Progressing the MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 20:06:06 -0000 --94eb2c18f38486119605597c453a Content-Type: text/plain; charset="UTF-8" Hi Tom, Only a few companies can control both client and server sides. However, ISPs might be able to control the STB at the client side and the middleboxes in their networks. This may be a relatively easy way to deploy MPTCP technology rather than updating clients or servers. -- Yoshi On Mon, Sep 18, 2017 at 11:51 AM, Tom Herbert wrote: > > Olivier, > > The benefits of using MPTCP are understood. The question is cost of > this solution. As you mention above MPTCP requires client and server > cooperation, but this solution requires cooperation between clients > and middleboxes, and middlebox and server. The number of cooperating > parties is not be reduced, and effectively turns TCP connection > negotiation into a three-way negotiation. The server/middlebox > interaction may be mostly transparent, but not the former. The clients > and middlebox support requires new protocol which means new software > needs to be deployed on clients and middleboxes. This takes time and > engineering effort. And there are a lot more network carriers than > there are significant content providers or client vendor, so that is > more parties to deal with in deployment. Given this, please provide > the details on why this path is going to be faster than working > directly with the content providers to start support MPTCP. WIth the > right motivation and effort, I believe that most major content > providers could have good support for MPTCP within 3 years. What is > your time and effort estimate for deploying this solution across all > clients and bringing up the converter in a significant number of > networks? > > Tom > > >> Also, the > >> cost analysis should take into account any negative effects on nodes > >> outside of the devices being touched-- this solution is not > >> transparent to the outside world (similar to how NAT isn't really > >> transparent to end hosts). > > > > > > The negative effect is that the smartphone needs to include MPTCP and the > > SOCKS client. The SOCKS server is a single-point of failure inside the > ISP > > network. It is not totally transparent since the smartphone needs to be > > configured with a SOCKS server, but there are clear benefits since this > kind > > of solution is deployed by several ISPs in several countries. > > > > > > Olivier > > --94eb2c18f38486119605597c453a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tom,

Only a few companies can contro= l both client and server sides.
However, ISPs might be able to co= ntrol the STB at the client side and the middleboxes in their networks.=C2= =A0
This may be a relatively easy way to deploy MPTCP technology = rather than updating clients or servers.
--
Yoshi
=

On Mon, Sep = 18, 2017 at 11:51 AM, Tom Herbert <tom@herbertland.com> wr= ote:

Olivier,

The benefits of using MPTCP are understood. The question is cost of
this solution. As you mention above MPTCP requires client and server
cooperation, but this solution requires cooperation between clients
and middleboxes, and middlebox and server. The number of cooperating
parties is not be reduced, and effectively turns TCP connection
negotiation into a three-way negotiation. The server/middlebox
interaction may be mostly transparent, but not the former. The clients
and middlebox support requires new protocol which means new software
needs to be deployed on clients and middleboxes. This takes time and
engineering effort. And there are a lot more network carriers than
there are significant content providers or client vendor, so that is
more parties to deal with in deployment. Given this, please provide
the details on why this path is going to be faster than working
directly with the content providers to start support MPTCP. WIth the
right motivation and effort, I believe that most major content
providers could have good support for MPTCP within 3 years. What is
your time and effort estimate for deploying this solution across all
clients and bringing up the converter in a significant number of
networks?

Tom

>> Also, the
>> cost analysis should take into account any negative effects on nod= es
>> outside of the devices being touched-- this solution is not
>> transparent to the outside world (similar to how NAT isn't rea= lly
>> transparent to end hosts).
>
>
> The negative effect is that the smartphone needs to include MPTCP and = the
> SOCKS client. The SOCKS server is a single-point of failure inside the= ISP
> network. It is not totally transparent since the smartphone needs to b= e
> configured with a SOCKS server, but there are clear benefits since thi= s kind
> of solution is deployed by several ISPs in several countries.
>
>
> Olivier


--94eb2c18f38486119605597c453a-- From nobody Mon Sep 18 13:44:05 2017 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E2242132F65 for ; Mon, 18 Sep 2017 13:43:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 CCgP3j7gQ-6L for ; Mon, 18 Sep 2017 13:43:48 -0700 (PDT) Received: from mail-qt0-x243.google.com (mail-qt0-x243.google.com [IPv6:2607:f8b0:400d:c0d::243]) (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 5110C133073 for ; Mon, 18 Sep 2017 13:43:48 -0700 (PDT) Received: by mail-qt0-x243.google.com with SMTP id f24so1123628qte.5 for ; Mon, 18 Sep 2017 13:43:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=O+xtoIr8UErp23dMMasJlNhIVvbP6u/XpmUVNKFOCgs=; b=b/epWhFI0neWMaC62yQ8rc4DmkeqUjAh/vvDse3K4L410g4E1NeMR12I7p3TJKiA+c ttpsUTPSLtcM4TdUIWWUmZ9Rkq+Tj3nDFe6NyQWAwa9IELkPjtlyNyMxvGQ/rP3f+M4H Wh0hjUosjnW2O0Sgl2RIR6SkuebYNAW3a+lC+HKHK6Wq0ZZWXX/TUfLsKJnE8fUPitzJ uyswRUSqRugkmHupD0UKFstoBAtf3Ma/m1kWDrrmRPfs7MOPGG8wVQNESuznT2aahjo5 f1LH393h3PRLgJOfj0y7yQcm4eZfwleu4rWwTRngzdmvcBFuFko7vkj8wt7wfMLNY0J6 RcSw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=O+xtoIr8UErp23dMMasJlNhIVvbP6u/XpmUVNKFOCgs=; b=ujihZsZhg9jTcnblB0uQFD+n5J+Bvu6tBHkLBkH/FfXusy6UdEnUbg5UKEnlAXxRsr hlKh3Hm6FbDxKT5ARhqF7StDLJEdIgLNn2iPzJzy0M+Ms3MQccx17AGfxeJAFcjjTA9b yBIHIA5XIFH0NEi+LH3Ov8kvtgpq/x5xS8ctLkyjk/jOMQzbWCA//dY8nF1Jx0CfxqMX FN7/kQT+pTyHQ1t/tj5iiwwJWzEZ4WHzPRMVBNsv+47pkUwkQHjrDZhBfxOrrBOae4Xc NrTxeuiBrJlFB4F5mQrLk+dxFOOEXlAMjh2c1bvWQudLu59eQwabdHn3a3a1CjXUj18W eGBg== X-Gm-Message-State: AHPjjUheaMgfW7qmf/ie5KgEDtytIMqMdyHVTOYK16BNO79R5cNnf5X9 A87QMoAzWGp0QEnfrsAcBT6YMTowE5OClvLOAVczBA== X-Google-Smtp-Source: AOwi7QC4mJTZ0AMMtn3WbCAPTxzONR5UwKVnlp25Pk76HROmMJgyer/lEkRFizRziCF/38Ld2iSLq4kKHx69I5FyKjs= X-Received: by 10.200.35.247 with SMTP id r52mr38657201qtr.275.1505767427387; Mon, 18 Sep 2017 13:43:47 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.61.196 with HTTP; Mon, 18 Sep 2017 13:43:46 -0700 (PDT) In-Reply-To: References: <2efd30edab0647dda78246734f89a3f1@rew09926dag03b.domain1.systemhost.net> <9ae40aa4-2780-a3ce-5b31-bafacf983730@uclouvain.be> <0fa089ba-444b-01ec-1eba-83159147b141@uclouvain.be> From: Tom Herbert Date: Mon, 18 Sep 2017 13:43:46 -0700 Message-ID: To: Yoshifumi Nishida Cc: Olivier Bonaventure , multipathtcp , "tcpm@ietf.org" , tsv-area@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [multipathtcp] Progressing the MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Sep 2017 20:43:51 -0000 On Mon, Sep 18, 2017 at 1:06 PM, Yoshifumi Nishida wrote: > Hi Tom, > > Only a few companies can control both client and server sides. > However, ISPs might be able to control the STB at the client side and the > middleboxes in their networks. > This may be a relatively easy way to deploy MPTCP technology rather than > updating clients or servers. Yoshi, I think you're focusing too much on the benefits of this solution and not considering the cost. We've seen time and time again that when middleboxes get involved in transport layer operations they break the end to end nature of TCP and that leads to problems. Middlebox involvement in TCP is one of the major source of protocol ossification on the Internet. MPTCP is just one feature of TCP that we might want do deploy there are many others. If this solution hampers use and deployment of those, then I don't believe this is a reasonable tradeoff regardless of what the benefits are. Tom From nobody Mon Sep 18 17:16:49 2017 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 539B51252BA; Mon, 18 Sep 2017 17:16:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.989 X-Spam-Level: X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, T_SPF_PERMERROR=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=strayalpha.com 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 20K3VFBlTyGC; Mon, 18 Sep 2017 17:16:45 -0700 (PDT) Received: from server217-3.web-hosting.com (server217-3.web-hosting.com [198.54.115.226]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19957133229; Mon, 18 Sep 2017 17:16:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=strayalpha.com; s=default; h=Content-Type:In-Reply-To:MIME-Version:Date: Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=Z9dqR+7M8+EcpFoQlwWAaGL/Bl8Bc2XQYLNbsYKiGFM=; b=6JndIJl5iQe7hWGi3oL06mgo8 F2vB0Yus3M/LchTaQtvdD7W9il6slFuLREnAA5QVpuIFuMyns8ctZyNWSk2RHw505XCeGeOk9A6J+ FntForprWA7DFNqmPEzvjP/9ccZeWeRr/GZw8SG1MqVumcecEYnYa0guTFUL0ag6FMvuhQSyhdoxW 6gKwm/xiO9ylRyFAmKF4g8crPwIQEl1y3UpCC3oSPm/Z9Wi/ZYFtGLqQCogQ/qrzhzFteSr5AtQ1g DtbL6PSiYSvMEiLj3nTBp2neYalnAA4D5lYTeCrgmClbdxlAA+VunfnzDBqDKeODjIB2Ae3nfWRtR 42bUp5VOw==; Received: from cpe-172-250-240-132.socal.res.rr.com ([172.250.240.132]:49825 helo=[192.168.1.189]) by server217.web-hosting.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.87) (envelope-from ) id 1du6DR-001Gv2-T6; Mon, 18 Sep 2017 20:16:42 -0400 To: Yoshifumi Nishida , Tom Herbert Cc: multipathtcp , tsv-area@ietf.org, "tcpm@ietf.org" , Olivier Bonaventure References: <2efd30edab0647dda78246734f89a3f1@rew09926dag03b.domain1.systemhost.net> <9ae40aa4-2780-a3ce-5b31-bafacf983730@uclouvain.be> <0fa089ba-444b-01ec-1eba-83159147b141@uclouvain.be> From: Joe Touch Message-ID: <178edb8e-ab55-1019-48dc-e766ccb7ba07@strayalpha.com> Date: Mon, 18 Sep 2017 17:16:27 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------BF17A9A92FBEE835345EF522" Content-Language: en-US X-OutGoing-Spam-Status: No, score=-1.0 X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - server217.web-hosting.com X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - strayalpha.com X-Get-Message-Sender-Via: server217.web-hosting.com: authenticated_id: touch@strayalpha.com X-Authenticated-Sender: server217.web-hosting.com: touch@strayalpha.com X-Source: X-Source-Args: X-Source-Dir: X-From-Rewrite: unmodified, already matched Archived-At: Subject: Re: [multipathtcp] [tcpm] Progressing the MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 00:16:47 -0000 This is a multi-part message in MIME format. --------------BF17A9A92FBEE835345EF522 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit If you have a TCP solution that endpoints don't want but ISPs do, you do not have a good solution. Again, this seems like an interim fix that only complicates the landscape for everyone - it impedes deployment of security and could complicate every other option. Every attempt to address these issues seems like significant rationalization. Joe On 9/18/2017 1:06 PM, Yoshifumi Nishida wrote: > Hi Tom, > > Only a few companies can control both client and server sides. > However, ISPs might be able to control the STB at the client side and > the middleboxes in their networks.  > This may be a relatively easy way to deploy MPTCP technology rather > than updating clients or servers. > -- > Yoshi > > On Mon, Sep 18, 2017 at 11:51 AM, Tom Herbert > wrote: > > > Olivier, > > The benefits of using MPTCP are understood. The question is cost of > this solution. As you mention above MPTCP requires client and server > cooperation, but this solution requires cooperation between clients > and middleboxes, and middlebox and server. The number of cooperating > parties is not be reduced, and effectively turns TCP connection > negotiation into a three-way negotiation. The server/middlebox > interaction may be mostly transparent, but not the former. The clients > and middlebox support requires new protocol which means new software > needs to be deployed on clients and middleboxes. This takes time and > engineering effort. And there are a lot more network carriers than > there are significant content providers or client vendor, so that is > more parties to deal with in deployment. Given this, please provide > the details on why this path is going to be faster than working > directly with the content providers to start support MPTCP. WIth the > right motivation and effort, I believe that most major content > providers could have good support for MPTCP within 3 years. What is > your time and effort estimate for deploying this solution across all > clients and bringing up the converter in a significant number of > networks? > > Tom > > >> Also, the > >> cost analysis should take into account any negative effects on > nodes > >> outside of the devices being touched-- this solution is not > >> transparent to the outside world (similar to how NAT isn't really > >> transparent to end hosts). > > > > > > The negative effect is that the smartphone needs to include > MPTCP and the > > SOCKS client. The SOCKS server is a single-point of failure > inside the ISP > > network. It is not totally transparent since the smartphone > needs to be > > configured with a SOCKS server, but there are clear benefits > since this kind > > of solution is deployed by several ISPs in several countries. > > > > > > Olivier > > > > > _______________________________________________ > tcpm mailing list > tcpm@ietf.org > https://www.ietf.org/mailman/listinfo/tcpm --------------BF17A9A92FBEE835345EF522 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

If you have a TCP solution that endpoints don't want but ISPs do, you do not have a good solution.

Again, this seems like an interim fix that only complicates the landscape for everyone - it impedes deployment of security and could complicate every other option.

Every attempt to address these issues seems like significant rationalization.

Joe


On 9/18/2017 1:06 PM, Yoshifumi Nishida wrote:
Hi Tom,

Only a few companies can control both client and server sides.
However, ISPs might be able to control the STB at the client side and the middleboxes in their networks. 
This may be a relatively easy way to deploy MPTCP technology rather than updating clients or servers.
--
Yoshi

On Mon, Sep 18, 2017 at 11:51 AM, Tom Herbert <tom@herbertland.com> wrote:

Olivier,

The benefits of using MPTCP are understood. The question is cost of
this solution. As you mention above MPTCP requires client and server
cooperation, but this solution requires cooperation between clients
and middleboxes, and middlebox and server. The number of cooperating
parties is not be reduced, and effectively turns TCP connection
negotiation into a three-way negotiation. The server/middlebox
interaction may be mostly transparent, but not the former. The clients
and middlebox support requires new protocol which means new software
needs to be deployed on clients and middleboxes. This takes time and
engineering effort. And there are a lot more network carriers than
there are significant content providers or client vendor, so that is
more parties to deal with in deployment. Given this, please provide
the details on why this path is going to be faster than working
directly with the content providers to start support MPTCP. WIth the
right motivation and effort, I believe that most major content
providers could have good support for MPTCP within 3 years. What is
your time and effort estimate for deploying this solution across all
clients and bringing up the converter in a significant number of
networks?

Tom

>> Also, the
>> cost analysis should take into account any negative effects on nodes
>> outside of the devices being touched-- this solution is not
>> transparent to the outside world (similar to how NAT isn't really
>> transparent to end hosts).
>
>
> The negative effect is that the smartphone needs to include MPTCP and the
> SOCKS client. The SOCKS server is a single-point of failure inside the ISP
> network. It is not totally transparent since the smartphone needs to be
> configured with a SOCKS server, but there are clear benefits since this kind
> of solution is deployed by several ISPs in several countries.
>
>
> Olivier




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

--------------BF17A9A92FBEE835345EF522-- From nobody Mon Sep 18 18:39:18 2017 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97A6013243A; Mon, 18 Sep 2017 18:39:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 EsTsPtlEV703; Mon, 18 Sep 2017 18:39:10 -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 DDCE4132331; Mon, 18 Sep 2017 18:39:09 -0700 (PDT) Received: from mail-yw0-f177.google.com (mail-yw0-f177.google.com [209.85.161.177]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 87B292786F1; Tue, 19 Sep 2017 10:39:08 +0900 (JST) Received: by mail-yw0-f177.google.com with SMTP id w22so1556013ywa.13; Mon, 18 Sep 2017 18:39:08 -0700 (PDT) X-Gm-Message-State: AHPjjUh3nroVbMpev7PG0IzH4OMir3JFMOK6fLG3xcpnXxiXwaF8Dy9+ W+e44/+dnz1r3V3HFVNIqL8x0z1y17QsgbV92ho= X-Google-Smtp-Source: AOwi7QDW0LysonelXgV82mHNqF68Kr6WukPu5wF6w3KvtV8AxnbZnYJk2CPJvay0OHS+WlrD91CuUZYdS/tFbIODfNA= X-Received: by 10.129.87.12 with SMTP id l12mr1497157ywb.487.1505785146965; Mon, 18 Sep 2017 18:39:06 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.64.145 with HTTP; Mon, 18 Sep 2017 18:39:06 -0700 (PDT) In-Reply-To: References: <2efd30edab0647dda78246734f89a3f1@rew09926dag03b.domain1.systemhost.net> <9ae40aa4-2780-a3ce-5b31-bafacf983730@uclouvain.be> <0fa089ba-444b-01ec-1eba-83159147b141@uclouvain.be> From: Yoshifumi Nishida Date: Mon, 18 Sep 2017 18:39:06 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Tom Herbert Cc: Yoshifumi Nishida , Olivier Bonaventure , multipathtcp , "tcpm@ietf.org" , tsv-area@ietf.org Content-Type: multipart/alternative; boundary="001a113ab0f2cb0592055980ecff" Archived-At: Subject: Re: [multipathtcp] Progressing the MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 01:39:11 -0000 --001a113ab0f2cb0592055980ecff Content-Type: text/plain; charset="UTF-8" Hi Tom, On Mon, Sep 18, 2017 at 1:43 PM, Tom Herbert wrote: > On Mon, Sep 18, 2017 at 1:06 PM, Yoshifumi Nishida > wrote: > > Hi Tom, > > > > Only a few companies can control both client and server sides. > > However, ISPs might be able to control the STB at the client side and the > > middleboxes in their networks. > > This may be a relatively easy way to deploy MPTCP technology rather than > > updating clients or servers. > > Yoshi, > > I think you're focusing too much on the benefits of this solution and > not considering the cost. We've seen time and time again that when > middleboxes get involved in transport layer operations they break the > end to end nature of TCP and that leads to problems. Middlebox > involvement in TCP is one of the major source of protocol ossification > on the Internet. MPTCP is just one feature of TCP that we might want > do deploy there are many others. If this solution hampers use and > deployment of those, then I don't believe this is a reasonable > tradeoff regardless of what the benefits are. You might be right that I focus on the benefits too much. But, I personally don't think all middleboxes are bad. I think these ossifications are mainly caused by poorly designed middleboxes. If we can do things correctly, I think a middlebox might be able to intervene only when it can be beneficial otherwise stays away to not harm anything. I guess you don't want to throw away all load balancers, IDSs, firewalls from the Internet because they ossify protocols in some cases. -- Yoshi --001a113ab0f2cb0592055980ecff Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Tom,

On Mon, Sep 18, 2017 at 1:43 PM, Tom Herbert &= lt;tom@herbertland= .com> wrote:
On Mon, = Sep 18, 2017 at 1:06 PM, Yoshifumi Nishida
<nishida@sfc= .wide.ad.jp> wrote:
> Hi Tom,
>
> Only a few companies can control both client and server sides.
> However, ISPs might be able to control the STB at the client side and = the
> middleboxes in their networks.
> This may be a relatively easy way to deploy MPTCP technology rather th= an
> updating clients or servers.

Yoshi,

I think you're focusing too much on the benefits of this solution and not considering the cost. We've seen time and time again that when
middleboxes get involved in transport layer operations they break the
end to end nature of TCP and that leads to problems. Middlebox
involvement in TCP is one of the major source of protocol ossification
on the Internet. MPTCP is just one feature of TCP that we might want
do deploy there are many others. If this solution hampers use and
deployment of those, then I don't believe this is a reasonable
tradeoff regardless of what the benefits are.

You might be right that I focus on the benefits too much.
But,= I personally don't think all middleboxes are bad. I think these ossifi= cations are mainly caused by poorly designed middleboxes.=C2=A0
I= f we can do things correctly, I think a middlebox might be able to interven= e only when it can be beneficial otherwise stays away to not harm anything.=
I guess you don't want to throw away all load balancers, IDS= s, firewalls from the Internet because they ossify protocols in some cases.=
--
Yoshi
=C2=A0

--001a113ab0f2cb0592055980ecff-- From nobody Tue Sep 19 03:00:15 2017 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E97F0126D0C for ; Tue, 19 Sep 2017 03:00:14 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.319 X-Spam-Level: X-Spam-Status: No, score=-4.319 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, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de 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 crQvzI7PWouk for ; Tue, 19 Sep 2017 03:00:12 -0700 (PDT) Received: from mailout13.telekom.de (MAILOUT13.telekom.de [80.149.113.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A2E15126BF0 for ; Tue, 19 Sep 2017 03:00:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1505815211; x=1537351211; h=from:to:subject:date:message-id:references: content-transfer-encoding:mime-version; bh=gN2yAvtztWWxDRkPEwMYoVghwgpS+24tQu5Z1aRur6I=; b=KMyootb9aD3ctJU265dLiPfJw+QqENVj0rAwMO0up3MEEL1oOPq2gROx O08dy20pPCXGWEwYeq36d6gQcp2qybqReHRY2oZBkwl+ZrQfvXK7HkeSQ JsHyRtfbWsxBRtxJDA0NwfxF8meKtIAVVWbyZ+VOv1SChznwDdzjAjwqA HjoLDfXfgtDONtLAGevtK9zsFtXR5QtYlm8Az2cluW/+biC0UjuyUjExu bSqK4FiM15OOOBMO5SL0VCFpiP2R3z1kds4AaJ+UFJ+rBnNr07Id3nr39 VJAZY1i0SKn8wZwrZEA/1OrfqrykzDrJv7zYZJpQuzogbvAMR2Ut+nI0a w==; Received: from qde8e4.de.t-internal.com ([10.171.255.33]) by MAILOUT11.telekom.de with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Sep 2017 12:00:08 +0200 X-IronPort-AV: E=Sophos;i="5.42,417,1500933600"; d="scan'208";a="81669372" Received: from he105685.emea1.cds.t-internal.com ([10.169.119.47]) by QDE8PP.de.t-internal.com with ESMTP/TLS/AES256-SHA; 19 Sep 2017 12:00:07 +0200 Received: from HE105686.EMEA1.cds.t-internal.com (10.169.119.48) by HE105685.emea1.cds.t-internal.com (10.169.119.47) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Tue, 19 Sep 2017 12:00:07 +0200 Received: from HE105686.EMEA1.cds.t-internal.com ([fe80::a951:f05b:3de5:32d9]) by HE105686.emea1.cds.t-internal.com ([fe80::a951:f05b:3de5:32d9%26]) with mapi id 15.00.1293.002; Tue, 19 Sep 2017 12:00:07 +0200 From: To: Thread-Topic: [multipathtcp] A proposal for MPTCP Robust session Establishment (MPTCP RobE) Thread-Index: AdL5l2p+5KDR4ahqRJeh9onNd2ThSgBn5kmAACWZiyAKaI2ZkALvaGdg Date: Tue, 19 Sep 2017 10:00:07 +0000 Message-ID: <272695de663e4adca1930203b32f44e7@HE105686.emea1.cds.t-internal.com> References: <64f1b27aee214f6b99b5c474158d7426@HE105686.emea1.cds.t-internal.com> <79ac6cb307784db3a6d8ae1550a49573@HE105686.emea1.cds.t-internal.com> Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.30.231] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] A proposal for MPTCP Robust session Establishment (MPTCP RobE) X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 10:00:15 -0000 RGVhciBhbGwsDQoNCmFueSBjb21tZW50cyB0byBteSBwcm9wb3NhbCBmcm9tIHR3byB3ZWVrcyBh Z28/DQoNCkJSDQoNCk1hcmt1cw0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy b206IEFtZW5kLCBNYXJrdXMNCj4gU2VudDogTW9udGFnLCA0LiBTZXB0ZW1iZXIgMjAxNyAxNDox Nw0KPiBUbzogbXVsdGlwYXRodGNwQGlldGYub3JnDQo+IFN1YmplY3Q6IFJFOiBbbXVsdGlwYXRo dGNwXSBBIHByb3Bvc2FsIGZvciBNUFRDUCBSb2J1c3Qgc2Vzc2lvbg0KPiBFc3RhYmxpc2htZW50 IChNUFRDUCBSb2JFKQ0KPiANCj4gRGVhciBhbGwsDQo+IA0KPiBCYXNlZCBvbiBmZWVkYmFjayBh dCBJRVRGOTksIHJlZ2FyZGluZyBNUFRDUCBSb2JFIHByb3Bvc2FsDQo+IChodHRwczovL2RhdGF0 cmFja2VyLmlldGYub3JnL21lZXRpbmcvOTkvbWF0ZXJpYWxzL3NsaWRlcy05OS1tcHRjcC1hLQ0K PiBwcm9wb3NhbC1mb3ItbXB0Y3Atcm9idXN0LXNlc3Npb24tZXN0YWJsaXNobWVudC1tcHRjcC1y b2JlKSwgSSBjb21wbGV0ZWx5DQo+IHJlY29uc2lkZXIgdGhlIG9yaWdpbmFsIGFwcHJvYWNoLCBJ IHByZXNlbnRlZC4gUmVtZW1iZXIsIHRoZSAiRG93bmdyYWRlIi0NCj4gYXBwcm9hY2ggKHNlZSBz bGlkZXMpIHdhcyBwcmVmZXJyZWQgZnJvbSBteSBzaWRlLCBiZWNhdXNlIGl0IGNvbWJpbmVzDQo+ IHJvYnVzdG5lc3MgYW5kIGEgaHVnZSBsYXRlbmN5IHJlZHVjdGlvbi4NCj4gDQo+IFRoZSBtYWlu IGZlZWRiYWNrIEkgZ290IHdhczoNCj4gDQo+ICAgKDEpIFJlbHlpbmcgb24gU1lOLUtleS1BIGFz IGlkZW50aWZpZXIgdG8gY29tYmluZSBwb3RlbnRpYWwgaW5pdGlhbCBmbG93cywgcmFpc2UNCj4g c2V2ZXJhbCBpc3N1ZXMNCj4gICAgICgxLjEpIG5vdCBhdmFpbGFibGUgaW4gUkZDNjgyNGJpcyBh bnltb3JlDQo+ICAgICAoMS4yKSBzZWN1cml0eSwgYmVjYXVzZQ0KPiAgICAgICAgICgxLjIuMSkg S2V5LUEgaXMgdHJhbnNtaXR0ZWQgbWFueSB0aW1lcw0KPiAgICAgICAgICgxLjIuMikgY2FuIGJl IGFidXNlZCBieSBhY2NpZGVudC9pbnRlbmQNCj4gICAoMikgU2VwYXJhdGUgcm9idXN0bmVzcyBh bmQgbGF0ZW5jeSBmdW5jdGlvbmFsaXR5DQo+ICAgKDMpIFRvIG11Y2ggY29tcHV0aW5nIHJlc291 cmNlcyBuZWVkZWQgb24gcmVjZWl2ZXIgc2lkZSB0byBkZXRlY3QNCj4gZHVwbGljYXRlIEtleS1B DQo+ICAgKDQpIERvIGl0IGluIHRoZSBhcHBsaWNhdGlvbiBsYXllciBsaWJyYXJ5IChidWlsZCBh IHNoaW0gbGF5ZXIpOyBub3QgaW4gdGhlDQo+IE1QVENQIHN0YW5kYXJkIGFuZC9vciBpbXBsZW1l bnRhdGlvbiB0byByZWR1Y2UgY29tcGxleGl0eQ0KPiANCj4gV2l0aCB0aGUgZm9sbG93aW5nIHJl d29ya2VkIHByb3Bvc2FsIChiYXNlZCBvbiB0aGUgIkRvd25ncmFkZSIgYXBwcm9hY2gsDQo+IHNl ZSBzbGlkZXMpLCBJIHRyeSB0byBhZGRyZXNzIGFsbCBvZiB0aGUgcG9pbnRzIGFib3ZlLg0KPiAN Cj4gV2l0aCBGaWcuIDEsIHRoZSBmbG93IGRpYWdyYW0gZm9yIHRoZSBuZXcgcHJvcG9zYWwgaXMg ZGVwaWN0ZWQuIEl0IGlzIHJlZmVycmVkDQo+IHRvIE1QVENQIHZlcnNpb24gMCwgYnV0IHNob3Vs ZCBiZSBlcXVpdmFsZW50IHRvIHByb2JhYmxlIHZlcnNpb24gMQ0KPiAoUkZDNjI4NGJpcyksIGp1 c3Qgd2l0aG91dCBhIFNZTi1NUF9DQVBBQkxFIGNvbnRhaW5pbmcgS2V5LUEuDQo+IFRvIHJlYWNo IHJvYnVzdG5lc3MsIHNldmVyYWwgc2VwYXJhdGUgTVBUQ1AgaW5pdGlhbCBmbG93cyBhcmUgaW5p dGlhdGVkIGF0IHRoZQ0KPiBiZWdpbm5pbmcsIGluIHRoZSBmb2xsb3dpbmcgZGVub3RlZCBhcyAi cG90ZW50aWFsIGluaXRpYWwgZmxvd3MiLiBJbiBzdGVwIFNBMQ0KPiBhbmQgU0EyLCByZXNwZWN0 aXZlbHkgU0IzIGFuZCBTQjQsIHN0YW5kYXJkIE1QVENQIGluaXRpYWwgZmxvdyBwcm9jZWR1cmUg aXMNCj4gYXBwbGllZCwgc28gbm8gY2hhbmdlIHNvIGZhci4gV2l0aCBvY2N1cnJpbmcgU0EzL1NB NCB0aGUgcmVxdWVzdGVyICJIb3N0IEEiDQo+IGhhcyB0byBkZWNpZGUgd2hpY2ggcG90ZW50aWFs IGluaXRpYWwgZmxvdyB3aWxsIGJlIHVzZWQgZnVydGhlciBhcyBpbml0aWFsIGZsb3cNCj4gKGUu Zy4gdGhlIGZpcnN0IHdoaWNoIHJldHVybnMpIGFuZCB3aGF0IHNoYWxsIGhhcHBlbiB3aXRoIHRo ZSBvdGhlciBwb3RlbnRpYWwNCj4gZmxvd3MuIEVpdGhlciBpdCBjYW4gYnJlYWsgYWxsIGJ1dCBv bmUgKGUuZy4gc2VuZGluZyBSU1QgYXQgU0E2LjEpIE9SIHJlY3ljbGUNCj4gdGhlbSAoc3RlcCBT QTYuMikuIFRoZXJlYnksIGl0IGlzIGEgZnVsbCBjbGllbnQgc2lkZSBkZWNpc2lvbiB0byB1c2Ug cm9idXN0bmVzcw0KPiBvbmx5IG9yIGJlbmVmaXQgZnJvbSBsYXRlbmN5IHJlZHVjdGlvbiBhcyB3 ZWxsIGFuZCBjYW4gYmUgdG9nZ2xlZCBzZXBhcmF0ZWx5DQo+IGJ5IGUuZy4gc3lzY3RsIGdsb2Jh bGx5IGFuZC9vciBzb2NrZXQgb3B0aW9uLg0KPiBVbnRpbCBTQTYuMSwgaXQgZG9lc24ndCByZXF1 aXJlIGFueSBNUFRDUCBzdGFuZGFyZCBtb2RpZmljYXRpb24hDQo+IA0KPiAgICAgICAgICAgICAg IEhvc3QgQSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBIb3N0IEINCj4gICAgICAt LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0gICAgICAgICAgICAgICAgICAgICAgIC0tLS0tLS0tLS0N Cj4gICAgICBBZGRyZXNzIEExICAgIEFkZHJlc3MgQTIgICAgICAgICAgICAgICAgICAgICAgIEFk ZHJlc3MgQjENCj4gICAgICAtLS0tLS0tLS0tICAgIC0tLS0tLS0tLS0gICAgICAgICAgICAgICAg ICAgICAgIC0tLS0tLS0tLS0NCj4gICAgICAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICB8DQo+ICAgICAgICAgIHwgICAgICAgICAgICBTWU4gKyBNUF9D QVBBQkxFKEtleS1BKSAgICAgICAgICAgfA0KPiAgKFNBMSkgICB8LS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwgIChTQjEpDQo+ICAgICAgICAgIHwgICAgICAg ICAgICAgfCAgICBTWU4gKyBNUF9DQVBBQkxFKEtleS1BJykgICAgfA0KPiAgKFNBMikgICB8ICAg ICAgICAgICAgIHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwgIChTQjIpDQo+ICAg ICAgICAgIHwgICAgICAgICAgICAgfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgfA0K PiAgKFNBMykgICB8PC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LXwgIChTQjMpDQo+ICAgICAgICAgIHwgICAgICAgICAgU1lOL0FDSyArIE1QX0NBUEFCTEUoS2V5 LUIpICAgICAgICAgfA0KPiAgKFNBNCkgICB8ICAgICAgICAgICAgIHw8LS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLXwgIChTQjQpDQo+ICAgICAgICAgIHwgICAgICAgICAgICAgfCAgIFNZ Ti9BQ0sgKyBNUF9DQVBBQkxFKEtleS1CJykgfA0KPiAgICAgICAgICB8ICAgICAgICAgICAgIHwg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gICAgICAgICAgfCAgICAgICAgQUNL ICsgTVBfQ0FQQUJMRShLZXktQSwgS2V5LUIpICAgICAgICB8DQo+ICAoU0E1KSAgIHwtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+fCAgKFNCNSkNCj4gICAgICAg ICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgIFJTVCAgICAgICAgICAgICAgICB8DQo+ICAo U0E2LjEpIHwgICAgICAgICAgICAgfC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0+fCAg KFNCNi4xKQ0KPiByb2J1c3QgICB8ICAgICAgICAgICAgIHwgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgIHwNCj4gbmVzcyAgICAgfCAgICAgICAgICAgICB8ICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICB8DQo+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4gbGF0ZW5jeSAgfCAgICAgICAgICAgICB8 ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICB8DQo+IHJlZC4gICAgIHwgICAgICAgICAg ICAgfCBBQ0sgKyBNUF9KT0lOX0NBUChLZXktQSwgSE1BQykgfA0KPiAgKFNBNi4yKSB8ICAgICAg ICAgICAgIHwtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPnwgIChTQjYuMikNCj4gDQo+ ICAgIEtleS1CX2Zhc3RfaGFzaCA9IGNyYzE2KEtleS1CKSAmIDB4M0ZGICAgICAgICAgICAgICAg LT4gKDEwYml0KQ0KPiAgICBITUFDX2tleXMgPSAgSE1BQyhLZXktQStLZXktQitLZXktQicpICAg ICAgICAgICAgICAgIC0+ICg+PTk2Yml0KQ0KPiAgICBITUFDID0gIChITUFDX2tleXMgJiB+MHgz RkYpIHwgS2V5LUJfZmFzdF9oYXNoICAgICAgIC0+IChzaXplIHNhbWUgYXMNCj4gSE1BQ19rZXlz KQ0KPiANCj4gRmlndXJlIDE6IEV4YW1wbGUgVXNlIG9mIE1QVENQIFJvYkUgKGZvciBNUFRDUCB2 ZXJzaW9uIDApDQo+IA0KPiBGb3Igbm90IHdhc3RpbmcgcmVzb3VyY2VzIGJ5IGJyZWFraW5nIGFs bCBidXQgb25lIGFuZCBiZW5lZml0IGluIGFkZGl0aW9uDQo+IGZyb20gYSBodWdlIGxhdGVuY3kg cmVkdWN0aW9uIChzZWUgTVBUQ1AgUm9iRSBwcm9wb3NhbCwgcC4xMiwxNCsxNSwxNyksDQo+IG9u ZSBjYW4gbWFrZSB1c2Ugb2YgYSBuZXcgcHJvcG9zZWQgTVBUQ1Agb3B0aW9uICJNUF9KT0lOX0NB UCIsDQo+IGlsbHVzdHJhdGVkIGluIEZpZy4gMi4gQWNjb3JkaW5nIHRvIEZpZy4gMSwgQTE8LT5C MSBpcyBhc3N1bWVkIGFzIGluaXRpYWwgZmxvdyBhdA0KPiBTQTMgYW5kIEEyPC0+QjEgc2hhbGwg YmUgcmVjeWNsZWQgYXQgU0E2LjIgKFNBNi4xIGlzIHNraXBwZWQgdGhlcmVmb3JlKS4NCj4gSW5z dGVhZCBvZiBzZW5kaW5nIGFuIE1QX0NBUEFCTEUgaW4gdGhlIHRoaXJkIEFDSywgYW4gTVBfSk9J Tl9DQVAgaXMNCj4gc2VudCwgd2hpY2ggaW5jbHVkZXMgS2V5LUEgb2YgdGhlIHNlbGVjdGVkIGlu aXRpYWwgZmxvdyBBMTwtPkIxIGFuZCBhbiBITUFDLA0KPiBjb2RpbmcgS2V5LUEsIEtleS1CLCBL ZXktQicgaW4gYSBkZXRlcm1pbmVkIHdheSAoc2VlIEZpZy4gMSBib3R0b20pLg0KPiANCj4gICAg ICAgICAgICAgICAgICAgIDEgICAgICAgICAgICAgICAgICAgMiAgICAgICAgICAgICAgICAgICAz DQo+ICAwIDEgMiAzIDQgNSA2IDcgOCA5IDAgMSAyIDMgNCA1IDYgNyA4IDkgMCAxIDIgMyA0IDUg NiA3IDggOSAwIDENCj4gKy0tLS0tLS0tLS0tLS0tLSstLS0tLS0tLS0tLS0tLS0rLS0tLS0tLSst LS0tLS0tKy0tLS0tLS0tLS0tLS0tLSsNCj4gfCAgICAgS2luZCAgICAgIHwgICAgTGVuZ3RoICAg ICB8U3VidHlwZXwgICAgICAgfCAgICBBRERSX0lEICAgIHwNCj4gKy0tLS0tLS0tLS0tLS0tLSst LS0tLS0tLS0tLS0tLS0rLS0tLS0tLSstLS0tLS0tKy0tLS0tLS0tLS0tLS0tLSsNCj4gfCAgICAg ICAgICAgICAgICAgICAgU2VuZGVyJ3MgS2V5LUEgKDY0IGJpdHMpICAgICAgICAgICAgICAgICAg IHwNCj4gfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIHwNCj4gfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4gfCAgICAgICAgICAgICAg ICAgICAgICAgIEhNQUMgKD49OTYgYml0cykgICAgICAgICAgICAgICAgICAgICAgIHwNCj4gfCAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIHwNCj4gfCAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgIHwNCj4gOiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIDoNCj4gKy0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLSsNCj4gRmlndXJlIDI6IE11 bHRpcGF0aCBKb2luIENhcGFibGUgKE1QX0pPSU5fQ0FQKSBPcHRpb24gKGZvciBUaGlyZA0KPiBN UF9DQVBBQkxFIEFDSykNCj4gDQo+IEZvciB0aGUgTVBfQ0FQQUJMRSwgQUREUl9JRCBpcyBzZXQg dG8gemVybyAobGlrZSBSRkM2ODI0KSBhbmQgZm9yDQo+IE1QX0pPSU5fQ0FQIGl0IGlzIHNlbnQg d2l0aC4NCj4gDQo+IFdoaWNoIGJvdW5kYXJ5IGNvbmRpdGlvbnMgY2FuIGhhcHBlbjoNCj4gDQo+ IDEuIExpa2UgRmlnLiAxLCBBMTwtPkIxIGlzIGFzc3VtZWQgYXMgaW5pdGlhbCBmbG93IGFuZCBN UF9DQVBBQkxFIHJlY2VpdmVzDQo+IGZpcnN0IGF0IEhvc3QgQiAoU0I1KSwgQTI8LT5CMSBzaGFs bCBiZSByZWN5Y2xlZCBhbmQgQUNLIGlzIHNlbnQgd2l0aA0KPiBNUF9KT0lOX0NBUA0KPiAgICBJ ZiBNUF9KT0lOX0NBUCBpcyByZWNlaXZlZCBpdCBoYXMgdG8gaXRlcmF0ZSBvbmNlIChsaWtlIE1Q X0pPSU4pIHRoZQ0KPiBjb25uZWN0aW9uIGxpc3QgYW5kIGNoZWNrIGZvciBLZXktQSBhdmFpbGFi aWxpdHkuIElmIGEgS2V5LUEgY29ubmVjdGlvbiBpcw0KPiBmb3VuZCwgaXQgaXMgdmFsaWRhdGVk IGFnYWluc3QgSE1BQyB2YWx1ZS4gVGhlIHZhbGlkYXRpb24gaGFzIHR3byByZWFzb25zLA0KPiBm aXJzdGx5IHNldmVyYWwgS2V5LUEgY2FuIGV4aXN0LCBiZWNhdXNlIGRpZmZlcmVudCBIb3N0cyBj aG9vc2Ugc2FtZSBLZXktQSBieQ0KPiBhY2NpZGVudC4gRnVydGhlcm1vcmUgbm8gb25lIGNhbiBq b2luIGEgY29ubmVjdGlvbiBieSBqdXN0IHJlY29yZGluZy9icnV0ZS0NCj4gZm9yY2luZyBLZXkt QSBhbmQgZHVwbGljYXRlIHRoZSByZXF1ZXN0LiAoc29sdmVzIHBvaW50ICgxKSBmcm9tIHRoZSBm ZWVkYmFjaykNCj4gDQo+IDIuIExpa2UgMS4sIGJ1dCBNUF9KT0lOX0NBUCBhcnJpdmVzIGJlZm9y ZSB0aGUgTVBfQ0FQQUJMRSBhdCBIb3N0IEINCj4gDQo+ICAgICAyLjEgZHJhZnQtaWV0Zi1tcHRj cC1yZmM2ODI0YmlzLTA5DQo+ICAgICAgICAgQmFzZWQgb24gS2V5LUEsIGl0IHdpbGwgaXRlcmF0 ZSBvdmVyIHRoZSBjb25uZWN0aW9uIGxpc3QsIGJ1dCBpdCB3aWxsIG5vdA0KPiBtYXRjaCwgYmVj YXVzZSBLZXktQSBmcm9tIGZvcm1lcmx5IHNlbGVjdGVkIGluaXRpYWwgZmxvdyBoYXNuJ3QgYXJy aXZlZCB5ZXQuDQo+IFNvIGl0IHdpbGwgY29udGludWUgd2l0aCBhIGZhc3QgaXRlcmF0ZSBvbmx5 IG92ZXIgdGhlIGNvbm5lY3Rpb25zLCB3aGljaCBhcmUgc3RpbGwNCj4gaW4gZXN0YWJsaXNobWVu dCBwaGFzZSwgdXNpbmcgdGhlIDEwYml0IEtleS1CX2Zhc3RfaGFzaCAoY3JjMTYoS2V5LUIpICYN Cj4gMHgzRkYpLiBJZiBpdCBtYXRjaGVzIGFnYWluc3QgYSAocHJlY29tcHV0ZWQpIGV4aXN0aW5n IEtleS1CX2Zhc3RfaGFzaCBpbiB0aGUNCj4gY29ubmVjdGlvbiBsaXN0LCBpdCB3aWxsIHZhbGlk YXRlIHdpdGggdGhlIEhNQUMoS2V5LUErS2V5LUIrS2V5LUInKSBhZ2FpbiB0bw0KPiBlbnN1cmUg bGVnaXRpbWF0aW9uLiBJZiBzdWNjZXNzZnVsLCBib3RoLCB0aGUgaW5pdGlhbCBmbG93IGFuZCB0 aGUgTVBfSk9JTl9DQVANCj4gZmxvdywgY2FuIGJlIGltbWVkaWF0ZWx5IGVzdGFibGlzaGVkLiBU aGlzIGlzIHRydWUsIGJlY2F1c2Ugd2l0aG91dCB0aGUNCj4ga25vd2xlZGdlIG9mIEtleS1CLCBI b3N0IEEgY291bGRuJ3QgY2FsY3VsYXRlIHRoZSBITUFDLiBTbyBpdCBpcyBjbGVhciwgdGhhdA0K PiBob3N0IEEgaGFkIHJlY2VpdmVkIHRoZSBTWU4vQUNLIChTQjMpLg0KPiBUaGlzIGFsc28gbWl0 aWdhdGVzIHRoZSByZXF1aXJlbWVudCBvZiBhIHJlbGlhYmxlIEFDSyAoZHJhZnQtaWV0Zi1tcHRj cC0NCj4gcmZjNjgyNGJpcy0wOSwgcC4xNSkgZXhjaGFuZ2UsIGJlY2F1c2Ugb25seSBvbmUNCj4g TVBfQ0FQQUJMRS9NUF9KT0lOX0NBUCBuZWVkcyB0byByZWFjaCByZWNlaXZlciBzaWRlLg0KPiAN Cj4gICAgIDIuMiBNUFRDUCB2ZXJzaW9uIDAgKFJGQzY4MjQpDQo+ICAgICAgICAgQ2FuIG1hdGNo IGJhc2VkIG9uIEtleS1BLCBsaWtlIDEuLCBzYW1lIGVmZm9ydCBhcyBmb3IgYSBNUF9KT0lOLg0K PiANCj4gMy4gQTI8LT5CMSBpcyBzZWxlY3RlZCBhcyBpbml0aWFsIGZsb3csIGJlY2F1c2UgYWNj b3JkaW5nIFNZTi9BQ0sgcmV0dXJucw0KPiBlYXJsaWVyIGF0IEhvc3QgQS4NCj4gICAgIEl0IGlz IHRoZSBzYW1lIGFzIDEuIGFuZCAyLiwganVzdCB0aGUgb3RoZXIgd2F5IHJvdW5kIDotKQ0KPiAN Cj4gV2l0aCB0aGVzZSBib3VuZGFyeSBjb25kaXRpb25zIGl0IGhhcyBiZWVuIHNob3duLCB0aGF0 IG5vIGFkZGl0aW9uYWwNCj4gY29tcHV0aW5nIHJlc291cmNlcyBhcmUgcmVxdWlyZWQgKHNlZSBm ZWVkYmFjayAoMykpLCBjb21wYXJlZCB0byB0b2RheXMNCj4gTVBUQ1AsIHdpdGggYSBtaW5pbWFs IGV4Y2VwdGlvbiBvZiAyLjEuDQo+IA0KPiBXaXRoIHN1Y2ggYSBzaW1wbGUgYXBwcm9hY2gsIGFu ZCBieSBhZGRpbmcgYW4gaW5jb25zcGljdW91cyBzaW1wbGUgTVBUQ1ANCj4gb3B0aW9uIE1QX0pP SU5fQ0FQLCBNUFRDUCB3b3VsZCBiZSBleHRlbmRlZCB0b3dhcmRzIHJvYnVzdG5lc3MgYW5kIGlm DQo+IGRlc2lyZWQsIGxhdGVuY3kgcmVkdWN0aW9uIGNhbiBiZSBlbmFibGVkIG9uIHRvcCwgYnV0 IG9idmlvdXNseSByZXF1aXJlcw0KPiByZWNlaXZlciBzdXBwb3J0LiBOZWdvdGlhdGlvbiBpcyBp bmhlcmVudGx5IGdpdmVuIGJ5IHRoZSBuZXcgTVBfSk9JTl9DQVANCj4gd2hpY2ggaXMgZWl0aGVy IGFjY2VwdGVkIG9yIG5vdC4gSWYgbm90LCB0aGUgc3RhbmRhcmQgTVBfSk9JTiBwcm9jZXNzIGNh biBiZQ0KPiBhcHBsaWVkLg0KPiANCj4gQmVjYXVzZSBvZiBzdWNoIGEgc2ltcGxpY2l0eSBhbmQg dGhlIG1hc3NpdmUgYmVuZWZpdCBieSBvcHRpb25hbCBsYXRlbmN5DQo+IHJlZHVjdGlvbiwgSSBz dGlsbCBiZWxpZXZlIGl0IGZpdHMgYmVzdCBpbiB0aGUgTVBUQ1AgbGF5ZXIgaXRzZWxmIGFuZCBu b3QgaW4gYW4NCj4gYXBwbGljYXRpb24gc2hpbSBsYXllciAoc2VlIGZlZWRiYWNrICg0KSkuDQo+ IA0KPiBEdWUgdG8gdGhlIHNlcGFyYXRpb24gb2Ygcm9idXN0bmVzcyBhbmQgbGF0ZW5jeSByZWR1 Y3Rpb24gZnVuY3Rpb25hbGl0eSwgaXQNCj4gb2ZmZXJzIHRoZSBjaGFuY2UgdG8gaW1wbGVtZW50 ICJyb2J1c3RuZXNzIiBpbiBwbGFpbiBUQ1AgYXMgd2VsbC4gSXQgY291bGQNCj4gbG9vayB0aGUg c2FtZSBsaWtlIGluIEZpZy4gMSwgKFNBMSktKFNBNi4xKSwganVzdCB3aXRob3V0IE1QX0NBUEFC TEUgb3B0aW9uLg0KPiBCdXQgYmUgYXdhcmUsIGl0IG5lZWRzIHNvbWUga2luZCBvZiBwYXRoIG1h bmFnZW1lbnQsIHdoaWNoIGlzIGFscmVhZHkNCj4gcHJlc2VudCBpbiBNUFRDUCwgYnV0IG5vdCBp biBUQ1AuIEZ1cnRoZXJtb3JlIEkgYXNzdW1lICJyb2J1c3RuZXNzIiBpcyBhDQo+IHRvcGljIG1v cmUgcmVsYXRlZCB0byB0YXBzIHdvcmtpbmcgZ3JvdXAsIHdoZXJlYXMgImxhdGVuY3kgcmVkdWN0 aW9uIiBpcw0KPiByZWxhdGVkIHRvIE1QVENQIG9idmlvdXNseSBhbmQgZGVwZW5kcyBvbiAicm9i dXN0bmVzcyIhDQo+IA0KPiBCUg0KPiANCj4gTWFya3VzDQo= From nobody Tue Sep 19 09:16:52 2017 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 11680134289; Tue, 19 Sep 2017 09:16:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 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, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uclouvain.be 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 8TJSGYLJNQ3f; Tue, 19 Sep 2017 09:16:40 -0700 (PDT) Received: from smtp2.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 08AD7134281; Tue, 19 Sep 2017 09:16:40 -0700 (PDT) Received: from mbpobo.local (host-78-129-6-94.dynamic.voo.be [78.129.6.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp2.sgsi.ucl.ac.be) by smtp2.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 3518467E2A7; Tue, 19 Sep 2017 18:16:31 +0200 (CEST) DKIM-Filter: OpenDKIM Filter v2.9.2 smtp2.sgsi.ucl.ac.be 3518467E2A7 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1505837791; bh=T7Onx5CQzhXFvqSJPNmjFQUbRPzJbMj2cFbUJzcjNpQ=; h=Reply-To:Subject:To:Cc:References:From:Date:In-Reply-To; b=Zn6WuM4Rk8MexOamA1qTNvtzQ2VS8MxYIpjKDACco40D1Gtf6KTSRrz+p78O1jlvA u3DKEjkM6HcHGaiDvyMh1h76tmXVSzBqbuL57qlCKPt0Jf2RsaXdCNJLqbz7ycpJss E4duI5gGG1DmnTxWVQqxC6P92O5QCr3O+8njulLI= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99.2 at smtp-2 Reply-To: Olivier.Bonaventure@uclouvain.be To: Tom Herbert , Yoshifumi Nishida Cc: multipathtcp , "tcpm@ietf.org" , tsv-area@ietf.org References: <2efd30edab0647dda78246734f89a3f1@rew09926dag03b.domain1.systemhost.net> <9ae40aa4-2780-a3ce-5b31-bafacf983730@uclouvain.be> <0fa089ba-444b-01ec-1eba-83159147b141@uclouvain.be> From: Olivier Bonaventure Message-ID: <49969822-1024-3811-9f87-f95f9d58837a@uclouvain.be> Date: Tue, 19 Sep 2017 18:16:31 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr-classic Content-Transfer-Encoding: 7bit X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-Information: X-SGSI-MailScanner-ID: 3518467E2A7.A198F X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Subject: Re: [multipathtcp] Progressing the MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 16:16:44 -0000 Tom, >> >> Only a few companies can control both client and server sides. >> However, ISPs might be able to control the STB at the client side and the >> middleboxes in their networks. >> This may be a relatively easy way to deploy MPTCP technology rather than >> updating clients or servers. > > Yoshi, > > I think you're focusing too much on the benefits of this solution and > not considering the cost. We've seen time and time again that when > middleboxes get involved in transport layer operations they break the > end to end nature of TCP and that leads to problems. Middlebox > involvement in TCP is one of the major source of protocol ossification > on the Internet. We've spent a long time fighting with middleboxes during the design and implementation of MPTCP and I know the problems that they cause. Most of the problems we have with middleboxes today come from the fact that they are not explicit in the architecture. A client cannot explicitly request the creation of a TCP connection through a specific middlebox that would provide service to this client. All middleboxes are implictly deployed in the network and they process/interfere with traffic without the consent of the client. On servers, some middleboxes (e.g. load balancers) are part of the infrastructure and the server are informed about their presence. The proposed converters change this approach by making the conversion an explicit (opt-in) service that can be requested by the client. If the client does not request the conversion service, then there is no interference from the middlebox. This is a different approach which could in the long term provide new benefits that go beyond the simple conversion service. > MPTCP is just one feature of TCP that we might want > do deploy there are many others. If this solution hampers use and > deployment of those, then I don't believe this is a reasonable > tradeoff regardless of what the benefits are. Since the conversion service is explicitly requested by the clients, they can opt-out this service when it is not required anymore (e.g. MPTCP is supported on servers) or when they wish to use a feature that is not supported by the converter. Olivier From nobody Tue Sep 19 10:32:33 2017 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4CD49134299 for ; Tue, 19 Sep 2017 10:32:27 -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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=herbertland-com.20150623.gappssmtp.com 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 Jeme1UUplxv8 for ; Tue, 19 Sep 2017 10:32:25 -0700 (PDT) Received: from mail-qk0-x236.google.com (mail-qk0-x236.google.com [IPv6:2607:f8b0:400d:c09::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E8FC0133342 for ; Tue, 19 Sep 2017 10:32:24 -0700 (PDT) Received: by mail-qk0-x236.google.com with SMTP id u73so323791qkl.12 for ; Tue, 19 Sep 2017 10:32:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=herbertland-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sfDJbj5n3pe5LQml50sxIFFCb0xGOzKUYojzsgDvp4E=; b=MMhDxFhNXeGur3a1zBEMtz1UsBKUZLD5jEH1QOgHkSHNBOmiwcJIvSXl+pipF7FEVc eb2AOdNYMeUY5hlznPPcegLrhezSVM1EFHzseQnLZwPrd7RC0AMlmen2333SiHrMWdKk gHDo+h9NXYb66dt9fBd2iMAq6DH2wq1wb3xNHDtlakhCZ2Oj3E7mX5nkAmXcH3FA0LZ3 WMB6pj3VljItmuhH99hYjh86hFoTK6rbW8aGCVI6KL3PkcsKm8WztAsI2l1t/AESu6Et 3j3oJmK312k34Kayni+rQhW/WhGsCDAGvN1MrNrHkX7sv1/zaMupR+ph8Sd7ThTpxeGQ 3GEQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sfDJbj5n3pe5LQml50sxIFFCb0xGOzKUYojzsgDvp4E=; b=kJxvfH/LhItahGPTBQrF6agfAyEsQUok+GScbULaCimBM8ovLT0E3vUOR6q+VsQf2/ pqY0Oe9m74l1+Dd9N7AK8R9fOjq9Ch9hF/+bpN69D5R2/quEOK/p5KmsIK+fxcsaFDjX galJJ7PtDlGsRRcjQdCTKUwOtx96zc53NHhAGVJa65e9Y7KnNuawUcg8Ju6PqV60bNth X+BQyaGtT+oMRGI7tJYSYzx5lBjSvHE16SDc0ZaJ5u3kGYsA0Ac/f92biHOsfJz6jmR3 y80qk5KX2dnOKOv/WWCtEX9YyecfU3NgEYukmTJ/HEtlwRFDyW9/t36g4e7FGvlAs+ue IjAQ== X-Gm-Message-State: AHPjjUgqqNeBy86jXhi/BIUIcnW8Yraj6VPJBCXwEicP8p8MZEtGRijw xwW7PK+CJoiI2j40rUyeUkF1DJb1BUkkwqJ9E4M+zg== X-Google-Smtp-Source: AOwi7QCGuKye21WCVf2kZcPoZa7oJ5vr25IrZ1kJ2uGL2q/tOgHnnDvVLFF8mKlJ9bkIq57uqiUG6T40a/y/6VST20Q= X-Received: by 10.55.109.131 with SMTP id i125mr2959705qkc.17.1505842343938; Tue, 19 Sep 2017 10:32:23 -0700 (PDT) MIME-Version: 1.0 Received: by 10.237.61.196 with HTTP; Tue, 19 Sep 2017 10:32:23 -0700 (PDT) In-Reply-To: References: <2efd30edab0647dda78246734f89a3f1@rew09926dag03b.domain1.systemhost.net> <9ae40aa4-2780-a3ce-5b31-bafacf983730@uclouvain.be> <0fa089ba-444b-01ec-1eba-83159147b141@uclouvain.be> From: Tom Herbert Date: Tue, 19 Sep 2017 10:32:23 -0700 Message-ID: To: Yoshifumi Nishida Cc: Olivier Bonaventure , multipathtcp , "tcpm@ietf.org" , tsv-area@ietf.org Content-Type: text/plain; charset="UTF-8" Archived-At: Subject: Re: [multipathtcp] Progressing the MPTCP proxy work X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Sep 2017 17:32:27 -0000 On Mon, Sep 18, 2017 at 6:39 PM, Yoshifumi Nishida wrote: > Hi Tom, > > On Mon, Sep 18, 2017 at 1:43 PM, Tom Herbert wrote: >> >> On Mon, Sep 18, 2017 at 1:06 PM, Yoshifumi Nishida >> wrote: >> > Hi Tom, >> > >> > Only a few companies can control both client and server sides. >> > However, ISPs might be able to control the STB at the client side and >> > the >> > middleboxes in their networks. >> > This may be a relatively easy way to deploy MPTCP technology rather than >> > updating clients or servers. >> >> Yoshi, >> >> I think you're focusing too much on the benefits of this solution and >> not considering the cost. We've seen time and time again that when >> middleboxes get involved in transport layer operations they break the >> end to end nature of TCP and that leads to problems. Middlebox >> involvement in TCP is one of the major source of protocol ossification >> on the Internet. MPTCP is just one feature of TCP that we might want >> do deploy there are many others. If this solution hampers use and >> deployment of those, then I don't believe this is a reasonable >> tradeoff regardless of what the benefits are. > > > You might be right that I focus on the benefits too much. > But, I personally don't think all middleboxes are bad. I think these > ossifications are mainly caused by poorly designed middleboxes. > If we can do things correctly, I think a middlebox might be able to > intervene only when it can be beneficial otherwise stays away to not harm > anything. > I guess you don't want to throw away all load balancers, IDSs, firewalls > from the Internet because they ossify protocols in some cases. It's a bit off topic, but, yes, I do want to eliminate these from the Internet. It's not just because of protocol ossification or their breaking of the end to end model (particularly for security). I believe they're becoming largely obsolete. Stateless load balancing can and ECMP can be accomplished with out DPI by including IPv6 flow label in a hash. The perimeter stateful firewall model is not relevant for cloud and multi-tenant environments and without IDS they don't give users much protection for modern threats. IDS on application layer protocols is great except for the fact that it's pretty much rendered useless in the presence of payload encryption (i.e. TLS). Besides that, I think were going to see more protocols like QUIC that purposely hide transport layer information from the network and hopefully more use of transport mode encryption for TCP to accomplish the same effect. The service that these devices provide (packet filtering, IDS, etc.) are still needed, but I believe we can get these without needing middleboxes in the data path and without breaking end to end model or end to end security. Tom > -- > Yoshi > > From nobody Wed Sep 20 00:37:30 2017 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79E601323B4 for ; Wed, 20 Sep 2017 00:37:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.4 X-Spam-Level: X-Spam-Status: No, score=-1.4 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001] autolearn=no autolearn_force=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 m1nQjXe9AeMw for ; Wed, 20 Sep 2017 00:37:25 -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 65F77132025 for ; Wed, 20 Sep 2017 00:37:24 -0700 (PDT) Received: from mail-yw0-f169.google.com (mail-yw0-f169.google.com [209.85.161.169]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 244A3278D5A for ; Wed, 20 Sep 2017 16:37:22 +0900 (JST) Received: by mail-yw0-f169.google.com with SMTP id l4so1323450ywa.6 for ; Wed, 20 Sep 2017 00:37:22 -0700 (PDT) X-Gm-Message-State: AHPjjUh3KkLGjSrBl5KOHRNZmey9tOZWjMTcmyH7X8bbm1jiqwWHdYCh BuIPXCRyJIFEp6ezjwivRFNL08W6y3L3QRIwLxc= X-Google-Smtp-Source: AOwi7QCUBJCfph4KMt5Roilk11KO7bn4PChW2Q2I4sMMvoIczXf2xQNPiBPgpOkC8t5VFKmfyrl00Yo5HNfA5bvP3CI= X-Received: by 10.129.145.214 with SMTP id i205mr3246296ywg.73.1505893040713; Wed, 20 Sep 2017 00:37:20 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.64.145 with HTTP; Wed, 20 Sep 2017 00:37:20 -0700 (PDT) In-Reply-To: <804577f3-f2a7-0726-08b3-717abe43f9c8@tessares.net> References: <804577f3-f2a7-0726-08b3-717abe43f9c8@tessares.net> From: Yoshifumi Nishida Date: Wed, 20 Sep 2017 00:37:20 -0700 X-Gmail-Original-Message-ID: Message-ID: To: =?UTF-8?Q?Fran=C3=A7ois_Finfe?= Cc: Yoshifumi Nishida , multipathtcp , Olivier Bonaventure Content-Type: multipart/alternative; boundary="94eb2c0941c2c2f60205599a0b80" Archived-At: Subject: Re: [multipathtcp] Multipath TCP FAST_CLOSE - abrupt closing X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 07:37:28 -0000 --94eb2c0941c2c2f60205599a0b80 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Oliver, Francois, Thanks for the comments. One concern I have is it seems that people are expecting to expose this feature to apps although this won't be a recommended way to terminate an MPTCP session. I think It won't be good if we end up always using it even when there's no resource limitations. -- Yoshi On Mon, Sep 18, 2017 at 4:58 AM, Fran=C3=A7ois Finfe wrote: > Hi Yoshi, > > On 2017-09-15 00:33, Yoshifumi Nishida wrote: > > Hi Francois, > > > > This is an interesting proposal for the bis draft. But, I guess the > > receiver of FAST_CLOSE (will be clients in most cases) may need to > > wait longer time in some cases. > > > > I am thinking that the main motivation of SO_LINGER with zero timeout > > approach is to avoid going into time_wait. > > I think MPTCP's FAST_CLOSE already takes care of this point to some > > extent and senders don't go into M_TIMEWAIT, although it requires at > > least 1 RTT. > > So, I am still not very sure if we should save this 1 RTT or should > > avoid unfortunate cases for long waiting. > Yes, in most likely cases, it will last 1 RTT. In worst case, with 3 > retransmissions and exp. backoff enabled, it will linger 8 RTO's. > > 1 RTT is relatively very high compared to the time to send an > MP_FASTCLOSE. On the current linux MPTCP implementation and on my > computer, the time required to fast close a MPTCP connection (send > MP_FASTCLOSE and RST's, without taking account the retransmissions or > waiting for RST from the other peer) is 1 ms. > > This time depends of a lot of factor but it is quite small compared to > typical values of RTT for DSL/LTE. > > In the case of the SO_LINGER with zero timeout, the user space will > expect that "all queued messages for the socket have been successfully > sent or the linger timeout has been reached" and nothing is done on > background. By waiting for a RST in response to a MP_FASTCLOSE, it is > not possible to match the timing requirement, or it must be done it in > the background. > > Abrupt connection closing can be explicitly set by the user space > software explicitly. > > But, it can be tacitly set as well: > - on GNU/Linux, if a process is killed, all the established connection > will be abruptly closed. > - Other scenarii are when the system is under pressure. > > In these cases, quickly close a connection is important. > > > > > > BTW, I happened to find that the state transition diagram in the draft > > doesn't contain M_FASTCLOSE state, although it is mentioned in Section > > 3.5. > I don't know why it's not mentioned. Maybe, it is omitted for the sake > of clarity, because you can switch from a lot of state (not only > established) to closed via fast close. On most TCP state transition > diagram, this transition (via a RST instead of a fast close) is not > mentioned either. > > Fran=C3=A7ois > > > Is this OK? > > > > Thanks, > > -- > > Yoshi > > > > > > On Wed, Sep 13, 2017 at 6:39 AM, Fran=C3=A7ois Finfe > > wrote: > >> Hi, > >> > >> > >> RFC6824 and RFC6824bis use the FAST_CLOSE option to abruptly close a > >> Multipath TCP connection. The motivation for the procedure defined in > >> section 3.5 is to enable a host to quickly terminate a Multipath TCP > >> connection without being forced to send DATA_FINs. > >> > >> The current procedure defined in section 3.5 is that the host that > >> wishes to abruptly terminate a connection must send a RST on all > >> subflows except one where it sends an ACK with the FAST_CLOSE option a= nd > >> waits for a RST before closing the Multipath TCP connection. The > >> FAST_CLOSE option includes the receiver=E2=80=99s key to authenticate = the abrupt > >> release of the subflow. This prevents attacks where a remote attacker > >> could send spoofed packets that would terminate the Multipath TCP > >> connection. > >> > >> Unfortunately, the procedure defined in section 3.5 has a very importa= nt > >> drawback. Although the host wants to abruptly close the Multipath TCP > >> connection, it needs to maintain state for this connection until the > >> other host has confirmed (with a RST) the termination of the connectio= n. > >> This goes against the idea of abruptly closing connections due to lack > >> of ressources for example. We have faced some issues with applications > >> using SO_LINGER set to zero that were expecting the socket to have > >> disappeared after an abrupt release while it did not disappear. > >> > >> It would make sense to reconsider the abrupt connection termination > >> procedure defined in section 3.5 to enable a host to immediately > >> terminate a Multipath TCP connection and release the associated data > >> structures. One possibility would be to work as follows. > >> > >> Consider a Multipath TCP connection established between a client and a > >> server. There are two subflows, A and B. The server wants to abruptly > >> close the connection. For this, we propose to continue to use the > >> FAST_CLOSE option, but place it inside the RST packet sent over all > >> subflows. By using a RST instead of an ACK as in section 3.5, the serv= er > >> does not need to maintain any state and can remove the data structures > >> associated with the closed connection immediately. If one of the RST > >> packets reaches the client, it will know that the entire connection ha= s > >> been closed by the server. > >> > >> The only issue with this new approach is when none of the RST packets > >> sent by the server reach the client. We would be in a situation where > >> the client considers that the Multipath TCP is active while it does no= t > >> exist anymore on the server. After some time, the client will send a > >> packet to the server over one of the subflows. Since the Multipath TCP > >> connection does not exist anymore on the server, it will reply with a > >> RST packet that will close this subflow. The client will receive the > >> same RST over all the established subflows. When all subflows have bee= n > >> closed, the client should try to establish a new subflow to the server > >> by sending a SYN with MP_JOIN. Upon reception of this SYN, the server > >> will try to match the connection token with the established Multipath > >> TCP connection and will find that there is no matching connection. > >> According to RFC6824, the server should reply with a RST packet to clo= se > >> the subflow. We could add to this RST packet a new MP_TCPRST option > >> indicating that the server could not match the received token with an > >> existing connection. Upon reception of a RST carrying this option, the > >> client would know that the corresponding connection has been closed by > >> the server and would close it itself. > >> > >> We believe that this approach is simpler on the server side while stil= l > >> allowing clients to detect closed Multipath TCP connections. The abrup= t > >> closing (e.g. socket option SO_LINGER with zero timeout) is also > >> properly implemented. In contrast with the current approach, it places > >> the burden on the client instead of on the server, but we believe this > >> is beneficial for servers that often need to abruptly close connection= s. > >> > >> > >> Fran=C3=A7ois > >> > >> -- > >> > >> ------------------------------ > >> DISCLAIMER. > >> This email and any files transmitted with it are confidential and > intended > >> solely for the use of the individual or entity to whom they are > addressed. > >> If you have received this email in error please notify the system > manager. > >> This message contains confidential information and is intended only fo= r > the > >> individual named. If you are not the named addressee you should not > >> disseminate, distribute or copy this e-mail. Please notify the sender > >> immediately by e-mail if you have received this e-mail by mistake and > >> delete this e-mail from your system. If you are not the intended > recipient > >> you are notified that disclosing, copying, distributing or taking any > >> action in reliance on the contents of this information is strictly > >> prohibited. > >> > >> _______________________________________________ > >> multipathtcp mailing list > >> multipathtcp@ietf.org > >> https://www.ietf.org/mailman/listinfo/multipathtcp > > -- > > ------------------------------ > DISCLAIMER. > This email and any files transmitted with it are confidential and intende= d > solely for the use of the individual or entity to whom they are addressed= . > If you have received this email in error please notify the system manager= . > This message contains confidential information and is intended only for t= he > individual named. If you are not the named addressee you should not > disseminate, distribute or copy this e-mail. Please notify the sender > immediately by e-mail if you have received this e-mail by mistake and > delete this e-mail from your system. If you are not the intended recipien= t > you are notified that disclosing, copying, distributing or taking any > action in reliance on the contents of this information is strictly > prohibited. > --94eb2c0941c2c2f60205599a0b80 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Oliver, Francois,

Thanks for the com= ments.=C2=A0
One concern I have is it seems that people are expec= ting to expose this feature to apps although this won't be a recommende= d way to terminate an MPTCP session.=C2=A0
I think It won'= ;t be good if we end up always using it even when there's no resource l= imitations.
--
Yoshi

On Mon, Sep 18, 2017 at 4:58 AM, Fran= =C3=A7ois Finfe <francois.finfe@tessares.net> wrot= e:
Hi Yoshi,

On 2017-09-15 00:33, Yoshifumi Nishida wrote:
> Hi Francois,
>
> This is an interesting proposal for the bis draft. But, I guess the > receiver of FAST_CLOSE (will be clients in most cases) may need to
> wait longer time in some cases.
>
> I am thinking that the main motivation of SO_LINGER with zero timeout<= br> > approach is to avoid going into time_wait.
> I think MPTCP's FAST_CLOSE already takes care of this point to som= e
> extent and senders don't go into M_TIMEWAIT, although it requires = at
> least 1 RTT.
> So, I am still not very sure if we should save this 1 RTT or should > avoid unfortunate cases for long waiting.
Yes, in most likely cases, it will last 1 RTT. In worst case, = with 3
retransmissions and exp. backoff enabled, it will linger 8 RTO's.

1 RTT is relatively very high compared to the time to send an
MP_FASTCLOSE. On the current linux MPTCP implementation and on my
computer, the time required to fast close a MPTCP connection (send
MP_FASTCLOSE and RST's, without taking account the retransmissio= ns or
waiting for RST from the other peer) is 1 ms.

This time depends of a lot of factor but it is quite small compared to
typical values of RTT for DSL/LTE.

In the case of the SO_LINGER with zero timeout, the user space will
expect that "all queued messages for the socket have been successfully=
sent or the linger timeout has been reached" and nothing is done on background. By waiting for a RST in response to a MP_FASTCLOSE, it i= s
not possible to match the timing requirement, or it must be done it i= n
the background.

Abrupt connection closing can be explicitly set by the user space
software explicitly.

But, it can be tacitly set as well:
- on GNU/Linux, if a process is killed, all the established connection
=C2=A0 will be abruptly closed.
- Other scenarii are when the system is under pressure.

In these cases, quickly close a connection=C2=A0 is important.
>
>
> BTW, I happened to find that the state transition diagram in the draft=
> doesn't contain M_FASTCLOSE state, although it is mentioned in Sec= tion
> 3.5.
I don't know why it's n= ot mentioned. Maybe, it is omitted for the sake
of clarity, because you can switch from a lot of state (not only
established) to closed via fast close. On most TCP state transition
diagram, this transition (via a RST instead of a fast close) is not
mentioned either.

Fran=C3=A7ois

> Is this OK?<= br> >
> Thanks,
> --
> Yoshi
>
>
> On Wed, Sep 13, 2017 at 6:39 AM, Fran=C3=A7ois Finfe
> <f= rancois.finfe@tessares.net> wrote:
>> Hi,
>>
>>
>> RFC6824 and RFC6824bis use the FAST_CLOSE option to abruptly close= a
>> Multipath TCP connection. The motivation for the procedure defined= in
>> section 3.5 is to enable a host to quickly terminate a Multipath T= CP
>> connection without being forced to send DATA_FINs.
>>
>> The current procedure defined in section 3.5 is that the host that=
>> wishes to abruptly terminate a connection must send a RST on all >> subflows except one where it sends an ACK with the FAST_CLOSE opti= on and
>> waits for a RST before closing the Multipath TCP connection. The >> FAST_CLOSE option includes the receiver=E2=80=99s key to authentic= ate the abrupt
>> release of the subflow. This prevents attacks where a remote attac= ker
>> could send spoofed packets that would terminate the Multipath TCP<= br> >> connection.
>>
>> Unfortunately, the procedure defined in section 3.5 has a very imp= ortant
>> drawback. Although the host wants to abruptly close the Multipath = TCP
>> connection, it needs to maintain state for this connection until t= he
>> other host has confirmed (with a RST) the termination of the conne= ction.
>> This goes against the idea of abruptly closing connections due to = lack
>> of ressources for example. We have faced some issues with applicat= ions
>> using SO_LINGER set to zero that were expecting the socket to have=
>> disappeared after an abrupt release while it did not disappear. >>
>> It would make sense to reconsider the abrupt connection terminatio= n
>> procedure defined in section 3.5 to enable a host to immediately >> terminate a Multipath TCP connection and release the associated da= ta
>> structures. One possibility would be to work as follows.
>>
>> Consider a Multipath TCP connection established between a client a= nd a
>> server. There are two subflows, A and B. The server wants to abrup= tly
>> close the connection. For this, we propose to continue to use the<= br> >> FAST_CLOSE option, but place it inside the RST packet sent over al= l
>> subflows. By using a RST instead of an ACK as in section 3.5, the = server
>> does not need to maintain any state and can remove the data struct= ures
>> associated with the closed connection immediately. If one of the R= ST
>> packets reaches the client, it will know that the entire connectio= n has
>> been closed by the server.
>>
>> The only issue with this new approach is when none of the RST pack= ets
>> sent by the server reach the client. We would be in a situation wh= ere
>> the client considers that the Multipath TCP is active while it doe= s not
>> exist anymore on the server. After some time, the client will send= a
>> packet to the server over one of the subflows. Since the Multipath= TCP
>> connection does not exist anymore on the server, it will reply wit= h a
>> RST packet that will close this subflow. The client will receive t= he
>> same RST over all the established subflows. When all subflows have= been
>> closed, the client should try to establish a new subflow to the se= rver
>> by sending a SYN with MP_JOIN. Upon reception of this SYN, the ser= ver
>> will try to match the connection token with the established Multip= ath
>> TCP connection and will find that there is no matching connection.=
>> According to RFC6824, the server should reply with a RST packet to= close
>> the subflow. We could add to this RST packet a new MP_TCPRST optio= n
>> indicating that the server could not match the received token with= an
>> existing connection. Upon reception of a RST carrying this option,= the
>> client would know that the corresponding connection has been close= d by
>> the server and would close it itself.
>>
>> We believe that this approach is simpler on the server side while = still
>> allowing clients to detect closed Multipath TCP connections. The a= brupt
>> closing (e.g. socket option SO_LINGER with zero timeout) is also >> properly implemented. In contrast with the current approach, it pl= aces
>> the burden on the client instead of on the server, but we believe = this
>> is beneficial for servers that often need to abruptly close connec= tions.
>>
>>
>> Fran=C3=A7ois
>>
>> --
>>
>> ------------------------------
>> DISCLAIMER.
>> This email and any files transmitted with it are confidential and = intended
>> solely for the use of the individual or entity to whom they are ad= dressed.
>> If you have received this email in error please notify the system = manager.
>> This message contains confidential information and is intended onl= y for the
>> individual named. If you are not the named addressee you should no= t
>> disseminate, distribute or copy this e-mail. Please notify the sen= der
>> immediately by e-mail if you have received this e-mail by mistake = and
>> delete this e-mail from your system. If you are not the intended r= ecipient
>> you are notified that disclosing, copying, distributing or taking = any
>> action in reliance on the contents of this information is strictly=
>> prohibited.
>>
>> _______________________________________________
>> multipathtcp mailing list
>> multipa= thtcp@ietf.org
>> https://www.ietf.org/mailman/listinf= o/multipathtcp

--

------------------------------
DISCLAIMER.
This email and any files transmitted with it are confidential and intended<= br> solely for the use of the individual or entity to whom they are addressed.<= br> If you have received this email in error please notify the system manager.<= br> This message contains confidential information and is intended only for the=
individual named. If you are not the named addressee you should not
disseminate, distribute or copy this e-mail. Please notify the sender
immediately by e-mail if you have received this e-mail by mistake and
delete this e-mail from your system. If you are not the intended recipient<= br> you are notified that disclosing, copying, distributing or taking any
action in reliance on the contents of this information is strictly
prohibited.

--94eb2c0941c2c2f60205599a0b80-- From nobody Wed Sep 20 02:15:00 2017 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 349E61332F2 for ; Wed, 20 Sep 2017 02:14:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=tessares-net.20150623.gappssmtp.com 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 pw53FckueFBl for ; Wed, 20 Sep 2017 02:14:56 -0700 (PDT) Received: from mail-wm0-x234.google.com (mail-wm0-x234.google.com [IPv6:2a00:1450:400c:c09::234]) (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 8C0FA133087 for ; Wed, 20 Sep 2017 02:14:56 -0700 (PDT) Received: by mail-wm0-x234.google.com with SMTP id v142so5239610wmv.5 for ; Wed, 20 Sep 2017 02:14:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=tessares-net.20150623.gappssmtp.com; s=20150623; h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language; bh=O+Dpv9f+oMCYnBRU4VVA04SBLjxDa3CnBOXXn2Q339A=; b=zDSs8cdRpUmS30JCIjc6WzdZJ8KMLJzK67B7Rf8B8xqhWWsgmSWni6KsKB2BdwL8yo /nqnfKzX3HYoz5OZlaszUmCSHgVReGistV2T4a6HAdAXAmfRcmUN0nXwE40trYUxDfsw SDtLAx80IPf1VGPnMLwEriGiXFFN+0QwseBCvdtDg1/0lDnM/era3gKgKbkXRg6D9qwZ XnN1C1r12SDvtNoHEJbJCJKLJQTnFtlLYFmwVVISZYqT03Ytm6UJsc4hUZcg2vdySGve LSP3BnUnASPx5aKtsk9VZ4SvDPA5/JVgmZhWCETMaYT5dKDAUiuejaeFRUOsfd/UIS8N FMKw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language; bh=O+Dpv9f+oMCYnBRU4VVA04SBLjxDa3CnBOXXn2Q339A=; b=KriLud3oIifFqwZPHOL35gv/3lTTOWJ3A0ETbEk5hpjye8Gd6nIpR/Su/sPcWjyFka s4DG6zfACOaXA6kcV2SlTL53SKuEM/0EBrDI9tGkIS19TMf0JLwzuf+ANElN6ZTIetaW xI/7E/w0HDo8n2vSChMTlYBnoJhkNcJs8O7xiWQLbLk0OCI5QRRnuz5pJ7C9yOyFvzba 94KQscPi53+XJ2UqBBkgqUwKy+D9ZZn5XBhCS5Mr03vIU8/M8sx5lElCZglqxS+iSm0V O86bXAFz7pztVUjO5ja75tCg1uCNHB6lCXME1qrZarUs91J+Y9TgyhftRa3lzKRXDdZU s5wQ== X-Gm-Message-State: AHPjjUhi8wJwvsT1MNgZ8a1Ffmse8nqq6MfGeoqpH4+ABp3fI3y8dT8H b0GwdRz3+2gJsRW3Um1Zcv3MnFbWcUmXrge0LCzRA65UrJawf7/A7InzmLDMO34uPeOw74KSutb KWbJmXscgrknl X-Google-Smtp-Source: AOwi7QArtWHnspCIZ0Pdkhx/zAqcaV1PwednSvlI+ihm2N86DLDv7wFQTL7Ezi2X+zaOh+LtTV34jA== X-Received: by 10.28.217.134 with SMTP id q128mr3616903wmg.116.1505898894660; Wed, 20 Sep 2017 02:14:54 -0700 (PDT) Received: from mbpobo.local ([2001:6a8:308f:2:cdf3:179e:370e:f383]) by smtp.gmail.com with ESMTPSA id u1sm1253522wrd.95.2017.09.20.02.14.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 20 Sep 2017 02:14:54 -0700 (PDT) To: Yoshifumi Nishida , =?UTF-8?Q?Fran=c3=a7ois_Finfe?= Cc: multipathtcp References: <804577f3-f2a7-0726-08b3-717abe43f9c8@tessares.net> From: Olivier Bonaventure Message-ID: <34dd7328-53f6-a2a2-b11b-05c3ca240184@tessares.net> Date: Wed, 20 Sep 2017 11:14:54 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Language: fr-classic Archived-At: Subject: Re: [multipathtcp] Multipath TCP FAST_CLOSE - abrupt closing X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Sep 2017 09:14:58 -0000 Yoshifumi, > > Thanks for the comments. > One concern I have is it seems that people are expecting to expose this > feature to apps although this won't be a recommended way to terminate an > MPTCP session. > I think It won't be good if we end up always using it even when there's > no resource limitations. An implementation could send RST with an option on all paths when SO_LINGER is set to zero or under pressure and send RST without option on all paths except one when SO_LINGER is larger Olivier -- ------------------------------ DISCLAIMER. This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. If you are not the intended recipient you are notified that disclosing, copying, distributing or taking any action in reliance on the contents of this information is strictly prohibited. From nobody Thu Sep 21 11:00:39 2017 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B372913219F for ; Thu, 21 Sep 2017 11:00:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_SORBS_SPAM=0.5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=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 ZLfM4M4aLSVe for ; Thu, 21 Sep 2017 11:00:31 -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 96C1E132355 for ; Thu, 21 Sep 2017 11:00:30 -0700 (PDT) Received: from mail-yw0-f179.google.com (mail-yw0-f179.google.com [209.85.161.179]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 340E92783B4 for ; Fri, 22 Sep 2017 03:00:28 +0900 (JST) Received: by mail-yw0-f179.google.com with SMTP id v72so4621409ywa.3 for ; Thu, 21 Sep 2017 11:00:28 -0700 (PDT) X-Gm-Message-State: AHPjjUhGUbJk6b4WRyN3eprxEnO0uRW1gccBYM2CQo8vA6+gGfwVzwd0 rQz8LFWAJin65/5eYC1TOcyLRUntjB5lBYy6miY= X-Google-Smtp-Source: AOwi7QDV3iLwho5rIcL4O0hKCibAVV+ohxSu/aTWRBdQ6U4bs2Q9f2lMiW5rc2nlW9aPbKUI9YtkPRHqm+fAS2ovwWc= X-Received: by 10.37.173.2 with SMTP id y2mr2203589ybi.113.1506016826558; Thu, 21 Sep 2017 11:00:26 -0700 (PDT) MIME-Version: 1.0 Received: by 10.37.64.145 with HTTP; Thu, 21 Sep 2017 11:00:25 -0700 (PDT) In-Reply-To: <34dd7328-53f6-a2a2-b11b-05c3ca240184@tessares.net> References: <804577f3-f2a7-0726-08b3-717abe43f9c8@tessares.net> <34dd7328-53f6-a2a2-b11b-05c3ca240184@tessares.net> From: Yoshifumi Nishida Date: Thu, 21 Sep 2017 11:00:25 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Olivier Bonaventure Cc: Yoshifumi Nishida , =?UTF-8?Q?Fran=C3=A7ois_Finfe?= , multipathtcp Content-Type: multipart/alternative; boundary="f403045daf06f911250559b6dd74" Archived-At: Subject: Re: [multipathtcp] Multipath TCP FAST_CLOSE - abrupt closing X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Sep 2017 18:00:38 -0000 --f403045daf06f911250559b6dd74 Content-Type: text/plain; charset="UTF-8" Hi Olivier, On Wed, Sep 20, 2017 at 2:14 AM, Olivier Bonaventure < olivier.bonaventure@tessares.net> wrote: > Yoshifumi, > >> >> Thanks for the comments. >> One concern I have is it seems that people are expecting to expose this >> feature to apps although this won't be a recommended way to terminate an >> MPTCP session. >> I think It won't be good if we end up always using it even when there's >> no resource limitations. >> > > An implementation could send RST with an option on all paths when > SO_LINGER is set to zero or under pressure and send RST without option on > all paths except one when SO_LINGER is larger Right. I just thought it won't be good if applications always do SO_LINGER with zero timeout, although it'll be tricky for us to prevent it. In unfortunate cases, I think client will need to wait well enough amount of time or need to check possible paths to see if the session is really gone. I have a bit concern about the MP_TCPRST approach suggested by Francois, because MP_TCPRST probably doesn't have key info for authentication. So, I think we had better not close the session unless we receive MP_TCPRST from all possible paths (or at least more than 1) OTOH, if the client try to reduce the waiting time because of optimization, it might hurt break-before-make scenarios. -- Yoshi --f403045daf06f911250559b6dd74 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Olivier,

On Wed, Sep 20, 2017 at 2:14 AM, Olivier Bonaventure <olivier.bonaventure@tessares.net> wrote:
Yoshifumi,

Thanks for the comments.
One concern I have is it seems that people are expecting to expose this fea= ture to apps although this won't be a recommended way to terminate an M= PTCP session.
I think It won't be good if we end up always using it even when there&#= 39;s no resource limitations.

 An implementation could send RST with an option on all paths when SO_LINGER= is set to zero or under pressure and send RST without option on all paths = except one when SO_LINGER is larger

Right. = I just thought it won't be good if applications always do SO_LINGER wit= h zero timeout, although it'll be tricky for us to prevent it.
In unfortunate cases, I think client will need to wait well enough amount= of time or need to check possible paths to see if the session is really go= ne.

I have a bit concern about the=C2=A0MP_TCPRST approach suggested by Francois, because MP_TCPRST probably doesn't ha= ve key info for authentication.
So, I think we had better = not close the session unless we receive MP_TCPRST from all possible paths (= or at least more than 1)

OTOH, if the client try t= o reduce the waiting time because of optimization, it might hurt break-befo= re-make scenarios.
--
Yoshi

--f403045daf06f911250559b6dd74--