From nobody Thu Jul 2 22:54:03 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9916D1B2CC5 for ; Thu, 2 Jul 2015 22:54:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5Qyj3yiwR5i for ; Thu, 2 Jul 2015 22:53:59 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias245.francetelecom.com [80.12.204.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4043B1B2CC2 for ; Thu, 2 Jul 2015 22:53:59 -0700 (PDT) Received: from omfeda08.si.francetelecom.fr (unknown [xx.xx.xx.201]) by omfeda14.si.francetelecom.fr (ESMTP service) with ESMTP id 6470D2ACC0E for ; Fri, 3 Jul 2015 07:53:57 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.32]) by omfeda08.si.francetelecom.fr (ESMTP service) with ESMTP id 4C62C38404A for ; Fri, 3 Jul 2015 07:53:57 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0235.001; Fri, 3 Jul 2015 07:53:56 +0200 From: To: multipathtcp Thread-Topic: I-D Action: draft-boucadair-mptcp-dhc-00.txt Thread-Index: AQHQtM12FmWwAN3Ib0KCpE+wGlL5GZ3JP1Ww Date: Fri, 3 Jul 2015 05:53:55 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933005353D02@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <20150702134554.17997.15791.idtracker@ietfa.amsl.com> In-Reply-To: <20150702134554.17997.15791.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.3.50317 Archived-At: Subject: [multipathtcp] TR: I-D Action: draft-boucadair-mptcp-dhc-00.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 05:54:01 -0000 Dear all, Comments and suggestions are more than welcome.=20 Cheers, Med > -----Message d'origine----- > De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de > internet-drafts@ietf.org > Envoy=E9=A0: jeudi 2 juillet 2015 15:46 > =C0=A0: i-d-announce@ietf.org > Objet=A0: I-D Action: draft-boucadair-mptcp-dhc-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > Title : DHCP Options for Network-Assisted Multipath TCP > (MPTCP) > Authors : Mohamed Boucadair > Christian Jacquenet > Filename : draft-boucadair-mptcp-dhc-00.txt > Pages : 10 > Date : 2015-07-02 >=20 > Abstract: > One of the promising deployment scenarios for Multipath TCP (MPTCP) > is to enable a Customer Premises Equipment (CPE) that is connected to > multiple networks (e.g., DSL, LTE, WLAN) to optimize the usage of its > network attachments. Because of the lack of MPTCP support at the > server side, some service providers now consider a "network-assisted > mode" that relies upon the activation of a dedicated function called: > MPTCP Concentrator. This document focuses on the explicit deployment > scheme where the identity of the MPTCP Concentrator(s) is explicitly > configured on connected hosts. >=20 > This document specifies DHCP (IPv4 and IPv6) options to configure > hosts with Multipath TCP (MPTCP) parameters. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-boucadair-mptcp-dhc/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-boucadair-mptcp-dhc-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Thu Jul 2 23:28:08 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7787B1B2D30 for ; Thu, 2 Jul 2015 23:27:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 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_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LzwI1pdFX3sQ for ; Thu, 2 Jul 2015 23:27:41 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB03A1B2D2E for ; Thu, 2 Jul 2015 23:27:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3179; q=dns/txt; s=iport; t=1435904852; x=1437114452; h=from:to:subject:date:message-id:references:in-reply-to: content-transfer-encoding:mime-version; bh=fFqbAWuUg6oCgPcNBBfmhqpI4TPqAtPmhfgYaWzN+DI=; b=mEqivMACSJpZ8gzvxF+8aR2auqi+l9npj4pEJMS5FOo6H2lemRM38Wix +eKyhjvkVIkezmHvMOwBmyD2mZ43hFxRPS8+0t7pzMmr4H/OZXQdnm/ZY dNiJ1SvZ6qMfZDjH5hRNBqvvtK2re5FgH1gJ0E59phyLm6UrdTjGp7HSR k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0DRAwCMKpZV/4UNJK1SCYMSVF8GvTUJgWQKhS5KAoFFOBQBAQEBAQEBgQqEIwEBAQQBAQFrFwQCAQgRBAEBCx0HJwsUCQgCBAESCAGIJg3NYAEBAQEBAQEBAQEBAQEBAQEBAQEBAReLSoQqERozBQaDEYEUBYxPh0MBhGCIP0SDUItqhxEmg3pvAYFGgQQBAQE X-IronPort-AV: E=Sophos;i="5.15,398,1432598400"; d="scan'208";a="12360870" Received: from alln-core-11.cisco.com ([173.36.13.133]) by rcdn-iport-3.cisco.com with ESMTP; 03 Jul 2015 06:27:32 +0000 Received: from xhc-rcd-x14.cisco.com (xhc-rcd-x14.cisco.com [173.37.183.88]) by alln-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id t636RVsw005913 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Fri, 3 Jul 2015 06:27:32 GMT Received: from xmb-rcd-x10.cisco.com ([169.254.15.123]) by xhc-rcd-x14.cisco.com ([173.37.183.88]) with mapi id 14.03.0195.001; Fri, 3 Jul 2015 01:27:30 -0500 From: "Tirumaleswar Reddy (tireddy)" To: "mohamed.boucadair@orange.com" , multipathtcp Thread-Topic: I-D Action: draft-boucadair-mptcp-dhc-00.txt Thread-Index: AQHQtM12FmWwAN3Ib0KCpE+wGlL5GZ3JP1WwgAAID7A= Date: Fri, 3 Jul 2015 06:27:29 +0000 Message-ID: <913383AAA69FF945B8F946018B75898A478839DF@xmb-rcd-x10.cisco.com> References: <20150702134554.17997.15791.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B933005353D02@OPEXCLILMA3.corporate.adroot.infra.ftgroup> In-Reply-To: <787AE7BB302AE849A7480A190F8B933005353D02@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [173.39.65.226] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] I-D Action: draft-boucadair-mptcp-dhc-00.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 06:27:56 -0000 Hi Med, My comments=20 1) How will this work if endpoint is MPTCP-aware but CPE is not capable of = acting as MPTCP proxy ? 2)You may want to discuss how the proposed mechanism can be used with https= ://tools.ietf.org/html/draft-ietf-mif-mpvd-dhcp-support-01=20 Cheers, -Tiru > -----Original Message----- > From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of > mohamed.boucadair@orange.com > Sent: Friday, July 03, 2015 11:24 AM > To: multipathtcp > Subject: [multipathtcp] TR: I-D Action: draft-boucadair-mptcp-dhc-00.txt >=20 > Dear all, >=20 > Comments and suggestions are more than welcome. >=20 > Cheers, > Med >=20 > > -----Message d'origine----- > > De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part d= e > > internet-drafts@ietf.org Envoy=E9=A0: jeudi 2 juillet 2015 15:46 =C0=A0= : > > i-d-announce@ietf.org Objet=A0: I-D Action: > > draft-boucadair-mptcp-dhc-00.txt > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > directories. > > > > > > Title : DHCP Options for Network-Assisted Multipath T= CP > > (MPTCP) > > Authors : Mohamed Boucadair > > Christian Jacquenet > > Filename : draft-boucadair-mptcp-dhc-00.txt > > Pages : 10 > > Date : 2015-07-02 > > > > Abstract: > > One of the promising deployment scenarios for Multipath TCP (MPTCP) > > is to enable a Customer Premises Equipment (CPE) that is connected t= o > > multiple networks (e.g., DSL, LTE, WLAN) to optimize the usage of it= s > > network attachments. Because of the lack of MPTCP support at the > > server side, some service providers now consider a "network-assisted > > mode" that relies upon the activation of a dedicated function called= : > > MPTCP Concentrator. This document focuses on the explicit deploymen= t > > scheme where the identity of the MPTCP Concentrator(s) is explicitly > > configured on connected hosts. > > > > This document specifies DHCP (IPv4 and IPv6) options to configure > > hosts with Multipath TCP (MPTCP) parameters. > > > > > > > > The IETF datatracker status page for this draft is: > > https://datatracker.ietf.org/doc/draft-boucadair-mptcp-dhc/ > > > > There's also a htmlized version available at: > > https://tools.ietf.org/html/draft-boucadair-mptcp-dhc-00 > > > > > > Please note that it may take a couple of minutes from the time of > > submission until the htmlized version and diff are available at > > tools.ietf.org. > > > > Internet-Drafts are also available by anonymous FTP at: > > ftp://ftp.ietf.org/internet-drafts/ > > > > _______________________________________________ > > I-D-Announce mailing list > > I-D-Announce@ietf.org > > https://www.ietf.org/mailman/listinfo/i-d-announce > > Internet-Draft directories: http://www.ietf.org/shadow.html or > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Fri Jul 3 00:16:00 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BACB51B2E32 for ; Fri, 3 Jul 2015 00:15:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bYOHmWCmWMdq for ; Fri, 3 Jul 2015 00:15:56 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 359CE1B2E23 for ; Fri, 3 Jul 2015 00:15:56 -0700 (PDT) Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 6E57F32490E; Fri, 3 Jul 2015 09:15:54 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.60]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 495C023805C; Fri, 3 Jul 2015 09:15:54 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7F.corporate.adroot.infra.ftgroup ([fe80::c1d7:e278:e357:11ad%19]) with mapi id 14.03.0235.001; Fri, 3 Jul 2015 09:15:53 +0200 From: To: "Tirumaleswar Reddy (tireddy)" , multipathtcp Thread-Topic: I-D Action: draft-boucadair-mptcp-dhc-00.txt Thread-Index: AQHQtM12FmWwAN3Ib0KCpE+wGlL5GZ3JP1WwgAAID7CAAArHsA== Date: Fri, 3 Jul 2015 07:15:52 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933005353DAF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <20150702134554.17997.15791.idtracker@ietfa.amsl.com> <787AE7BB302AE849A7480A190F8B933005353D02@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <913383AAA69FF945B8F946018B75898A478839DF@xmb-rcd-x10.cisco.com> In-Reply-To: <913383AAA69FF945B8F946018B75898A478839DF@xmb-rcd-x10.cisco.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.2.125417 Archived-At: Subject: Re: [multipathtcp] I-D Action: draft-boucadair-mptcp-dhc-00.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 07:15:58 -0000 Hi Tiru, Thank you for the comments.=20 Please see inline. Cheers, Med > -----Message d'origine----- > De=A0: Tirumaleswar Reddy (tireddy) [mailto:tireddy@cisco.com] > Envoy=E9=A0: vendredi 3 juillet 2015 08:27 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; multipathtcp > Objet=A0: RE: I-D Action: draft-boucadair-mptcp-dhc-00.txt >=20 > Hi Med, >=20 > My comments > 1) How will this work if endpoint is MPTCP-aware but CPE is not capable o= f > acting as MPTCP proxy ? [Med] The draft assumes the following: "This deployment scenario relies on MPTCP Proxy on both the CPE and the network sides (Figure 1). " which means that the option is requested only when the CPE embeds an MPTCP = proxy.=20 As for an MPTCP-enabled host serviced by a CPE that does not embed an MPTCP= proxy, the behavior is left unspecified because we considered it is out of= scope. > 2)You may want to discuss how the proposed mechanism can be used with > https://tools.ietf.org/html/draft-ietf-mif-mpvd-dhcp-support-01 [Med] This is a good point...but the draft adopts a simple scheme where ava= ilable access networks belong to the same administrative entity. We may cla= rify this point in the next revision. >=20 > Cheers, > -Tiru >=20 > > -----Original Message----- > > From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of > > mohamed.boucadair@orange.com > > Sent: Friday, July 03, 2015 11:24 AM > > To: multipathtcp > > Subject: [multipathtcp] TR: I-D Action: draft-boucadair-mptcp-dhc-00.tx= t > > > > Dear all, > > > > Comments and suggestions are more than welcome. > > > > Cheers, > > Med > > > > > -----Message d'origine----- > > > De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part= de > > > internet-drafts@ietf.org Envoy=E9=A0: jeudi 2 juillet 2015 15:46 =C0= =A0: > > > i-d-announce@ietf.org Objet=A0: I-D Action: > > > draft-boucadair-mptcp-dhc-00.txt > > > > > > > > > A New Internet-Draft is available from the on-line Internet-Drafts > > > directories. > > > > > > > > > Title : DHCP Options for Network-Assisted Multipath > TCP > > > (MPTCP) > > > Authors : Mohamed Boucadair > > > Christian Jacquenet > > > Filename : draft-boucadair-mptcp-dhc-00.txt > > > Pages : 10 > > > Date : 2015-07-02 > > > > > > Abstract: > > > One of the promising deployment scenarios for Multipath TCP (MPTCP= ) > > > is to enable a Customer Premises Equipment (CPE) that is connected > to > > > multiple networks (e.g., DSL, LTE, WLAN) to optimize the usage of > its > > > network attachments. Because of the lack of MPTCP support at the > > > server side, some service providers now consider a "network- > assisted > > > mode" that relies upon the activation of a dedicated function > called: > > > MPTCP Concentrator. This document focuses on the explicit > deployment > > > scheme where the identity of the MPTCP Concentrator(s) is > explicitly > > > configured on connected hosts. > > > > > > This document specifies DHCP (IPv4 and IPv6) options to configure > > > hosts with Multipath TCP (MPTCP) parameters. > > > > > > > > > > > > The IETF datatracker status page for this draft is: > > > https://datatracker.ietf.org/doc/draft-boucadair-mptcp-dhc/ > > > > > > There's also a htmlized version available at: > > > https://tools.ietf.org/html/draft-boucadair-mptcp-dhc-00 > > > > > > > > > Please note that it may take a couple of minutes from the time of > > > submission until the htmlized version and diff are available at > > > tools.ietf.org. > > > > > > Internet-Drafts are also available by anonymous FTP at: > > > ftp://ftp.ietf.org/internet-drafts/ > > > > > > _______________________________________________ > > > I-D-Announce mailing list > > > I-D-Announce@ietf.org > > > https://www.ietf.org/mailman/listinfo/i-d-announce > > > Internet-Draft directories: http://www.ietf.org/shadow.html or > > > ftp://ftp.ietf.org/ietf/1shadow-sites.txt > > > > _______________________________________________ > > multipathtcp mailing list > > multipathtcp@ietf.org > > https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Fri Jul 3 04:34:30 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C82D41B2D7F for ; Fri, 3 Jul 2015 04:34:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qhGKxzn6vWyl for ; Fri, 3 Jul 2015 04:34:27 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9DD5E1B2A3F for ; Fri, 3 Jul 2015 04:34:26 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id DCA0A22CEE7 for ; Fri, 3 Jul 2015 13:34:24 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.31]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id B32A44C06E for ; Fri, 3 Jul 2015 13:34:24 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM22.corporate.adroot.infra.ftgroup ([fe80::8c90:f4e9:be28:2a1%19]) with mapi id 14.03.0235.001; Fri, 3 Jul 2015 13:34:24 +0200 From: To: multipathtcp Thread-Topic: I-D Action: draft-boucadair-mptcp-natfwfree-profile-00.txt Thread-Index: AQHQtXNaZSiyO9/XnE2fH1tBqRxCRp3JnUcg Date: Fri, 3 Jul 2015 11:34:23 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933005354242@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <20150703093326.19144.84475.idtracker@ietfa.amsl.com> In-Reply-To: <20150703093326.19144.84475.idtracker@ietfa.amsl.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.3.110316 Archived-At: Subject: [multipathtcp] TR: I-D Action: draft-boucadair-mptcp-natfwfree-profile-00.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2015 11:34:30 -0000 Dear all, Comments and suggestions are more than welcome. Cheers, Med > -----Message d'origine----- > De=A0: I-D-Announce [mailto:i-d-announce-bounces@ietf.org] De la part de > internet-drafts@ietf.org > Envoy=E9=A0: vendredi 3 juillet 2015 11:33 > =C0=A0: i-d-announce@ietf.org > Objet=A0: I-D Action: draft-boucadair-mptcp-natfwfree-profile-00.txt >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts > directories. >=20 >=20 > Title : An MPTCP Profile for NAT- and Firewall-Free > Networks: Network-Assisted MPTCP Deployments > Authors : Mohamed Boucadair > Christian Jacquenet > Pierrick Seite > Olivier Bonaventure > Lingli Deng > Filename : draft-boucadair-mptcp-natfwfree-profile-00.txt > Pages : 11 > Date : 2015-07-03 >=20 > Abstract: > One of the promising deployment scenarios for Multipath TCP (MPTCP) > is to enable a Customer Premises Equipment (CPE) that is connected to > multiple networks (e.g., DSL, LTE, WLAN) to optimize the usage of > such resources, thereby providing better serviceability overall > (including whenever the CPE fails to connect to one of the access > networks). This document specifies a MPTCP profile for such > deployments in network regions that are firewall- and NAT-free. >=20 >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-boucadair-mptcp-natfwfree-profile/ >=20 > There's also a htmlized version available at: > https://tools.ietf.org/html/draft-boucadair-mptcp-natfwfree-profile-00 >=20 >=20 > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. >=20 > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ >=20 > _______________________________________________ > I-D-Announce mailing list > I-D-Announce@ietf.org > https://www.ietf.org/mailman/listinfo/i-d-announce > Internet-Draft directories: http://www.ietf.org/shadow.html > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt From nobody Mon Jul 6 06:16:43 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9BD081A1B46; Mon, 6 Jul 2015 06:16:41 -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] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2P5PPMZtX0ps; Mon, 6 Jul 2015 06:16:40 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B8E11A1A72; Mon, 6 Jul 2015 06:16:40 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: X-Test-IDTracker: no X-IETF-IDTracker: 6.0.4.p1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <20150706131640.19378.74279.idtracker@ietfa.amsl.com> Date: Mon, 06 Jul 2015 06:16:40 -0700 Archived-At: Cc: multipathtcp@ietf.org Subject: [multipathtcp] I-D Action: draft-ietf-mptcp-experience-02.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 13:16:41 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Multipath TCP Working Group of the IETF. Title : Use Cases and Operational Experience with Multipath TCP Authors : Olivier Bonaventure Christoph Paasch Gregory Detal Filename : draft-ietf-mptcp-experience-02.txt Pages : 24 Date : 2015-07-06 Abstract: This document discusses both use cases and operational experience with Multipath TCP in real world networks. It lists several prominent use cases for which Multipath TCP has been considered and is being used. It also gives insight to some heuristics and decisions that have helped to realize these use cases. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-mptcp-experience/ There's also a htmlized version available at: https://tools.ietf.org/html/draft-ietf-mptcp-experience-02 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-mptcp-experience-02 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jul 6 11:01:29 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF7741A1B19 for ; Mon, 6 Jul 2015 11:01:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2XAKknM9wENZ for ; Mon, 6 Jul 2015 11:01:26 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.135]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDF271A1B30 for ; Mon, 6 Jul 2015 11:01:25 -0700 (PDT) Received: from E07HT02-UKBR.domain1.systemhost.net (193.113.197.160) by EVMED01-UKBR.bt.com (10.216.161.31) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 6 Jul 2015 19:01:22 +0100 Received: from rew09926dag03d.domain1.systemhost.net (10.55.202.30) by E07HT02-UKBR.domain1.systemhost.net (193.113.197.160) with Microsoft SMTP Server (TLS) id 8.3.342.0; Mon, 6 Jul 2015 19:01:22 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03d.domain1.systemhost.net (10.55.202.30) with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 6 Jul 2015 19:01:21 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.0995.031; Mon, 6 Jul 2015 19:01:21 +0100 From: To: Thread-Topic: Preparing for Prague meeting - things to delete or add to MPTCP protocol bis Thread-Index: AQHQuBC1ogV2Z1ShB0+RXyp9UJJDtJ3Ou0Bj Date: Mon, 6 Jul 2015 18:01:21 +0000 Message-ID: <1436205703501.53882@bt.com> References: <1436204168109.20146@bt.com> In-Reply-To: <1436204168109.20146@bt.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.216.161.24] Content-Type: multipart/alternative; boundary="_000_143620570350153882btcom_" MIME-Version: 1.0 Archived-At: Subject: [multipathtcp] Preparing for Prague meeting - things to delete or add to MPTCP protocol bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 06 Jul 2015 18:01:28 -0000 --_000_143620570350153882btcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, In the Prague meeting, we aim to move forward the protocol bis doc (to meet= ing our Cahrter objetive for a standards track version of RFC6824) One topic we'd like to discuss is if there's anything that should be delete= d from or added to the current draft, https://tools.ietf.org/wg/mptcp/draft-ietf-mptcp-= rfc6824bis/ - based on operational and implementation experience. Any proposals? Looking at the (expired) draft summarising the various implementations, https://tools.ietf.org/html/draft-eardley-mptcp-implementations-survey-02 one thing that may be worth discussing is whether we need both 4 & 8 byte D= ata ack & DSS << All implementations support 4 bytes "Data ACK" and "Data sequence number" fields, and will interoperate with an implementation sending 8 bytes. Implementation 1 uses only 4 bytes fields; if an implementation sends an 8 byte data sequence number it replies with a 4 byte data ack. >> I don't think the implementation survey suggests that there's anything else= worth considering deleting - are there any other proposals? As to things to add, there are a few proposals for some (minor?) additions = in the recent set of drafts from Olivier Bonaventure and team. Since we have a lot more requests for presentation time than it's possible = to squeeze into the meeting, it would be excellent to have discussion on th= e list before the meeting, about anything that should be added to, or delet= ed from, the current rfc6824bis, before we progress it to WG last call. thanks! --_000_143620570350153882btcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

In the Prague meeting, we aim to move forward the protocol bis doc (to m= eeting our Cahrter objetive for a standards track version of RFC6824)

 

One topic we'd like to discuss is if there's anything that should be del= eted from or added to the current draft, = https://tools.ietf.org/wg/mptcp/draft-ietf-mptcp-rfc6824bis/ - bas= ed on operational and implementation experience.

 

Any proposals?

 

Looking at the (expired) draft summarising the various implementations, =

https://tools.ietf.org/html/draft-eardley-mptcp-implementatio= ns-survey-02

one thing that may be worth discussing is whether we need both 4 & 8= byte Data ack & DSS

<<   All implementations support 4 bytes "Data ACK&= quot; and "Data sequence
   number" fields, and will interoperate with an implementat= ion sending
   8 bytes.  Implementation 1 uses only 4 bytes fields; if a= n
   implementation sends an 8 byte data sequence number it replies= with a
   4 byte data ack.

>>

 

I don't think the implementation survey suggests that there's anything e= lse worth considering deleting - are there any other proposals?

 

As to things to add, there are a few proposals for some (minor?) additio= ns in the recent set of drafts from Olivier Bonaventure and team.

 

Since we have a lot more requests for presentation time than it's possib= le to squeeze into the meeting, it would be excellent to have discussion on= the list before the meeting, about anything that should be added to, or de= leted from, the current rfc6824bis, before we progress it to WG last call.

 

thanks!

--_000_143620570350153882btcom_-- From nobody Mon Jul 6 23:30:59 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3FD2F1A9104 for ; Mon, 6 Jul 2015 23:30:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cL8CZTiR_SPc for ; Mon, 6 Jul 2015 23:30:56 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C5F3B1A9110 for ; Mon, 6 Jul 2015 23:30:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1436250656; x=2300164256; 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=Y814xjdXJuxRRfsEaN4w67LFPLCvMGBOV1Yhz6u6lO8=; b=pat+wnFWspqtcZzeD9bQqWjdFTcc4vvjt7MT+ko1hQMOcw8iMQdHAUdqIAAFf7q8 NPcuR91tiAWm7doj8KTErbkKZGFNhWNLj2NqgxjByGXJ7kSHxYYoFLA3XsUgAXd0 4lCd4lrEsFsemcN14KqeiZoMVr5/lAbsJegfYL7Cw65DadOSpKMTeNOVKwVOLXJJ m5vmMJsSbyak0nOFGxtxP+HnhNmSuWHHWf8Wcj2EbllFqehzH6wn3RWaJ9AlIrRu 41BqtjXVw2QlTqKJW7hy1GP66NkUme/WEBHnqmvNuMUQHSxqo3sPTSOA0ON/3XLg ZCOvzdeONhg9T3rniBR4jQ==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 49.1C.09370.0227B955; Mon, 6 Jul 2015 23:30:56 -0700 (PDT) X-AuditID: 11973e16-f79856d00000249a-99-559b7220bb75 Received: from chive.apple.com (chive.apple.com [17.128.115.15]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id C7.77.14452.4B36B955; Mon, 6 Jul 2015 22:29:25 -0700 (PDT) Received: from localhost ([17.153.26.188]) by chive.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NR3001Q3U3JIW30@chive.apple.com> for multipathtcp@ietf.org; Mon, 06 Jul 2015 23:30:56 -0700 (PDT) Date: Mon, 06 Jul 2015 23:30:55 -0700 From: Christoph Paasch To: philip.eardley@bt.com Message-id: <20150707063055.GL25229@Chimay.local> References: <1436204168109.20146@bt.com> <1436205703501.53882@bt.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline In-reply-to: <1436205703501.53882@bt.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrILMWRmVeSWpSXmKPExsUi2FAYpatQNDvUoO89r8Xn1dfZHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV0TTxLGPBHOGK5nd3mBsYT/J3MXJySAiYSOxc2sQGYYtJXLi3 Hsjm4hAS2Mso8Xr2KVaYoukr1rBDJLqZJJrXfWGFcFqZJKb8ugfWziKgKnG2B6SKk4NNQEvi 7e12sG4RAUmJFdtXgdUwg9h/P4HFhQWyJPo7l7KA2LwChhIzVl1l6mLkABrqKjHtjRdEWFDi x+R7LBCtWhLrdx5ngrClJR79ncEOUs4poCmxbEkeSFhUQEXiyoS3YHdKCLxklfg+Yz77BEbh WUhGzUIyahaSUQsYmVcxCuUmZuboZuaZ6yUWFOSk6iXn525iBIXxdDuxHYwPV1kdYhTgYFTi 4b0hMTtUiDWxrLgy9xCjNAeLkjhvThZQSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA2NP767+ yu2M/2fWzKqqnPSfa0Yxq6NU0YFTN/IDnsze+y3uSxTDsQlu99/E1ouf1vr273DQZj3VTJbd Sk7GAfushb7M3/Jpf5r+j6uy+ya8mLyQ/71Cbcujp++8G5Xjnly47vDIikVpPiszp51AM8/i CU/F1z3sv3KDf/ffq0xse5UrS7g2Mv1XYinOSDTUYi4qTgQALlvIJEQCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUi2FDMr7s1eXaowWxPi8+rr7M5MHosWfKT KYAxissmJTUnsyy1SN8ugSujaeJZxoI5whXN7+4wNzCe5O9i5OSQEDCRmL5iDTuELSZx4d56 ti5GLg4hgW4mieZ1X1ghnFYmiSm/7rGBVLEIqEqc7YHoYBPQknh7u50VxBYRkJRYsX0VWA0z iP33E1hcWCBLor9zKQuIzStgKDFj1VWmLkYOoKGuEtPeeEGEBSV+TL7HAtGqJbF+53EmCFta 4tHfGewg5ZwCmhLLluSBhEUFVCSuTHjLPoFRYBaS7llIumch6V7AyLyKUaAoNSex0kwvsaAg J1UvOT93EyM46AqjdjA2LLc6xCjAwajEw3uCa3aoEGtiWXFl7iFGCQ5mJRHeCj2gEG9KYmVV alF+fFFpTmrxIUZpDhYlcd79rVNChQTSE0tSs1NTC1KLYLJMHJxSDYwOmx2btyWuPXmtTEFA uP3bj1ThuEsPDu9iqEhVqpFTqjin61JyTsbj6OafO56VSs/l3pV0zOXZqu3h+b+dbsU4OGws nxT/3+jkLuYSf85FEt5Xm3Q5jC0qkiYkqtr7hK4V6Lt1I9b0fQjHmayIDc5mvK+jJs9aY5V+ ZglvEsueXfbaSkfEviqxFGckGmoxFxUnAgA1z6FYNgIAAA== Archived-At: Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Preparing for Prague meeting - things to delete or add to MPTCP protocol bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 06:30:58 -0000 Hello, On 06/07/15 - 18:01:21, philip.eardley@bt.com wrote: > In the Prague meeting, we aim to move forward the protocol bis doc (to > meeting our Cahrter objetive for a standards track version of RFC6824) > > > > One topic we'd like to discuss is if there's anything that should be > deleted from or added to the current draft, > > https://tools.ietf.org/wg/mptcp/draft-ietf-mptcp-rfc6824bis/ - based on > operational and implementation experience. > > > > Any proposals? Might we consider to include something similar to draft-paasch-mptcp-syncookies-00 in RFC6824bis, to better handle MPTCP on stateless webservers? We received offline-comments from Olivier and Alan on the draft and still have to update it. However, neither I nor Anumita won't be able to attend the IETF in Prague. draft-paasch-mptcp-syncookies-00 however also depends on whether we intend to bump the MPTCP-version number up to 1 for RFC6824bis. > Looking at the (expired) draft summarising the various implementations, > > https://tools.ietf.org/html/draft-eardley-mptcp-implementations-survey-02 > > one thing that may be worth discussing is whether we need both 4 & 8 byte > Data ack & DSS > > << All implementations support 4 bytes "Data ACK" and "Data sequence > number" fields, and will interoperate with an implementation sending 8 > bytes. Implementation 1 uses only 4 bytes fields; if an implementation > sends an 8 byte data sequence number it replies with a 4 byte data ack. > > >> I think that both, 8 bytes Data-ACK and DSS are necessary, because it may (in theory) be possible that a segment on one subflow gets delayed while the other one advances the sequence numbers by 2^32 bytes. In that case this old segment will be considered as valid. 64-bit sequence numbers will protect against this. > I don't think the implementation survey suggests that there's anything > else worth considering deleting - are there any other proposals? > > > > As to things to add, there are a few proposals for some (minor?) additions > in the recent set of drafts from Olivier Bonaventure and team. +1 on draft-bonaventure-mptcp-exp-option-00, as it allows to experiment to figure out which other signalling mechanisms would be useful to control the scheduling across the subflows or policies for subflow creation. Cheers, Christoph From nobody Tue Jul 7 00:12:20 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 884231A0095 for ; Tue, 7 Jul 2015 00:12:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ulzzhJjni0L2 for ; Tue, 7 Jul 2015 00:12:16 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 A647D1A0076 for ; Tue, 7 Jul 2015 00:12:16 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t677CGGM017856 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 7 Jul 2015 07:12:16 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t677CFbK013405 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 7 Jul 2015 07:12:16 GMT Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t677CFlu019020 for ; Tue, 7 Jul 2015 07:12:15 GMT Received: from [192.168.1.5] (/67.180.17.69) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 07 Jul 2015 00:12:15 -0700 Message-ID: <559B7BCD.4050704@oracle.com> Date: Tue, 07 Jul 2015 00:12:13 -0700 From: Rao Shoaib User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: multipathtcp@ietf.org References: <1436204168109.20146@bt.com> <1436205703501.53882@bt.com> In-Reply-To: <1436205703501.53882@bt.com> Content-Type: multipart/alternative; boundary="------------090207000607080405020503" X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: Re: [multipathtcp] Preparing for Prague meeting - things to delete or add to MPTCP protocol bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 07:12:18 -0000 This is a multi-part message in MIME format. --------------090207000607080405020503 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit While implementing MPTCP for Solaris I struggled with how the keys and tokens were created and used. It is not clear what needs to be in network byte order. I got interoperability with Linux by simply trying the combinations. It might be good to add some specifics unless the community feels that it is just my lack of understanding of cryptography. Regards, Shoaib On 07/06/2015 11:01 AM, philip.eardley@bt.com wrote: > > Hi, > > In the Prague meeting, we aim to move forward the protocol bis doc (to > meeting our Cahrter objetive for a standards track version of RFC6824) > > One topic we'd like to discuss is if there's anything that should be > deleted from or added to the current draft, > https://tools.ietf.org/wg/mptcp/draft-ietf-mptcp-rfc6824bis/ - based > on operational and implementation experience. > > Any proposals? > > Looking at the (expired) draft summarising the various implementations, > > https://tools.ietf.org/html/draft-eardley-mptcp-implementations-survey-02 > > one thing that may be worth discussing is whether we need both 4 & 8 > byte Data ack & DSS > > << All implementations support 4 bytes "Data ACK" and "Data sequence > number" fields, and will interoperate with an implementation sending > 8 bytes. Implementation 1 uses only 4 bytes fields; if an > implementation sends an 8 byte data sequence number it replies with a > 4 byte data ack. > > >> > > I don't think the implementation survey suggests that there's anything > else worth considering deleting - are there any other proposals? > > As to things to add, there are a few proposals for some (minor?) > additions in the recent set of drafts from Olivier Bonaventure and team. > > Since we have a lot more requests for presentation time than it's > possible to squeeze into the meeting, it would be excellent to have > discussion on the list before the meeting, about anything that should > be added to, or deleted from, the current rfc6824bis, before we > progress it to WG last call. > > thanks! > > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp --------------090207000607080405020503 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit While implementing MPTCP for Solaris I struggled with how the keys and tokens were created and used. It is not clear what needs to be in network byte order. I got interoperability with Linux by simply trying the combinations. It might be good to add some specifics unless the community feels that it is just my lack of understanding of cryptography.

Regards,

Shoaib

On 07/06/2015 11:01 AM, philip.eardley@bt.com wrote:

Hi,

In the Prague meeting, we aim to move forward the protocol bis doc (to meeting our Cahrter objetive for a standards track version of RFC6824)

 

One topic we'd like to discuss is if there's anything that should be deleted from or added to the current draft, https://tools.ietf.org/wg/mptcp/draft-ietf-mptcp-rfc6824bis/ - based on operational and implementation experience.

 

Any proposals?

 

Looking at the (expired) draft summarising the various implementations,

https://tools.ietf.org/html/draft-eardley-mptcp-implementations-survey-02

one thing that may be worth discussing is whether we need both 4 & 8 byte Data ack & DSS

<<   All implementations support 4 bytes "Data ACK" and "Data sequence
   number" fields, and will interoperate with an implementation sending
   8 bytes.  Implementation 1 uses only 4 bytes fields; if an
   implementation sends an 8 byte data sequence number it replies with a
   4 byte data ack.

>>

 

I don't think the implementation survey suggests that there's anything else worth considering deleting - are there any other proposals?

 

As to things to add, there are a few proposals for some (minor?) additions in the recent set of drafts from Olivier Bonaventure and team.

 

Since we have a lot more requests for presentation time than it's possible to squeeze into the meeting, it would be excellent to have discussion on the list before the meeting, about anything that should be added to, or deleted from, the current rfc6824bis, before we progress it to WG last call.

 

thanks!



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

--------------090207000607080405020503-- From nobody Tue Jul 7 00:17:17 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E85DA1A00C3 for ; Tue, 7 Jul 2015 00:17:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1HRNnIjeUmgS for ; Tue, 7 Jul 2015 00:17:16 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 1ED8E1A00BB for ; Tue, 7 Jul 2015 00:17:16 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t677HFP5002054 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 7 Jul 2015 07:17:15 GMT Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t677HEwF029353 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Tue, 7 Jul 2015 07:17:14 GMT Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23]) by aserv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t677HENs010829 for ; Tue, 7 Jul 2015 07:17:14 GMT Received: from [10.159.187.127] (/10.159.187.127) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 07 Jul 2015 00:17:14 -0700 Message-ID: <559B7CF8.4040909@oracle.com> Date: Tue, 07 Jul 2015 00:17:12 -0700 From: Rao Shoaib User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: multipathtcp@ietf.org Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: [multipathtcp] MPTCP compliance test suite X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 07:17:17 -0000 Hi All, Is there a MPTCP compliance test suite to evaluate the compliance of an implementation. Regards, Shoaib From nobody Tue Jul 7 00:27:44 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 490391A00D6 for ; Tue, 7 Jul 2015 00:27:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.901 X-Spam-Level: X-Spam-Status: No, score=-2.901 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2aEmlg9jkWxN for ; Tue, 7 Jul 2015 00:27:40 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 509C61A00E0 for ; Tue, 7 Jul 2015 00:27:40 -0700 (PDT) Received: from mbpobo.local (unknown [82.33.220.194]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 37B461834CB; Tue, 7 Jul 2015 09:27:31 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 37B461834CB DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1436254051; bh=idvkFdBDe5C3Bn+L73fN/4YvC0XS+7buJJ4HWEYlJxc=; h=Reply-To:Subject:References:To:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=X47RhpuZRJhR6tQAck1DDMcy3FSAnp2xFlZzxOuQfoeRG9QrtivdTKH67OukKwBUM aLU4xAwtH7ezHLAGBRc3VIRzVOUAKX45/JF8lW5ds8Y9BfByZABNK/Yiy5ra902kt6 6Gnd58DEVhxJJflntckCfOFB4uYEfC+STuOiP0so= References: <559B7CF8.4040909@oracle.com> To: Rao Shoaib , multipathtcp@ietf.org From: Olivier Bonaventure Message-ID: <559B7F61.4080701@uclouvain.be> Date: Tue, 7 Jul 2015 09:27:29 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <559B7CF8.4040909@oracle.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99-beta1 at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 37B461834CB.A4B34 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Subject: Re: [multipathtcp] MPTCP compliance test suite X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 07 Jul 2015 07:27:43 -0000 Hello, > > Is there a MPTCP compliance test suite to evaluate the compliance of an > implementation. Not in the working group. One of our students wrote such a test during his Master thesis and presented it at the IETF and the area directors replied that an IETF WG should not work on conformance tests... The draft is still available at https://tools.ietf.org/html/draft-coene-mptcp-conformance-00 Two of our students also wrote a version of packetdrill that has been adapted for MPTCP and could be useful if you define tests https://github.com/aschils/packetdrill_mptcp Despite the fact that the IETF will not define conformance tests, it would be interesting to collect information about the test suites that implementors use to validate their implementation. Olivier From nobody Tue Jul 7 18:31:29 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC10F1B2C96 for ; Tue, 7 Jul 2015 18:31:28 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.21 X-Spam-Level: X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9KDr7zJeNE9T for ; Tue, 7 Jul 2015 18:31:26 -0700 (PDT) Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (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 67DA91B2C94 for ; Tue, 7 Jul 2015 18:31:26 -0700 (PDT) Received: from aserv0021.oracle.com (aserv0021.oracle.com [141.146.126.233]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t681VP3e004117 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 8 Jul 2015 01:31:25 GMT Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t681VPbT024874 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Wed, 8 Jul 2015 01:31:25 GMT Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t681VP5G019721 for ; Wed, 8 Jul 2015 01:31:25 GMT Received: from [10.159.187.127] (/10.159.187.127) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 07 Jul 2015 18:31:25 -0700 Message-ID: <559C7D68.3080002@oracle.com> Date: Tue, 07 Jul 2015 18:31:20 -0700 From: Rao Shoaib User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: multipathtcp@ietf.org Content-Type: multipart/alternative; boundary="------------060207000807040107030107" X-Source-IP: aserv0021.oracle.com [141.146.126.233] Archived-At: Subject: [multipathtcp] Need clarification on data mapping X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 01:31:28 -0000 This is a multi-part message in MIME format. --------------060207000807040107030107 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Hi, I need clarification on following issues regarding data mapping in RFC 6824 1) "The sender MUST keep data in its send buffer as long as the data has not been acknowledged at both connection level and on all subflows on which it has been sent." Does an implementation has to verify acknowledgements on all flows or is a connection level ack on any subflow sufficient. 2) " A mapping is fixed, in that the subflow sequence number is bound to the data sequence number after the mapping has been processed. A sender MUST NOT change this mapping after it has been declared;" This does not disallow sending the same data sequence in future using a different subflow sequence number. Correct ? Thanks, Shoaib --------------060207000807040107030107 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit Hi,

I need clarification on following issues regarding data mapping in RFC 6824

1)
"The sender MUST keep data in its send buffer as long as the data has
 not been acknowledged at both connection level and on all subflows on
 which it has been sent."
Does an implementation has to verify acknowledgements on all flows or is a connection level ack on any subflow sufficient.

2)
" A mapping is fixed, in that the subflow sequence number is bound to the data sequence number after the mapping has been processed. A sender MUST NOT change this mapping after it has been declared;"

This does not disallow sending the same data sequence in future using a different subflow sequence number. Correct ?

Thanks,

Shoaib




--------------060207000807040107030107-- From nobody Wed Jul 8 00:44:49 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D58DC1B320D for ; Wed, 8 Jul 2015 00:44:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.689 X-Spam-Level: X-Spam-Status: No, score=0.689 tagged_above=-999 required=5 tests=[BAYES_50=0.8, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0VSPlkp4UZpY for ; Wed, 8 Jul 2015 00:44:45 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 101C51B320B for ; Wed, 8 Jul 2015 00:44:44 -0700 (PDT) Received: from EVMHT04-UKBR.domain1.systemhost.net (193.113.108.57) by EVMED05-UKBR.bt.com (10.216.161.37) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 8 Jul 2015 08:44:39 +0100 Received: from rew09926dag03d.domain1.systemhost.net (10.55.202.30) by EVMHT04-UKBR.domain1.systemhost.net (193.113.108.57) with Microsoft SMTP Server (TLS) id 8.3.342.0; Wed, 8 Jul 2015 08:44:32 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03d.domain1.systemhost.net (10.55.202.30) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 8 Jul 2015 08:44:31 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.0995.031; Wed, 8 Jul 2015 08:44:31 +0100 From: To: Thread-Topic: [multipathtcp] IETF hackathon Thread-Index: AQHQl7FjqKxTwo7rTUWo1H6VVrM8iJ3Rc0QA Date: Wed, 8 Jul 2015 07:44:31 +0000 Message-ID: <3d33a478f86940c9beb5af4ba238edf2@rew09926dag03b.domain1.systemhost.net> References: <07A05FD5-A69A-4AD5-9093-8C6CFB8886E3@piuha.net> <1431857585427.77044@bt.com> <555AECAD.8050907@uclouvain.be> <3139857.6Qu1WdSWEE@nordmarka.simula.nornet> In-Reply-To: <3139857.6Qu1WdSWEE@nordmarka.simula.nornet> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.202.233] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] IETF hackathon X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 07:44:48 -0000 Several people have signed up for the hackathon and mention MPTCP, which is= great http://www.ietf.org/hackathon/93-hackathon.html=20 I suggest you coordinate directly amongst yourselves.=20 Also, the capacity is declared at 100 people - there are already 95 for Sat= and 112 for Sunday, so I guess you should arrive early to get a seat! phil > -----Original Message----- > From: Thomas Dreibholz [mailto:dreibh@iem.uni-due.de] > Sent: 26 May 2015 13:42 > To: multipathtcp@ietf.org; Olivier.Bonaventure@uclouvain.be > Cc: Eardley,PL,Philip,TUB8 R > Subject: Re: [multipathtcp] IETF hackathon >=20 > Hi, >=20 > Tirsdag 19. mai 2015 09.56.29 skrev Olivier Bonaventure: > > If there are some members of the list who would be interested in > > working with us on the Multipath TCP implementation in the Linux > > kernel or related tools like mptcptrace or tracebox, we could > organise > > something in Prague. >=20 > This is a great idea! >=20 > I will be in Prague as well and can provide interested people access to > the NorNet Core infrastructure. I have ~100 nodes with a pre-installed > Linux MPTCP kernel, and I could further instantiate some full VMs with > Linux and FreeBSD 10.1 for running modified MPTCP kernel versions. The > NorNet Core systems are distributed at ca. 20 sites, most of them with > IPv4/IPv6 multi-homing and many of the sites also have multiple > independent ISPs. A list of the sites is provided at > https://www.nntb.no/pub/nornet-configuration/NorNetCore-Sites.html . I > think this is can be an interesting and challenging setup for some > real-world MPTCP tests. >=20 > More details on NorNet Core are provided on the project website at > https://www.nntb.no/ . >=20 > -- > Best regards / Mit freundlichen Gr=FC=DFen / Med vennlig hilsen >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > Thomas Dreibholz >=20 > Simula Research Laboratory > Simula Innovation AS, Network Systems Group Visiting address: Martin > Linges vei 17, 1364 Fornebu, Norway Mailing address: P.O.Box 134, > 1325 Lysaker, Norway > ----------------------------------------------------------------------- > E-Mail: dreibh@simula.no > Homepage: http://simula.no/people/dreibh > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D From nobody Wed Jul 8 00:52:19 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA1A41B322A for ; Wed, 8 Jul 2015 00:52:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.215 X-Spam-Level: ** X-Spam-Status: No, score=2.215 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RELAY_IS_203=0.994, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n1xWkrb3yI3y for ; Wed, 8 Jul 2015 00:52:16 -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 D7B9D1B3225 for ; Wed, 8 Jul 2015 00:52:15 -0700 (PDT) Received: from mail-oi0-f53.google.com (mail-oi0-f53.google.com [209.85.218.53]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id EDB0527812C for ; Wed, 8 Jul 2015 16:52:11 +0900 (JST) Received: by oiab3 with SMTP id b3so41723969oia.1 for ; Wed, 08 Jul 2015 00:52:10 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.202.108.142 with SMTP id h136mr7934099oic.5.1436341930451; Wed, 08 Jul 2015 00:52:10 -0700 (PDT) Received: by 10.202.177.193 with HTTP; Wed, 8 Jul 2015 00:52:10 -0700 (PDT) In-Reply-To: <559B7F61.4080701@uclouvain.be> References: <559B7CF8.4040909@oracle.com> <559B7F61.4080701@uclouvain.be> Date: Wed, 8 Jul 2015 00:52:10 -0700 Message-ID: From: Yoshifumi Nishida To: Olivier Bonaventure Content-Type: multipart/alternative; boundary=001a1142da9c8a69c0051a586a09 Archived-At: Cc: multipathtcp Subject: Re: [multipathtcp] MPTCP compliance test suite X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 07:52:17 -0000 --001a1142da9c8a69c0051a586a09 Content-Type: text/plain; charset=UTF-8 On Tue, Jul 7, 2015 at 12:27 AM, Olivier Bonaventure < Olivier.Bonaventure@uclouvain.be> wrote: > Hello, > >> >> Is there a MPTCP compliance test suite to evaluate the compliance of an >> implementation. >> > > Not in the working group. One of our students wrote such a test during his > Master thesis and presented it at the IETF and the area directors replied > that an IETF WG should not work on conformance tests... > > The draft is still available at > > https://tools.ietf.org/html/draft-coene-mptcp-conformance-00 > > > Two of our students also wrote a version of packetdrill that has been > adapted for MPTCP and could be useful if you define tests > > https://github.com/aschils/packetdrill_mptcp > > Despite the fact that the IETF will not define conformance tests, it would > be interesting to collect information about the test suites that > implementors use to validate their implementation. Just in case.. We might not standardize conformance tests, but I think it should be totally fine to use the WG to discuss them or share the related info. Thanks, -- Yoshi --001a1142da9c8a69c0051a586a09 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
On T= ue, Jul 7, 2015 at 12:27 AM, Olivier Bonaventure <Olivier.B= onaventure@uclouvain.be> wrote:
Hello,

Is there a MPTCP compliance test suite to evaluate the compliance of an
implementation.

 Not in the working group. One of our students wrote such a test during his = Master thesis and presented it at the IETF and the area directors replied t= hat an IETF WG should not work on conformance tests...

The draft is still available at

https://tools.ietf.org/html/draft-coene-= mptcp-conformance-00


Two of our students also wrote a version of packetdrill that has been adapt= ed for MPTCP and could be useful if you define tests

https://github.com/aschils/packetdrill_mptcp

Despite the fact that the IETF will not define conformance tests, it would = be interesting to collect information about the test suites that implemento= rs use to validate their implementation.

Ju= st in case..
We might not standardize conformance tests, but I th= ink it should be totally fine to use the WG to discuss them or share the re= lated info.=C2=A0

Thanks,
--
Y= oshi
--001a1142da9c8a69c0051a586a09-- From nobody Wed Jul 8 01:42:26 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F1911A8A45 for ; Wed, 8 Jul 2015 01:42:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qzhLmt-7gwGr for ; Wed, 8 Jul 2015 01:42:22 -0700 (PDT) Received: from bells2.cs.ucl.ac.uk (bells2.cs.ucl.ac.uk [128.16.5.33]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF9B11B3299 for ; Wed, 8 Jul 2015 01:42:21 -0700 (PDT) Received: from [78.32.160.217] (helo=[10.186.213.244]) by bells2.cs.ucl.ac.uk with esmtpsa (TLSv1:AES256-SHA:256) (C.Raiciu authenticated) (Exim 4.54) id 1ZCkvd-0006vb-9A; Wed, 08 Jul 2015 09:42:05 +0100 Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) From: Costin Raiciu In-Reply-To: <559C7D68.3080002@oracle.com> Date: Wed, 8 Jul 2015 11:40:52 +0300 Content-Transfer-Encoding: quoted-printable Message-Id: References: <559C7D68.3080002@oracle.com> To: Rao Shoaib X-Mailer: Apple Mail (2.2070.6) Archived-At: Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Need clarification on data mapping X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Jul 2015 08:42:25 -0000 > 1) > "The sender MUST keep data in its send buffer as long as the data has > not been acknowledged at both connection level and on all subflows on > which it has been sent." >=20 > Does an implementation has to verify acknowledgements on all flows or = is a connection level ack on any subflow sufficient.=20 Actually, both. Before you release data from the sendbuffer you must: 1) have a connection level ack covering it (and this can come from any = sub flow) and=20 2) appropriate subflow ACKs for the subflows this data has been sent on. 1) is meant to protect against proactive ACKing by middleboxes on one = sub flow. 2) ensures that the sender can always send the original segment on the = subflow that lost it to avoid confusing middleboxes such as traffic = normalizers that expect to see the same data in segments with the same = sequence numbers. In other words, if on subflow 1 you have sent subflow = SEQ 1 =E2=80=9CHello=E2=80=9D you are not allowed to resend subflow SEQ = 1 =E2=80=9CByeBye=E2=80=9D, you must send Hello again if the ack has not = arrived. > 2) > " A mapping is fixed, in that the subflow sequence number is bound to = the data sequence number after the mapping has been processed. A sender = MUST NOT change this mapping after it has been declared;=E2=80=9D This covers point (2) above > This does not disallow sending the same data sequence in future using = a different subflow sequence number. Correct ? Exactly. You can take the same data (with the same connection level = sequence number) and send it on a new sub flow where it will receive a = new subflow sequence number. Cheers. Costin >=20 > Thanks, >=20 > Shoaib >=20 >=20 >=20 >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Thu Jul 9 00:45:20 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 168B61AC529 for ; Thu, 9 Jul 2015 00:45:18 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.111 X-Spam-Level: X-Spam-Status: No, score=-0.111 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, J_CHICKENPOX_72=0.6, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Kg7mKZ_tGKMn for ; Thu, 9 Jul 2015 00:45:14 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.137]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44DE91AC43D for ; Thu, 9 Jul 2015 00:45:14 -0700 (PDT) Received: from E07HT05-UKBR.domain1.systemhost.net (193.113.197.167) by EVMED03-UKBR.bt.com (10.216.161.33) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 9 Jul 2015 08:45:06 +0100 Received: from rew09926dag03a.domain1.systemhost.net (10.55.202.18) by E07HT05-UKBR.domain1.systemhost.net (193.113.197.167) with Microsoft SMTP Server (TLS) id 8.3.342.0; Thu, 9 Jul 2015 08:45:08 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03a.domain1.systemhost.net (10.55.202.18) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 9 Jul 2015 08:45:07 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.0995.031; Thu, 9 Jul 2015 08:45:07 +0100 From: To: Thread-Topic: MPTCP draft agenda for Prague Thread-Index: AdCv/w6oaw+ZSPMmQIOp60un9O6p5gKGyEkg Date: Thu, 9 Jul 2015 07:45:07 +0000 Message-ID: <227e96ecae4047c08050ffa7ec631941@rew09926dag03b.domain1.systemhost.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.202.233] Content-Type: multipart/alternative; boundary="_000_227e96ecae4047c08050ffa7ec631941rew09926dag03bdomain1sy_" MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] MPTCP draft agenda for Prague X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 07:45:18 -0000 --_000_227e96ecae4047c08050ffa7ec631941rew09926dag03bdomain1sy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Since we have more requests than time, we've asked for a second meeting slo= t. At the moment there aren't any (suitable) slots available - but if somet= hing gets cancelled, then we get more time. I guess there's a reasonable ch= ance of this happening, but we may not know about the extra timeslot until = the week of the IETF. If we don't get another timeslot, then we'll try and fix an interim (audio)= meeting in the near future. At the moment our intention is that the Tuesday slot is used for discussion= s on how to progress the experiences and protocol bis drafts - including br= ief updates about the implementations. Best wishes Phil & Yoshi. From: Eardley,PL,Philip,TUB8 R Sent: 26 June 2015 18:22 To: multipathtcp Cc: Yoshifumi Nishida Subject: MPTCP draft agenda for Prague Hi, We uploaded an initial version of the agenda https://www.ietf.org/proceedings/93/agenda/agenda-93-mptcp Please let us know if we forgot any requests (or added some that are not ne= eded), or if there are any further requests. There are quite a lot of requests for agenda time - it is great that there'= s a lot of activity - I know there are several new drafts since the last ie= tf, with likely more before the cut-off deadline. Unfortunately this means that probably not everyone can get all the time th= ey asked for. We'll prioritise the WG Experiences draft, discussion on how = to progress the protocol bis, and other topics which would most usefully be= discussed face to face. One option is that we see if we can get a second timeslot. Don't know if th= is would be possible (the IETF agenda is very full), but most likely it wou= ld be Friday afternoon (if it's possible). If you'd like us to try, please = say (the default is that we stick with 1 slot). I want to keep our current = slot, Tuesday 1-3pm (on the preliminary IETF agenda) - since some extra peo= ple may come for the hackathon and be able to stay for this. Thanks Phil & Yoshi. --_000_227e96ecae4047c08050ffa7ec631941rew09926dag03bdomain1sy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Since we have more requests th= an time, we’ve asked for a second meeting slot. At the moment there a= ren’t any (suitable) slots available – but if something gets ca= ncelled, then we get more time. I guess there’s a reasonable chance of this h= appening, but we may not know about the extra timeslot until the week of th= e IETF.

 

If we don’t get another = timeslot, then we’ll try and fix an interim (audio) meeting in the ne= ar future.

At the moment our intention is= that the Tuesday slot is used for discussions on how to progress the exper= iences and protocol bis drafts – including brief updates about the implementations.

 

Best wishes<= /p>

Phil & Yoshi.

 

From:= Eardley,PL,Philip,TUB8 R
Sent: 26 June 2015 18:22
To: multipathtcp
Cc: Yoshifumi Nishida
Subject: MPTCP draft agenda for Prague

 

Hi,

We uploaded an initial version of the age= nda

https://www.ietf.org/proceedings/93/agenda/ag= enda-93-mptcp

 

Please let us know if we forgot any reque= sts (or added some that are not needed), or if there are any further reques= ts.

 

There are quite a lot of requests for age= nda time – it is great that there’s a lot of activity – I= know there are several new drafts since the last ietf, with likely more be= fore the cut-off deadline.

 

Unfortunately this means that probably no= t everyone can get all the time they asked for. We’ll prioritise the = WG Experiences draft, discussion on how to progress the protocol bis, and other topics which would most usefully be discussed face to face.=

 

One option is that we see if we can get a= second timeslot. Don’t know if this would be possible (the IETF agen= da is very full), but most likely it would be Friday afternoon (if it’s possible). If you’d like us to try, please say (the d= efault is that we stick with 1 slot). I want to keep our current slot, Tues= day 1-3pm (on the preliminary IETF agenda) – since some extra people = may come for the hackathon and be able to stay for this.

 

Thanks

Phil & Yoshi.

--_000_227e96ecae4047c08050ffa7ec631941rew09926dag03bdomain1sy_-- From nobody Thu Jul 9 08:05:41 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A08571B2A4C for ; Thu, 9 Jul 2015 08:05:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3aenCKc2j8fx for ; Thu, 9 Jul 2015 08:05:36 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id B9A8E1B2A8F for ; Thu, 9 Jul 2015 08:05:35 -0700 (PDT) Received: from mbpobo.dhcp.info.ucl.ac.be (mbpobo.dhcp.info.ucl.ac.be [130.104.228.16]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 3351A183479 for ; Thu, 9 Jul 2015 17:04:33 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 3351A183479 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1436454273; bh=ogY/o19Tn4uc/usyrmrtnyDzxMLCbrQEtrCIurWQlNU=; h=From:Subject:To:Reply-To:Message-ID:Date:MIME-Version: Content-Type:Content-Transfer-Encoding; b=F6T+UUD4Sec8E9Ozj6sm5OiZZCAB/PuAXkxIM2LjxiT+CcMORvbTYFgCp1RGIoIkh nB/Nhq/TTSqWXzzGuTXmbW3yoHDYrIAlCtYNYzCZUtv/VDz36wIX3XyYtVkxGgDQ3Q zMZc6GSW6nz5e/d1+mCV4OevW+YfZNIAldDksi3g= From: Olivier Bonaventure To: multipathtcp Message-ID: <559E8D85.2060603@uclouvain.be> Date: Thu, 9 Jul 2015 17:04:37 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99-beta1 at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 3351A183479.AE09F X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Subject: [multipathtcp] Submitted drafts X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 15:05:39 -0000 Hello, During the last week we have written and submitted several drafts that could be of interest for the working group : * https://www.ietf.org/internet-drafts/draft-ietf-mptcp-experience-02.txt This is a revised version of the Use case and experience draft that is part of the WG charter. We've taken into account most of the comments received in June and have added some text on the utilisation of MPTCP proxies. * https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-exp-option-00.txt This draft proposes a standard encoding for experimental MPTCP options. Given the small number of MPTCP options, it is important to allow experimenters to use MPTCP options without wasting this limited ressource. https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-timestamp-01.txt This is an example of the utilisation of experimental options to encode a timestamp option * https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-addr-00.txt This draft discusses some issues with the advertisement of addresses in Multipath TCP and proposes a small modification to the handling of the address identifiers of the initial subflow to simplify implementations. It also shows how the reverse DNS can be used as an alternative to ADD_ADDR to announce the addresses of servers. This technique is already used for multipath-tcp.org * https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-backup-00.txt This draft discusses some issues with the support of backup subflows in the existing Multipath TCP specification. In RFC6824 backup subflows work well when a subflow completely stops, but not when a subflow experiences huge losses. * https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-long-options-00.txt There have been many discussions on the TCPM working group about extending the space for TCP options in the TCP header. In this draft, we explore several ways of changing the DSS option to allow Multipath TCP to support long options. Comments on any of those drafts are of course welcome. Some will be presented quickly in Prague but we won't probably have time to discuss all of them Olivier From nobody Thu Jul 9 08:45:21 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 556181B2AA8 for ; Thu, 9 Jul 2015 08:45:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id elGVusoeGPaV for ; Thu, 9 Jul 2015 08:45:14 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D0811B2AA3 for ; Thu, 9 Jul 2015 08:45:14 -0700 (PDT) Received: from EPDAG01C-UKBR.domain1.systemhost.net (193.113.197.204) by EVMED05-UKBR.bt.com (10.216.161.37) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 9 Jul 2015 16:45:12 +0100 Received: from rew09926dag03a.domain1.systemhost.net (10.55.202.18) by EPDAG01C-UKBR.domain1.systemhost.net (193.113.197.204) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 9 Jul 2015 16:45:11 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03a.domain1.systemhost.net (10.55.202.18) with Microsoft SMTP Server (TLS) id 15.0.995.29; Thu, 9 Jul 2015 16:45:11 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.0995.031; Thu, 9 Jul 2015 16:45:11 +0100 From: To: , Thread-Topic: [multipathtcp] Submitted drafts Thread-Index: AQHQuljwYGvn+70fnkqHopUyfKqQSJ3TR2nQ Date: Thu, 9 Jul 2015 15:45:10 +0000 Message-ID: References: <559E8D85.2060603@uclouvain.be> In-Reply-To: <559E8D85.2060603@uclouvain.be> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.202.233] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] Submitted drafts X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 15:45:20 -0000 Olivier and colleagues, Thanks for all the work.=20 Please comment on the drafts - for instance, what things are worth adding t= o the protocol bis? phil > -----Original Message----- > From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of > Olivier Bonaventure > Sent: 09 July 2015 16:05 > To: multipathtcp > Subject: [multipathtcp] Submitted drafts >=20 > Hello, >=20 >=20 > During the last week we have written and submitted several drafts that > could be of interest for the working group : >=20 > * https://www.ietf.org/internet-drafts/draft-ietf-mptcp-experience- > 02.txt >=20 > This is a revised version of the Use case and experience draft that is > part of the WG charter. We've taken into account most of the comments > received in June and have added some text on the utilisation of MPTCP > proxies. >=20 > * > https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-exp- > option-00.txt >=20 > This draft proposes a standard encoding for experimental MPTCP options. > Given the small number of MPTCP options, it is important to allow > experimenters to use MPTCP options without wasting this limited > ressource. >=20 > https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-timestamp- > 01.txt >=20 > This is an example of the utilisation of experimental options to encode > a timestamp option >=20 > * https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-addr- > 00.txt >=20 > This draft discusses some issues with the advertisement of addresses in > Multipath TCP and proposes a small modification to the handling of the > address identifiers of the initial subflow to simplify implementations. > It also shows how the reverse DNS can be used as an alternative to > ADD_ADDR to announce the addresses of servers. This technique is > already > used for multipath-tcp.org >=20 > * https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-backup- > 00.txt >=20 > This draft discusses some issues with the support of backup subflows in > the existing Multipath TCP specification. In RFC6824 backup subflows > work well when a subflow completely stops, but not when a subflow > experiences huge losses. >=20 > * > https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-long- > options-00.txt >=20 > There have been many discussions on the TCPM working group about > extending the space for TCP options in the TCP header. In this draft, > we > explore several ways of changing the DSS option to allow Multipath TCP > to support long options. >=20 >=20 > Comments on any of those drafts are of course welcome. Some will be > presented quickly in Prague but we won't probably have time to discuss > all of them >=20 > Olivier >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Thu Jul 9 09:19:36 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C367A1B2ACF for ; Thu, 9 Jul 2015 09:19:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IZ5-7HLBlUJh for ; Thu, 9 Jul 2015 09:19:34 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 7F1E51B2AC8 for ; Thu, 9 Jul 2015 09:19:34 -0700 (PDT) Received: from userv0021.oracle.com (userv0021.oracle.com [156.151.31.71]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t69GJVZ1009255 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 9 Jul 2015 16:19:33 GMT Received: from userv0121.oracle.com (userv0121.oracle.com [156.151.31.72]) by userv0021.oracle.com (8.13.8/8.13.8) with ESMTP id t69GJV0G027411 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for ; Thu, 9 Jul 2015 16:19:31 GMT Received: from abhmp0011.oracle.com (abhmp0011.oracle.com [141.146.116.17]) by userv0121.oracle.com (8.13.8/8.13.8) with ESMTP id t69GJVSB002478 for ; Thu, 9 Jul 2015 16:19:31 GMT Received: from [10.159.187.186] (/10.159.187.186) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 09 Jul 2015 09:19:31 -0700 Message-ID: <559E9F0F.3090305@oracle.com> Date: Thu, 09 Jul 2015 09:19:27 -0700 From: Rao Shoaib User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: multipathtcp@ietf.org References: <1436204168109.20146@bt.com> <1436205703501.53882@bt.com> In-Reply-To: <1436205703501.53882@bt.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: userv0021.oracle.com [156.151.31.71] Archived-At: Subject: Re: [multipathtcp] Preparing for Prague meeting - things to delete or add to MPTCP protocol bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 16:19:35 -0000 On 07/06/2015 11:01 AM, philip.eardley@bt.com wrote: > > Looking at the (expired) draft summarising the various implementations, > > https://tools.ietf.org/html/draft-eardley-mptcp-implementations-survey-02 > > one thing that may be worth discussing is whether we need both 4 & 8 > byte Data ack & DSS > +1 Choosing one (8 byte ack) would make implementation as well as debugging easier. What is the purpose of providing two options. Shoaib > > << All implementations support 4 bytes "Data ACK" and "Data sequence > number" fields, and will interoperate with an implementation sending > 8 bytes. Implementation 1 uses only 4 bytes fields; if an > implementation sends an 8 byte data sequence number it replies with a > 4 byte data ack. > > >> > From nobody Thu Jul 9 09:45:38 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D251F1AC408 for ; Thu, 9 Jul 2015 09:45:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SzrJQ41lTmrV for ; Thu, 9 Jul 2015 09:45:36 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 801321A88EB for ; Thu, 9 Jul 2015 09:45:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1436460336; x=2300373936; 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=xttj+QNDrCGzLt4cmtnEN4uefmL8cqK4fw1YaSmUjAU=; b=TBnCwSKsR+EJoGI71wglzWfRwssEZsPL4K/9p8/PmXQAdlRBMhux73HOw/3kR9aQ PCP0IvpLGxn9XQ8MA2p1/3Oj0dhNd6g7Br+O1Typ+GDpfFcoO6dPI+h4IJUHHb8a TxCRlt/RWY2L9YdHxoLNkmBHcktdxsalb4sc+zuRhjtMHUpedco2vSUVnAPrpMkR i+O3J3+Iok2IM72vEP6IPxV/T885Kj+NYvJSobl2Ve13d1T/jVDLAL/X3SUc5DXM oOrZUHmasNJw31wJlqybIWSdRdNIqpRZx1rEi206ZlvScQzL+MyXsh1whTQIGII+ Ch95Y0ZeRAq5pyehdL9aJw==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 33.52.09370.F25AE955; Thu, 9 Jul 2015 09:45:35 -0700 (PDT) X-AuditID: 11973e16-f79856d00000249a-97-559ea52f5b98 Received: from chive.apple.com (chive.apple.com [17.128.115.15]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id A2.FE.14452.4C69E955; Thu, 9 Jul 2015 08:44:04 -0700 (PDT) Received: from localhost ([17.153.89.48]) by chive.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NR8008ZRBVZP550@chive.apple.com> for multipathtcp@ietf.org; Thu, 09 Jul 2015 09:45:35 -0700 (PDT) Date: Thu, 09 Jul 2015 09:45:37 -0700 From: Christoph Paasch To: Rao Shoaib Message-id: <20150709164537.GG1144@Chimay.local> References: <1436204168109.20146@bt.com> <1436205703501.53882@bt.com> <559E9F0F.3090305@oracle.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline In-reply-to: <559E9F0F.3090305@oracle.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrPLMWRmVeSWpSXmKPExsUi2FAYpau/dF6oweXbNhafV19nc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXRt/Wz8wF/1gqXt3+xNzA+Je5i5GDQ0LAROJIZ3oXIyeQKSZx 4d56ti5GLg4hgb2MEpvuX2aFSJhInN+5gA3EFhLoZpJ4cMwCwm5hkvj+wRpkDouAqsShc2Ig YTYBLYm3t9vBWkUE1CQmnLkHZjMLSEqs+PsJzBYWyJLo71zKAmLzChhItC2fxQoxMlWiddNP qLigxI/J91ggerUk1u88zgRhS0s8+juDHcTmBIr/urcbrEZUQEXiyoS37CD3Swg8ZZU4fmEG 0wRG4VlIZs1CMmsWklkLGJlXMQrlJmbm6GbmmeslFhTkpOol5+duYgSF8HQ7sR2MD1dZHWIU 4GBU4uFt2Dk3VIg1say4MvcQozQHi5I4740PQCGB9MSS1OzU1ILUovii0pzU4kOMTBycUg2M fG9vTXp6JfPism+TZy3eeH+6kopIUt2Tr9NM7JR0OPzPxjxrVxY9nWzU5zFv+dPO8nlaOxa+ 3P+yi9VrXcCXA/ExtUofpYQX3ebdNsF+retW5ZXbGNawz1wdN6mlZLXV8YVax8x/hlvfVt7v u5vD5JCP6pq7swNZNOSkZ2X/1FqSO8dTZF5TgBJLcUaioRZzUXEiAHdOdMRCAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMLMWRmVeSWpSXmKPExsUi2FDMr3tk2rxQg2PbpS0+r77O5sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujL6tn5kL/rFUvLr9ibmB8S9zFyMnh4SAicT5nQvYIGwxiQv3 1oPZQgLdTBIPjllA2C1MEt8/WHcxcnCwCKhKHDonBhJmE9CSeHu7nRXEFhFQk5hw5h6YzSwg KbHi7ycwW1ggS6K/cykLiM0rYCDRtnwWK8TIVInWTT+h4oISPybfY4Ho1ZJYv/M4E4QtLfHo 7wx2EJsTKP7r3m6wGlEBFYkrE96yT2AUmIWkfRaS9llI2hcwMq9iFChKzUmsNNNLLCjISdVL zs/dxAgOusKoHYwNy60OMQpwMCrx8BasnhsqxJpYVlyZe4hRgoNZSYT3cv+8UCHelMTKqtSi /Pii0pzU4kOM0hwsSuK8+1unhAoJpCeWpGanphakFsFkmTg4pRoYK8LjT59q/JnZGfzA8YRG x+swo61rLhd1Gtnu2MRz7Zw1R/PVN2u2lNvs+SJseyxni/yPZ7Ni78hxquh8+Pnkj/e7ra9b OG6pN9zNnGR07J/o2y1ac3/3R7PJWOxWjNvbWLLmf++PlSGdM9+t12qVO/kiSMCCp8f0YltZ RqI+862svbG6IXcfKrEUZyQaajEXFScCANjD5OU2AgAA Archived-At: Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Preparing for Prague meeting - things to delete or add to MPTCP protocol bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 16:45:38 -0000 Hello, On 09/07/15 - 09:19:27, Rao Shoaib wrote: > On 07/06/2015 11:01 AM, philip.eardley@bt.com wrote: > > > >Looking at the (expired) draft summarising the various implementations, > > > >https://tools.ietf.org/html/draft-eardley-mptcp-implementations-survey-02 > > > >one thing that may be worth discussing is whether we need both 4 & 8 byte > >Data ack & DSS > > > +1 > Choosing one (8 byte ack) would make implementation as well as debugging > easier. What is the purpose of providing two options. I think the 4-byte option is good to reduce the TCP-option space consumption of MPTCP. Cheers, Christoph From nobody Thu Jul 9 09:49:54 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 69BAA1B2AEF for ; Thu, 9 Jul 2015 09:49:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R5Qac7yO7Hjk for ; Thu, 9 Jul 2015 09:49:50 -0700 (PDT) Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) (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 CE46C1B2AEA for ; Thu, 9 Jul 2015 09:49:50 -0700 (PDT) Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by aserp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id t69GnmFu016282 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 9 Jul 2015 16:49:49 GMT Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.13.8/8.13.8) with ESMTP id t69GnmWG014075 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 9 Jul 2015 16:49:48 GMT Received: from abhmp0012.oracle.com (abhmp0012.oracle.com [141.146.116.18]) by userv0122.oracle.com (8.13.8/8.13.8) with ESMTP id t69GnmXK007486; Thu, 9 Jul 2015 16:49:48 GMT Received: from [10.132.148.88] (/10.132.148.88) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 09 Jul 2015 09:49:48 -0700 Message-ID: <559EA884.1050800@oracle.com> Date: Thu, 09 Jul 2015 09:59:48 -0700 From: Rao Shoaib User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Christoph Paasch References: <1436204168109.20146@bt.com> <1436205703501.53882@bt.com> <559E9F0F.3090305@oracle.com> <20150709164537.GG1144@Chimay.local> In-Reply-To: <20150709164537.GG1144@Chimay.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Source-IP: userv0022.oracle.com [156.151.31.74] Archived-At: Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Preparing for Prague meeting - things to delete or add to MPTCP protocol bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Jul 2015 16:49:52 -0000 On 07/09/2015 09:45 AM, Christoph Paasch wrote: > Hello, > > On 09/07/15 - 09:19:27, Rao Shoaib wrote: >> On 07/06/2015 11:01 AM, philip.eardley@bt.com wrote: >>> Looking at the (expired) draft summarising the various implementations, >>> >>> https://tools.ietf.org/html/draft-eardley-mptcp-implementations-survey-02 >>> >>> one thing that may be worth discussing is whether we need both 4 & 8 byte >>> Data ack & DSS >>> >> +1 >> Choosing one (8 byte ack) would make implementation as well as debugging >> easier. What is the purpose of providing two options. > I think the 4-byte option is good to reduce the TCP-option space > consumption of MPTCP. That's a good point. I suggested 8 byte option to cover any wrap around issues but if 4 bytes work that is fine too. Shoaib > > Cheers, > Christoph > > From nobody Thu Jul 9 23:22:55 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 602051A87B8 for ; Thu, 9 Jul 2015 23:22:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.598 X-Spam-Level: X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DFDNUlP0j0XN for ; Thu, 9 Jul 2015 23:22:49 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias243.francetelecom.com [80.12.204.243]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E59F41A874E for ; Thu, 9 Jul 2015 23:22:47 -0700 (PDT) Received: from omfeda06.si.francetelecom.fr (unknown [xx.xx.xx.199]) by omfeda11.si.francetelecom.fr (ESMTP service) with ESMTP id E279B1B8C1E for ; Fri, 10 Jul 2015 08:22:45 +0200 (CEST) Received: from localhost.localdomain (unknown [127.0.0.1]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id D5D39C804F for ; Fri, 10 Jul 2015 08:22:45 +0200 (CEST) Received: from omfeda06.si.francetelecom.fr by omfeda06.si.francetelecom.fr with queue id 343633-37 for multipathtcp@ietf.org; Fri, 10 Jul 2015 06:22:45 GMT Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.32]) by omfeda06.si.francetelecom.fr (ESMTP service) with ESMTP id BA451C8065; Fri, 10 Jul 2015 08:22:45 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM32.corporate.adroot.infra.ftgroup ([fe80::8924:188:2124:a046%19]) with mapi id 14.03.0235.001; Fri, 10 Jul 2015 08:22:45 +0200 From: To: "philip.eardley@bt.com" , "multipathtcp@ietf.org" Thread-Topic: Preparing for Prague meeting - things to delete or add to MPTCP protocol bis Thread-Index: AQHQuBC1ogV2Z1ShB0+RXyp9UJJDtJ3Ou0BjgAWEG4A= Date: Fri, 10 Jul 2015 06:22:44 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B933005359DAA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <1436204168109.20146@bt.com> <1436205703501.53882@bt.com> In-Reply-To: <1436205703501.53882@bt.com> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933005359DAAOPEXCLILMA3corp_" MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.2.124516 Archived-At: Subject: Re: [multipathtcp] Preparing for Prague meeting - things to delete or add to MPTCP protocol bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 06:22:53 -0000 --_000_787AE7BB302AE849A7480A190F8B933005359DAAOPEXCLILMA3corp_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi Philip, A change was proposed in (https://tools.ietf.org/html/draft-boucadair-mptcp= -symmetric-02) to redefine IPVer field of ADD_ADDR as a set of flag bits (s= ee below). This change applies also for ADD_ADDR2. OLD: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+--------+--------+---------------+ | Kind | Length |ADD_ADDR| IPVer | Address ID | +---------------+---------------+--------+--------+---------------+ | Address (IPv4 - 4 octets / IPv6 - 16 octets) | +-------------------------------+---------------------------------+ | Port (2 octets) | +-------------------------------+ NEW: 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+--------+--------+---------------+ | Kind | Length |ADD_ADDR| Flags | Address ID | +---------------+---------------+--------+--------+---------------+ | Address (IPv4 - 4 octets / IPv6 - 16 octets) | +-------------------------------+---------------------------------+ | Port (2 octets) | +-------------------------------+ +-+-+-+-+ Flags is a set of 4 flags: |C|r|r|r| +-+-+-+-+ C flag MUST be set to 1 when the address/port are checked. "rrr" are for future assignment as additional flag bits. r bits MUST each be sent as zero and MUST be ignored on receipt. Figure 1 Another proposal from the symmetric draft is to define one of these flag bi= ts as C-flag to indicate to a remote peer that it can initiate subflows eve= n if its didn't initiated the first subflow. The problem was mentioned in [= I-D.ietf-mptcp-experience]: From a subflow viewpoint, the Multipath TCP protocol is completely symmetrical. Both the clients and the server have the capability to create subflows. However in practice the existing Multipath TCP implementations [I-D.eardley-mptcp-implementations-survey] have opted for a strategy where only the client creates new subflows. The main motivation for this strategy is that often the client resides behind a NAT or a firewall, preventing passive subflow openings on the client. Cheers, Med De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de phil= ip.eardley@bt.com Envoy=E9 : lundi 6 juillet 2015 20:01 =C0 : multipathtcp@ietf.org Objet : [multipathtcp] Preparing for Prague meeting - things to delete or a= dd to MPTCP protocol bis Hi, In the Prague meeting, we aim to move forward the protocol bis doc (to meet= ing our Cahrter objetive for a standards track version of RFC6824) One topic we'd like to discuss is if there's anything that should be delete= d from or added to the current draft, https://tools.ietf.org/wg/mptcp/draft= -ietf-mptcp-rfc6824bis/ - based on operational and implementation experienc= e. Any proposals? Looking at the (expired) draft summarising the various implementations, https://tools.ietf.org/html/draft-eardley-mptcp-implementations-survey-02 one thing that may be worth discussing is whether we need both 4 & 8 byte D= ata ack & DSS << All implementations support 4 bytes "Data ACK" and "Data sequence number" fields, and will interoperate with an implementation sending 8 bytes. Implementation 1 uses only 4 bytes fields; if an implementation sends an 8 byte data sequence number it replies with a 4 byte data ack. >> I don't think the implementation survey suggests that there's anything else= worth considering deleting - are there any other proposals? As to things to add, there are a few proposals for some (minor?) additions = in the recent set of drafts from Olivier Bonaventure and team. Since we have a lot more requests for presentation time than it's possible = to squeeze into the meeting, it would be excellent to have discussion on th= e list before the meeting, about anything that should be added to, or delet= ed from, the current rfc6824bis, before we progress it to WG last call. thanks! --_000_787AE7BB302AE849A7480A190F8B933005359DAAOPEXCLILMA3corp_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Philip,

 

A change was proposed in (https= ://tools.ietf.org/html/draft-boucadair-mptcp-symmetric-02) to redefine IPVer field of ADD_ADDR as a set of flag bits (see below). Thi= s change applies also for ADD_ADDR2.

 

OLD:

        = 1            &n= bsp;      2      &nb= sp;            3

        = 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1<= /span>

       +-= --------------+---------------+--------+--------+----------= -----+

       | = ;    Kind      |   &= nbsp; Length    |ADD_ADDR| IPVer  |  Address ID&nb= sp;  |

       +-= --------------+---------------+--------+--------+----------= -----+

       | = ;         Address (IPv4 - 4 octets = / IPv6 - 16 octets)         &n= bsp; |

       +-= ------------------------------+---------------------------------+

       | = ;  Port (2 octets)        &nbs= p;    |

       +-= ------------------------------+

 

NEW:

       1 = ;            &n= bsp;     2       &nb= sp;           3

       0 1 2 = 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1=

      +-------= --------+---------------+--------+--------+---------------&= #43;

      |  = ;   Kind      |     = Length    |ADD_ADDR| Flags  |  Address ID &nb= sp; |

      +-------= --------+---------------+--------+--------+---------------&= #43;

      |  = ;        Address (IPv4 - 4 octets / IPv6= - 16 octets)           |=

      +-------= ------------------------+---------------------------------+

      |  = ; Port (2 octets)         &nbs= p;   |

      +-------= ------------------------+

 

       &= nbsp;           &nbs= p;            &= nbsp;       +-+-+-+-+

      Flags is a s= et of 4 flags:        |C|r|r|r|

       &= nbsp;           &nbs= p;            &= nbsp;       +-+-+-+-+

 

      C flag MUST = be set to 1 when the address/port are checked.

      "rrr&qu= ot; are for future assignment as additional flag bits.

      r bits MUST = each be sent as zero and MUST be ignored on receipt.

 

       &= nbsp;           &nbs= p;             Figure 1

 

Another proposal from the symme= tric draft is to define one of these flag bits as C-flag to indicate to a r= emote peer that it can initiate subflows even if its didn’t initiated the first subflow. The problem was mentioned in= [I-D.ietf-mptcp-experience]:

 
      From a subflow vie=
wpoint, the Multipath TCP protocol is completely
      symmetrical. =
 Both the clients and the server have the capability

      to create subflows=
.  However in practice the existing Multipath


      TCP implementation=
s [I-D.eardley-mptcp-implementations-survey]<=
o:p>


      have opted for a s=
trategy where only the client creates new


      subflows.  Th=
e main motivation for this strategy is that often the

      client resides beh=
ind a NAT or a firewall, preventing passive


      subflow openings o=
n the client.


 


Cheers,


Med


 








De : mult=
ipathtcp [mailto:multipathtcp-bounces@ietf.org]
De la part de philip.eardley@bt.com

Envoy=E9 : lundi 6 juillet 2015 20:01

=C0 : multipathtcp@ietf.org

Objet : [multipathtcp] Preparing for Prague meeting - things to=
 delete or add to MPTCP protocol bis






 






Hi,


In the Prague meeting, we aim to move=
 forward the protocol bis doc (to meeting our Cahrter objetive for a standa=
rds track version of RFC6824)


 


One topic we'd like to discuss is if =
there's anything that should be deleted from or added to the current draft,
ht=
tps://tools.ietf.org/wg/mptcp/draft-ietf-mptcp-rfc6824bis/ - based=
 on operational and implementation experience.


 


Any proposals?


 


Looking at the (expired) draft summar=
ising the various implementations,



https://tools.ietf.org/htm=
l/draft-eardley-mptcp-implementations-survey-02


one thing that may be worth discussin=
g is whether we need both 4 & 8 byte Data ack & DSS


<<   All implementati=
ons support 4 bytes "Data ACK" and "Data sequence

   number" fields, and will interoperate with an implementat=
ion sending

   8 bytes.  Implementation 1 uses only 4 bytes fields; if a=
n

   implementation sends an 8 byte data sequence number it replies=
 with a

   4 byte data ack.


>> 


 


I don't think the implementation surv=
ey suggests that there's anything else worth considering deleting - are the=
re any other proposals?


 


As to things to add, there are a few =
proposals for some (minor?) additions in the recent set of drafts from Oliv=
ier Bonaventure and team.


 


Since we have a lot more requests for=
 presentation time than it's possible to squeeze into the meeting, it would=
 be excellent to have discussion on the list before the
 meeting, about anything that should be added to, or deleted from, the curr=
ent rfc6824bis, before we progress it to WG last call.

 


thanks!
--_000_787AE7BB302AE849A7480A190F8B933005359DAAOPEXCLILMA3corp_-- From nobody Thu Jul 9 23:27:29 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 70B841A87DE for ; Thu, 9 Jul 2015 23:27:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KR7PoLraEXa3 for ; Thu, 9 Jul 2015 23:27:25 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id ABF0D1A87D0 for ; Thu, 9 Jul 2015 23:27:25 -0700 (PDT) Received: from [192.168.43.239] (ptr-178-50-71-57.dyn.mobistar.be [178.50.71.57]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 9616A183432; Fri, 10 Jul 2015 08:27:19 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be 9616A183432 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1436509640; bh=jIzE/LuYrqBwiDIBY4mmhPtVOTailXJwhHYcjbEY+PQ=; h=Reply-To:Subject:References:To:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=pkR7xgh+Zy6mDQ9xRZiDNfTbkJhParG37p+bp7z3lTvuvS2gJ4pVNi7tivJ6ghD6b jZ7k25vac+IcM6z2uYeaw8QHr9xUPVVbXHUb+FvwA/Y2tFC0XrUj5DTNuaRkw3dYrB aAwo34DSGqX/zp5wJbzz8+v4n5V7PMVgR5xtK1rE= References: <559E8D85.2060603@uclouvain.be> To: philip.eardley@bt.com, multipathtcp@ietf.org From: Olivier Bonaventure Message-ID: <559F65C6.8030305@uclouvain.be> Date: Fri, 10 Jul 2015 08:27:18 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99-beta1 at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 9616A183432.A083B X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Subject: Re: [multipathtcp] Submitted drafts X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 06:27:27 -0000 Phil, > > Thanks for all the work. > > Please comment on the drafts - for instance, what things are worth adding to the protocol bis? > >> * >> https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-exp- >> option-00.txt This draft would be a good candidate to be included in RFC6824bis. >> https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-timestamp- >> 01.txt >> >> This is an example of the utilisation of experimental options to encode >> a timestamp option >> >> * https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-addr- >> 00.txt This draft includes a slight modification of the handling of the address identifier for the initial subflow. Comments from other implementors would be useful on this draft. The other drafts are more improvements that do not necessarily need to go into rfc6824bis Olivier From nobody Fri Jul 10 07:31:40 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EBF71B2C89 for ; Fri, 10 Jul 2015 07:31:39 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1GJfqp_LBg-b for ; Fri, 10 Jul 2015 07:31:34 -0700 (PDT) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 298751A9153 for ; Fri, 10 Jul 2015 07:30:28 -0700 (PDT) Received: from mbpobo.dhcp.info.ucl.ac.be (mbpobo.dhcp.info.ucl.ac.be [130.104.228.16]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id DD2E31982B3; Fri, 10 Jul 2015 16:30:21 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be DD2E31982B3 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1436538621; bh=l07zaTqyxdPXJjEMxcqykzqS4GD60Hg5st3Si4oDLKg=; h=Reply-To:Subject:References:To:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type:Content-Transfer-Encoding:Date:From: MIME-Version:To:Subject:References:In-Reply-To:Content-Type:; b=Q7qnaiTCWLB2uziB2mUclpbHxj4n7JmiLWpj6KLnPq7Vp/3Aypplal+xqjzdR4r9C 5+qscbClaJnIyjcQJ+YFGFWizfcYTNlxg+Ba0FlpIrCCYrAjUnWEI09hyuRruf+frQ YTCwfUVb4cxRnc+oChvtJ6ZSQD3Uvnu/2Eje+XSQ= References: <1436204168109.20146@bt.com> <1436205703501.53882@bt.com> <787AE7BB302AE849A7480A190F8B933005359DAA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> To: mohamed.boucadair@orange.com, "philip.eardley@bt.com" , "multipathtcp@ietf.org" From: Olivier Bonaventure Message-ID: <559FD6FF.3040003@uclouvain.be> Date: Fri, 10 Jul 2015 16:30:23 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B933005359DAA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99-beta1 at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: DD2E31982B3.A2D58 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Subject: Re: [multipathtcp] Preparing for Prague meeting - things to delete or add to MPTCP protocol bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 14:31:39 -0000 Med, > > A change was proposed in > (https://tools.ietf.org/html/draft-boucadair-mptcp-symmetric-02) to > redefine IPVer field of ADD_ADDR as a set of flag bits (see below). This > change applies also for ADD_ADDR2. I think that replacing the IP version with a set of flags (at least in ADD_ADDR2 to prevent backward compatibility problems with the existing ADD_ADDR implementation) would make sense. > +-+-+-+-+ > > Flags is a set of 4 flags: |C|r|r|r| > > +-+-+-+-+ > > C flag MUST be set to 1 when the address/port are checked. > > "rrr" are for future assignment as additional flag bits. > > r bits MUST each be sent as zero and MUST be ignored on receipt. > However, I'm stil not convinced by the usefulness of using the C bit that you propose. If a host knows that it cannot receive a SYN over a given address, then the best solution is to not advertise this address. This will typically be the case when a host is behind a NAT or a firewall (I guess that at some point middlebox vendors will include software to parse ADD_ADDR and remove the ADD_ADDR that correspond to addresses that are not reachable accoring to their policies) Olivier From nobody Fri Jul 10 10:36:04 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BAAC1A020D for ; Fri, 10 Jul 2015 10:36:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QPlhVnhXoM6U for ; Fri, 10 Jul 2015 10:36:01 -0700 (PDT) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3771D1A01D6 for ; Fri, 10 Jul 2015 10:36:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1436549760; x=2300463360; 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=fJxZZqXCntN1CXwyG3hQVOlCFUSt1TgHtz9zoW+nGOc=; b=TqWhNurHth7KG3xqc1zOIArj05NUBJI+G7iQ63AdTKY3xu8IT0h286RSj/YyN3bt zy54EOIxgZ2dwsELw5JT7sRKr7koIrO4RB8wRY6hiCog7LITcSDW95en0TGTEZlo XPdvZoJRNbLrdaE0mw3o5Lhb+kz71bbT6U/cBnzqZ/vXwv+jmRHXfu46pWSXanVA ChRLN/e4LH/TSYKjDxwg/Egkxo3heAHliISEdztTM21+gkNzbYJ/YAV3Nj8xB3y4 jqJQ+2qfm9mzbaopk/88+v4x9b+fJQmKKQuyUSh8v50bxCcdDg4SRBB58S1wUFT4 4PmswafkLi6TLS4OvZJmBA==; Received: from relay2.apple.com (relay2.apple.com [17.128.113.67]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id 39.2B.18963.08200A55; Fri, 10 Jul 2015 10:36:00 -0700 (PDT) X-AuditID: 11973e12-f79456d000004a13-96-55a002807bc4 Received: from fenugreek.apple.com (fenugreek.apple.com [17.128.115.97]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay2.apple.com (Apple SCV relay) with SMTP id 15.4D.13288.08200A55; Fri, 10 Jul 2015 10:36:00 -0700 (PDT) Received: from localhost ([17.226.23.204]) by fenugreek.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NRA005GL8W0NK60@fenugreek.apple.com> for multipathtcp@ietf.org; Fri, 10 Jul 2015 10:36:00 -0700 (PDT) Date: Fri, 10 Jul 2015 10:36:00 -0700 From: Christoph Paasch To: Olivier Bonaventure Message-id: <20150710173600.GO1144@Chimay.local> References: <559E8D85.2060603@uclouvain.be> <559F65C6.8030305@uclouvain.be> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline In-reply-to: <559F65C6.8030305@uclouvain.be> User-Agent: Mutt/1.5.23 (2014-03-12) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrELMWRmVeSWpSXmKPExsUi2FDorNvAtCDU4EGPlsXn1dfZHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsW3ZYpaCVoGK2y9uMTcwdvB2MXJySAiYSKy4spoNwhaTuHBv PZDNxSEksJdR4vmNlewwRfPWbGUEsYUEJjNJTDyYBVHUzyTxtvsOWIJFQFXi19XjLCA2m4CW xNvb7awgtoiAlcSp09PBBjELGEgsnXMRyObgEBbQkbj9SgQkzAsUnjhnDSvEzBlAi3dtZoJI CEr8mHyPBaJXS2L9zuNMELa0xKO/M8BmcgLNuXr1I9guUQEViSsT3rKDDJIQeMsq8fPZJ5YJ jMKzkMyahWTWLCSzFjAyr2IUyk3MzNHNzDPRSywoyEnVS87P3cQICuTpdkI7GE+tsjrEKMDB qMTDG8A2P1SINbGsuDL3EKM0B4uSOO+fK/NChQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTD2 bq1Pb9vKyHTt2P4nt00OHH/8Ly0mb8njOaX3XC6c+/KNu+VE+qHOF8pLHZ6cX3Eozm1Cur+a +bOg9G+3M48t33R6olRtb8trLbfs+GiVTTwVf9/XXtkWcfGBwWz9DaevdpXOMSx7EfLIOVT8 xMuUwM/z9pSz2HLIaa7c1br58Y7Vb8+cPD6zRomlOCPRUIu5qDgRAL7gXcRFAgAA X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrKLMWRmVeSWpSXmKPExsUi2FCcqNvAtCDUYOFVVYvPq6+zOTB6LFny kymAMYrLJiU1J7MstUjfLoErY9uyxSwFrQIVt1/cYm5g7ODtYuTkkBAwkZi3ZisjhC0mceHe ejYQW0hgMpPExINZXYxcQHY/k8Tb7jtgRSwCqhK/rh5nAbHZBLQk3t5uZwWxRQSsJE6dns4O YjMLGEgsnXMRyObgEBbQkbj9SgQkzAsUnjhnDSvEzBmMEs93bWaCSAhK/Jh8jwWiV0ti/c7j TBC2tMSjvzPAZnICzbl69SPYLlEBFYkrE96yT2AUmIWkfRaS9llI2hcwMq9iFChKzUmsNNJL LCjISdVLzs/dxAgOvELnHYzHllkdYhTgYFTi4Q1gmx8qxJpYVlyZe4hRgoNZSYS3exVQiDcl sbIqtSg/vqg0J7X4EKM0B4uSOK/mlCmhQgLpiSWp2ampBalFMFkmDk6pBkb/QB01DZs+uePP faZlF3czdixhePrWbdK10Pq5rocbyk02M7QfKhQLCxcUkaw4vXjtM983iRYrre68klysvsV0 47GUDzM+SP5vznnqWnHRlV8u5Bf7wvNzcxPjXsRf2pLwvHu69p9ZM+eq+0v8Wt1tunzVOXF/ nVQxLq2O20e4ppfJ1e8+NUmJpTgj0VCLuag4EQDtAUMXOAIAAA== Archived-At: Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Submitted drafts X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 17:36:02 -0000 Hello, On 10/07/15 - 08:27:18, Olivier Bonaventure wrote: > >Thanks for all the work. > > > >Please comment on the drafts - for instance, what things are worth adding to the protocol bis? > > > > >>* > >>https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-exp- > >>option-00.txt > > This draft would be a good candidate to be included in RFC6824bis. +1 > >>https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-timestamp- > >>01.txt > >> > >>This is an example of the utilisation of experimental options to encode > >>a timestamp option > >> > >>* https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-addr- > >>00.txt > > This draft includes a slight modification of the handling of the address > identifier for the initial subflow. Comments from other implementors would > be useful on this draft. I agree with section 2.1 that having a different address-ID for the initial subflow is very cumbersome. An implementation has to store the local address-id's within the state-machine of each subflow. It would be much easier if we could have a fully global address-table. However, I'm not sure whether it is good to solve it through an empty ADD_ADDR-option. Because, the option is not sent reliably. Even if it gets combined with data, we have an issue with unidirectional streams. And communicating this ADD_ADDR-option reliably to the peer is here in this case even more important than for the "regular" ADD_ADDR option. It would be better if we could put the address-ID inside the MP_CAPABLE. Maybe we can use 8 bits of the key? (also, a little nit: Adding the IPVer within this ADD_ADDR-option is not necessary and will bring issues in NAT64-environments). Cheers, Christoph > > The other drafts are more improvements that do not necessarily need to go > into rfc6824bis > > > Olivier > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Fri Jul 10 13:57:25 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7B3151B2B26 for ; Fri, 10 Jul 2015 13:57:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eNfbcijSECV8 for ; Fri, 10 Jul 2015 13:57:21 -0700 (PDT) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 30E031B2B0B for ; Fri, 10 Jul 2015 13:57:14 -0700 (PDT) Received: from mbpobo.local (host-78-129-6-94.dynamic.voo.be [78.129.6.94]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 04624198278; Fri, 10 Jul 2015 22:57:05 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be 04624198278 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1436561826; bh=0UEWNj2/ED5cO16RWAeIEVKSlgQByjCs73+pvVGcDT8=; h=Reply-To:Subject:References:To:Cc:From:Message-ID:Date: MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding: Date:From:MIME-Version:To:Subject:References:In-Reply-To: Content-Type:; b=GXoOPQNacodIvX8BxGd51ASv/DFsoX+WYQxJnf/hkhRM8+Pl/2g6vtl6Q2LA2CBhe j/Ka2beex8Ccf4l/f+ihv+QhQx4v15/zN5rxroDihz2tnZO7b/ESCRdsYRqwm+8W9r Xr90IULOFHAWGnLK8OzYlTj5NaW3vpwC5cdn60yo= References: <559E8D85.2060603@uclouvain.be> <559F65C6.8030305@uclouvain.be> <20150710173600.GO1144@Chimay.local> To: Christoph Paasch From: Olivier Bonaventure Message-ID: <55A031A1.90703@uclouvain.be> Date: Fri, 10 Jul 2015 22:57:05 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <20150710173600.GO1144@Chimay.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99-beta1 at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: 04624198278.AFB07 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Submitted drafts X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 10 Jul 2015 20:57:23 -0000 Christoph, >>>> * https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-addr- >>>> 00.txt >> >> This draft includes a slight modification of the handling of the address >> identifier for the initial subflow. Comments from other implementors would >> be useful on this draft. > > I agree with section 2.1 that having a different address-ID for the > initial subflow is very cumbersome. An implementation has to store the local > address-id's within the state-machine of each subflow. It would be much > easier if we could have a fully global address-table. > > However, I'm not sure whether it is good to solve it through an empty > ADD_ADDR-option. Because, the option is not sent reliably. Even if it gets > combined with data, we have an issue with unidirectional streams. And > communicating this ADD_ADDR-option reliably to the peer is here in this case > even more important than for the "regular" ADD_ADDR option. > > It would be better if we could put the address-ID inside the MP_CAPABLE. > Maybe we can use 8 bits of the key? Then the entropy for the key is lower because it is reduced to 56 bits. > > (also, a little nit: Adding the IPVer within this ADD_ADDR-option is not > necessary and will bring issues in NAT64-environments). Agreed. An alternative is to use the same approach as in https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-exp-option-00.txt to make ADD_ADDR reliable We can remove the IPVer from ADD_ADDR2 that AFAIK nobody has implemented and replace it with a set of flags. 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+-------+-------+---------------+ | Kind | Length |Subtype| ABCD | Address ID | +---------------+---------------+-------+-------+---------------+ | Address (IPv4 - 4 octets / IPv6 - 16 octets) | +-------------------------------+-------------------------------+ | Port (2 octets, optional) | | +-------------------------------+ | | Truncated HMAC (8 octets) | | +-------------------------------+ | | +-------------------------------+ For example, the A flag could be set to zero when a host announces a new address. The host that receives an ADD_ADDR2 with the A flag set to zero must set the A flag to one and return it to acknowledge it. A host should retransmit the ADD_ADDR2 option up to n times if it wants to ensure that the ADD_ADDR2 option is delivered reliably. This would work for the ADD_ADDR2 option that does not contain any address and has thus a total length of 32 bits. Olivier From nobody Sun Jul 12 23:09:27 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 360F81ACEF2 for ; Sun, 12 Jul 2015 23:09:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.611 X-Spam-Level: X-Spam-Status: No, score=-1.611 tagged_above=-999 required=5 tests=[BAYES_50=0.8, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xj2JaEDyMYUW for ; Sun, 12 Jul 2015 23:09:24 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7E6831AD05F for ; Sun, 12 Jul 2015 23:09:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1436767764; x=2300681364; 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=TjXJIlgGPaZmIG3IH979rOvR0SY/QKhkYeN6OyzVhM4=; b=Iv5BUoGIxxAsZzto5SY4+Wz26pLU8URF3QOzmql8NOslpyFxvwwWPyt2WWenhPAu 04JoWyDaYLIebZL1UkRoHnbu+xXPFzYm8JdNc+7wYYDFVrueJGvgb6lod2Mcx+8l 6JoDLy45W3/Jg7m8eBOeaUhPfdHi4hRwkv3Jjai+9WfO7xTUzsbUgqJCMscYk9Sn SVZ+3VQwt7mAffjWndDTYQ5YKD7Rf69iN6/tV/sCMPNwIf0Qd+S6O0h8hQMLq+er KeSxmoUeYfdpYKT2LXBEmC4p6IT0fiOSo0cPhX6lcXF2jtZaYn1P7bltnMi6VYVM sbtAX1q9vM9oK6t3iUFoNQ==; Received: from relay3.apple.com (relay3.apple.com [17.128.113.83]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id F1.2A.09370.41653A55; Sun, 12 Jul 2015 23:09:24 -0700 (PDT) X-AuditID: 11973e16-f79856d00000249a-7d-55a356145a66 Received: from cilantro.apple.com (cilantro.apple.com [17.128.115.18]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay3.apple.com (Apple SCV relay) with SMTP id 54.A4.32123.31653A55; Sun, 12 Jul 2015 23:09:23 -0700 (PDT) Received: from localhost ([17.153.36.73]) by cilantro.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NRE00KP5X3NLN70@cilantro.apple.com> for multipathtcp@ietf.org; Sun, 12 Jul 2015 23:09:23 -0700 (PDT) Date: Sun, 12 Jul 2015 23:09:23 -0700 From: Christoph Paasch To: Olivier Bonaventure Message-id: <20150713060923.GP1144@Chimay.local> References: <559E8D85.2060603@uclouvain.be> <559F65C6.8030305@uclouvain.be> <20150710173600.GO1144@Chimay.local> <55A031A1.90703@uclouvain.be> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline In-reply-to: <55A031A1.90703@uclouvain.be> User-Agent: Mutt/1.5.23 (2014-03-12) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrILMWRmVeSWpSXmKPExsUi2FAYrCsStjjUYG+axefV19kcGD2WLPnJ FMAYxWWTkpqTWZZapG+XwJUxYe4ploJzihWzJ6xjbGB8JdHFyMkhIWAi0d+wlRnCFpO4cG89 WxcjF4eQwF5GiZNv/rHDFDXs6GGCSExkkni3/zszhNPFJHHi23xWkCoWAVWJD80TwTrYBLQk 3t5uB4uLCFhJnDo9HSzOLGAgsXTORSCbg0NYQEfi9isRkDAvULh/zQyozXcZJa5t/s4IkRCU +DH5HgtEr5bE+p3HmSBsaYlHf2eAzeQEii/bthbsBVEBFYkrE95CXf2SVeL0TIEJjMKzkIya hWTULCSjFjAyr2IUyk3MzNHNzDPXSywoyEnVS87P3cQICuPpdmI7GB+usjrEKMDBqMTD27Bl UagQa2JZcWXuIUZpDhYlcV6pzwtDhQTSE0tSs1NTC1KL4otKc1KLDzEycXBKNTAe7ryWVejA 83bNk8vB5z8nrp5WKfdiG8PnGUyfWe+svJIWaaj40YB/5/OcVoPmxp4NsUr7VDRqz4U2Sm0r DH3O8ucPQ05kt0ru/pSLh2QU1jLJHViQpsU4R788OiuJR7KW8+wiSce+sxc+Bff2XszIky6e 3epnG6StYL9+bV3gMk7WNXdnMCmxFGckGmoxFxUnAgDGc1meRAIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUi2FAspCsctjjU4OAea4vPq6+zOTB6LFny kymAMYrLJiU1J7MstUjfLoErY8LcUywF5xQrZk9Yx9jA+Eqii5GTQ0LARKJhRw8ThC0mceHe erYuRi4OIYGJTBLv9n9nhnC6mCROfJvPClLFIqAq8aF5IjuIzSagJfH2djtYXETASuLU6elg cWYBA4mlcy4C2RwcwgI6ErdfiYCEeYHC/WtmQC24yyhxbfN3RoiEoMSPyfdYIHq1JNbvPM4E YUtLPPo7A2wmJ1B82ba1zCC2qICKxJUJb9knMArMQtI+C0n7LCTtCxiZVzEKFKXmJFYa6yUW FOSk6iXn525iBIdeYfAOxj/LrA4xCnAwKvHwNmxZFCrEmlhWXJl7iFGCg1lJhPfzWaAQb0pi ZVVqUX58UWlOavEhRmkOFiVxXs0pU0KFBNITS1KzU1MLUotgskwcnFINjExzSttM1/kyXo8+ WaUn6R7LL5Qn+4jlk7KqySNZqS+HY5y634hPcvHPk5HyeZTUpPFlZVCk1idT5qC/rx0kUpf8 /ur1bCLv+ZplfQXqF6cf8V8TknCYxdJ50u1vnwK6pBzyzG8vfaMQupCF5dhMEX8J1bO/jHR6 z1yfpv2o89rjl6c3b+HsVGIpzkg01GIuKk4EAFjnb3k5AgAA Archived-At: Cc: multipathtcp@ietf.org Subject: Re: [multipathtcp] Submitted drafts X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Jul 2015 06:09:26 -0000 Hello, On 10/07/15 - 22:57:05, Olivier Bonaventure wrote: > >>>>* https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-addr- > >>>>00.txt > >> > >>This draft includes a slight modification of the handling of the address > >>identifier for the initial subflow. Comments from other implementors would > >>be useful on this draft. > > > >I agree with section 2.1 that having a different address-ID for the > >initial subflow is very cumbersome. An implementation has to store the local > >address-id's within the state-machine of each subflow. It would be much > >easier if we could have a fully global address-table. > > > >However, I'm not sure whether it is good to solve it through an empty > >ADD_ADDR-option. Because, the option is not sent reliably. Even if it gets > >combined with data, we have an issue with unidirectional streams. And > >communicating this ADD_ADDR-option reliably to the peer is here in this case > >even more important than for the "regular" ADD_ADDR option. > > > >It would be better if we could put the address-ID inside the MP_CAPABLE. > >Maybe we can use 8 bits of the key? > > Then the entropy for the key is lower because it is reduced to 56 bits. > > > > >(also, a little nit: Adding the IPVer within this ADD_ADDR-option is not > >necessary and will bring issues in NAT64-environments). > > Agreed. > > An alternative is to use the same approach as in > https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-exp-option-00.txt > > to make ADD_ADDR reliable > > We can remove the IPVer from ADD_ADDR2 that AFAIK nobody has implemented and > replace it with a set of flags. > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +---------------+---------------+-------+-------+---------------+ > | Kind | Length |Subtype| ABCD | Address ID | > +---------------+---------------+-------+-------+---------------+ > | Address (IPv4 - 4 octets / IPv6 - 16 octets) | > +-------------------------------+-------------------------------+ > | Port (2 octets, optional) | | > +-------------------------------+ | > | Truncated HMAC (8 octets) | > | +-------------------------------+ > | | > +-------------------------------+ > > > > For example, the A flag could be set to zero when a host announces a new > address. The host that receives an ADD_ADDR2 with the A flag set to zero > must set the A flag to one and return it to acknowledge it. > > A host should retransmit the ADD_ADDR2 option up to n times if it wants to > ensure that the ADD_ADDR2 option is delivered reliably. Yes, I think it would be good to have such a reliable ADD_ADDR2 exchange. > This would work for the ADD_ADDR2 option that does not contain any address > and has thus a total length of 32 bits. Concerning the address-ID of the initial subflow, I am not sure whether it is worth it to replace the complexity in the implementations of handling the implicit zero address-ID, with a reliable empty ADD_ADDR-exchange (which will also add complexity of its own). If we could add the address-ID in the MP_CAPABLE it would be great (as this will simplify a lot), but I understand that we do not want to lose the entropy of the 64 bits. In general, if the MP_CAPABLE could transport all the information that is relevant for this subflow (address-ID and backup-bit), would be great. Because, as of today, if a stack sends a SYN+MP_CAPABLE on a subflow that is actually meant to operate as a "backup" subflow (as soon as another subflow with higher priority can be established), a stack has to send an MP_PRIO immediately after the 3-way handshake. The reliability of the MP_CAPABLE in the SYN could actually get exploited to send such information immediately (as is already done in the MP_JOIN). Considering that the keys are already sent in plaintext, maybe the loss of entropy is not such a big deal? Cheers, Christoph From nobody Wed Jul 15 02:05:36 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A85031A00A4 for ; Wed, 15 Jul 2015 02:05:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qqHTrMewX45q for ; Wed, 15 Jul 2015 02:05:33 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6AE2B1A0098 for ; Wed, 15 Jul 2015 02:05:33 -0700 (PDT) Received: from omfedm05.si.francetelecom.fr (unknown [xx.xx.xx.1]) by omfedm09.si.francetelecom.fr (ESMTP service) with ESMTP id B48FA2DC4F3; Wed, 15 Jul 2015 11:05:31 +0200 (CEST) Received: from localhost.localdomain (unknown [127.0.0.1]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 9829935C048; Wed, 15 Jul 2015 11:05:31 +0200 (CEST) Received: from omfedm05.si.francetelecom.fr by omfedm05.si.francetelecom.fr with queue id 298353-31; Wed, 15 Jul 2015 09:05:31 GMT Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.18]) by omfedm05.si.francetelecom.fr (ESMTP service) with ESMTP id 7D6A235C05A; Wed, 15 Jul 2015 11:05:31 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM34.corporate.adroot.infra.ftgroup ([::1]) with mapi id 14.03.0235.001; Wed, 15 Jul 2015 11:05:30 +0200 From: To: "Olivier.Bonaventure@uclouvain.be" , "philip.eardley@bt.com" , "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] Preparing for Prague meeting - things to delete or add to MPTCP protocol bis Thread-Index: AQHQuxz4mS/CMoSoHUSzVGi2xtsxDZ3cPlQg Date: Wed, 15 Jul 2015 09:05:30 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300535BCE9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <1436204168109.20146@bt.com> <1436205703501.53882@bt.com> <787AE7BB302AE849A7480A190F8B933005359DAA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <559FD6FF.3040003@uclouvain.be> In-Reply-To: <559FD6FF.3040003@uclouvain.be> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.5] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.15.81516 Archived-At: Subject: Re: [multipathtcp] Preparing for Prague meeting - things to delete or add to MPTCP protocol bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 09:05:35 -0000 Hi Olivier,=20 Please see inline.=20 Cheers, Med > -----Message d'origine----- > De=A0: Olivier Bonaventure [mailto:Olivier.Bonaventure@uclouvain.be] > Envoy=E9=A0: vendredi 10 juillet 2015 16:30 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; philip.eardley@bt.com; > multipathtcp@ietf.org > Objet=A0: Re: [multipathtcp] Preparing for Prague meeting - things to del= ete > or add to MPTCP protocol bis >=20 > Med, >=20 > > > > A change was proposed in > > (https://tools.ietf.org/html/draft-boucadair-mptcp-symmetric-02) to > > redefine IPVer field of ADD_ADDR as a set of flag bits (see below). Thi= s > > change applies also for ADD_ADDR2. >=20 >=20 > I think that replacing the IP version with a set of flags (at least in > ADD_ADDR2 to prevent backward compatibility problems with the existing > ADD_ADDR implementation) would make sense. [Med] Ok. >=20 > > +-+-+-+-+ > > > > Flags is a set of 4 flags: |C|r|r|r| > > > > +-+-+-+-+ > > > > C flag MUST be set to 1 when the address/port are checked. > > > > "rrr" are for future assignment as additional flag bits. > > > > r bits MUST each be sent as zero and MUST be ignored on receipt. > > >=20 > However, I'm stil not convinced by the usefulness of using the C bit > that you propose. If a host knows that it cannot receive a SYN over a > given address, then the best solution is to not advertise this address. [Med] Agree. An implementation that supports the "C" flag is likely to adve= rtise addresses/ports for which pinholes have been created in NATs/FWs and = address/ports that can be used to receive incoming packets successfully. Th= e issue with the implicit approach (i.e., no C-flag) is at the server side:= should the server interpret the advertisement of an address/port as an ind= ication that packets can be sent without experiencing reachability issues o= r not? The experience has shown that only the endpoint who initiated the fi= rst subflow can create new ones even if addresses/ports have been announced= to the remote peer. =20 The explicit approach (c-flag) explores an alternate approach that is worth= to be investigated, IMHO. > This will typically be the case when a host is behind a NAT or a > firewall (I guess that at some point middlebox vendors will include > software to parse ADD_ADDR and remove the ADD_ADDR that correspond to > addresses that are not reachable accoring to their policies) [Med] We can also consider some middleboxes (read CPEs) that will set the C= -flag on behalf of an endpoints for a better quality of experience. =20 >=20 >=20 > Olivier From nobody Wed Jul 15 07:48:58 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 77BAB1AC417 for ; Wed, 15 Jul 2015 07:48:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dad_iqT_3GVT for ; Wed, 15 Jul 2015 07:48:55 -0700 (PDT) Received: from smtp6.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 8C6A21AC40F for ; Wed, 15 Jul 2015 07:48:55 -0700 (PDT) Received: from mbpobo.dhcp.info.ucl.ac.be (mbpobo.dhcp.info.ucl.ac.be [130.104.228.16]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp6.sgsi.ucl.ac.be) by smtp6.sgsi.ucl.ac.be (Postfix) with ESMTPSA id B32AF1834A7; Wed, 15 Jul 2015 16:48:40 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp6.sgsi.ucl.ac.be B32AF1834A7 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1436971720; bh=KEsEOIW91XCzlKV9dZ6c2hYiySmCOihL5SBjsBcNDpM=; h=Reply-To:Subject:References:To:From:Message-ID:Date:MIME-Version: In-Reply-To:Content-Type:Content-Transfer-Encoding; b=0dINKphItq+rVVwRskS2WqiM1tQl184Wgpw3xQ3CvIptJr8bHItdRq3tvxxb5HCRf c7ZcJWqKq3y837D21cGLo0Z2vBRgpammfPMdveyFLU48MB7ZkLe3F4V7dtsRZr4viD te4KKIcRb5Msg8f8LXg3C5FnwZxVupzXdkN4eTU0= References: <1436204168109.20146@bt.com> <1436205703501.53882@bt.com> <787AE7BB302AE849A7480A190F8B933005359DAA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <559FD6FF.3040003@uclouvain.be> <787AE7BB302AE849A7480A190F8B93300535BCE9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> To: mohamed.boucadair@orange.com, "philip.eardley@bt.com" , "multipathtcp@ietf.org" From: Olivier Bonaventure Message-ID: <55A672C8.7060901@uclouvain.be> Date: Wed, 15 Jul 2015 16:48:40 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <787AE7BB302AE849A7480A190F8B93300535BCE9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99-beta1 at smtp-6.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: B32AF1834A7.A2E13 X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Subject: Re: [multipathtcp] Preparing for Prague meeting - things to delete or add to MPTCP protocol bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 14:48:57 -0000 Med, >> >>> +-+-+-+-+ >>> >>> Flags is a set of 4 flags: |C|r|r|r| >>> >>> +-+-+-+-+ >>> >>> C flag MUST be set to 1 when the address/port are checked. >>> >>> "rrr" are for future assignment as additional flag bits. >>> >>> r bits MUST each be sent as zero and MUST be ignored on receipt. >>> >> >> However, I'm stil not convinced by the usefulness of using the C bit >> that you propose. If a host knows that it cannot receive a SYN over a >> given address, then the best solution is to not advertise this address. > > [Med] Agree. An implementation that supports the "C" flag is likely to advertise addresses/ports for which pinholes have been created in NATs/FWs and address/ports that can be used to receive incoming packets successfully. > The issue with the implicit approach (i.e., no C-flag) is at the server side: should the server interpret the advertisement of an address/port as an indication that packets can be sent without experiencing reachability issues or not? This is what RFC6824 assumes today. ADD_ADDR is only a hint about the possibility of trying to reach this address. Anyway it will be a SYN and the host will wait for a SYN+ACK to confirm the reachability > The experience has shown that only the endpoint who initiated the first subflow can create new ones even if addresses/ports have been announced to the remote peer. AFAIK, there has been no experience on letting the server create subflows on the Internet and see what happens. The existing implementation have assumed that this would be difficult and they have not implemented the code to allow the server to create subflows, but this could be done. It will likelly work in private networks or datacenters > > The explicit approach (c-flag) explores an alternate approach that is worth to be investigated, IMHO. We should probably first try to create subflows from the server. We might be able to install a test server to analyse this on multipath-tcp.org after the holidays. This could give use data on the possibility of creating subflows from the server and the problems that such a feature could cause. > >> This will typically be the case when a host is behind a NAT or a >> firewall (I guess that at some point middlebox vendors will include >> software to parse ADD_ADDR and remove the ADD_ADDR that correspond to >> addresses that are not reachable accoring to their policies) > > [Med] We can also consider some middleboxes (read CPEs) that will set the C-flag on behalf of an endpoints for a better quality of experience. I'm not sure that expecting middleboxes to change the content of the ADD_ADDR is a good approach in the long term. We've seen various problems with middleboxes that change the content of packets Olivier From nobody Wed Jul 15 08:44:18 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6D5291ACE80 for ; Wed, 15 Jul 2015 08:44:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6yAiFk82woy7 for ; Wed, 15 Jul 2015 08:44:14 -0700 (PDT) Received: from mail-in4.apple.com (mail-out4.apple.com [17.151.62.26]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D5CF41ACE7C for ; Wed, 15 Jul 2015 08:44:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1436975054; x=2300888654; 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=HcnHI99FqGhVS99OvuPxuyJXaOKmsasgcAlCGd2YbBo=; b=VkaOYyNMH9tU1a0QXWW8r+hIfUw7bnO8ScmbW9idli1CAiNeo7e9C1N8mOqxeNMl sNLKNEsjYqQ+ebLd4i9XUB2KSSxmDs/YdEd7vgABbRPIuyZgzrLXHiF7UnRUfyE6 k72kkubQGy8uuY3ioZ5sF1OPOFNxW21WCJgTB+O9JAFsEXsx3F34k//zt+01PKSc RINY5F9uXu+57uUV5dMCS7wtNdQjhGYicsKhpqYRPWCcxqjYQMIIoys/ePavGTQm jCIcfQvDeorGTo31XRztkbap8kpLBoel0FTH8SJOl4Uzp/f+LBHqSLJJRLBew+tN TW2guuf/Kv43U/4FUHhEHg==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in4.apple.com (Apple Secure Mail Relay) with SMTP id F8.DF.18963.ECF76A55; Wed, 15 Jul 2015 08:44:14 -0700 (PDT) X-AuditID: 11973e12-f79456d000004a13-2f-55a67fce3b15 Received: from cardamom.apple.com (cardamom.apple.com [17.128.115.94]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id A7.2A.14452.16176A55; Wed, 15 Jul 2015 07:42:41 -0700 (PDT) Received: from localhost ([17.153.60.253]) by cardamom.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NRJ00E55D1PBX30@cardamom.apple.com> for multipathtcp@ietf.org; Wed, 15 Jul 2015 08:44:13 -0700 (PDT) Date: Wed, 15 Jul 2015 08:44:13 -0700 From: Christoph Paasch To: Olivier Bonaventure Message-id: <20150715154413.GF15860@Chimay.local> References: <1436204168109.20146@bt.com> <1436205703501.53882@bt.com> <787AE7BB302AE849A7480A190F8B933005359DAA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <559FD6FF.3040003@uclouvain.be> <787AE7BB302AE849A7480A190F8B93300535BCE9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <55A672C8.7060901@uclouvain.be> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline In-reply-to: <55A672C8.7060901@uclouvain.be> User-Agent: Mutt/1.5.23 (2014-03-12) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMLMWRmVeSWpSXmKPExsUi2FAYpXuuflmowfvbfBafV19nc2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxtWFjewFW2Urtq9+yNzA+F6si5GTQ0LARGLxhC+MELaYxIV7 69m6GLk4hAT2Mko0zzrPCFPU8HkZI0RiIpPEwlfb2UASQgLdTBKXDiaC2CwCqhLXP8xhBbHZ BLQk3t5uB7NFBKwkTp2ezg7SzCzQxiixccVVsISwQJZEf+dSFhCbV8BQ4vuyBywQG3YySUyf uZMdIiEo8WPyPbAiZqCp63ceZ4KwpSUe/Z0BVMPBwSmgI/FmghVIWFRAReLKhLdgyyQEvrJK zGvbyzqBUXgWklGzkIyahWTUAkbmVYxCuYmZObqZeSZ6iQUFOal6yfm5mxhBoTzdTmgH46lV VocYBTgYlXh4byxZGirEmlhWXJl7iFGag0VJnPdG6rJQIYH0xJLU7NTUgtSi+KLSnNTiQ4xM HJxSDYyGNkndnR9/TlsvNKM74XpXm+Umh/hX+SbvPTQZHwpJV3D6zbugoD/p52bml/sUW+eY BPG/vWCVnmewWnXOHYntLjMZlZ/9asl6G3H/3VwDvZwFxZ2f52r+8xHdkq0VtuQNv/7hqozd 82VOfJE79PiHx5SHa6ZeSduxfn7Iqgd7Dxe9ZVu8wPyBEktxRqKhFnNRcSIAgmyfnUYCAAA= X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUi2FAcp5tYuCzU4NUnfYvPq6+zOTB6LFny kymAMYrLJiU1J7MstUjfLoEr4+rCRvaCrbIV21c/ZG5gfC/WxcjJISFgItHweRkjhC0mceHe erYuRi4OIYGJTBILX21nA0kICXQzSVw6mAhiswioSlz/MIcVxGYT0JJ4e7sdzBYRsJI4dXo6 O0gzs0Abo8TGFVfBEsICWRL9nUtZQGxeAUOJ78sesEBs2MkkMX3mTnaIhKDEj8n3wIqYgaau 33mcCcKWlnj0dwZQDQcHp4COxJsJViBhUQEViSsT3rJPYBSYhaR7FpLuWUi6FzAyr2IUKErN Saw000ssKMhJ1UvOz93ECA69wqgdjA3LrQ4xCnAwKvHwFkxZGirEmlhWXJl7iFGCg1lJhPdQ 9bJQId6UxMqq1KL8+KLSnNTiQ4zSHCxK4rz7W6eECgmkJ5akZqemFqQWwWSZODilGhh1bm0O qqxxKeV9w3fc6MJtOYZ/7H99yiN1Fnhl/jV7e+fKgcUVZ0L35lW0SVx9sbPi3EznwzdCzgZH TdTu8067dXfjWrWV7HnSZjdPqT+fev1Rg9iSuIm3DB8km62IEy659kH8ha9z4NlvavZ595nn Zru//5j1eNMjkZPlbVusFRiKTeacvmWuxFKckWioxVxUnAgAam8ssjkCAAA= Archived-At: Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] Preparing for Prague meeting - things to delete or add to MPTCP protocol bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 15:44:16 -0000 Hello, On 15/07/15 - 16:48:40, Olivier Bonaventure wrote: > >>> +-+-+-+-+ > >>> > >>> Flags is a set of 4 flags: |C|r|r|r| > >>> > >>> +-+-+-+-+ > >>> > >>> C flag MUST be set to 1 when the address/port are checked. > >>> > >>> "rrr" are for future assignment as additional flag bits. > >>> > >>> r bits MUST each be sent as zero and MUST be ignored on receipt. > >>> > >> > >>However, I'm stil not convinced by the usefulness of using the C bit > >>that you propose. If a host knows that it cannot receive a SYN over a > >>given address, then the best solution is to not advertise this address. > > > >[Med] Agree. An implementation that supports the "C" flag is likely to advertise addresses/ports for which pinholes have been created in NATs/FWs and address/ports that can be used to receive incoming packets successfully. > > > >The issue with the implicit approach (i.e., no C-flag) is at the server side: should the server interpret the advertisement of an address/port as an indication that packets can be sent without experiencing reachability issues or not? > > This is what RFC6824 assumes today. ADD_ADDR is only a hint about the > possibility of trying to reach this address. Anyway it will be a SYN and the > host will wait for a SYN+ACK to confirm the reachability I think, concerning the reachability, what is rather interesting is to advertise the secondary address without wanting the peer to even try establishing a new subflow to this address. This advertisement is done in case the "primary" subflow becomes unreachable. If it becomes unreachable, then the peer can use the advertised address to create a new subflow. It's a little bit like the "handover"-mode we did some time ago in the Cellnet, but the other way around (peer creates the subflows not the client). Cheers, Christoph > >The experience has shown that only the endpoint who initiated the first subflow can create new ones even if addresses/ports have been announced to the remote peer. > > AFAIK, there has been no experience on letting the server create subflows on > the Internet and see what happens. The existing implementation have assumed > that this would be difficult and they have not implemented the code to allow > the server to create subflows, but this could be done. It will likelly work > in private networks or datacenters > > > > >The explicit approach (c-flag) explores an alternate approach that is worth to be investigated, IMHO. > > We should probably first try to create subflows from the server. We might be > able to install a test server to analyse this on > multipath-tcp.org after the holidays. This could give use data on the > possibility of creating subflows from the server and the problems that such > a feature could cause. > > > >>This will typically be the case when a host is behind a NAT or a > >>firewall (I guess that at some point middlebox vendors will include > >>software to parse ADD_ADDR and remove the ADD_ADDR that correspond to > >>addresses that are not reachable accoring to their policies) > > > >[Med] We can also consider some middleboxes (read CPEs) that will set the C-flag on behalf of an endpoints for a better quality of experience. > > I'm not sure that expecting middleboxes to change the content of the > ADD_ADDR is a good approach in the long term. We've seen various problems > with middleboxes that change the content of packets > > > Olivier > > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Wed Jul 15 08:49:33 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97C8E1B2B04 for ; Wed, 15 Jul 2015 08:49:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oq0LLobP-WVW for ; Wed, 15 Jul 2015 08:49:31 -0700 (PDT) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 1A1B81B2AFF for ; Wed, 15 Jul 2015 08:49:31 -0700 (PDT) Received: from mbpobo.dhcp.info.ucl.ac.be (mbpobo.dhcp.info.ucl.ac.be [130.104.228.16]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id AC66C1982E0; Wed, 15 Jul 2015 17:49:24 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be AC66C1982E0 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1436975364; bh=RzUniy8p67JlvRPmDj3SYx/978SvUyMQBfr1PGysjLo=; h=Reply-To:Subject:References:To:Cc:From:Message-ID:Date: MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding: Date:From:MIME-Version:To:Subject:References:In-Reply-To: Content-Type:; b=DL3S+B4vVgfYXplWDtiBAHdiiHKSgmvykgidCbvBzuXau1bwESYFwgO4UR+lqoySj W8xhTLelS2QN76v1+VRJIhmb1i69aqpl4o8bN9LtcDJ/BWXGB0o4OOF0NKaC0OO3CZ ikaVcK6CTMQpAiugcv7+MqLJ9jMD7bsmgkwH5WHs= References: <1436204168109.20146@bt.com> <1436205703501.53882@bt.com> <787AE7BB302AE849A7480A190F8B933005359DAA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <559FD6FF.3040003@uclouvain.be> <787AE7BB302AE849A7480A190F8B93300535BCE9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <55A672C8.7060901@uclouvain.be> <20150715154413.GF15860@Chimay.local> To: Christoph Paasch From: Olivier Bonaventure Message-ID: <55A68104.8070401@uclouvain.be> Date: Wed, 15 Jul 2015 17:49:24 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.0.1 MIME-Version: 1.0 In-Reply-To: <20150715154413.GF15860@Chimay.local> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99-beta1 at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: AC66C1982E0.A448C X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] Preparing for Prague meeting - things to delete or add to MPTCP protocol bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 15:49:32 -0000 Christoph, > > On 15/07/15 - 16:48:40, Olivier Bonaventure wrote: >>>>> +-+-+-+-+ >>>>> >>>>> Flags is a set of 4 flags: |C|r|r|r| >>>>> >>>>> +-+-+-+-+ >>>>> >>>>> C flag MUST be set to 1 when the address/port are checked. >>>>> >>>>> "rrr" are for future assignment as additional flag bits. >>>>> >>>>> r bits MUST each be sent as zero and MUST be ignored on receipt. >>>>> >>>> >>>> However, I'm stil not convinced by the usefulness of using the C bit >>>> that you propose. If a host knows that it cannot receive a SYN over a >>>> given address, then the best solution is to not advertise this address. >>> >>> [Med] Agree. An implementation that supports the "C" flag is likely to advertise addresses/ports for which pinholes have been created in NATs/FWs and address/ports that can be used to receive incoming packets successfully. >> >> >>> The issue with the implicit approach (i.e., no C-flag) is at the server side: should the server interpret the advertisement of an address/port as an indication that packets can be sent without experiencing reachability issues or not? >> >> This is what RFC6824 assumes today. ADD_ADDR is only a hint about the >> possibility of trying to reach this address. Anyway it will be a SYN and the >> host will wait for a SYN+ACK to confirm the reachability > > I think, concerning the reachability, what is rather interesting is to > advertise the secondary address without wanting the peer to even try > establishing a new subflow to this address. This advertisement is done in > case the "primary" subflow becomes unreachable. If it becomes unreachable, > then the peer can use the advertised address to create a new subflow. You would then propose a kind of "Backup" flag in the ADD_ADDR option meaning that this address should only be used to create a subflow if the primary subflow fails ? Olivier From nobody Wed Jul 15 09:08:22 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9661E1B3078 for ; Wed, 15 Jul 2015 09:08:20 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.311 X-Spam-Level: X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tpZCXifyI_FF for ; Wed, 15 Jul 2015 09:08:19 -0700 (PDT) Received: from mail-in7.apple.com (mail-out7.apple.com [17.151.62.29]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 767811B30A9 for ; Wed, 15 Jul 2015 09:08:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=apple.com; s=mailout2048s; c=relaxed/simple; q=dns/txt; i=@apple.com; t=1436976499; x=2300890099; 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=E+Abk7XCMzmVKRaZT9hdcL9WHAvQOGab2XzrbcjMw54=; b=j0mWSgYqyvngJ27DU/3nBXkLDhhDCT8l1sb5B6FzVvJNi4Gf5FIL/BZryKIXACOf MJsuoK5VngFDrTpqIOzLoel2/foqM0inlFQ8oIhyhyh1j5l0Pkilj5kfe4M0HieM hzxfIoNj8U4kc/PYjOB5mRTmyCH6JCDXL8q+BxuAwzVF+0v2ewakUBLP5xgnfMiM FB7Cm0OoKbl6BpbW53fXdWqroK+7CnUw4zKu7b6KL2tMgE0+jH4BV7hn0PYKcZNS 88STaxMMfPpo2++sg/zx7l2sdgnPdi6GjlKznY5uX4grHf8Cl0EJj2PPHb4k+LU0 1m2RKR2D8mdpv3q6npHrIQ==; Received: from relay6.apple.com (relay6.apple.com [17.128.113.90]) by mail-in7.apple.com (Apple Secure Mail Relay) with SMTP id 9A.1E.22479.37586A55; Wed, 15 Jul 2015 09:08:19 -0700 (PDT) X-AuditID: 11973e16-f79036d0000057cf-46-55a685731c92 Received: from cardamom.apple.com (cardamom.apple.com [17.128.115.94]) (using TLS with cipher RC4-MD5 (128/128 bits)) (Client did not present a certificate) by relay6.apple.com (Apple SCV relay) with SMTP id 82.27.14452.60776A55; Wed, 15 Jul 2015 08:06:46 -0700 (PDT) Received: from localhost ([17.153.60.253]) by cardamom.apple.com (Oracle Communications Messaging Server 7.0.5.30.0 64bit (built Oct 22 2013)) with ESMTPSA id <0NRJ00E80E5UBX40@cardamom.apple.com> for multipathtcp@ietf.org; Wed, 15 Jul 2015 09:08:18 -0700 (PDT) Date: Wed, 15 Jul 2015 09:08:18 -0700 From: Christoph Paasch To: Olivier Bonaventure Message-id: <20150715160818.GH15860@Chimay.local> References: <1436204168109.20146@bt.com> <1436205703501.53882@bt.com> <787AE7BB302AE849A7480A190F8B933005359DAA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <559FD6FF.3040003@uclouvain.be> <787AE7BB302AE849A7480A190F8B93300535BCE9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <55A672C8.7060901@uclouvain.be> <20150715154413.GF15860@Chimay.local> <55A68104.8070401@uclouvain.be> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-disposition: inline In-reply-to: <55A68104.8070401@uclouvain.be> User-Agent: Mutt/1.5.23 (2014-03-12) X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrKLMWRmVeSWpSXmKPExsUi2FAYpVvcuizU4HsPl8Xn1dfZHBg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV0bFwO0vBbcGKCy0LmRoYd/J2MXJySAiYSNydu4EVwhaTuHBv PVsXIxeHkMBeRon1C1pZYYpmdW1igUhMZJKYeHknM4TTzSTRsfg7G0gVi4CqxPqTnYwgNpuA lsTb2+1g3SICVhKnTk9nB2lgFmhjlNi44ipYQlggS6K/cykLiM0rYCgxf88dqBWNzBItzxex QSQEJX5MvgdWxAw0df3O40wQtrTEo78z2EFsTgEdibufvzKD2KICKhJXJrwF2yYh8JFVYvHe mWwTGIVnIZk1C8msWUhmLWBkXsUolJuYmaObmWeul1hQkJOql5yfu4kRFM7T7cR2MD5cZXWI UYCDUYmHt2HR0lAh1sSy4srcQ4zSHCxK4rw3U5eFCgmkJ5akZqemFqQWxReV5qQWH2Jk4uCU amDkWBFxdZfrS7fUo4ySURcdry0q2L7G0WDOJDbTeUvslzK8c7Q9E7qylVE91Ln0/a+3oTbu gl9nTv30MLu4XYyny/uu6KdFjiUOkr5V8UvllDo2fqlnCHT1TJ17NOjZq3Lhl31rvv+uzLl1 Ot/HcHP2YpbAbctXV5e+6Z5z8T5vdZjBpCsbAuOVWIozEg21mIuKEwHo9c2YSAIAAA== X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrBLMWRmVeSWpSXmKPExsUi2FAcp8tWvizUYNVufYvPq6+zOTB6LFny kymAMYrLJiU1J7MstUjfLoEro2PhdpaC24IVF1oWMjUw7uTtYuTkkBAwkZjVtYkFwhaTuHBv PVsXIxeHkMBEJomJl3cyQzjdTBIdi7+zgVSxCKhKrD/ZyQhiswloSby93c4KYosIWEmcOj2d HaSBWaCNUWLjiqtgCWGBLIn+zqVgK3gFDCXm77nDAjG1kVmi5fkiNoiEoMSPyffAipiBpq7f eZwJwpaWePR3BjuIzSmgI3H381dmEFtUQEXiyoS37BMYBWYhaZ+FpH0WkvYFjMyrGAWKUnMS K830EgsKclL1kvNzNzGCw68wagdjw3KrQ4wCHIxKPLwFU5aGCrEmlhVX5h5ilOBgVhLhPVS9 LFSINyWxsiq1KD++qDQntfgQozQHi5I47/7WKaFCAumJJanZqakFqUUwWSYOTqkGRi03xQPF qp0XfvarbbDpO/+yW6Vb8U7iox3xCy+ta1U+xrHngdalV7K6WsH7l/XNfvWheOczHZ3kR/sC r8UGLlasnn5RvGWTbOTmnf9uXfj14EuIVkTP69iQ4gsGzTOMVl2ZoeGkza/c+js/WdnVrXGv Wab/W5HIl7EfDEKM330MzI+QfbdqhxJLcUaioRZzUXEiAN+9ClU7AgAA Archived-At: Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] Preparing for Prague meeting - things to delete or add to MPTCP protocol bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 15 Jul 2015 16:08:20 -0000 On 15/07/15 - 17:49:24, Olivier Bonaventure wrote: > Christoph, > > > >On 15/07/15 - 16:48:40, Olivier Bonaventure wrote: > >>>>> +-+-+-+-+ > >>>>> > >>>>> Flags is a set of 4 flags: |C|r|r|r| > >>>>> > >>>>> +-+-+-+-+ > >>>>> > >>>>> C flag MUST be set to 1 when the address/port are checked. > >>>>> > >>>>> "rrr" are for future assignment as additional flag bits. > >>>>> > >>>>> r bits MUST each be sent as zero and MUST be ignored on receipt. > >>>>> > >>>> > >>>>However, I'm stil not convinced by the usefulness of using the C bit > >>>>that you propose. If a host knows that it cannot receive a SYN over a > >>>>given address, then the best solution is to not advertise this address. > >>> > >>>[Med] Agree. An implementation that supports the "C" flag is likely to advertise addresses/ports for which pinholes have been created in NATs/FWs and address/ports that can be used to receive incoming packets successfully. > >> > >> > >>>The issue with the implicit approach (i.e., no C-flag) is at the server side: should the server interpret the advertisement of an address/port as an indication that packets can be sent without experiencing reachability issues or not? > >> > >>This is what RFC6824 assumes today. ADD_ADDR is only a hint about the > >>possibility of trying to reach this address. Anyway it will be a SYN and the > >>host will wait for a SYN+ACK to confirm the reachability > > > >I think, concerning the reachability, what is rather interesting is to > >advertise the secondary address without wanting the peer to even try > >establishing a new subflow to this address. This advertisement is done in > >case the "primary" subflow becomes unreachable. If it becomes unreachable, > >then the peer can use the advertised address to create a new subflow. > > You would then propose a kind of "Backup" flag in the ADD_ADDR option > meaning that this address should only be used to create a subflow if the > primary subflow fails ? Yes, something along those lines. When all other addresses are failing, then this "backup"-address can be used for a new subflow. Cheers, Christoph From nobody Wed Jul 15 22:42:42 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A59771B3140 for ; Wed, 15 Jul 2015 22:42:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qkhmHH8JZALF for ; Wed, 15 Jul 2015 22:42:40 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A97261B313B for ; Wed, 15 Jul 2015 22:42:39 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id EFB8A324B8B; Thu, 16 Jul 2015 07:42:37 +0200 (CEST) Received: from localhost.localdomain (unknown [127.0.0.1]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id E29A727C066; Thu, 16 Jul 2015 07:42:37 +0200 (CEST) Received: from omfedm06.si.francetelecom.fr by omfedm06.si.francetelecom.fr with queue id 349408-32; Thu, 16 Jul 2015 05:42:37 GMT Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.2]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id C9F5527C058; Thu, 16 Jul 2015 07:42:37 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06%19]) with mapi id 14.03.0235.001; Thu, 16 Jul 2015 07:42:36 +0200 From: To: "Olivier.Bonaventure@uclouvain.be" , "philip.eardley@bt.com" , "multipathtcp@ietf.org" Thread-Topic: [multipathtcp] Preparing for Prague meeting - things to delete or add to MPTCP protocol bis Thread-Index: AQHQvw1a6fUEmCoE7ki6K9btSJ/JUZ3dkapA Date: Thu, 16 Jul 2015 05:42:36 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300535C5A7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <1436204168109.20146@bt.com> <1436205703501.53882@bt.com> <787AE7BB302AE849A7480A190F8B933005359DAA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <559FD6FF.3040003@uclouvain.be> <787AE7BB302AE849A7480A190F8B93300535BCE9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <55A672C8.7060901@uclouvain.be> In-Reply-To: <55A672C8.7060901@uclouvain.be> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.16.45415 Archived-At: Subject: Re: [multipathtcp] Preparing for Prague meeting - things to delete or add to MPTCP protocol bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2015 05:42:41 -0000 Hi Olivier,=20 Please see inline. Cheers, Med > -----Message d'origine----- > De=A0: Olivier Bonaventure [mailto:Olivier.Bonaventure@uclouvain.be] > Envoy=E9=A0: mercredi 15 juillet 2015 16:49 > =C0=A0: BOUCADAIR Mohamed IMT/OLN; philip.eardley@bt.com; > multipathtcp@ietf.org > Objet=A0: Re: [multipathtcp] Preparing for Prague meeting - things to del= ete > or add to MPTCP protocol bis >=20 > Med, >=20 > >> > >>> +-+-+-+-+ > >>> > >>> Flags is a set of 4 flags: |C|r|r|r| > >>> > >>> +-+-+-+-+ > >>> > >>> C flag MUST be set to 1 when the address/port are checked. > >>> > >>> "rrr" are for future assignment as additional flag bits. > >>> > >>> r bits MUST each be sent as zero and MUST be ignored on > receipt. > >>> > >> > >> However, I'm stil not convinced by the usefulness of using the C bit > >> that you propose. If a host knows that it cannot receive a SYN over a > >> given address, then the best solution is to not advertise this address= . > > > > [Med] Agree. An implementation that supports the "C" flag is likely to > advertise addresses/ports for which pinholes have been created in NATs/FW= s > and address/ports that can be used to receive incoming packets > successfully. >=20 >=20 > > The issue with the implicit approach (i.e., no C-flag) is at the server > side: should the server interpret the advertisement of an address/port as > an indication that packets can be sent without experiencing reachability > issues or not? >=20 > This is what RFC6824 assumes today. ADD_ADDR is only a hint about the > possibility of trying to reach this address. Anyway it will be a SYN and > the host will wait for a SYN+ACK to confirm the reachability [Med] when multiple alternate addresses are available, having the c-flag wi= ll help the remote side decide which address to pick rather than try-and-se= e approach that may not be optimal. c-flag can be considered an additional = hint. >=20 > > The experience has shown that only the endpoint who initiated the first > subflow can create new ones even if addresses/ports have been announced t= o > the remote peer. >=20 > AFAIK, there has been no experience on letting the server create > subflows on the Internet and see what happens. The existing > implementation have assumed that this would be difficult and they have > not implemented the code to allow the server to create subflows, but > this could be done. It will likelly work in private networks or > datacenters >=20 > > > > The explicit approach (c-flag) explores an alternate approach that is > worth to be investigated, IMHO. >=20 > We should probably first try to create subflows from the server. We > might be able to install a test server to analyse this on > multipath-tcp.org after the holidays. This could give use data on the > possibility of creating subflows from the server and the problems that > such a feature could cause. > > > >> This will typically be the case when a host is behind a NAT or a > >> firewall (I guess that at some point middlebox vendors will include > >> software to parse ADD_ADDR and remove the ADD_ADDR that correspond to > >> addresses that are not reachable accoring to their policies) > > > > [Med] We can also consider some middleboxes (read CPEs) that will set > the C-flag on behalf of an endpoints for a better quality of experience. >=20 > I'm not sure that expecting middleboxes to change the content of the > ADD_ADDR is a good approach in the long term. We've seen various > problems with middleboxes that change the content of packets >=20 >=20 > Olivier >=20 From nobody Wed Jul 15 22:54:59 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E5F641B3161 for ; Wed, 15 Jul 2015 22:54:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.677 X-Spam-Level: X-Spam-Status: No, score=-0.677 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, THIS_AD=1.922, UNPARSEABLE_RELAY=0.001] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k-YB2Lgve2xb for ; Wed, 15 Jul 2015 22:54:56 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6BBFC1B315D for ; Wed, 15 Jul 2015 22:54:56 -0700 (PDT) Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id 3499E18C9F2; Thu, 16 Jul 2015 07:54:55 +0200 (CEST) Received: from localhost.localdomain (unknown [127.0.0.1]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 25E2F4C06D; Thu, 16 Jul 2015 07:54:55 +0200 (CEST) Received: from omfedm07.si.francetelecom.fr by omfedm07.si.francetelecom.fr with queue id 409813-36; Thu, 16 Jul 2015 05:54:55 GMT Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.2]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id 09F9C4C069; Thu, 16 Jul 2015 07:54:55 +0200 (CEST) Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06%19]) with mapi id 14.03.0235.001; Thu, 16 Jul 2015 07:54:54 +0200 From: To: Christoph Paasch , Olivier Bonaventure Thread-Topic: [multipathtcp] Preparing for Prague meeting - things to delete or add to MPTCP protocol bis Thread-Index: AQHQvxUbk5HVGpZ3tkifzNAHjOY+Hp3ci/MAgAAFSACAAQaPoA== Date: Thu, 16 Jul 2015 05:54:53 +0000 Message-ID: <787AE7BB302AE849A7480A190F8B93300535C5DF@OPEXCLILMA3.corporate.adroot.infra.ftgroup> References: <1436204168109.20146@bt.com> <1436205703501.53882@bt.com> <787AE7BB302AE849A7480A190F8B933005359DAA@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <559FD6FF.3040003@uclouvain.be> <787AE7BB302AE849A7480A190F8B93300535BCE9@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <55A672C8.7060901@uclouvain.be> <20150715154413.GF15860@Chimay.local> <55A68104.8070401@uclouvain.be> <20150715160818.GH15860@Chimay.local> In-Reply-To: <20150715160818.GH15860@Chimay.local> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.1] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2015.7.16.45415 Archived-At: Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] Preparing for Prague meeting - things to delete or add to MPTCP protocol bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 16 Jul 2015 05:54:58 -0000 Hi Christoph, For this to work, ADD_ADDR should convey the external IP address/port not t= he internal ones. =20 FWIW, the steps to be followed are listed in draft-boucadair-mptcp-symmetri= c: =3D=3D=3D o Each endpoint proceeds to the discovery of upstream flow-aware devices (e.g., NAT, Firewall). This can be achieved by various means, e.g., using UPnP IGD [IGD1][IGD2], PCP server discovery [RFC6887], PCP DHCP option [RFC7291], DS-Lite AFTR [RFC6334], etc. A NAT/firewall can be embedded in a CPE (Customer Premises Equipment) and/or hosted in the network provider's side. o Appropriate mappings are instantiated in those discovered flow- aware devices. In particular, external IP address(es) and port numbers are retrieved. This can be achieved using PCP [RFC6887]. Note, mappings created by PCP MAP requests are, by definition, endpoint-independent mappings (EIMs) with endpoint-independent filtering (EIF). Filters can be associated with the PCP MAP request to restrict a mapping to be bound to specific remote peer(s). PCP allows to dynamically control both NATs and firewalls. Furthermore, PCP allows to retrieve the lifetime associated with an external IP address and external port number. If the host is a UPnP IGD Control Point, [RFC6970] allows to relay UPnP IGD primitives into PCP messages. PCP can also be used to control multi-layered NATs/firewall owing to the activation of [I-D.ietf-pcp-proxy] in intermediate NATs/firewalls. o When initiating an MPTCP connection, external IP addresses and port numbers are communicated to the remote peer. =3D=3D=3D=3D=3D Cheers, Med > -----Message d'origine----- > De=A0: Christoph Paasch [mailto:cpaasch@apple.com] > Envoy=E9=A0: mercredi 15 juillet 2015 18:08 > =C0=A0: Olivier Bonaventure > Cc=A0: BOUCADAIR Mohamed IMT/OLN; philip.eardley@bt.com; > multipathtcp@ietf.org > Objet=A0: Re: [multipathtcp] Preparing for Prague meeting - things to del= ete > or add to MPTCP protocol bis >=20 > On 15/07/15 - 17:49:24, Olivier Bonaventure wrote: > > Christoph, > > > > > >On 15/07/15 - 16:48:40, Olivier Bonaventure wrote: > > >>>>> +-+-+-+-+ > > >>>>> > > >>>>> Flags is a set of 4 flags: |C|r|r|r| > > >>>>> > > >>>>> +-+-+-+-+ > > >>>>> > > >>>>> C flag MUST be set to 1 when the address/port are checked. > > >>>>> > > >>>>> "rrr" are for future assignment as additional flag bits. > > >>>>> > > >>>>> r bits MUST each be sent as zero and MUST be ignored on > receipt. > > >>>>> > > >>>> > > >>>>However, I'm stil not convinced by the usefulness of using the C bi= t > > >>>>that you propose. If a host knows that it cannot receive a SYN over > a > > >>>>given address, then the best solution is to not advertise this > address. > > >>> > > >>>[Med] Agree. An implementation that supports the "C" flag is likely > to advertise addresses/ports for which pinholes have been created in > NATs/FWs and address/ports that can be used to receive incoming packets > successfully. > > >> > > >> > > >>>The issue with the implicit approach (i.e., no C-flag) is at the > server side: should the server interpret the advertisement of an > address/port as an indication that packets can be sent without > experiencing reachability issues or not? > > >> > > >>This is what RFC6824 assumes today. ADD_ADDR is only a hint about the > > >>possibility of trying to reach this address. Anyway it will be a SYN > and the > > >>host will wait for a SYN+ACK to confirm the reachability > > > > > >I think, concerning the reachability, what is rather interesting is to > > >advertise the secondary address without wanting the peer to even try > > >establishing a new subflow to this address. This advertisement is done > in > > >case the "primary" subflow becomes unreachable. If it becomes > unreachable, > > >then the peer can use the advertised address to create a new subflow. > > > > You would then propose a kind of "Backup" flag in the ADD_ADDR option > > meaning that this address should only be used to create a subflow if th= e > > primary subflow fails ? >=20 > Yes, something along those lines. > When all other addresses are failing, then this "backup"-address can be > used > for a new subflow. >=20 >=20 > Cheers, > Christoph From nobody Sat Jul 18 09:23:59 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5C821A017C for ; Sat, 18 Jul 2015 09:23:57 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bOEvHwWGQ00a for ; Sat, 18 Jul 2015 09:23:55 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3CC41A0151 for ; Sat, 18 Jul 2015 09:23:54 -0700 (PDT) Received: from EVHUB04-UKBR.domain1.systemhost.net (193.113.108.172) by EVMED05-UKBR.bt.com (10.216.161.37) with Microsoft SMTP Server (TLS) id 14.3.195.1; Sat, 18 Jul 2015 17:23:51 +0100 Received: from rew09926dag03d.domain1.systemhost.net (10.55.202.30) by EVHUB04-UKBR.domain1.systemhost.net (193.113.108.172) with Microsoft SMTP Server (TLS) id 14.3.158.1; Sat, 18 Jul 2015 17:23:52 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03d.domain1.systemhost.net (10.55.202.30) with Microsoft SMTP Server (TLS) id 15.0.995.29; Sat, 18 Jul 2015 17:23:51 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.0995.031; Sat, 18 Jul 2015 17:23:51 +0100 From: To: Thread-Topic: Update to the draft agenda for MPTCP WG meeting Thread-Index: AQHQwUdm9R8/ZU3kq0OsJjdJrFVOLg== Date: Sat, 18 Jul 2015 16:23:51 +0000 Message-ID: <1437236644644.6193@bt.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.187.101.41] Content-Type: multipart/alternative; boundary="_000_14372366446446193btcom_" MIME-Version: 1.0 Archived-At: Subject: [multipathtcp] Update to the draft agenda for MPTCP WG meeting X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 18 Jul 2015 16:23:58 -0000 --_000_14372366446446193btcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable We've been working on a new version of the agenda (draft - updates still po= ssible). https://www.ietf.org/proceedings/93/agenda/agenda-93-mptcp Volunteers for note taking and jabber scribing would be much appreciated. Please could presenters send slides by lunchtime Monday. We've broken the agenda into several sections. First we hear briefly about the status of the various implementations. If anyone with another implementation wants to be added, please let us know= . We also need to discuss what goes in the WG doc - the suggestion was to sta= rt with "Guidelines for implementers" https://tools.ietf.org/html/draft-bar= re-mptcp-impl-00 (and perhaps include some info from https://tools.ietf.org= /html/draft-eardley-mptcp-implementations-survey) The second section is about Operational Experiences of using MPTCP http://d= atatracker.ietf.org/doc/draft-ietf-mptcp-experience/ . The doc has gone through WG last call. We should discuss how to complete th= is doc, if anything is missing (perhaps to motivate proposed changes to RFC= 6824bis?) Thomas: Please highlight anything from your work that should be included in= the WG doc, which isn't already. Sorry the time constraints mean that your= timeslot is shorter than you hoped. Olivier: Do you want 5-10 minutes to highlight work from your recent submit= ted papers? The third major topic is to discuss changes to RFC6824bis. The primary goal= of the WG is to publish this on the Standards track. Our suggestion is to = use our face-to-face time to discuss those proposals that have generated di= scussion /interest, and hopefully resolve each of them (resolution to be co= nfirmed on the mailing list). I think the list is:- * http://datatracker.ietf.org/doc/draft-bonaventure-mptcp-exp-option/ * Do we need both 4 & 8 byte Data ack & DSS? * http://datatracker.ietf.org/doc/draft-barre-mptcp-tfo/ * http://datatracker.ietf.org/doc/draft-paasch-mptcp-syncookies/ * http://datatracker.ietf.org/doc/draft-boucadair-mptcp-symmetric/ * http://datatracker.ietf.org/doc/draft-bonaventure-mptcp-addr/ Please let us know if there are any other proposed mods to RFC6824bis that = you think would particularly benefit from face-to-face discussion. Unfortunately this is likely to use all our agenda time up, and there are a= couple of presentations that we may therefore not get to. Hopefully we'll = get another session for MPTCP, but if not we'll organise an interim (audio)= meeting. Also to highlight that Costin Raiciu's talk, rough title "Three ways to (ab= )use Multipath TCP Congestion Control" is now part of the ICCRG meeting (W= ednesday, 3.50pm - 5.10pm, Congress Hall I). thanks, best wishes, Phil & Yoshi. --_000_14372366446446193btcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

We've been working on a new version of the agenda (draft - updates = still possible). http= s://www.ietf.org/proceedings/93/agenda/agenda-93-mptcp

 

Volunteers for note taking and jabber scribing would be much appreciated= .

Please could presenters send slides by lunchtime Monday.

 

We've broken the agenda into several sections.

First we hear briefly about the status of the various implementations. <= /p>

If anyone with another implementation wants to be added, please let us k= now.

We also need to discuss what goes in the WG doc - the suggestion was to = start with "Guidelines for implementers" https://t= ools.ietf.org/html/draft-barre-mptcp-impl-00 (and perhaps include = some info from https://tools.ietf.org/html/draft-eardley-mptcp-implementations-survey)=

 

The second section is about Operational Experiences of using MPTCP= http://datatracker.ietf.org/doc/draft-ietf-mptcp-experience/ . <= /p>

The doc has gone through WG last call. We should discuss how to co= mplete this doc, if anything is missing (perhaps to motivate proposed chang= es to RFC6824bis?)

Thomas: Please highlight anything from your work that should be in= cluded in the WG doc, which isn't already. Sorry the time constraints mean = that your timeslot is shorter than you hoped.

Olivier: Do you want 5-10 minutes to highlight work from your rece= nt submitted papers?

 

The third major topic is to discuss changes to RFC6824bis. = The primary goal of the WG is to publish this on the Standards track. Our s= uggestion is to use our face-to-face time to discuss those proposals that h= ave generated discussion /interest, and hopefully resolve each of them (resolution to be confirmed on the mail= ing list). I think the list is:-
* http://datatracker.ietf.org/doc/draft-bonaventure-mptcp-exp-option/<= /a>
* Do we need both 4 & 8 byte Data ack & DSS?
* http:/= /datatracker.ietf.org/doc/draft-barre-mptcp-tfo/
* http://datatracker.ietf.org/doc/draft-paasch-mptcp-syncookies/
* http://datatracker.ietf.org/doc/draft-boucadair-mptcp-symmetric/ * http://datatracker.ietf.org/doc/draft-bonaventure-mptcp-addr/

 

Please let us know if there are any other proposed mods to RFC6824b= is that you think would particularly benefit from face-to-face discussion.

 

Unfortunately this is likely to use all our agenda time up, and there ar= e a couple of presentations that we may therefore not get to. Hopefully we'= ll get another session for MPTCP, but if not we'll organise an interim (aud= io) meeting.

 

Also to highlight that Costin Raiciu's talk, rough title "Three way= s to (ab)use Multipath TCP Congestion Control" is now part of the= ICCRG meeting  (Wednesday, 3.50pm - 5.10pm, Congress Hall I).

 

thanks,

best wishes,

Phil & Yoshi.

--_000_14372366446446193btcom_-- From nobody Mon Jul 20 11:57:09 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8AC1B2A9C for ; Mon, 20 Jul 2015 11:57:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mnOKnxyXy3vI for ; Mon, 20 Jul 2015 11:57:04 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.135]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DD4FD1A87D2 for ; Mon, 20 Jul 2015 11:57:03 -0700 (PDT) Received: from EVMHT01-UKBR.domain1.systemhost.net (193.113.108.42) by EVMED01-UKBR.bt.com (10.216.161.31) with Microsoft SMTP Server (TLS) id 14.3.195.1; Mon, 20 Jul 2015 19:57:00 +0100 Received: from rew09926dag03c.domain1.systemhost.net (10.55.202.26) by EVMHT01-UKBR.domain1.systemhost.net (193.113.108.42) with Microsoft SMTP Server (TLS) id 8.3.342.0; Mon, 20 Jul 2015 19:57:01 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03c.domain1.systemhost.net (10.55.202.26) with Microsoft SMTP Server (TLS) id 15.0.995.29; Mon, 20 Jul 2015 19:57:00 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.0995.031; Mon, 20 Jul 2015 19:57:01 +0100 From: To: Thread-Topic: Update to the draft agenda for MPTCP WG meeting Thread-Index: AQHQwUdm9R8/ZU3kq0OsJjdJrFVOLp3kt2Qh Date: Mon, 20 Jul 2015 18:57:00 +0000 Message-ID: <1437418635105.71434@bt.com> References: <1437236644644.6193@bt.com> In-Reply-To: <1437236644644.6193@bt.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.187.101.37] Content-Type: multipart/alternative; boundary="_000_143741863510571434btcom_" MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] Update to the draft agenda for MPTCP WG meeting X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 Jul 2015 18:57:07 -0000 --_000_143741863510571434btcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, I uploaded all the presentations that I received so far. also tweaked the a= genda slightly. https://datatracker.ietf.org/meeting/93/materials.html [& search for mptcp] I'm expecting several more. Please send to me as soon as possible - early tomorrow. This is important so that [1] remote participants have access to the slides [2] I've had some network problems, so last minute uploads are likely not t= o be possible thanks! phil ________________________________ From: multipathtcp on behalf of philip.eard= ley@bt.com Sent: 18 July 2015 17:23 To: multipathtcp@ietf.org Subject: [multipathtcp] Update to the draft agenda for MPTCP WG meeting We've been working on a new version of the agenda (draft - updates still po= ssible). https://www.ietf.org/proceedings/93/agenda/agenda-93-mptcp Volunteers for note taking and jabber scribing would be much appreciated. Please could presenters send slides by lunchtime Monday. We've broken the agenda into several sections. First we hear briefly about the status of the various implementations. If anyone with another implementation wants to be added, please let us know= . We also need to discuss what goes in the WG doc - the suggestion was to sta= rt with "Guidelines for implementers" https://tools.ietf.org/html/draft-bar= re-mptcp-impl-00 (and perhaps include some info from https://tools.ietf.org= /html/draft-eardley-mptcp-implementations-survey) The second section is about Operational Experiences of using MPTCP http://d= atatracker.ietf.org/doc/draft-ietf-mptcp-experience/ . The doc has gone through WG last call. We should discuss how to complete th= is doc, if anything is missing (perhaps to motivate proposed changes to RFC= 6824bis?) Thomas: Please highlight anything from your work that should be included in= the WG doc, which isn't already. Sorry the time constraints mean that your= timeslot is shorter than you hoped. Olivier: Do you want 5-10 minutes to highlight work from your recent submit= ted papers? The third major topic is to discuss changes to RFC6824bis. The primary goal= of the WG is to publish this on the Standards track. Our suggestion is to = use our face-to-face time to discuss those proposals that have generated di= scussion /interest, and hopefully resolve each of them (resolution to be co= nfirmed on the mailing list). I think the list is:- * http://datatracker.ietf.org/doc/draft-bonaventure-mptcp-exp-option/ * Do we need both 4 & 8 byte Data ack & DSS? * http://datatracker.ietf.org/doc/draft-barre-mptcp-tfo/ * http://datatracker.ietf.org/doc/draft-paasch-mptcp-syncookies/ * http://datatracker.ietf.org/doc/draft-boucadair-mptcp-symmetric/ * http://datatracker.ietf.org/doc/draft-bonaventure-mptcp-addr/ Please let us know if there are any other proposed mods to RFC6824bis that = you think would particularly benefit from face-to-face discussion. Unfortunately this is likely to use all our agenda time up, and there are a= couple of presentations that we may therefore not get to. Hopefully we'll = get another session for MPTCP, but if not we'll organise an interim (audio)= meeting. Also to highlight that Costin Raiciu's talk, rough title "Three ways to (ab= )use Multipath TCP Congestion Control" is now part of the ICCRG meeting (W= ednesday, 3.50pm - 5.10pm, Congress Hall I). thanks, best wishes, Phil & Yoshi. --_000_143741863510571434btcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

I uploaded all the presentations that I received so far. also tweaked th= e agenda slightly.

 

https= ://datatracker.ietf.org/meeting/93/materials.html [& search fo= r mptcp]

 

I'm expecting several more.

Please send to me as soon as possible - early tomorrow.

 

This is important so that

[1] remote participants have access to the slides

[2] I've had some network problems, so last minute uploads are likely no= t to be possible

 

thanks!

phil

From: multipathtcp <mu= ltipathtcp-bounces@ietf.org> on behalf of philip.eardley@bt.com <phil= ip.eardley@bt.com>
Sent: 18 July 2015 17:23
To: multipathtcp@ietf.org
Subject: [multipathtcp] Update to the draft agenda for MPTCP WG meet= ing
 

We've been working on a new version of the agenda (draft - updates = still possible). http= s://www.ietf.org/proceedings/93/agenda/agenda-93-mptcp

 

Volunteers for note taking and jabber scribing would be much appreciated= .

Please could presenters send slides by lunchtime Monday.

 

We've broken the agenda into several sections.

First we hear briefly about the status of the various implementations. <= /p>

If anyone with another implementation wants to be added, please let us k= now.

We also need to discuss what goes in the WG doc - the suggestion was to = start with "Guidelines for implementers" https://t= ools.ietf.org/html/draft-barre-mptcp-impl-00 (and perhaps include = some info from https://tools.ietf.org/html/draft-eardley-mptcp-implementations-survey)=

 

The second section is about Operational Experiences of using MPTCP= http://datatracker.ietf.org/doc/draft-ietf-mptcp-experience/ . <= /p>

The doc has gone through WG last call. We should discuss how to co= mplete this doc, if anything is missing (perhaps to motivate proposed chang= es to RFC6824bis?)

Thomas: Please highlight anything from your work that should be in= cluded in the WG doc, which isn't already. Sorry the time constraints mean = that your timeslot is shorter than you hoped.

Olivier: Do you want 5-10 minutes to highlight work from your rece= nt submitted papers?

 

The third major topic is to discuss changes to RFC6824bis. = The primary goal of the WG is to publish this on the Standards track. Our s= uggestion is to use our face-to-face time to discuss those proposals that h= ave generated discussion /interest, and hopefully resolve each of them (resolution to be confirmed on the mail= ing list). I think the list is:-
* http://datatracker.ietf.org/doc/draft-bonaventure-mptcp-exp-option/<= /a>
* Do we need both 4 & 8 byte Data ack & DSS?
* http:/= /datatracker.ietf.org/doc/draft-barre-mptcp-tfo/
* http://datatracker.ietf.org/doc/draft-paasch-mptcp-syncookies/
* http://datatracker.ietf.org/doc/draft-boucadair-mptcp-symmetric/ * http://datatracker.ietf.org/doc/draft-bonaventure-mptcp-addr/

 

Please let us know if there are any other proposed mods to RFC6824b= is that you think would particularly benefit from face-to-face discussion.

 

Unfortunately this is likely to use all our agenda time up, and there ar= e a couple of presentations that we may therefore not get to. Hopefully we'= ll get another session for MPTCP, but if not we'll organise an interim (aud= io) meeting.

 

Also to highlight that Costin Raiciu's talk, rough title "Three way= s to (ab)use Multipath TCP Congestion Control" is now part of the= ICCRG meeting  (Wednesday, 3.50pm - 5.10pm, Congress Hall I).

 

thanks,

best wishes,

Phil & Yoshi.

--_000_143741863510571434btcom_-- From nobody Mon Jul 20 21:42:36 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 191121ACE47 for ; Mon, 20 Jul 2015 21:42:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.22 X-Spam-Level: * X-Spam-Status: No, score=1.22 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FM_FORGED_GMAIL=0.622, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qS5QrJBpuQj2 for ; Mon, 20 Jul 2015 21:42:33 -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 3DC071ACC88 for ; Mon, 20 Jul 2015 21:42:19 -0700 (PDT) Received: from mail-yk0-f169.google.com (mail-yk0-f169.google.com [209.85.160.169]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 385A62780C9 for ; Tue, 21 Jul 2015 13:42:18 +0900 (JST) Received: by ykfw194 with SMTP id w194so76100165ykf.0 for ; Mon, 20 Jul 2015 21:42:16 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.129.82.129 with SMTP id g123mr21433873ywb.9.1437453736766; Mon, 20 Jul 2015 21:42:16 -0700 (PDT) Received: by 10.37.223.74 with HTTP; Mon, 20 Jul 2015 21:42:16 -0700 (PDT) Date: Mon, 20 Jul 2015 21:42:16 -0700 Message-ID: From: Yoshifumi Nishida To: multipathtcp Content-Type: text/plain; charset=UTF-8 Archived-At: Subject: [multipathtcp] note takers and jabber volunteer for Prague meeting X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 04:42:35 -0000 We're looking for note takers and jabber volunteer for our WG meeting. If you're interested, please let chairs know. It will save our meeting time if we can have someone before the meeting starts. We really appreciate your cooperation. If you're interested, but you're not very sure what to do, please feel free to contact me. Thanks, -- Yoshi & Phil From nobody Tue Jul 21 04:02:52 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2ADEC1A0063 for ; Tue, 21 Jul 2015 04:02:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F_vAl3bDVp_U for ; Tue, 21 Jul 2015 04:02:44 -0700 (PDT) Received: from smtp5.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) by ietfa.amsl.com (Postfix) with ESMTP id 6FD4E1A009E for ; Tue, 21 Jul 2015 04:02:44 -0700 (PDT) Received: from dhcp-9a5b.meeting.ietf.org (dhcp-9a5b.meeting.ietf.org [31.133.154.91]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp5.sgsi.ucl.ac.be) by smtp5.sgsi.ucl.ac.be (Postfix) with ESMTPSA id D718E1982F5 for ; Tue, 21 Jul 2015 13:02:25 +0200 (CEST) X-DKIM: Sendmail DKIM Filter v2.8.3 smtp5.sgsi.ucl.ac.be D718E1982F5 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1437476545; bh=d3CUKYFkcJ5RYuXP6YytanJN94rgDzrmsi92xJHsCDU=; h=Reply-To:To:From:Subject:Message-ID:Date:MIME-Version: Content-Type:Content-Transfer-Encoding:Date:From:MIME-Version:To: Subject:References:In-Reply-To:Content-Type:; b=XvhYY/e/GrO3wmkmh2uaRkNyoxXdt8PCxDSnNx4qtDh2GXVWj0Rg6ImmMGE2TuMCF TgbAwmVZg9UnAeyopwTzPe43UcS1GPcBpszKOdvyeHHKiPuAJBlspH7NsGWt8mKEgN YEGWtZoyD7MIlZ2S+RK3LeG6hLvcvGmscBB8oqiE= To: multipathtcp From: Olivier Bonaventure Message-ID: <55AE26C0.90005@uclouvain.be> Date: Tue, 21 Jul 2015 13:02:24 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99-beta1 at smtp-5.sipr-dc.ucl.ac.be X-Virus-Status: Clean X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-MailScanner-ID: D718E1982F5.A35FA X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Subject: [multipathtcp] Implementation draft X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list Reply-To: Olivier.Bonaventure@uclouvain.be List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 21 Jul 2015 11:02:49 -0000 Hello, Our charter recommends that we write a draft on the guidelines for implementors. There are now several interoperable implementations, which shows that the protocol specification is understable. The two existing drafts on this topic are : https://tools.ietf.org/html/draft-eardley-mptcp-implementations-survey-02 https://tools.ietf.org/html/draft-barre-mptcp-impl-00 I would suggest to gather the known implementors and write a short draft to meet this remaining milestone. A possible table of contents could be : 1. Introduction 2. Known implementations brief description of the known MPTCP implementations 3. Implementation choices Some discussion of the choices made by implementors, such as : - support for add_addr/add_addr2 and remove_addr - support for 32bits/64 bits dsn - support for congestion control - support for other features of the protocol 4. Interoperability a matrix with the known interopebility among the implementations 5. Conclusion Olivier From nobody Wed Jul 22 04:48:15 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9CD441B2C77 for ; Wed, 22 Jul 2015 04:48:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.61 X-Spam-Level: X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2D2rvRGCMa4A for ; Wed, 22 Jul 2015 04:48:11 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.141]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6E321B2C62 for ; Wed, 22 Jul 2015 04:48:10 -0700 (PDT) Received: from E07HT05-UKBR.domain1.systemhost.net (193.113.197.167) by EVMED05-UKBR.bt.com (10.216.161.37) with Microsoft SMTP Server (TLS) id 14.3.195.1; Wed, 22 Jul 2015 12:44:00 +0100 Received: from rew09926dag03a.domain1.systemhost.net (10.55.202.18) by E07HT05-UKBR.domain1.systemhost.net (193.113.197.167) with Microsoft SMTP Server (TLS) id 8.3.342.0; Wed, 22 Jul 2015 12:42:42 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03a.domain1.systemhost.net (10.55.202.18) with Microsoft SMTP Server (TLS) id 15.0.995.29; Wed, 22 Jul 2015 12:42:41 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.0995.031; Wed, 22 Jul 2015 12:42:41 +0100 From: To: Thread-Topic: Doodle for Interim MPTCP WG meeting Thread-Index: AQHQxHHyZ1Qmb05sokmk9/FXVadVjQ== Date: Wed, 22 Jul 2015 11:42:40 +0000 Message-ID: <1437565377086.72935@bt.com> Accept-Language: en-GB, en-US Content-Language: en-GB X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.187.101.36] Content-Type: multipart/alternative; boundary="_000_143756537708672935btcom_" MIME-Version: 1.0 Archived-At: Subject: [multipathtcp] Doodle for Interim MPTCP WG meeting X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 11:48:13 -0000 --_000_143756537708672935btcom_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Hi, Please fill in the doodle for when you can make an (audio) interim meeting = of the WG. http://doodle.com/h6v6zyutbrz9ruud In the past we found that 3pm GMT was a good time for people; please say if= this is a bad time for you, as we could see if a different time is now bet= ter for the WG. It was very exciting to hear about all the excellent multipath TCP cativity= during yesterday's meeting. However, we didn't complete the agenda * MPTCP proxy - Xinpeng Wei * Using MPTCP for channel combining for NASA project - Chairs on behalf of = William Ivancic * Deployment use cases - slides presented by Chairs on behalf of A.Palanive= lan There are also several drafts from people who weren't in Prague, at least s= ome of which we should think about how / if to progress (for instance by in= cluding in the protocol bis document). So these should also be considered. We also plan to do the final completion of the Operationl Experiences draft= and create the Implementations WG draft in the next weeks. So the interim meeting will cover the above topics. Best wishes, Phil & Yoshi. --_000_143756537708672935btcom_ Content-Type: text/html; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable

Hi,

 

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

http://doodle.com/h6v6zyu= tbrz9ruud

 

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

 

It was very exciting to hear about all the excellent multipath TCP cativ= ity during yesterday's meeting. However, we didn't complete the agenda

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

 

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

 

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

 

So the interim meeting will cover the above topics.

 

Best wishes,

Phil & Yoshi.



--_000_143756537708672935btcom_-- From nobody Wed Jul 22 08:21:58 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5A991A0334 for ; Wed, 22 Jul 2015 08:21:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7YQcMjSBnIq for ; Wed, 22 Jul 2015 08:21:53 -0700 (PDT) Received: from mail-yk0-x232.google.com (mail-yk0-x232.google.com [IPv6:2607:f8b0:4002:c07::232]) (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 9E1191A064C for ; Wed, 22 Jul 2015 08:21:49 -0700 (PDT) Received: by ykdu72 with SMTP id u72so195187908ykd.2 for ; Wed, 22 Jul 2015 08:21:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=8lbP4y7Bx8M97OhjteddkCm451+2I4/wOK9evGZvQEE=; b=KP+FOqGApZaXSyuAcelTsx6WDMXSRHng4Jl0LqqL/u2iZCjddI2Ig9wUreBxQwO4SK /JW3rV+5cUOagNg8hBzU5bakZnYDOpiOMfh5R6tlb+d4hFg0dq3wlSB2ZoCsk0p4mUwE LbDgL2MsNoUQ8FIWgWHzwVHb6C96tj35jZ7Wmk5PBzcRcKbp81y4eDRBXnINUw5ykIx9 I7++44ceKZeCwjWrdXBV9YNNI3lKAhnreJVPlKdY6I72DFfBJhmAAFCfE+r5sun6CzSx kjJd24NplmrHCzWsfyf7GFNdMWPxhTbCSTJko6/brDGST5hqpoXZxdtvoTf7Zr0+O/v+ iASg== MIME-Version: 1.0 X-Received: by 10.129.73.18 with SMTP id w18mr2873427ywa.28.1437578509058; Wed, 22 Jul 2015 08:21:49 -0700 (PDT) Received: by 10.129.119.9 with HTTP; Wed, 22 Jul 2015 08:21:49 -0700 (PDT) In-Reply-To: <559E8D85.2060603@uclouvain.be> References: <559E8D85.2060603@uclouvain.be> Date: Wed, 22 Jul 2015 16:21:49 +0100 Message-ID: From: Alan Ford To: "multipathtcp@ietf.org" Content-Type: multipart/alternative; boundary=001a114dae4a5e8774051b78547b Archived-At: Subject: Re: [multipathtcp] Submitted drafts X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 15:21:56 -0000 --001a114dae4a5e8774051b78547b Content-Type: text/plain; charset=UTF-8 Hi Olivier, all, Inline... On 9 July 2015 at 16:04, Olivier Bonaventure < Olivier.Bonaventure@uclouvain.be> wrote: > > During the last week we have written and submitted several drafts that > could be of interest for the working group : > > * > https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-exp-option-00.txt > > This draft proposes a standard encoding for experimental MPTCP options. > Given the small number of MPTCP options, it is important to allow > experimenters to use MPTCP options without wasting this limited ressource. > > This met with consensus in the WG session yesterday and I'll wrap it into the next version of the bis draft. However, do we really need to use 2 bytes on the experiment ID? That seems like a lot when we have very limited TCP option space. Surely we want to minimise the overhead? Could we make do with a single byte here? > * https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-addr-00.txt > > This draft discusses some issues with the advertisement of addresses in > Multipath TCP and proposes a small modification to the handling of the > address identifiers of the initial subflow to simplify implementations. It > also shows how the reverse DNS can be used as an alternative to ADD_ADDR to > announce the addresses of servers. This technique is already used for > multipath-tcp.org (I'll reply later in the thread re this) > > * > https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-backup-00.txt > > This draft discusses some issues with the support of backup subflows in > the existing Multipath TCP specification. In RFC6824 backup subflows work > well when a subflow completely stops, but not when a subflow experiences > huge losses. > > As I mentioned in the WG session yesterday, I am not sure this needs any protocol changes, but maybe some improvements to advice in the heuristics section. It was always the intention that end hosts could use any kind of indication they had available to trigger a change between subflows, so if an implementor could shorten timeouts, or use some out-of-band triggers, that would achieve the desired result. Regards, Alan --001a114dae4a5e8774051b78547b Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi Olivier, all,

Inline...

On 9 July 2015 at 1= 6:04, Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be= > wrote:
During the last week we have written and submitted several drafts that coul= d be of interest for the working group :

* https://www.ietf= .org/internet-drafts/draft-bonaventure-mptcp-exp-option-00.txt

This draft proposes a standard encoding for experimental MPTCP options. Giv= en the small number of MPTCP options, it is important to allow experimenter= s to use MPTCP options without wasting this limited ressource.


This met with consensus in the WG sess= ion yesterday and I'll wrap it into the next version of the bis draft.<= /div>

However, do we really need to use 2 bytes on the e= xperiment ID? That seems like a lot when we have very limited TCP option sp= ace. Surely we want to minimise the overhead? Could we make do with a singl= e byte here?
=C2=A0
* https://www.ietf.org/inter= net-drafts/draft-bonaventure-mptcp-addr-00.txt

This draft discusses some issues with the advertisement of addresses in Mul= tipath TCP and proposes a small modification to the handling of the address= identifiers of the initial subflow to simplify implementations. It also sh= ows how the reverse DNS can be used as an alternative to ADD_ADDR to announ= ce the addresses of servers. This technique is already used for multipath-tc= p.org

(I'll reply later in the thre= ad re this)
=C2=A0

* https://www.ietf.org/int= ernet-drafts/draft-bonaventure-mptcp-backup-00.txt

This draft discusses some issues with the support of backup subflows in the= existing Multipath TCP specification. In RFC6824 backup subflows work well= when a subflow completely stops, but not when a subflow experiences huge l= osses.

=C2=A0
As I mentioned in the WG = session yesterday, I am not sure this needs any protocol changes, but maybe= some improvements to advice in the heuristics section. It was always the i= ntention that end hosts could use any kind of indication they had available= to trigger a change between subflows, so if an implementor could shorten t= imeouts, or use some out-of-band triggers, that would achieve the desired r= esult.

Regards,
Alan
--001a114dae4a5e8774051b78547b-- From nobody Wed Jul 22 08:33:51 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4001F1A1B1C for ; Wed, 22 Jul 2015 08:33:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n7acogrHUBQD for ; Wed, 22 Jul 2015 08:33:47 -0700 (PDT) Received: from mail-yk0-x236.google.com (mail-yk0-x236.google.com [IPv6:2607:f8b0:4002:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 003AD1A1B84 for ; Wed, 22 Jul 2015 08:33:16 -0700 (PDT) Received: by ykax123 with SMTP id x123so196051957yka.1 for ; Wed, 22 Jul 2015 08:33:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=U6UyG1aBpWeS4qmqj0LRwQzL2xNbVFhuMQjvCIhbcQc=; b=onyfOdKEDucB5PavvjQu81avrjIrfo6x+E1H/hV198WedrM/USbFp6BY1se4bPwtUW p4yGvtCKWAVDlrhO3ucFYlyPi4zgdRWJYpoV6pWajVOwKT0tVAnlL4TIlc/Sem6M7AfD fR0wbOf4mPz7hlBhm1wi07qJITWBEW4gaHOwZ62lFd9KKK9Y3zVwx/E4ZbCGKSL7fpV2 io0Y2x8ppRFbVqjNTUegNPi0wBnllggiDOC+YPgaJP5d1IWbazH8rPe1ica1mcCC85ao xiJueTb/qRVZeirfnwvrd1MIee94K+j0/l2Mqo3cSFwlEzjPA8JY6UuhuYR2IAJbLvpC J0LQ== MIME-Version: 1.0 X-Received: by 10.170.196.4 with SMTP id n4mr2995646yke.127.1437579196336; Wed, 22 Jul 2015 08:33:16 -0700 (PDT) Received: by 10.129.119.9 with HTTP; Wed, 22 Jul 2015 08:33:16 -0700 (PDT) In-Reply-To: <55A031A1.90703@uclouvain.be> References: <559E8D85.2060603@uclouvain.be> <559F65C6.8030305@uclouvain.be> <20150710173600.GO1144@Chimay.local> <55A031A1.90703@uclouvain.be> Date: Wed, 22 Jul 2015 16:33:16 +0100 Message-ID: From: Alan Ford To: Olivier Bonaventure Content-Type: multipart/alternative; boundary=001a113979b055937b051b787d6d Archived-At: Cc: "multipathtcp@ietf.org" Subject: Re: [multipathtcp] Submitted drafts X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 22 Jul 2015 15:33:50 -0000 --001a113979b055937b051b787d6d Content-Type: text/plain; charset=UTF-8 Hi all, On 10 July 2015 at 21:57, Olivier Bonaventure < Olivier.Bonaventure@uclouvain.be> wrote: > Christoph, > > * https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-addr- >>>>> 00.txt >>>>> >>>> >>> This draft includes a slight modification of the handling of the address >>> identifier for the initial subflow. Comments from other implementors >>> would >>> be useful on this draft. >>> >> >> I agree with section 2.1 that having a different address-ID for the >> initial subflow is very cumbersome. An implementation has to store the >> local >> address-id's within the state-machine of each subflow. It would be much >> easier if we could have a fully global address-table. >> >> This issue puzzles me, is this really such a big issue? I haven't implemented this myself of course, but as I understand it, you just want to use a single table for all address-to-addressID mappings. OK, fine. But you already have connection-level state (for the key etc), so is it really too complex to e.g. have a single byte in your connection-level state that points to the index on your global mapping table? That seems much more simple and much more reliable than a potentially unreliable signal! > However, I'm not sure whether it is good to solve it through an empty >> ADD_ADDR-option. Because, the option is not sent reliably. Even if it gets >> combined with data, we have an issue with unidirectional streams. And >> communicating this ADD_ADDR-option reliably to the peer is here in this >> case >> even more important than for the "regular" ADD_ADDR option. >> >> It would be better if we could put the address-ID inside the MP_CAPABLE. >> Maybe we can use 8 bits of the key? >> > > Then the entropy for the key is lower because it is reduced to 56 bits. > > Definitely thumbs-down for that I'm afraid! > (also, a little nit: Adding the IPVer within this ADD_ADDR-option is not >> necessary and will bring issues in NAT64-environments). >> > > Agreed. > > An alternative is to use the same approach as in > > https://www.ietf.org/internet-drafts/draft-bonaventure-mptcp-exp-option-00.txt > > to make ADD_ADDR reliable > > We can remove the IPVer from ADD_ADDR2 that AFAIK nobody has implemented > and replace it with a set of flags. > > 1 2 3 > 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 > +---------------+---------------+-------+-------+---------------+ > | Kind | Length |Subtype| ABCD | Address ID | > +---------------+---------------+-------+-------+---------------+ > | Address (IPv4 - 4 octets / IPv6 - 16 octets) | > +-------------------------------+-------------------------------+ > | Port (2 octets, optional) | | > +-------------------------------+ | > | Truncated HMAC (8 octets) | > | +-------------------------------+ > | | > +-------------------------------+ > > > > For example, the A flag could be set to zero when a host announces a new > address. The host that receives an ADD_ADDR2 with the A flag set to zero > must set the A flag to one and return it to acknowledge it. > > A host should retransmit the ADD_ADDR2 option up to n times if it wants to > ensure that the ADD_ADDR2 option is delivered reliably. > > This would work for the ADD_ADDR2 option that does not contain any address > and has thus a total length of 32 bits. That seems an interesting idea. We can certainly remove IPVer (as you say it's implied by length now). It was only relevant when we could put multiple addresses in one option - before we had the HMAC. Having flags could be useful - I like to idea of reliability like this. We could use the same trick on REMOVE_ADDR. Incidentally, if we end up bumping the MPTCP version for the syncookies support (and I think this is a good idea - I'm awaiting an updated draft to comment in more detail on this one), then we can also put ADD_ADDR2 back to its rightful place as ADD_ADDR :) Regards, Alan --001a113979b055937b051b787d6d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Hi all,

On 10 July 2015 at 21:57, Olivier Bonaventure = <O= livier.Bonaventure@uclouvain.be> wrote:
Christoph,

* https://www.ietf.org/internet-drafts/draft-bonaventur= e-mptcp-addr-
00.txt

This draft includes a slight modification of the handling of the address identifier for the initial subflow. Comments from other implementors would<= br> be useful on this draft.

I agree with section 2.1 that having a different address-ID for the
initial subflow is very cumbersome. An implementation has to store the loca= l
address-id's within the state-machine of each subflow. It would be much=
easier if we could have a fully global address-table.


This issue puzzles= me, is this really such a big issue? I haven't implemented this myself= of course, but as I understand it, you just want to use a single table for= all address-to-addressID mappings.

OK, fine. But = you already have connection-level state (for the key etc), so is it really = too complex to e.g. have a single byte in your connection-level state that = points to the index on your global mapping table? That seems much more simp= le and much more reliable than a potentially unreliable signal!
= =C2=A0
<= span class=3D""> However, I'm not sure whether it is good to solve it through an empty ADD_ADDR-option. Because, the option is not sent reliably. Even if it gets<= br> combined with data, we have an issue with unidirectional streams. And
communicating this ADD_ADDR-option reliably to the peer is here in this cas= e
even more important than for the "regular" ADD_ADDR option.

It would be better if we could put the address-ID inside the MP_CAPABLE. Maybe we can use 8 bits of the key?

Then the entropy for the key is lower because it is reduced to 56 bits.


Definitely thumbs-down for that= I'm afraid!
=C2=A0
(also, a little nit: Adding the IPVer within this ADD_ADDR-option is not necessary and will bring issues in NAT64-environments).

Agreed.

An alternative is to use the same approach as in
https://www.ietf.org/i= nternet-drafts/draft-bonaventure-mptcp-exp-option-00.txt

to make ADD_ADDR reliable

We can remove the IPVer from ADD_ADDR2 that AFAIK nobody has implemented an= d replace it with a set of flags.

=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 1=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A02=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A03
=C2=A0 =C2=A0 =C2=A0 =C2=A00 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 = 4 5 6 7 8 9 0 1
=C2=A0 =C2=A0 =C2=A0 +---------------+---------------+-------+-------+-----= ----------+
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0Kind=C2=A0 =C2=A0 =C2=A0 |=C2=A0 = =C2=A0 =C2=A0Length=C2=A0 =C2=A0 |Subtype| ABCD=C2=A0 |=C2=A0 Address ID=C2= =A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 +---------------+---------------+-------+-------+-----= ----------+
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 Address (IPv4 - 4 = octets / IPv6 - 16 octets)=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 +-------------------------------+---------------------= ----------+
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0Port (2 octets, optional)=C2=A0 =C2=A0|= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 +-------------------------------+=C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 Truncated HMAC (8 octets)=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 |
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0+---------------= ----------------+
=C2=A0 =C2=A0 =C2=A0 |=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0|
=C2=A0 =C2=A0 =C2=A0 +-------------------------------+



For example, the A flag could be set to zero when a host announces a new ad= dress. The host that receives an ADD_ADDR2 with the A flag set to zero must= set the A flag to one and=C2=A0 return it to acknowledge it.

A host should retransmit the ADD_ADDR2 option up to n times if it wants to = ensure that the ADD_ADDR2 option is delivered reliably.

This would work for the ADD_ADDR2 option that does not contain any address = and has thus a total length of 32 bits.

Tha= t seems an interesting idea. We can certainly remove IPVer (as you say it&#= 39;s implied by length now). It was only relevant when we could put multipl= e addresses in one option - before we had the HMAC. Having flags could be u= seful - I like to idea of reliability like this. We could use the same tric= k on REMOVE_ADDR.

Incidentally, if we end up bumpi= ng the MPTCP version for the syncookies support (and I think this is a good= idea - I'm awaiting an updated draft to comment in more detail on this= one), then we can also put ADD_ADDR2 back to its rightful place as ADD_ADD= R :)

Regards,
Alan

<= /div>
--001a113979b055937b051b787d6d-- From nobody Thu Jul 23 06:40:33 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D71D1A1BE6; Thu, 23 Jul 2015 06:40:31 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.912 X-Spam-Level: X-Spam-Status: No, score=-101.912 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_WHITELIST=-100] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M1k92DlKxwzG; Thu, 23 Jul 2015 06:40:30 -0700 (PDT) Received: from rfc-editor.org (rfc-editor.org [IPv6:2001:1900:3001:11::31]) by ietfa.amsl.com (Postfix) with ESMTP id 12CA81A1A40; Thu, 23 Jul 2015 06:40:30 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id 0D535180205; Thu, 23 Jul 2015 06:36:32 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org X-PHP-Originating-Script: 1005:ams_util_lib.php From: rfc-editor@rfc-editor.org Message-Id: <20150723133632.0D535180205@rfc-editor.org> Date: Thu, 23 Jul 2015 06:36:32 -0700 (PDT) Archived-At: Cc: multipathtcp@ietf.org, rfc-editor@rfc-editor.org Subject: [multipathtcp] RFC 7430 on Analysis of Residual Threats and Possible Fixes for Multipath TCP (MPTCP) X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 23 Jul 2015 13:40:31 -0000 A new Request for Comments is now available in online RFC libraries. RFC 7430 Title: Analysis of Residual Threats and Possible Fixes for Multipath TCP (MPTCP) Author: M. Bagnulo, C. Paasch, F. Gont, O. Bonaventure, C. Raiciu Status: Informational Stream: IETF Date: July 2015 Mailbox: marcelo@it.uc3m.es, christoph.paasch@gmail.com, fgont@si6networks.com, Olivier.Bonaventure@uclouvain.be, costin.raiciu@cs.pub.ro Pages: 19 Characters: 41877 Updates/Obsoletes/SeeAlso: None I-D Tag: draft-ietf-mptcp-attacks-04.txt URL: https://www.rfc-editor.org/info/rfc7430 DOI: http://dx.doi.org/10.17487/RFC7430 This document analyzes the residual threats for Multipath TCP (MPTCP) and explores possible solutions to address them. This document is a product of the Multipath TCP Working Group of the IETF. INFORMATIONAL: This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see https://www.ietf.org/mailman/listinfo/ietf-announce https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see https://www.rfc-editor.org/search For downloading RFCs, see https://www.rfc-editor.org/rfc.html Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From nobody Tue Jul 28 08:49:41 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 066DB1ACD3B for ; Tue, 28 Jul 2015 08:49:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YyubfVVoCTNf for ; Tue, 28 Jul 2015 08:49:37 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.135]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 280C01ACD30 for ; Tue, 28 Jul 2015 08:49:37 -0700 (PDT) Received: from E07HT05-UKBR.domain1.systemhost.net (193.113.197.167) by EVMED01-UKBR.bt.com (10.216.161.31) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 28 Jul 2015 16:49:31 +0100 Received: from rew09926dag03c.domain1.systemhost.net (10.55.202.26) by E07HT05-UKBR.domain1.systemhost.net (193.113.197.167) with Microsoft SMTP Server (TLS) id 8.3.342.0; Tue, 28 Jul 2015 16:49:35 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03c.domain1.systemhost.net (10.55.202.26) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 28 Jul 2015 16:49:34 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.0995.031; Tue, 28 Jul 2015 16:49:34 +0100 From: To: Thread-Topic: [multipathtcp] RFC 7430 on Analysis of Residual Threats and Possible Fixes for Multipath TCP (MPTCP) Thread-Index: AQHQxU1UvbYK6rxqwU224YxBG66QsJ3xDLIQ Date: Tue, 28 Jul 2015 15:49:34 +0000 Message-ID: <5bea84d8173f47c7a3603337cda99d78@rew09926dag03b.domain1.systemhost.net> References: <20150723133632.0D535180205@rfc-editor.org> In-Reply-To: <20150723133632.0D535180205@rfc-editor.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.202.233] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] RFC 7430 on Analysis of Residual Threats and Possible Fixes for Multipath TCP (MPTCP) X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 15:49:40 -0000 Thanks to Marcelo, Christoph, Fernando, Olivier and Costin for all the work= on this. > -----Original Message----- > From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of > rfc-editor@rfc-editor.org > Sent: 23 July 2015 14:37 > To: ietf-announce@ietf.org; rfc-dist@rfc-editor.org > Cc: multipathtcp@ietf.org; rfc-editor@rfc-editor.org > Subject: [multipathtcp] RFC 7430 on Analysis of Residual Threats and > Possible Fixes for Multipath TCP (MPTCP) >=20 > A new Request for Comments is now available in online RFC libraries. >=20 >=20 > RFC 7430 >=20 > Title: Analysis of Residual Threats and > Possible Fixes for Multipath TCP (MPTCP) > Author: M. Bagnulo, C. Paasch, > F. Gont, O. Bonaventure, C. Raiciu > Status: Informational > Stream: IETF > Date: July 2015 > Mailbox: marcelo@it.uc3m.es, > christoph.paasch@gmail.com, > fgont@si6networks.com, > Olivier.Bonaventure@uclouvain.be, > costin.raiciu@cs.pub.ro > Pages: 19 > Characters: 41877 > Updates/Obsoletes/SeeAlso: None >=20 > I-D Tag: draft-ietf-mptcp-attacks-04.txt >=20 > URL: https://www.rfc-editor.org/info/rfc7430 > =09 > DOI: http://dx.doi.org/10.17487/RFC7430 >=20 > This document analyzes the residual threats for Multipath TCP (MPTCP) > and explores possible solutions to address them. >=20 > This document is a product of the Multipath TCP Working Group of the > IETF. >=20 >=20 > INFORMATIONAL: This memo provides information for the Internet > community. > It does not specify an Internet standard of any kind. Distribution of > this memo is unlimited. >=20 > This announcement is sent to the IETF-Announce and rfc-dist lists. > To subscribe or unsubscribe, see > https://www.ietf.org/mailman/listinfo/ietf-announce > https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist >=20 > For searching the RFC series, see https://www.rfc-editor.org/search For > downloading RFCs, see https://www.rfc-editor.org/rfc.html >=20 > Requests for special distribution should be addressed to either the > author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless > specifically noted otherwise on the RFC itself, all RFCs are for > unlimited distribution. >=20 >=20 > The RFC Editor Team > Association Management Solutions, LLC >=20 >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Tue Jul 28 09:22:46 2015 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7CDB51ACDCE for ; Tue, 28 Jul 2015 09:22:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.611 X-Spam-Level: X-Spam-Status: No, score=-2.611 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tTd4oPs_DCeJ for ; Tue, 28 Jul 2015 09:22:42 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.138]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1C6F1ACDAE for ; Tue, 28 Jul 2015 09:22:41 -0700 (PDT) Received: from EVHUB04-UKBR.domain1.systemhost.net (193.113.108.172) by EVMED04-UKBR.bt.com (10.216.161.34) with Microsoft SMTP Server (TLS) id 14.3.195.1; Tue, 28 Jul 2015 17:22:37 +0100 Received: from rew09926dag03d.domain1.systemhost.net (10.55.202.30) by EVHUB04-UKBR.domain1.systemhost.net (193.113.108.172) with Microsoft SMTP Server (TLS) id 14.3.158.1; Tue, 28 Jul 2015 17:22:39 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03d.domain1.systemhost.net (10.55.202.30) with Microsoft SMTP Server (TLS) id 15.0.995.29; Tue, 28 Jul 2015 17:22:37 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.0995.031; Tue, 28 Jul 2015 17:22:38 +0100 From: To: , Thread-Topic: [multipathtcp] Implementation draft Thread-Index: AQHQw6ThM7RviyNWn0ivNJH6lpL29p3xGnQw Date: Tue, 28 Jul 2015 16:22:37 +0000 Message-ID: <8e886f03d4da4cd89e049aab0d2b5ec3@rew09926dag03b.domain1.systemhost.net> References: <55AE26C0.90005@uclouvain.be> In-Reply-To: <55AE26C0.90005@uclouvain.be> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.55.202.233] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] Implementation draft X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 28 Jul 2015 16:22:44 -0000 Thanks Olivier. Assuming this isn't too much work, I think it's worth doing. If it is a lot= of work, we should discuss Lars's suggestion of not doing this doc. Yes, it would be interesting to record what features aren't implemented by = (some of) the implementations. Deployment status and plans (to the extent p= ublic) could also be interesting. The charter says <> I think some of this material is already in the protocol RFC or bis doc. Is= it worth moving? Phil > -----Original Message----- > From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of > Olivier Bonaventure > Sent: 21 July 2015 12:02 > To: multipathtcp > Subject: [multipathtcp] Implementation draft >=20 > Hello, >=20 > Our charter recommends that we write a draft on the guidelines for > implementors. There are now several interoperable implementations, > which shows that the protocol specification is understable. >=20 > The two existing drafts on this topic are : >=20 > https://tools.ietf.org/html/draft-eardley-mptcp-implementations-survey- > 02 >=20 > https://tools.ietf.org/html/draft-barre-mptcp-impl-00 >=20 > I would suggest to gather the known implementors and write a short > draft to meet this remaining milestone. A possible table of contents > could be : >=20 > 1. Introduction >=20 > 2. Known implementations >=20 > brief description of the known MPTCP implementations >=20 > 3. Implementation choices >=20 > Some discussion of the choices made by implementors, such as : > - support for add_addr/add_addr2 and remove_addr > - support for 32bits/64 bits dsn > - support for congestion control > - support for other features of the protocol >=20 > 4. Interoperability >=20 > a matrix with the known interopebility among the implementations >=20 > 5. Conclusion >=20 >=20 >=20 >=20 > Olivier >=20 > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp