From nobody Tue Jun 5 01:13:45 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81B8D130F11 for ; Tue, 5 Jun 2018 01:13:42 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y3JN2l1ztHOt for ; Tue, 5 Jun 2018 01:13:39 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 98B1A130F0E for ; Tue, 5 Jun 2018 01:13:39 -0700 (PDT) Received: from rew09926dag03d.domain1.systemhost.net (10.55.202.30) by EVMED02-UKBR.bt.com (10.216.161.32) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 5 Jun 2018 09:13:35 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03d.domain1.systemhost.net (10.55.202.30) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Tue, 5 Jun 2018 09:13:35 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.1293.004; Tue, 5 Jun 2018 09:13:35 +0100 From: To: Thread-Topic: WG Last Call for draft-ietf-mptcp-rfc6824bis Thread-Index: AdP8pPjqwq5n45WRS2ywhz4YK91ZcQ== Date: Tue, 5 Jun 2018 08:13:35 +0000 Message-ID: <0dd5e48298ed4b4fb7344630abc794b7@rew09926dag03b.domain1.systemhost.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.202.232] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 08:13:43 -0000 VGhpcyBzdGFydHMgYSBXRyBMYXN0IENhbGwgZm9yIGRyYWZ0LWlldGYtbXB0Y3AtcmZjNjgyNGJp cy4gUGxlYXNlIHNlbmQgY29tbWVudHMgYnkgdGhlIGVuZCBvZiBKdW5lLiANCg0KUGxlYXNlIG5v dGUgdGhlcmUgYXJlIHRocmVlIElQUiBkaXNjbG9zdXJlcyAod2UncmUgd29ya2luZyBvbiBnZXR0 aW5nIHRoZW0gYWRkZWQgdG8gdGhlIHJmYzY4MjRiaXMgcGFnZSk6IA0KDQoqIHR3byBhcmUgaW5o ZXJpdGVkIGZyb20gUkZDNjgyNCAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9pcHIvc2Vh cmNoLz9zdWJtaXQ9ZHJhZnQmaWQ9ZHJhZnQtaWV0Zi1tcHRjcC1tdWx0aWFkZHJlc3NlZCAgICAN Ciogb25lIGlzIGluaGVyaXRlZCBmcm9tIGRyYWZ0LXBhYXNjaC1tcHRjcC1zeW5jb29raWVzICh3 aGljaCBnb3QgaW5jbHVkZSBpbiByZmM2ODI0YmlzKSBodHRwczovL2RhdGF0cmFja2VyLmlldGYu b3JnL2lwci8yNjc4LyANCg0KVGhhbmtzLA0KUGhpbCAmIFlvc2hpDQo= From nobody Tue Jun 5 04:21:31 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 292D1130FBD for ; Tue, 5 Jun 2018 04:21:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id e089tkagi6I7 for ; Tue, 5 Jun 2018 04:21:26 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38081130FB8 for ; Tue, 5 Jun 2018 04:21:26 -0700 (PDT) Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by EVMED03-UKBR.bt.com (10.216.161.33) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 5 Jun 2018 12:21:22 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03b.domain1.systemhost.net (10.55.202.22) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Tue, 5 Jun 2018 12:21:22 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.1293.004; Tue, 5 Jun 2018 12:21:22 +0100 From: To: Thread-Topic: WG Last Call for draft-ietf-mptcp-rfc6824bis Thread-Index: AdP8pPjqwq5n45WRS2ywhz4YK91ZcQAGiU/g Date: Tue, 5 Jun 2018 11:21:21 +0000 Message-ID: <39fbc9f18384473398fca38670c73cf6@rew09926dag03b.domain1.systemhost.net> References: <0dd5e48298ed4b4fb7344630abc794b7@rew09926dag03b.domain1.systemhost.net> In-Reply-To: <0dd5e48298ed4b4fb7344630abc794b7@rew09926dag03b.domain1.systemhost.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.202.232] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jun 2018 11:21:30 -0000 As a reminder, this document Obsoletes: 6824 (if approved) and its Intended= status is Standards Track. As well as suggested changes or edits, positive review comments ("It's read= y") are also very valuable.=20 -----Original Message----- From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of phil= ip.eardley@bt.com Sent: 05 June 2018 09:14 To: multipathtcp@ietf.org Subject: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis This starts a WG Last Call for draft-ietf-mptcp-rfc6824bis. Please send com= ments by the end of June.=20 Please note there are three IPR disclosures (we're working on getting them = added to the rfc6824bis page):=20 * two are inherited from RFC6824 https://datatracker.ietf.org/ipr/search/?= submit=3Ddraft&id=3Ddraft-ietf-mptcp-multiaddressed =20 * one is inherited from draft-paasch-mptcp-syncookies (which got include in= rfc6824bis) https://datatracker.ietf.org/ipr/2678/=20 Thanks, Phil & Yoshi _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Sun Jun 10 02:18:21 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B90A5130E23 for ; Sun, 10 Jun 2018 02:18:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.001 X-Spam-Level: X-Spam-Status: No, score=-0.001 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FDaxQTyvIk2x for ; Sun, 10 Jun 2018 02:18:17 -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 9794D1292F1 for ; Sun, 10 Jun 2018 02:18:17 -0700 (PDT) Received: from mail-io0-f178.google.com (mail-io0-f178.google.com [209.85.223.178]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id CE3EE27834B for ; Sun, 10 Jun 2018 18:18:14 +0900 (JST) Received: by mail-io0-f178.google.com with SMTP id g7-v6so20565733ioh.11 for ; Sun, 10 Jun 2018 02:18:14 -0700 (PDT) X-Gm-Message-State: APt69E0YNppw8loDiw4/b/SG9BHygVTdCxvbtzg1LgQvTNeJhhGmEgYd iAWQQWkrGSYJz0jM5DVJ1StFTSiCdbEttOr1c4o= X-Google-Smtp-Source: ADUXVKKVm1RyaaIJioNJ/JPRTkkzGx4AhlXTYMU0CyZfhPtOmnKbbI14mklmD8gB+5gXLnyarzv3VheYfCtn14CwkHc= X-Received: by 2002:a6b:3446:: with SMTP id b67-v6mr6513190ioa.6.1528622293613; Sun, 10 Jun 2018 02:18:13 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:11c4:0:0:0:0:0 with HTTP; Sun, 10 Jun 2018 02:18:13 -0700 (PDT) From: Yoshifumi Nishida Date: Sun, 10 Jun 2018 02:18:13 -0700 X-Gmail-Original-Message-ID: Message-ID: To: multipathtcp Content-Type: multipart/alternative; boundary="000000000000ce8228056e461c12" Archived-At: Subject: [multipathtcp] some comments on draft-ietf-mptcp-rfc6824bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jun 2018 09:18:20 -0000 --000000000000ce8228056e461c12 Content-Type: text/plain; charset="UTF-8" Hello, Although I am still reading the draft, I have a few comments on 6824bis. 1: Section 3.5 "If Host A wants to fore the closure of an MPTCP connection, it has two different options:" -> It might be better if there are some descriptions about why we have 2 options here. Also, a simple guidance of choosing them might be useful. "if a host receives a packet with a valid MP_FASECLOSE option.." -> It seems that the rest of paragraph only explains the behavior for Option A. If so, I think this should be stated to avoid confusions. 2: As we have removed AddrID from MP_PRIO, we have a certain problem in the situations like the followings. Let's say a server has two address S1, S2 while the client is behind FW. Since the client is behind firewall, the server uses ADD_ADDR to send the info of S2 through S1, but it wants S2 to be used as a backup. In this case, if MP_PRIO has addr id field, the server is able to specify S2 is a backup. However, since MP_PRIO doesn't have addr id any more, all the server can do is to wait until the client establishes the connection with S2. But, this connection doesn't look what the server wants. I guess using 1 bit in ADD_ADDR might solve the issue. Thanks, -- Yoshi --000000000000ce8228056e461c12 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,
Although I am still reading= the draft, I have a few comments on 6824bis.

1: Section 3.5
=C2= =A0 =C2=A0 "If Host A wants to fore the closure of an MPTCP connection= , it has two different options:"
=C2=A0 =C2=A0 =C2=A0 =C2=A0-> I= t might be better if there are some descriptions about why we have 2 option= s here. Also, a simple guidance of choosing them might be useful.

= =C2=A0 =C2=A0"if a host receives a packet with a valid MP_FASECLOSE op= tion.."
=C2=A0 =C2=A0 =C2=A0 =C2=A0-> It seems that the rest of = paragraph only explains the behavior for Option A. If so, I think this shou= ld be stated to avoid confusions.

2: =C2=A0As we have removed AddrID= from MP_PRIO, we have a certain problem in the situations like the followi= ngs.

Let's say a server has two address S1, S2 while the client = is behind FW. Since=C2=A0the client is behind firewall, the server uses ADD= _ADDR to send the info of S2 through S1, but it wants S2 to be used as a ba= ckup.

In this case, if MP_PRIO has addr id field, the server is able= to specify S2 is=C2=A0a backup. However, since MP_PRIO doesn't have ad= dr id any more, all the server can do is to wait until the client establish= es the connection with S2. But, this connection doesn't look what the s= erver wants.=C2=A0
I guess using 1 bit in ADD_ADDR might solve the issu= e.

Thanks,
--
Yoshi
--000000000000ce8228056e461c12-- From nobody Thu Jun 14 00:16:53 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2082C1310D9 for ; Thu, 14 Jun 2018 00:16:52 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfdmNve3Gavy for ; Thu, 14 Jun 2018 00:16:45 -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 E880F1310D3 for ; Thu, 14 Jun 2018 00:16:44 -0700 (PDT) Received: from mail-io0-f172.google.com (mail-io0-f172.google.com [209.85.223.172]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 68D3E278375 for ; Thu, 14 Jun 2018 16:16:42 +0900 (JST) Received: by mail-io0-f172.google.com with SMTP id d22-v6so6107437iof.13 for ; Thu, 14 Jun 2018 00:16:42 -0700 (PDT) X-Gm-Message-State: APt69E0LDzynAWHIR9Pi9rlQUIhLHy1aen5Y+vDJd/8E3R+7WDiHCnP+ oP+p8hEcj6YRCW3ooYT5SDBtQx7tkVOwQQqxhII= X-Google-Smtp-Source: ADUXVKLwBBaNhw+bGfqlC57m+3jVP/BqBNIMbBNCPiN5c4/tXMHlh+UjLGoKM0zRHImCRu+CFS3ietiEobYL3A+pzYY= X-Received: by 2002:a6b:9654:: with SMTP id y81-v6mr1196057iod.237.1528960601315; Thu, 14 Jun 2018 00:16:41 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:11c4:0:0:0:0:0 with HTTP; Thu, 14 Jun 2018 00:16:40 -0700 (PDT) From: Yoshifumi Nishida Date: Thu, 14 Jun 2018 00:16:40 -0700 X-Gmail-Original-Message-ID: Message-ID: To: multipathtcp Content-Type: multipart/alternative; boundary="0000000000008464da056e94e17d" Archived-At: Subject: [multipathtcp] Possible future items for mptcp WG X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 07:16:52 -0000 --0000000000008464da056e94e17d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello everyone, Phil and I have been discussing the next step for the WG. After we finish 6824bis, we =EF=BD=97on't have active WG items as the proxy= work will be discussed at tcpm WG. One suggestion might be to close the WG or to put it in dormant state, however, we are thinking there still might be some more working items as we've seen interesting presentations for new ideas, experiment results and so on at the meetings and on the ML. Below is the list of potential working items from the chairs' point of view= . Please let us know if you think some of them are important items for the WG (and your willingness to contribute if possible) or there are some more items, or this is not something we should work on, etc. Also, if you have some opinions on the status of the WG or suggestions to the chairs, please let us hear! We appreciate your feedback Thanks, -- Yoshi & Phil 1: API extensions (This is already in our charter) draft-hesmans-mptcp-socket draft-samar-mptcp-socketapi 2: Feature extensions a) robust initial setup proposed by Markus, also Kien presented a similar idea b) fast subflow setup proposed by Quentin c) security enhancement 1) TLS draft-bonaventure-mptcp-tls-00 draft-paasch-mptcp-tls-authentication-00 2) Utilize proposals from tcpinc? 3) Elliptic Curve Cryptography draft-kim-mptcp-semptcp-00 d) Solutions for operational issues 1) how to handle nat64 issue proposed by Quentin 2) how to handle load balancer proposed by Fabien, Christoph, Costin 3: Congestion Control (This topic itself should probably be discussed at ICCRG. But, it may trigger some updates of the protocol or APIs later) a) OLIA draft-khalili-mptcp-congestion-control-05 b) mptcp + BBR? presented by Jing --0000000000008464da056e94e17d Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello everyone,

Phil and I have been discussing the next step for the WG.After we finish 6= 824bis, we =EF=BD=97on't have active WG items as the proxy=C2=A0= work will be discussed at tcpm WG.One suggestion might be to close the WG or= to put it in dormant state, however,=C2=A0we are thinking there still might be some more working items as we= 9;ve seen=C2=A0interesting presentati= ons for new ideas, experiment results and so on at the=C2=A0meetings and on the ML.

Below is= the list of potential working items from the chairs' point of view.
Please let = us know if you think some of them are important items for=C2=A0the WG (and your willingness to contribute if pos= sible) or there are=C2=A0some more it= ems, or this is not something we should work on, etc.

A= lso, if you have some opinions on the status of the WG or suggestions=C2=A0= to the chairs, please let us hear!

We appreciate your feedback

Thanks,=
--
Yoshi & Ph= il



=
1: API extensio= ns (This is already in our charter)
=C2=A0 =C2=A0 draft-hesmans-mptcp-socket<= br style=3D"font-size:16px">=C2=A0 =C2=A0 dr= aft-samar-mptcp-socketapi

2: Feature extensions<= br style=3D"font-size:16px">=C2=A0 =C2=A0 a)= robust initial setup
=C2=A0 =C2=A0 =C2=A0 =C2=A0 proposed by Markus,=C2=A0also Kien presented a similar idea

=C2=A0 =C2=A0 b) fast subflow setup
=C2=A0 =C2=A0 =C2=A0 =C2=A0 proposed by= Quentin=C2=A0

=C2=A0 =C2=A0 c) security enhancement
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 1) TLS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-bonaventure= -mptcp-tls-00
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-paasch-mptcp-tls-authenticati= on-00

=C2=A0 =C2=A0 =C2=A0 =C2=A0 2) Utilize proposals = from tcpinc?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 3) Elliptic Cu= rve Cryptography
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-kim-mptcp-semptcp-0= 0

=C2=A0 =C2=A0 d) Solutions for operational issues
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A01) how to handle nat64 issue proposed by Quentin
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A02) how to handle load balancer proposed by Fabien, = Christoph, Costin

3: Congestion Control (This topic its= elf should probably be discussed at ICCRG. But, it may trigger some updates= of the protocol or APIs later) =C2=A0
<= span style=3D"font-size:16px">=C2=A0 =C2=A0 =C2=A0a) OLIA
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 draft-khalili-mptcp-congestion-control-05

=C2=A0 = =C2=A0 =C2=A0b) mptcp + BBR?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 presented by Jing
--0000000000008464da056e94e17d-- From nobody Thu Jun 14 03:55:48 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9152130E1E for ; Thu, 14 Jun 2018 03:55:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JqR_O7txI8Tv for ; Thu, 14 Jun 2018 03:55:43 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9D765130E14 for ; Thu, 14 Jun 2018 03:55:42 -0700 (PDT) Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by EVMED02-UKBR.bt.com (10.216.161.32) with Microsoft SMTP Server (TLS) id 14.3.319.2; Thu, 14 Jun 2018 11:55:35 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03b.domain1.systemhost.net (10.55.202.22) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Thu, 14 Jun 2018 11:55:38 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.1293.004; Thu, 14 Jun 2018 11:55:38 +0100 From: To: , Thread-Topic: WG Last Call for draft-ietf-mptcp-rfc6824bis Thread-Index: AdP8pPjqwq5n45WRS2ywhz4YK91ZcQHJh45A Date: Thu, 14 Jun 2018 10:55:37 +0000 Message-ID: <8aaece0dfe6641ad96f4860720308424@rew09926dag03b.domain1.systemhost.net> References: <0dd5e48298ed4b4fb7344630abc794b7@rew09926dag03b.domain1.systemhost.net> In-Reply-To: <0dd5e48298ed4b4fb7344630abc794b7@rew09926dag03b.domain1.systemhost.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.202.243] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 10:55:46 -0000 A few comments as I work through the document, basically minor so far Section 3.1 << Given the SYN exchange is different between v1 and v0 the exchange cannot be immediately downgraded, and therefore if the far end has requested a lower version then the initiator SHOULD respond with an ACK without any MP_CAPABLE option, to fall back to regular TCP.>> I think it should say "to ensure the exchange cannot..." << The first 4 bits of the first octet in the MP_CAPABLE option (Figure 4) define the MPTCP option subtype (see Section 8; for MP_CAPABLE, this is 0), and the remaining 4 bits of this octet specify the MPTCP version in use (for this specification, this is 1). >> "The first 4 bits of the first octet in the MP_CAPABLE option" Fig 4 shows = two earlier octets (Kind & Length) - I know these arent the MP-CAPABLE opti= on, but I think it might be worth spelling out what they are.=20 Would it be better strictly to have "0x0" rather than "0"? (ie match the IA= NA registry) Section 3.4.1 <> 4 comments: Assinged /assigned The 'E' bit - better to say flag? Section 2.3 needs to be amended to show the reply /echo message for ADD-ADD= R. I suggest the pic in S2.3 also shows the E value.=20 Not sure - does this open security hole, where an attacker pretends an ADD-= ADDR has been received? (the Echo doesn't include an hmac, so is easy to sp= oof) And in Fig 12 | Truncated HMAC (8 octets, if length > 10 octets) | Could this be made more straightforward? Ie spell out when length is >10 oc= tets ie IPv6 (if I understand it). This also seems to mean that IPv4 doesn'= t include the HMAC, is this right?? Thanks phil -----Original Message----- From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of phil= ip.eardley@bt.com Sent: 05 June 2018 09:14 To: multipathtcp@ietf.org Subject: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis This starts a WG Last Call for draft-ietf-mptcp-rfc6824bis. Please send com= ments by the end of June.=20 Please note there are three IPR disclosures (we're working on getting them = added to the rfc6824bis page):=20 * two are inherited from RFC6824 https://datatracker.ietf.org/ipr/search/?= submit=3Ddraft&id=3Ddraft-ietf-mptcp-multiaddressed =20 * one is inherited from draft-paasch-mptcp-syncookies (which got include in= rfc6824bis) https://datatracker.ietf.org/ipr/2678/=20 Thanks, Phil & Yoshi _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Thu Jun 14 06:39:50 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0F50131072 for ; Thu, 14 Jun 2018 06:39:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.301 X-Spam-Level: X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uclouvain.be Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EFFrV14yRGFC for ; Thu, 14 Jun 2018 06:39:45 -0700 (PDT) Received: from smtp1.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D9735130F1B for ; Thu, 14 Jun 2018 06:39:44 -0700 (PDT) Received: from mbpobo.local (unknown [130.104.228.107]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp1.sgsi.ucl.ac.be) by smtp1.sgsi.ucl.ac.be (Postfix) with ESMTPSA id 9216A67DA3A; Thu, 14 Jun 2018 15:39:34 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1528983574; bh=E7yutWvGOTlnnySXnY7HxdZ+gLSmUUTQOj37A5ABF9A=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To:From; b=nqop8BPfEGK2NgK0GCUTrRxMAPjzdqdKHS99K0AkUgU9oZLme0Ngpycsf2qzsH5sZ DJFIDoGy+xdosyLSdXGyVjD1zhdelkQlihsjG4UJBgfCqOMJAnat0/QIlGinVy1B5j wBonqjkHbDJVCPcbTlqAXRlz+NT2aibT8ZeDojnI= X-Virus-Status: Clean X-Virus-Scanned: clamav-milter 0.99.3-beta2 at smtp-1 Reply-To: Olivier.Bonaventure@uclouvain.be To: Yoshifumi Nishida , multipathtcp References: From: Olivier Bonaventure Message-ID: <269c647e-a727-d0e4-e450-0948c8823446@uclouvain.be> Date: Thu, 14 Jun 2018 15:39:34 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr-classic Content-Transfer-Encoding: 8bit X-Sgsi-Spamcheck: SASL authenticated, X-SGSI-Information: X-SGSI-MailScanner-ID: 9216A67DA3A.A85AA X-SGSI-MailScanner: Found to be clean X-SGSI-From: olivier.bonaventure@uclouvain.be X-SGSI-Spam-Status: No Archived-At: Subject: Re: [multipathtcp] Possible future items for mptcp WG X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 13:39:48 -0000 Phil, Yoshifumi, > > Phil and I have been discussing the next step for the WG. > After we finish 6824bis, we ļ½—on't have active WG items as the proxy > work will be discussed at tcpm WG. > One suggestion might be to close the WG or to put it in dormant state, > however, we are thinking there still might be some more working items as > we've seenĀ interesting presentations for new ideas, experiment results > and so on at the meetings and on the ML. > > Below is the list of potential working items from the chairs' point of view. > Please let us know if you think some of them are important items for the > WG (and your willingness to contribute if possible) or there are some > more items, or this is not something we should work on, etc. I think that the socket API still makes sense and it would be useful to have an agreement on an API that is supported by different implementations. At this point, I'm only aware of API efforts on the Linux implementation. Concerning the extensions, I think that it makes sense to reconsider the extensions that we have not included in rfc6824bis and evaluate whether they could be of benefit for Multipath TCP. Congestion control is probably a more difficult topic since ICCRG is the natural place for work on new congestion control schemes. Maybe we should encourage the development of new coupled congestion control schemes. Another direction that the WG could pursue are the interactions with other working groups where Multipath TCP could play a role. For example, v6ops and spring develop the Segment Routing architecture. The IPv6 variant of SR brings a nice framework to allow the establishment of Multipath TCP subflows over specific paths. As IPv6 SR is available on Linux, it becomes possible to perform experiments and think about the interactions between SR and MPTCP. Another example is happy eyeballs. This technique works with HTTP on dual-stack machines. It could also be applied to MPTCP (e.g. with the parallel establishment idea) A third example are the interactions between MPTCP and applications. It would be interesting to interact with WG developing application level protocols to see how to map them on MPTCP. A fourth example is IPv6 multihoming. The rtgwg will soon publish a recommendation on techniques to support IPv6 multihoming. This document mainly assumes that endhosts use single path transport protocols. It would be interesting to work with rtgwg to describe the benefits that MPTCP could bring in this environment. Another example is intermittent connectivity. MPTCP can use multiple paths simultaneously, but it also supports seamless handovers on mobile. On mobiles that have only WiFi connectivity, MPTCP could support intermittent connectivity, i.e. connections that start on one AP, then move a few seconds, minutes or hours later on another AP. This could require to maintain MPTCP connections without an associated subflow for a longer period of time that the default used by TCP. I guess that there are many other possiblities Best regards, Olivier From nobody Thu Jun 14 14:01:26 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E43F130F15 for ; Thu, 14 Jun 2018 14:01:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pOYp5KzzMi7p for ; Thu, 14 Jun 2018 14:01:23 -0700 (PDT) Received: from mail-qt0-x231.google.com (mail-qt0-x231.google.com [IPv6:2607:f8b0:400d:c0d::231]) (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 1B238130E2F for ; Thu, 14 Jun 2018 14:01:23 -0700 (PDT) Received: by mail-qt0-x231.google.com with SMTP id y31-v6so7197960qty.9 for ; Thu, 14 Jun 2018 14:01:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=G98yp7DP88LOs2IAR38GONATJtdGA5i+tBVTakdE6RI=; b=A3bbmqvX7Dts0YFWS34Zw5BaFWurEjyGPFmJyagU/uZ77Hv3RwdODyv6Hud8jUa9w/ aUvHGklnxgQzE44sA3sipSYNnSjorZD9OjXeMdUU+ix1KU09d00KaDTsGMvIxSFvfT8v K32Hl/sIJjwcgo49W7zVREBXxTC4G1sR2AZGP13oLN4iHun0ob7Fxx0VCD2YdfizV+sx VSybCKXQlEzaeboWNNULzk66Ahsaigolmvip6aSzRYir+IGqHEpJBe3ID6p9+vlrDf5z Q5hSsbFfw9yyLJgTNXnmIU4EL7tlVqdisxz9SIIjwI//FyBzLae1hX7OgQ1w+YGWOmEr 00PA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=G98yp7DP88LOs2IAR38GONATJtdGA5i+tBVTakdE6RI=; b=ODwjZQWK1GdZ54EeKv6O9TvVFf7jvu63Khpix0K/kmawHHuTJLB34GI+sSOW2SsM7i +5AoGRQnnx4+i1VeVkG/2hMqNqbIp1RJ/kbEuC34e4Q21FS+1zndH1zLW9CvRnOykqVa bkCCtRnYuA1nCzbpNVebdJkTNPgjsgsAE4U6YB91oKubqyoQGknYZx/E5uHt+DP8tBES HsRKuXccZH5N/GzX/CjzJLo59CJvdxEU0xp+cXKe+qz9Eb5BTdINBl5PdDR6h3c6gIhc WgZUSHowhkA40iCeCExZx3muZNiJDbVaxqTCmkhm541qxyFIGtIpMqa0jZjKMOz+OFm2 niBg== X-Gm-Message-State: APt69E3E1rSOJHytgpQyEQFw4R1ScGqjgEIL0F75tc5Oe43ZyVgs2bPk gzhX6f27O1Jkquw4/NOICdvx7ZCkftTryxlBnw1STQ== X-Google-Smtp-Source: ADUXVKKF0I85LC487QgJs47Qq6IvYfG2ymbvAcE4bBt85KfgdLdFyi/G1pHoSsQHel6tWOuv0QJu7FdQZswRHETSjsA= X-Received: by 2002:a0c:89dd:: with SMTP id 29-v6mr3761597qvs.233.1529010081293; Thu, 14 Jun 2018 14:01:21 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:353a:0:0:0:0:0 with HTTP; Thu, 14 Jun 2018 14:01:20 -0700 (PDT) In-Reply-To: References: From: Xavier de Foy Date: Thu, 14 Jun 2018 17:01:20 -0400 Message-ID: To: Yoshifumi Nishida Cc: multipathtcp Content-Type: multipart/alternative; boundary="000000000000c0eaf3056ea066c4" Archived-At: Subject: Re: [multipathtcp] Possible future items for mptcp WG X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 14 Jun 2018 21:01:25 -0000 --000000000000c0eaf3056ea066c4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Yoshifumi & Phil, Another potential item under "Feature Extensions" could be dedicated to interoperability with 5G. We are preparing an update to the "5G considerations" draft presented in the last session, which can be used as input for the group to decide if it should be on this list. Best Regards, Xavier On Thu, Jun 14, 2018 at 3:16 AM, Yoshifumi Nishida wrote: > Hello everyone, > > Phil and I have been discussing the next step for the WG. > After we finish 6824bis, we =EF=BD=97on't have active WG items as the pro= xy work > will be discussed at tcpm WG. > One suggestion might be to close the WG or to put it in dormant state, > however, we are thinking there still might be some more working items as > we've seen interesting presentations for new ideas, experiment results > and so on at the meetings and on the ML. > > Below is the list of potential working items from the chairs' point of > view. > Please let us know if you think some of them are important items for the > WG (and your willingness to contribute if possible) or there are some > more items, or this is not something we should work on, etc. > > Also, if you have some opinions on the status of the WG or suggestions to > the chairs, please let us hear! > > We appreciate your feedback > > Thanks, > -- > Yoshi & Phil > > > > > 1: API extensions (This is already in our charter) > draft-hesmans-mptcp-socket > draft-samar-mptcp-socketapi > > 2: Feature extensions > a) robust initial setup > proposed by Markus, also Kien presented a similar idea > > b) fast subflow setup > proposed by Quentin > > c) security enhancement > 1) TLS > draft-bonaventure-mptcp-tls-00 > draft-paasch-mptcp-tls-authentication-00 > > 2) Utilize proposals from tcpinc? > > 3) Elliptic Curve Cryptography > draft-kim-mptcp-semptcp-00 > > d) Solutions for operational issues > 1) how to handle nat64 issue proposed by Quentin > 2) how to handle load balancer proposed by Fabien, Christoph, > Costin > > 3: Congestion Control (This topic itself should probably be discussed at > ICCRG. But, it may trigger some updates of the protocol or APIs later) > a) OLIA > draft-khalili-mptcp-congestion-control-05 > > b) mptcp + BBR? > presented by Jing > > _______________________________________________ > multipathtcp mailing list > multipathtcp@ietf.org > https://www.ietf.org/mailman/listinfo/multipathtcp > > --000000000000c0eaf3056ea066c4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Yoshifumi &=20 Phil,

=C2=A0 Another potential item under "Fe= ature Extensions" could be dedicated to interoperability with 5G. We a= re preparing an update to the "5G considerations" draft presented= in the last session, which can be used as input for the group to decide if= it should be on this list.

=C2=A0 Best Regards,
Xavier

On Thu, Jun 14, 2018 at 3:16 AM, Yoshifumi Nishida <ni= shida@sfc.wide.ad.jp> wrote:
Hello everyone,
Phil and I have been discussing the next step for the WG.=
After we finish= 6824bis, we =EF=BD=97on't have active WG items as the proxy=C2=A0work will be discussed at tcpm WG.<= div>One suggestion might be to close the WG = or to put it in dormant state, however,=C2=A0we are thinking there still might be some more working items as we&= #39;ve seen=C2=A0interesting presenta= tions for new ideas, experiment results and so on at the=C2=A0meetings and on the ML.

Below = is the list of potential working items from the chairs' point of view.<= /span>
Please le= t us know if you think some of them are important items for=C2=A0the WG (and your willingness to contribute if p= ossible) or there are=C2=A0some more = items, or this is not something we should work on, etc.

Also, if you have some opinions on the status of the WG or suggestions=C2= =A0to the chairs, please let us hear!=

We appreciate your feedback

Thanks= ,
--
Yoshi & P= hil



1: API extensi= ons (This is already in our charter)
=C2=A0 =C2=A0 draft-hesmans-mptcp-socket=
=C2=A0 =C2=A0 d= raft-samar-mptcp-socketapi

2: Feature extensions=
=C2=A0 =C2=A0 a= ) robust initial setup
=C2=A0 =C2=A0 =C2=A0 =C2=A0 proposed by Markus,=C2=A0<= span style=3D"font-size:16px">also Kien presented a similar idea

=C2=A0 =C2=A0 b) fast subflow setup
=C2=A0 =C2=A0 =C2=A0 =C2=A0 proposed b= y Quentin=C2=A0

=C2=A0 =C2=A0 c) security enhancement
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 1) TLS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-bonaventure= -mptcp-tls-00
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-paasch-mptcp-tls-authentication-00

=C2=A0 =C2=A0 =C2=A0 =C2=A0 2) Utilize proposals from tcpinc?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 3) Elliptic Curve Cryptography=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 draft-kim-mptcp-semptcp-00

=C2= =A0 =C2=A0 d) Solutions for operational issues
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01) = how to handle nat64 issue proposed by Quentin
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02) h= ow to handle load balancer proposed by Fabien, Christoph, Costin

3: Congestion Control (This topic itself should probably be discu= ssed at ICCRG. But, it may trigger some updates of the protocol or APIs lat= er) =C2=A0
=C2=A0 =C2=A0 =C2=A0a) OLIA
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-khalili-mptcp= -congestion-control-05
=C2=A0 =C2=A0 =C2=A0b) mptcp + BBR?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 pr= esented by Jing

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


--000000000000c0eaf3056ea066c4-- From nobody Fri Jun 15 01:03:21 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47BFB130DDC for ; Fri, 15 Jun 2018 01:03:20 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fP73JHZbYdAQ for ; Fri, 15 Jun 2018 01:03:17 -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 A6B20130DC2 for ; Fri, 15 Jun 2018 01:03:17 -0700 (PDT) Received: from mail-io0-f178.google.com (mail-io0-f178.google.com [209.85.223.178]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id B08CE278538 for ; Fri, 15 Jun 2018 17:03:15 +0900 (JST) Received: by mail-io0-f178.google.com with SMTP id s26-v6so9958324ioj.4 for ; Fri, 15 Jun 2018 01:03:15 -0700 (PDT) X-Gm-Message-State: APt69E1LBuQXMYKVSwb/nXOnERgUBdZUKQAn/fkM7M2MEymJRGgLy+Q8 fU6wnCWjxpf0X76Y5O9IEo62/tEeaj5L5asjcFE= X-Google-Smtp-Source: ADUXVKJ1mAgldzrIpk5vnES6TIQtCas86lKzuUllwobhuREIBffw4o9Fcgc7aRP74j80IGtuYC9pW8XLESnBrUqGM5U= X-Received: by 2002:a6b:3446:: with SMTP id b67-v6mr627651ioa.6.1529049794276; Fri, 15 Jun 2018 01:03:14 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:11c4:0:0:0:0:0 with HTTP; Fri, 15 Jun 2018 01:03:13 -0700 (PDT) In-Reply-To: <269c647e-a727-d0e4-e450-0948c8823446@uclouvain.be> References: <269c647e-a727-d0e4-e450-0948c8823446@uclouvain.be> From: Yoshifumi Nishida Date: Fri, 15 Jun 2018 01:03:13 -0700 X-Gmail-Original-Message-ID: Message-ID: To: "Olivier.Bonaventure@uclouvain.be" Cc: Yoshifumi Nishida , multipathtcp Content-Type: multipart/alternative; boundary="000000000000d4f8ff056ea9a5bc" Archived-At: Subject: Re: [multipathtcp] Possible future items for mptcp WG X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 08:03:20 -0000 --000000000000d4f8ff056ea9a5bc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Olivier, Thank you so much for the inputs! I agree that there are many possibilities and the topic you mentioned looks promising. One thing the chairs would like to know is if there are items we can work on in (relatively) short term. If there are promising topics that we can adopt as WG items in our near feature, please share. It will be great if we can discuss such items in our next WG meeting. Thanks, -- Yoshi On Thu, Jun 14, 2018 at 6:39 AM, Olivier Bonaventure wrote: > Phil, Yoshifumi, > >> >> Phil and I have been discussing the next step for the WG. >> After we finish 6824bis, we =EF=BD=97on't have active WG items as the pr= oxy work >> will be discussed at tcpm WG. >> One suggestion might be to close the WG or to put it in dormant state, >> however, we are thinking there still might be some more working items as >> we've seen interesting presentations for new ideas, experiment results a= nd >> so on at the meetings and on the ML. >> >> Below is the list of potential working items from the chairs' point of >> view. >> Please let us know if you think some of them are important items for the >> WG (and your willingness to contribute if possible) or there are some mo= re >> items, or this is not something we should work on, etc. >> > > I think that the socket API still makes sense and it would be useful to > have an agreement on an API that is supported by different implementation= s. > At this point, I'm only aware of API efforts on the Linux implementation. > > Concerning the extensions, I think that it makes sense to reconsider the > extensions that we have not included in rfc6824bis and evaluate whether > they could be of benefit for Multipath TCP. > > Congestion control is probably a more difficult topic since ICCRG is the > natural place for work on new congestion control schemes. Maybe we should > encourage the development of new coupled congestion control schemes. > > Another direction that the WG could pursue are the interactions with othe= r > working groups where Multipath TCP could play a role. > > For example, v6ops and spring develop the Segment Routing architecture. > The IPv6 variant of SR brings a nice framework to allow the establishment > of Multipath TCP subflows over specific paths. As IPv6 SR is available on > Linux, it becomes possible to perform experiments and think about the > interactions between SR and MPTCP. > > Another example is happy eyeballs. This technique works with HTTP on > dual-stack machines. It could also be applied to MPTCP (e.g. with the > parallel establishment idea) > > A third example are the interactions between MPTCP and applications. It > would be interesting to interact with WG developing application level > protocols to see how to map them on MPTCP. > > A fourth example is IPv6 multihoming. The rtgwg will soon publish a > recommendation on techniques to support IPv6 multihoming. This document > mainly assumes that endhosts use single path transport protocols. It woul= d > be interesting to work with rtgwg to describe the benefits that MPTCP cou= ld > bring in this environment. > > Another example is intermittent connectivity. MPTCP can use multiple path= s > simultaneously, but it also supports seamless handovers on mobile. On > mobiles that have only WiFi connectivity, MPTCP could support intermitten= t > connectivity, i.e. connections that start on one AP, then move a few > seconds, minutes or hours later on another AP. This could require to > maintain MPTCP connections without an associated subflow for a longer > period of time that the default used by TCP. > > I guess that there are many other possiblities > > > Best regards, > > > Olivier > --000000000000d4f8ff056ea9a5bc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Olivier,

Thank you so much for the i= nputs!
I agree that there are many possibilities and the topic yo= u mentioned looks promising.

One thing the chairs = would like to know is if there are items we can work on in (relatively) sho= rt term.
If there are promising topics that we can adopt as WG it= ems in our near feature, please share.
It will be great if we can= discuss such items in our next WG meeting.

Thanks= ,
--
Yoshi

On Thu, Jun 14, 2018 at 6:39 AM, Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be> wrote:
=
Phil, Yoshifumi,

Phil and I have been discussing the next step for the WG.
After we finish 6824bis, we =EF=BD=97on't have active WG items as the p= roxy work will be discussed at tcpm WG.
One suggestion might be to close the WG or to put it in dormant state, howe= ver, we are thinking there still might be some more working items as we'= ;ve seen=C2=A0interesting presentations for new ideas, experiment results a= nd so on at the meetings and on the ML.

Below is the list of potential working items from the chairs' point of = view.
Please let us know if you think some of them are important items for the WG= (and your willingness to contribute if possible) or there are some more it= ems, or this is not something we should work on, etc.

 I think that the socket API still makes sense and it would be useful to hav= e an agreement on an API that is supported by different implementations. At= this point, I'm only aware of API efforts on the Linux implementation.=

Concerning the extensions, I think that it makes sense to reconsider the ex= tensions that we have not included in rfc6824bis and evaluate whether they = could be of benefit for Multipath TCP.

Congestion control is probably a more difficult topic since ICCRG is the na= tural place for work on new congestion control schemes. Maybe we should enc= ourage the development of new coupled congestion control schemes.

Another direction that the WG could pursue are the interactions with other = working groups where Multipath TCP could play a role.

For example, v6ops and spring develop the Segment Routing architecture. The= IPv6 variant of SR brings a nice framework to allow the establishment of M= ultipath TCP subflows over specific paths. As IPv6 SR is available on Linux= , it becomes possible to perform experiments and think about the interactio= ns between SR and MPTCP.

Another example is happy eyeballs. This technique works with HTTP on dual-s= tack machines. It could also be applied to MPTCP (e.g. with the parallel es= tablishment idea)

A third example are the interactions between MPTCP and applications. It wou= ld be interesting to interact with WG developing application level protocol= s to see how to map them on MPTCP.

A fourth example is IPv6 multihoming. The rtgwg will soon publish a recomme= ndation on techniques to support IPv6 multihoming. This document mainly ass= umes that endhosts use single path transport protocols. It would be interes= ting to work with rtgwg to describe the benefits that MPTCP could bring in = this environment.

Another example is intermittent connectivity. MPTCP can use multiple paths = simultaneously, but it also supports seamless handovers on mobile. On mobil= es that have only WiFi connectivity, MPTCP could support intermittent conne= ctivity, i.e. connections that start on one AP, then move a few seconds, mi= nutes or hours later on another AP. This could require to maintain MPTCP co= nnections without an associated subflow for a longer period of time that th= e default used by TCP.

I guess that there are many other possiblities


Best regards,


Olivier

--000000000000d4f8ff056ea9a5bc-- From nobody Fri Jun 15 01:04:15 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C294130DE0 for ; Fri, 15 Jun 2018 01:04:12 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EKCIBP4GzRLd for ; Fri, 15 Jun 2018 01:04:10 -0700 (PDT) Received: from mail.sfc.wide.ad.jp (shonan.sfc.wide.ad.jp [203.178.142.130]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1DDD6130DDC for ; Fri, 15 Jun 2018 01:04:10 -0700 (PDT) Received: from mail-io0-f174.google.com (mail-io0-f174.google.com [209.85.223.174]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id BE8BE278538 for ; Fri, 15 Jun 2018 17:04:08 +0900 (JST) Received: by mail-io0-f174.google.com with SMTP id t5-v6so9951444ioa.8 for ; Fri, 15 Jun 2018 01:04:08 -0700 (PDT) X-Gm-Message-State: APt69E1OLPD6/eXJfAl3GjqQQHmhK+IOdh0aquZmGws1oE7tBWdQIjlK Ds8R/Df5VGPdb6/AFGp4A9M06k8nm3wJnxtcs8M= X-Google-Smtp-Source: ADUXVKJSwml62V6i7pNCMn2kzXPQUpwd6daLsRLfXpE80b31LHd7EyeLWwtp0GGlInj0CR0GX/P/wHl0mfPD9rVaBNY= X-Received: by 2002:a6b:dd14:: with SMTP id f20-v6mr597331ioc.7.1529049847597; Fri, 15 Jun 2018 01:04:07 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:11c4:0:0:0:0:0 with HTTP; Fri, 15 Jun 2018 01:04:06 -0700 (PDT) In-Reply-To: References: From: Yoshifumi Nishida Date: Fri, 15 Jun 2018 01:04:06 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Xavier de Foy Cc: Yoshifumi Nishida , multipathtcp Content-Type: multipart/alternative; boundary="000000000000028fb9056ea9a929" Archived-At: Subject: Re: [multipathtcp] Possible future items for mptcp WG X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 Jun 2018 08:04:13 -0000 --000000000000028fb9056ea9a929 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Xavier, Thank you so much! Yes, we have thought about 5G stuff as well. The reason why we haven't included in the list below was it might not be a short term topic while it can be important for mptcp in future. New suggestions to mptcp with regard to this topic will always be very welcome. -- Yoshi On Thu, Jun 14, 2018 at 2:01 PM, Xavier de Foy wrote: > Yoshifumi & Phil, > > Another potential item under "Feature Extensions" could be dedicated to > interoperability with 5G. We are preparing an update to the "5G > considerations" draft presented in the last session, which can be used as > input for the group to decide if it should be on this list. > > Best Regards, > Xavier > > On Thu, Jun 14, 2018 at 3:16 AM, Yoshifumi Nishida > wrote: > >> Hello everyone, >> >> Phil and I have been discussing the next step for the WG. >> After we finish 6824bis, we =EF=BD=97on't have active WG items as the pr= oxy work >> will be discussed at tcpm WG. >> One suggestion might be to close the WG or to put it in dormant state, >> however, we are thinking there still might be some more working items as >> we've seen interesting presentations for new ideas, experiment results >> and so on at the meetings and on the ML. >> >> Below is the list of potential working items from the chairs' point of >> view. >> Please let us know if you think some of them are important items for the >> WG (and your willingness to contribute if possible) or there are some >> more items, or this is not something we should work on, etc. >> >> Also, if you have some opinions on the status of the WG or suggestions t= o >> the chairs, please let us hear! >> >> We appreciate your feedback >> >> Thanks, >> -- >> Yoshi & Phil >> >> >> >> >> 1: API extensions (This is already in our charter) >> draft-hesmans-mptcp-socket >> draft-samar-mptcp-socketapi >> >> 2: Feature extensions >> a) robust initial setup >> proposed by Markus, also Kien presented a similar idea >> >> b) fast subflow setup >> proposed by Quentin >> >> c) security enhancement >> 1) TLS >> draft-bonaventure-mptcp-tls-00 >> draft-paasch-mptcp-tls-authentication-00 >> >> 2) Utilize proposals from tcpinc? >> >> 3) Elliptic Curve Cryptography >> draft-kim-mptcp-semptcp-00 >> >> d) Solutions for operational issues >> 1) how to handle nat64 issue proposed by Quentin >> 2) how to handle load balancer proposed by Fabien, Christoph, >> Costin >> >> 3: Congestion Control (This topic itself should probably be discussed at >> ICCRG. But, it may trigger some updates of the protocol or APIs later) >> a) OLIA >> draft-khalili-mptcp-congestion-control-05 >> >> b) mptcp + BBR? >> presented by Jing >> >> _______________________________________________ >> multipathtcp mailing list >> multipathtcp@ietf.org >> https://www.ietf.org/mailman/listinfo/multipathtcp >> >> > --000000000000028fb9056ea9a929 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Xavier,

Thank you so much!
Yes, we have thought about 5G stuff as well.=C2=A0
The reason wh= y we haven't included in the list below was it might not be a short ter= m topic while it can be important for mptcp in future.
New sugges= tions to mptcp with regard to this topic will always be very welcome.
=
--
Yoshi

On Thu, Jun 14, 2018 at 2:01 PM, Xavier de Foy <x.defoy= .ietf@gmail.com> wrote:
Yoshifumi &=20 Phil,

=C2=A0 Another potential item under "Fe= ature Extensions" could be dedicated to interoperability with 5G. We a= re preparing an update to the "5G considerations" draft presented= in the last session, which can be used as input for the group to decide if= it should be on this list.

=C2=A0 Best Regards,
Xavier

On Thu, Jun 14, = 2018 at 3:16 AM, Yoshifumi Nishida <nishida@sfc.wide.ad.jp> wrote:
Hello everyone,

Phil and I have been discussing the = next step for the WG.
After we finish 6824bis, we =EF=BD=97on't have active WG i= tems as the proxy=C2=A0work will be d= iscussed at tcpm WG.
One suggesti= on might be to close the WG or to put it in dormant state, however,=C2=A0we are thinking there still might be so= me more working items as we've seen=C2=A0interesting presentations for new ideas, experiment results and so = on at the=C2=A0meetings and on the ML= .

Below is the list of potential working items from the= chairs' point of view.
Please let us know if you think some of them are import= ant items for=C2=A0the WG (and your w= illingness to contribute if possible) or there are=C2=A0some more items, or this is not something we should wor= k on, etc.

= Also, if you have some opinions on the statu= s of the WG or suggestions=C2=A0to th= e chairs, please let us hear!

We appreciate your feedb= ack

Thanks,
--
Yoshi & Phil



1: API extensions (This is already in our charter)=C2=A0 =C2=A0 dra= ft-hesmans-mptcp-socket
=C2=A0 =C2=A0 draft-samar-mptcp-socketapi

2: Feature extensions
=C2=A0 =C2=A0 a) robust initial setup
=C2=A0 =C2=A0 =C2=A0 =C2=A0 pro= posed by Markus,=C2=A0also Kien prese= nted a similar idea

=C2=A0 =C2=A0 b) fast subflow setup=
=C2=A0 = =C2=A0 =C2=A0 =C2=A0 proposed by Quentin=C2=A0

=C2=A0 = =C2=A0 c) security enhancement
=C2=A0 =C2=A0 =C2=A0 =C2=A0 1) TLS
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 draft-bonaventure-mptcp-tls-00
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 draft-paasch-mptcp-tls-authentication-00

=C2=A0 =C2=A0 =C2=A0 =C2=A0 2) Utilize pro= posals from tcpinc?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 3) Elli= ptic Curve Cryptography
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-kim-mptcp-se= mptcp-00

=C2=A0 =C2=A0 d) Solutions for operational iss= ues
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01) how to handle nat64 issue proposed by Que= ntin
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02) how to handle load balancer proposed by F= abien, Christoph, Costin

3: Congestion Control (This to= pic itself should probably be discussed at ICCRG. But, it may trigger some = updates of the protocol or APIs later) =C2=A0
=C2=A0 =C2=A0 =C2=A0a) OLIA
=C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 draft-khalili-mptcp-congestion-control-05

=C2=A0 =C2=A0 =C2=A0b) mptc= p + BBR?
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 presented by Jing

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



--000000000000028fb9056ea9a929-- From nobody Mon Jun 18 06:59:25 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52AE9124C04 for ; Mon, 18 Jun 2018 06:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.601 X-Spam-Level: X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vMTY3qxzx151 for ; Mon, 18 Jun 2018 06:59:17 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 18587120049 for ; Mon, 18 Jun 2018 06:59:16 -0700 (PDT) Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by EVMED02-UKBR.bt.com (10.216.161.32) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 18 Jun 2018 14:59:10 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03b.domain1.systemhost.net (10.55.202.22) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Mon, 18 Jun 2018 14:59:13 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.1293.004; Mon, 18 Jun 2018 14:59:13 +0100 From: To: Thread-Topic: WG Last Call for draft-ietf-mptcp-rfc6824bis Thread-Index: AdP8pPjqwq5n45WRS2ywhz4YK91ZcQHJh45AAMTUIlA= Date: Mon, 18 Jun 2018 13:59:12 +0000 Message-ID: References: <0dd5e48298ed4b4fb7344630abc794b7@rew09926dag03b.domain1.systemhost.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.202.243] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 13:59:23 -0000 More comments: Section 3.5 -=20 Option R (RST) - add (at the end of the bullet) "the Host A enters the CLOS= ED state directly" (I think) << If a host receives a packet with a valid MP_FASTCLOSE option, it shall process it as follows :>> I think the text that follows (apart from the last bullet) is only relevant= for Option A, where the MP_FASTCLOSE is sent on an ACK - it doesn't apply = for option R (where it's sent on a RST). Anyway, things could be laid out s= lightly differently so the section is clearer.=20 Section 3.6 I wonder if it would be more logical for this section to be before Fast clo= se? This section could do with a read through. A few things: << As discussed in Section 3.5 above, the MP_FASTCLOSE option provides a connection-level reset roughly analagous to a TCP RST. Regular TCP RST options remain used to at the subflow-level to indicate the receiving host has no knowledge of the MPTCP subflow or TCP connection to which the packet belongs.>> Can this paragraph be deleted? at least I found it a bit confusing that thi= s text is not about this section.=20 "remain used to at" is ugly << However, in MPTCP, there may be many reasons for rejecting the opening of a subflow, but these semantics cannot be carried in a standard TCP RST. It would be beneficial for a host to the reasons why its subflow has been closed with a RST, and thus whether it should try to re-establish the subflow immediately, later, or never again. These semantics are carried in the MP_TCPRST option that can be included on a TCP RST packet.>> I presume the new MP_TCPRST can be added to a RST, whenever it's created - = the sentence seems to imply it's only when it wants to reject the opening o= f a subflow (ie in response to MP_JOIN).=20 I assume inclusion of the MP_TCPRST option is optional? potential better phrasing: A host sends a TCP RST in order to close a subflow or reject an attempt to = open a subflow (MP_JOIN). In order to inform the receiving host why a subfl= ow is being closed or rejected, the TCP RST packet MAY include the MP_TCPRS= T Option. The host MAY use this information to decide, for example, whether= it tries to re-establish the subflow immediately, later, or never.=20 << o Unspecified error (code 0x0). This is the default error implying the subflow is not longer available. The receiving host SHOULD take account of the 'T' bit in deciding whether to re-estbalish this subflow. The presence of this option shows that the RST was generated by a MPTCP-aware device.>> " The receiving host SHOULD take account of the 'T' bit in deciding whether= to re-estbalish this subflow." Only this sub-bullet mentions the T bit, which may suggest that it should n= ot be taken account of with the other reason codes. I think the sentence s= hould be deleted (using the T flag is mentioned earlier).=20 <> enough resources Section 3.7 I guess it's OK to refer to it as RST rather than TCP RST? << The case described above is a specialized case of fallback, for when the lack of MPTCP support is detected before any data is acknowledged at the connection level on a subflow. >> "The case above" - I'm not sure which of the previous paragraph or paragrap= hs you're referring to. "specialised" - maybe "specific" [is it really specialised?] "for when" -> when S3.9.2 << If the two communicating hosts immediately try to set up subflows from all available addresses to all available addresses on the other host, this could end up creating two subflows per path. This is an inefficient use of resources.>> is two subflows correct? Multiple I think " could end up creating two subflows per path" -> "could create multiple su= bflows over the same path" << If a host does not support TCP simultaneous open, it is RECOMMENDED that some element of randomization is applied to the time waited before opening new subflows, so that only one subflow exists between a given address pair. If, however, hosts signal additional ports to use (for example, for leveraging ECMP on-path), this heuristic need not apply.>> "time waited" - ugly phrase? "exists" -> is created "need not apply" -> is not appropriate Section 5 - Security This section needs updating to reflect the changes in the bis.: Add mention of ADD_ADDR, now with HMAC and reliability, Discuss the revised MP_CAPABLE I'm not sure if the new fast close option (option R) has any security impac= t? Discuss the MP_PRIO change (no off path address indication) Discuss downgrade attacks (to v0) during connection initiation Section 8 IANA << This document updates [RFC6824] and as such IANA is requested to update the TCP option space registry to point to this document for Multipath TCP>> This document obsoletes rather than updates... I suspect this means all t= he MPTCP options need to be included in this document, but we can leave IAN= A to decide that.=20 << | C | Do not attempt to connect to | This document, | | | source address | Section 3.1 | >> I don't think this is a good summary of flag C's meaning. << The contents of this sub-registry are to to this document, as follows: >> Is this sentence needed? Appendix B TCP Fast Open Maybe rephrae the title as "TCP Fast Open and MPTCP" or "Considerations abo= ut using TCP Fast Open and MPTCP"? This section could do with a read through, it could do with a few minor re-= phrasings << TCP Fast Open (TFO) is an experimental TCP extension, described in [RFC7413], which has been introduced with the objective of gaining one RTT before transmitting data.>> " gaining one RTT"? maybe: which allows data to be sent one RTT earlier th= an with regular TCP.=20 << It achieves this by sending the SYN- segment together with data>> re-phrase (I think data is referring ot the cookie - but you havent yet men= tioned it - rather than user data) "resp." =3D ? << TFO and MPTCP can be combined provided that the total length of their options does not exceed the maximum 40 bytes possible in TCP>> "their" is wrong, as there may be other options. -> "all the" << We also note that this does not entail a loss of functionality, because TFO-data is always sent when only one path is active.>> -> "TFO-data is only ever sent when only a single path is active" How do you guarantee this? Not sure I understand.=20 << To solve this, the TFO data should not be considered part of the Data Sequence Number space:>> Is this a SHOULD NOT? Does it imply a change to rfc7413 (the tfo rfc)? I g= uess this is really a suggestion to the implementer? Section B.3 I assume this sub-section is an example (so no SHOULD or even MAY are neede= d) << client server | | | S 0(0) , | | -----------------------------------------------------------> | >> Can you explain the S 0(0) nomenclature/ please. Appendix D Finite state machine I presume we don't need similar FSM for fastclose? Section 2: Need to add sub-sections on closing subflow & fast close & fallback S2.7 - I think the third bullet about notable features could be slightly al= tered, with enhanced security for ADD_ADDR and MP_CAPABLE. You could also a= dd a mention of rfc7430 Section 2.1 & 3.1 - can you remind me why we changed MP_CAPABLE so that Hos= t A's key is sent only on the ACK (not on the SYN)? Is this so it's only se= nt when we know host B is MPTCP capable, which is therefore a slight securi= ty improvement? (Just send a link to earlier emails, if that's easier) Thanks phil -----Original Message----- From: Eardley,PL,Philip,TUD1 R=20 Sent: 14 June 2018 11:56 To: 'philip.eardley@bt.com' ; multipathtcp@ietf.org Subject: RE: WG Last Call for draft-ietf-mptcp-rfc6824bis A few comments as I work through the document, basically minor so far Section 3.1 << Given the SYN exchange is different between v1 and v0 the exchange cannot be immediately downgraded, and therefore if the far end has requested a lower version then the initiator SHOULD respond with an ACK without any MP_CAPABLE option, to fall back to regular TCP.>> I think it should say "to ensure the exchange cannot..." << The first 4 bits of the first octet in the MP_CAPABLE option (Figure 4) define the MPTCP option subtype (see Section 8; for MP_CAPABLE, this is 0), and the remaining 4 bits of this octet specify the MPTCP version in use (for this specification, this is 1). >> "The first 4 bits of the first octet in the MP_CAPABLE option" Fig 4 shows = two earlier octets (Kind & Length) - I know these arent the MP-CAPABLE opti= on, but I think it might be worth spelling out what they are.=20 Would it be better strictly to have "0x0" rather than "0"? (ie match the IA= NA registry) Section 3.4.1 <> 4 comments: Assinged /assigned The 'E' bit - better to say flag? Section 2.3 needs to be amended to show the reply /echo message for ADD-ADD= R. I suggest the pic in S2.3 also shows the E value.=20 Not sure - does this open security hole, where an attacker pretends an ADD-= ADDR has been received? (the Echo doesn't include an hmac, so is easy to sp= oof) And in Fig 12 | Truncated HMAC (8 octets, if length > 10 octets) | Could this be made more straightforward? Ie spell out when length is >10 oc= tets ie IPv6 (if I understand it). This also seems to mean that IPv4 doesn'= t include the HMAC, is this right?? Thanks phil -----Original Message----- From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of phil= ip.eardley@bt.com Sent: 05 June 2018 09:14 To: multipathtcp@ietf.org Subject: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis This starts a WG Last Call for draft-ietf-mptcp-rfc6824bis. Please send com= ments by the end of June.=20 Please note there are three IPR disclosures (we're working on getting them = added to the rfc6824bis page):=20 * two are inherited from RFC6824 https://datatracker.ietf.org/ipr/search/?= submit=3Ddraft&id=3Ddraft-ietf-mptcp-multiaddressed =20 * one is inherited from draft-paasch-mptcp-syncookies (which got include in= rfc6824bis) https://datatracker.ietf.org/ipr/2678/=20 Thanks, Phil & Yoshi _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Mon Jun 18 09:00:14 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01669130DF6 for ; Mon, 18 Jun 2018 09:00:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9XCtC5HFr_M4 for ; Mon, 18 Jun 2018 09:00:02 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D6816130DF5 for ; Mon, 18 Jun 2018 09:00:01 -0700 (PDT) Received: from rew09926dag03c.domain1.systemhost.net (10.55.202.26) by EVMED05-UKBR.bt.com (10.216.161.37) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 18 Jun 2018 16:59:55 +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.1293.2; Mon, 18 Jun 2018 16:59:59 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.1293.004; Mon, 18 Jun 2018 16:59:58 +0100 From: To: , Thread-Topic: WG Last Call for draft-ietf-mptcp-rfc6824bis Thread-Index: AdP8pPjqwq5n45WRS2ywhz4YK91ZcQHJh45AAMTUIlAAD7sb8A== Date: Mon, 18 Jun 2018 15:59:58 +0000 Message-ID: <4fcc654b84644bb985d2ae7730823d5d@rew09926dag03b.domain1.systemhost.net> References: <0dd5e48298ed4b4fb7344630abc794b7@rew09926dag03b.domain1.systemhost.net> In-Reply-To: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.202.243] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 16:00:13 -0000 One other high-level comment: it would be very good if the bis code, imple= mented in linux, could be released - to allow testing of the protocol chang= es in the bis, for instance to make sure that no unexpected issues have bee= n introduced Best wishes Phil -----Original Message----- From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of phil= ip.eardley@bt.com Sent: 18 June 2018 14:59 To: multipathtcp@ietf.org Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis More comments: Section 3.5 - Option R (RST) - add (at the end of the bullet) "the Host A enters the CLOS= ED state directly" (I think) << If a host receives a packet with a valid MP_FASTCLOSE option, it shall process it as follows :>> I think the text that follows (apart from the last bullet) is only relevant= for Option A, where the MP_FASTCLOSE is sent on an ACK - it doesn't apply = for option R (where it's sent on a RST). Anyway, things could be laid out s= lightly differently so the section is clearer.=20 Section 3.6 I wonder if it would be more logical for this section to be before Fast clo= se? This section could do with a read through. A few things: << As discussed in Section 3.5 above, the MP_FASTCLOSE option provides a connection-level reset roughly analagous to a TCP RST. Regular TCP RST options remain used to at the subflow-level to indicate the receiving host has no knowledge of the MPTCP subflow or TCP connection to which the packet belongs.>> Can this paragraph be deleted?= at least I found it a bit confusing that this text is not about this secti= on.=20 "remain used to at" is ugly << However, in MPTCP, there may be many reasons for rejecting the opening of a subflow, but these semantics cannot be carried in a standard TCP RST. It would be beneficial for a host to the reasons why its subflow has been closed with a RST, and thus whether it should try to re-establish the subflow immediately, later, or never again. These semantics are carried in the MP_TCPRST option that can be included on a TCP RST packet.>> I presume the new MP_TCPRST can be added to a RST, whenever it's created - = the sentence seems to imply it's only when it wants to reject the opening o= f a subflow (ie in response to MP_JOIN).=20 I assume inclusion of the MP_TCPRST option is optional? potential better phrasing: A host sends a TCP RST in order to close a subflow or reject an attempt to = open a subflow (MP_JOIN). In order to inform the receiving host why a subfl= ow is being closed or rejected, the TCP RST packet MAY include the MP_TCPRS= T Option. The host MAY use this information to decide, for example, whether= it tries to re-establish the subflow immediately, later, or never.=20 << o Unspecified error (code 0x0). This is the default error implying the subflow is not longer available. The receiving host SHOULD take account of the 'T' bit in deciding whether to re-estbalish this subflow. The presence of this option shows that the RST was generated by a MPTCP-aware device.>> " The receiving host SHOULD take account of the 'T' bit in deciding whether= to re-estbalish this subflow." Only this sub-bullet mentions the T bit, which may suggest that it should n= ot be taken account of with the other reason codes. I think the sentence s= hould be deleted (using the T flag is mentioned earlier).=20 <> enough resources Section 3.7 I guess it's OK to refer to it as RST rather than TCP RST? << The case described above is a specialized case of fallback, for when the lack of MPTCP support is detected before any data is acknowledged at the connection level on a subflow. >> "The case above" - I'm not sur= e which of the previous paragraph or paragraphs you're referring to. "specialised" - maybe "specific" [is it really specialised?] "for when" -> = when S3.9.2 << If the two communicating hosts immediately try to set up subflows from all available addresses to all available addresses on the other host, this could end up creating two subflows per path. This is an inefficient use of resources.>> is two subflows correct? Multiple I think " could end up creating two subfl= ows per path" -> "could create multiple subflows over the same path" << If a host does not support TCP simultaneous open, it is RECOMMENDED that some element of randomization is applied to the time waited before opening new subflows, so that only one subflow exists between a given address pair. If, however, hosts signal additional ports to use (for example, for leveraging ECMP on-path), this heuristic need not apply.>> "time waited" - ugly phrase? "exists" -> is created "need not apply" -> is not appropriate Section 5 - Security This section needs updating to reflect the changes in the bis.: Add mention of ADD_ADDR, now with HMAC and reliability, Discuss the revised= MP_CAPABLE I'm not sure if the new fast close option (option R) has any se= curity impact? Discuss the MP_PRIO change (no off path address indication) Discuss downgra= de attacks (to v0) during connection initiation Section 8 IANA << This document updates [RFC6824] and as such IANA is requested to update the TCP option space registry to point to this document for Multipath TCP>> This document obsoletes rather than updates... I suspect this means all t= he MPTCP options need to be included in this document, but we can leave IAN= A to decide that.=20 << | C | Do not attempt to connect to | This document, | | | source address | Section 3.1 | >> I don't think this is a good summary of flag C's meaning. << The contents of this sub-registry are to to this document, as follows: >> Is this sentence needed? Appendix B TCP Fast Open Maybe rephrae the title as "TCP Fast Open and MPTCP" or "Considerations abo= ut using TCP Fast Open and MPTCP"? This section could do with a read through, it could do with a few minor re-= phrasings << TCP Fast Open (TFO) is an experimental TCP extension, described in [RFC7413], which has been introduced with the objective of gaining one RTT before transmitting data.>> " gaining one RTT"? maybe: which allows data to be sent one RTT earlier th= an with regular TCP.=20 << It achieves this by sending the SYN- segment together with data>> re-phrase (I think data is referring ot the cookie - but you havent yet men= tioned it - rather than user data) "resp." =3D ? << TFO and MPTCP can be combined provided that the total length of their options does not exceed the maximum 40 bytes possible in TCP>> "their" i= s wrong, as there may be other options. -> "all the" << We also note that this does not entail a loss of functionality, because TFO-data is always sent when only one path is active.>> -> "TFO-data is only ever sent when only a single path is active" How do you guarantee this? Not sure I understand.=20 << To solve this, the TFO data should not be considered part of the Data Sequence Number space:>> Is this a SHOULD NOT? Does it imply a change to rfc7413 (the tfo rfc)? I g= uess this is really a suggestion to the implementer? Section B.3 I assume this sub-section is an example (so no SHOULD or even MAY are neede= d) << client server | | | S 0(0) , | | -----------------------------------------------------------> | >> Can you explain the S 0(0) nomenclature/ please. Appendix D Finite state machine I presume we don't need similar FSM for fastclose? Section 2: Need to add sub-sections on closing subflow & fast close & fallback S2.7 - I think the third bullet about notable features could be slightly al= tered, with enhanced security for ADD_ADDR and MP_CAPABLE. You could also a= dd a mention of rfc7430 Section 2.1 & 3.1 - can you remind me why we changed MP_CAPABLE so that Hos= t A's key is sent only on the ACK (not on the SYN)? Is this so it's only se= nt when we know host B is MPTCP capable, which is therefore a slight securi= ty improvement? (Just send a link to earlier emails, if that's easier) Thanks phil -----Original Message----- From: Eardley,PL,Philip,TUD1 R Sent: 14 June 2018 11:56 To: 'philip.eardley@bt.com' ; multipathtcp@ietf.org Subject: RE: WG Last Call for draft-ietf-mptcp-rfc6824bis A few comments as I work through the document, basically minor so far Section 3.1 << Given the SYN exchange is different between v1 and v0 the exchange cannot be immediately downgraded, and therefore if the far end has requested a lower version then the initiator SHOULD respond with an ACK without any MP_CAPABLE option, to fall back to regular TCP.>> I think it should say "to ensure the exchange cannot..." << The first 4 bits of the first octet in the MP_CAPABLE option (Figure 4) define the MPTCP option subtype (see Section 8; for MP_CAPABLE, this is 0), and the remaining 4 bits of this octet specify the MPTCP version in use (for this specification, this is 1). >> "The first 4 bits of the first octet in the MP_CAPABLE option" Fig 4 shows = two earlier octets (Kind & Length) - I know these arent the MP-CAPABLE opti= on, but I think it might be worth spelling out what they are.=20 Would it be better strictly to have "0x0" rather than "0"? (ie match the IA= NA registry) Section 3.4.1 <> 4 comments: Assinged /assigned The 'E' bit - better to say flag? Section 2.3 needs to be amended to show the reply /echo message for ADD-ADD= R. I suggest the pic in S2.3 also shows the E value.=20 Not sure - does this open security hole, where an attacker pretends an ADD-= ADDR has been received? (the Echo doesn't include an hmac, so is easy to sp= oof) And in Fig 12 | Truncated HMAC (8 octets, if length > 10 octets) | Could this be made more straightforward? Ie spell out when length is >10 oc= tets ie IPv6 (if I understand it). This also seems to mean that IPv4 doesn'= t include the HMAC, is this right?? Thanks phil -----Original Message----- From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of phil= ip.eardley@bt.com Sent: 05 June 2018 09:14 To: multipathtcp@ietf.org Subject: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis This starts a WG Last Call for draft-ietf-mptcp-rfc6824bis. Please send com= ments by the end of June.=20 Please note there are three IPR disclosures (we're working on getting them = added to the rfc6824bis page):=20 * two are inherited from RFC6824 https://datatracker.ietf.org/ipr/search/?= submit=3Ddraft&id=3Ddraft-ietf-mptcp-multiaddressed =20 * one is inherited from draft-paasch-mptcp-syncookies (which got include in= rfc6824bis) https://datatracker.ietf.org/ipr/2678/=20 Thanks, Phil & Yoshi _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp From nobody Tue Jun 19 00:55:19 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BC811310AF for ; Tue, 19 Jun 2018 00:55:15 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OSE1G9fQX_Fk for ; Tue, 19 Jun 2018 00:55:12 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3053112D7F8 for ; Tue, 19 Jun 2018 00:55:12 -0700 (PDT) Received: from rew09926dag03c.domain1.systemhost.net (10.55.202.26) by EVMED03-UKBR.bt.com (10.216.161.33) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 19 Jun 2018 08:55:05 +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.1293.2; Tue, 19 Jun 2018 08:55:09 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.1293.004; Tue, 19 Jun 2018 08:55:09 +0100 From: To: Thread-Topic: Call for agenda items for MPTCP WG meeting Thread-Index: AdQHoi744SqWSoWSSWCPIWmg0RGHaw== Date: Tue, 19 Jun 2018 07:55:08 +0000 Message-ID: Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.202.242] Content-Type: multipart/alternative; boundary="_000_b0d183d924404d19942f05b626952c2brew09926dag03bdomain1sy_" MIME-Version: 1.0 Archived-At: Subject: [multipathtcp] Call for agenda items for MPTCP WG meeting X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 07:55:16 -0000 --_000_b0d183d924404d19942f05b626952c2brew09926dag03bdomain1sy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, Please send requests for anything you want to present or discuss in Montrea= l. Our timeslot is on Monday at 1550-1750 (on the preliminary agenda - so m= ay change). Please let us know topic /title, presenter & requested length of time. Thanks Phil & Yoshi --_000_b0d183d924404d19942f05b626952c2brew09926dag03bdomain1sy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Please send requests for anything you want to present or discuss i= n Montreal. Our timeslot is on Monday at 1550-1750 (on the preliminary agen= da – so may change).

Please let us know topic /title, presenter & requested length = of time.

Thanks

Phil & Yoshi

 

--_000_b0d183d924404d19942f05b626952c2brew09926dag03bdomain1sy_-- From nobody Tue Jun 19 09:06:57 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BDEA9130DF2 for ; Tue, 19 Jun 2018 09:06:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xVg8t65NTeYF for ; Tue, 19 Jun 2018 09:06:52 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.141]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 872C812777C for ; Tue, 19 Jun 2018 09:06:50 -0700 (PDT) Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by EVMED05-UKBR.bt.com (10.216.161.37) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 19 Jun 2018 17:06:44 +0100 Received: from rew09926dag03c.domain1.systemhost.net (10.55.202.26) by rew09926dag03b.domain1.systemhost.net (10.55.202.22) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Tue, 19 Jun 2018 17:06:43 +0100 Received: from rew09926dag03c.domain1.systemhost.net ([fe80::bd0c:3548:7105:cecb]) by rew09926dag03c.domain1.systemhost.net ([fe80::bd0c:3548:7105:cecb%12]) with mapi id 15.00.1293.002; Tue, 19 Jun 2018 17:06:43 +0100 From: To: , Thread-Topic: http://open-innovation.alcatel-lucent.com/projects/mptcp-proxy Thread-Index: AdQH5xiKlemZvX4vRFa4J+ArHNjLfA== Date: Tue, 19 Jun 2018 16:06:43 +0000 Message-ID: <491e857194604e9ba4ab4711cd2e338e@rew09926dag03c.domain1.systemhost.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.202.243] Content-Type: multipart/alternative; boundary="_000_491e857194604e9ba4ab4711cd2e338erew09926dag03cdomain1sy_" MIME-Version: 1.0 Archived-At: Subject: [multipathtcp] http://open-innovation.alcatel-lucent.com/projects/mptcp-proxy X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 16:06:56 -0000 --_000_491e857194604e9ba4ab4711cd2e338erew09926dag03cdomain1sy_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Dear Georg / all I am looking for an open-source MPTCP proxy for a research project. The lin= k in subject line is from ietf.org code release, but the link is broken. Ca= n you help ? Many thanks Michael Fitch BT Research and Innovation --_000_491e857194604e9ba4ab4711cd2e338erew09926dag03cdomain1sy_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Dear Georg / all

 

I am looking for an open-source MPTCP proxy for a re= search project. The link in subject line is from ietf.org code release, but= the link is broken. Can you help ?

 

Many thanks

 

Michael Fitch

BT Research and Innovation

--_000_491e857194604e9ba4ab4711cd2e338erew09926dag03cdomain1sy_-- From nobody Tue Jun 19 12:45:11 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFAA7130E6E for ; Tue, 19 Jun 2018 12:45:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZXutjWxvR85q for ; Tue, 19 Jun 2018 12:45:05 -0700 (PDT) Received: from mail-qt0-x235.google.com (mail-qt0-x235.google.com [IPv6:2607:f8b0:400d:c0d::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 760C2130EA6 for ; Tue, 19 Jun 2018 12:45:03 -0700 (PDT) Received: by mail-qt0-x235.google.com with SMTP id l33-v6so873489qta.11 for ; Tue, 19 Jun 2018 12:45:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=kBE6hWyJKfqNe8wzRjAN0xDsQedif8WFMXIFN2JQU1g=; b=MGZoQxlmR4JUDOZVQnA4k7dVMSbR9fDwhlv5Pdou74YUA2nrOLkR/xYexux3BIJL0N D2duTReKDs0PENP5FnKlajSUV26GksAH23EJaCFBIUhg8Ga1zM7TPXyrgX5A6i4+3R67 yxV0YlCTQaaMFx+FIl02fu6vee47X1K3d8lYpOCSKZ3cGDap6bt6COs4Mya/xdZqbZGw vs16OrQLkhOl/QM1f+5NObJdAL9HhFrYaqVhrceB2TQDRAVkt71z8cOTrsAU73L3+trG k/vcq2h7eTpTnlS/9iVYdUGtmBor/1dxkkcR654IJYENN89tvjhukTjWkgaIeI5lfJCZ a6rg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=kBE6hWyJKfqNe8wzRjAN0xDsQedif8WFMXIFN2JQU1g=; b=MXp68i7LeVcGuHUruOMTLL0zBKO//cwXQMRae9AQBCgYHaLw9p2728865VE8PVWf8s Xwl0wMC57beZ3eb4y8MGDrevKbRS3ZFBKsLP9OqW3/BwS0beaNDsXC8mYvwlEh9I1TTM qOP1QPLgv+lywe4WJJTSGKY4DJfQijo+GMwm7KQ+xLY+RkExsKUZbbG0bdhdqMxv/Bdw /SSUWcAyH5i3OHHlDAgLSaunxBvWCgxrmftkpIoOVoIVSN+2+CbZIuKSAvHfHZXiurwS ma8tVPnx4LEi6I4JN3mfCqggOQFdkdSysQAoEYybHUXllC+uZhmpM/02D2+Sk5E8OOG/ HpCg== X-Gm-Message-State: APt69E0C6Ht2vD1+y7iRkNnQQpcLkIJape+gavO/VHPjPWpaIWlRpsFY cDwwWEHNhpV7uCj6o+g1d7GjVlQx6qWUHvj23jkpfQ== X-Google-Smtp-Source: ADUXVKJK7pSrbNSRHMu5Wl68+mDH/6LeZkbPcQD7npNwsKS1obOuERWVVriLcnwLReYDQTgtx8TgVW6InjQvsHh5Qbk= X-Received: by 2002:a0c:93ec:: with SMTP id g41-v6mr15954833qvg.243.1529437502603; Tue, 19 Jun 2018 12:45:02 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:2f69:0:0:0:0:0 with HTTP; Tue, 19 Jun 2018 12:45:02 -0700 (PDT) In-Reply-To: References: From: Xavier de Foy Date: Tue, 19 Jun 2018 15:45:02 -0400 Message-ID: To: Yoshifumi Nishida Cc: multipathtcp Content-Type: multipart/alternative; boundary="0000000000000c86b1056f03eb98" Archived-At: Subject: Re: [multipathtcp] Possible future items for mptcp WG X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 19:45:08 -0000 --0000000000000c86b1056f03eb98 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Yoshi, Thanks for the answer. In term of timing: 5G global deployment should occur in 2020 (with smaller/test deployments before this), so work related to 5G adaptation may be best completed within 12 to 18 months (just my understanding, maybe others on the list can share their views on the best timing for this type of work). Do you think it is too far ahead, or would it make sense to include 5G related investigations in the list? Best Regards, Xavier On Fri, Jun 15, 2018 at 4:04 AM, Yoshifumi Nishida wrote: > Hi Xavier, > > Thank you so much! > Yes, we have thought about 5G stuff as well. > The reason why we haven't included in the list below was it might not be = a > short term topic while it can be important for mptcp in future. > New suggestions to mptcp with regard to this topic will always be very > welcome. > -- > Yoshi > > > On Thu, Jun 14, 2018 at 2:01 PM, Xavier de Foy > wrote: > >> Yoshifumi & Phil, >> >> Another potential item under "Feature Extensions" could be dedicated t= o >> interoperability with 5G. We are preparing an update to the "5G >> considerations" draft presented in the last session, which can be used a= s >> input for the group to decide if it should be on this list. >> >> Best Regards, >> Xavier >> >> On Thu, Jun 14, 2018 at 3:16 AM, Yoshifumi Nishida < >> nishida@sfc.wide.ad.jp> wrote: >> >>> Hello everyone, >>> >>> Phil and I have been discussing the next step for the WG. >>> After we finish 6824bis, we =EF=BD=97on't have active WG items as the p= roxy work >>> will be discussed at tcpm WG. >>> One suggestion might be to close the WG or to put it in dormant state, >>> however, we are thinking there still might be some more working items >>> as we've seen interesting presentations for new ideas, experiment >>> results and so on at the meetings and on the ML. >>> >>> Below is the list of potential working items from the chairs' point of >>> view. >>> Please let us know if you think some of them are important items for th= e >>> WG (and your willingness to contribute if possible) or there are some >>> more items, or this is not something we should work on, etc. >>> >>> Also, if you have some opinions on the status of the WG or suggestions = to >>> the chairs, please let us hear! >>> >>> We appreciate your feedback >>> >>> Thanks, >>> -- >>> Yoshi & Phil >>> >>> >>> >>> >>> 1: API extensions (This is already in our charter) >>> draft-hesmans-mptcp-socket >>> draft-samar-mptcp-socketapi >>> >>> 2: Feature extensions >>> a) robust initial setup >>> proposed by Markus, also Kien presented a similar idea >>> >>> b) fast subflow setup >>> proposed by Quentin >>> >>> c) security enhancement >>> 1) TLS >>> draft-bonaventure-mptcp-tls-00 >>> draft-paasch-mptcp-tls-authentication-00 >>> >>> 2) Utilize proposals from tcpinc? >>> >>> 3) Elliptic Curve Cryptography >>> draft-kim-mptcp-semptcp-00 >>> >>> d) Solutions for operational issues >>> 1) how to handle nat64 issue proposed by Quentin >>> 2) how to handle load balancer proposed by Fabien, Christoph, >>> Costin >>> >>> 3: Congestion Control (This topic itself should probably be discussed a= t >>> ICCRG. But, it may trigger some updates of the protocol or APIs later) >>> a) OLIA >>> draft-khalili-mptcp-congestion-control-05 >>> >>> b) mptcp + BBR? >>> presented by Jing >>> >>> _______________________________________________ >>> multipathtcp mailing list >>> multipathtcp@ietf.org >>> https://www.ietf.org/mailman/listinfo/multipathtcp >>> >>> >> > --0000000000000c86b1056f03eb98 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Yoshi,

=C2=A0 Thanks for the answer. In term of timing: 5G global= =20 deployment should occur in 2020 (with smaller/test deployments before=20 this), so work related to 5G adaptation may be best=20 completed within 12 to 18 months (just my understanding, maybe others on the list can share their views on the best timing for this type of=20 work). Do you think it is too far ahead, or would it make sense to=20 include 5G related investigations in the list?
=C2=A0=C2=A0=C2=A0
= =C2=A0 Best Regards,
=C2=A0
Xavier

On Fri,= Jun 15, 2018 at 4:04 AM, Yoshifumi Nishida <nishida@sfc.wide.ad.jp= > wrote:
H= i Xavier,

Thank you so much!
Yes, we have thou= ght about 5G stuff as well.=C2=A0
The reason why we haven't i= ncluded in the list below was it might not be a short term topic while it c= an be important for mptcp in future.
New suggestions to mptcp wit= h regard to this topic will always be very welcome.
--
<= div>Yoshi


On Thu, Jun 14, 2018 at 2:01 PM, Xavier de Foy <x.= defoy.ietf@gmail.com> wrote:
Yoshifumi &=20 Phil,

=C2=A0 Another potential item under "Fe= ature Extensions" could be dedicated to interoperability with 5G. We a= re preparing an update to the "5G considerations" draft presented= in the last session, which can be used as input for the group to decide if= it should be on this list.

=C2=A0 Best Regards,
Xavier

On Thu, Jun 14, 2018 at 3:16 AM, Yoshifumi Nishida = <nishida@sfc= .wide.ad.jp> wrote:
Hello everyone,

Phil and I have been discussing the next step for the WG.
After we finish 6824= bis, we =EF=BD=97on't have active WG items as the proxy=C2=A0work will be discussed at tcpm WG.
<= span style=3D"font-size:16px">One suggestion might be to close the WG or to= put it in dormant state, however,=C2=A0we are thinking there still might be some more working items as we'v= e seen=C2=A0interesting presentations= for new ideas, experiment results and so on at the=C2=A0meetings and on the ML.

Below is th= e list of potential working items from the chairs' point of view.
Please let us = know if you think some of them are important items for=C2=A0the WG (and your willingness to contribute if possib= le) or there are=C2=A0some more items= , or this is not something we should work on, etc.

Also= , if you have some opinions on the status of the WG or suggestions=C2=A0to the chairs, please let us hear!

We appreciate your feedback

Thanks,
--
Yoshi & Phil




1: API extensions (T= his is already in our charter)
=C2=A0 =C2=A0 draft-hesmans-mptcp-socket
=C2=A0 =C2=A0 draft-s= amar-mptcp-socketapi

2: Feature extensions
=C2=A0 =C2=A0 a) robu= st initial setup
=C2=A0 =C2=A0 =C2=A0 =C2=A0 proposed by Markus,=C2=A0also Kien presented a similar idea

=C2=A0 =C2=A0 b) fast subflow setup
=C2=A0 =C2=A0 =C2=A0 =C2=A0 proposed by Que= ntin=C2=A0

= =C2=A0 =C2=A0 c) security enhancement=
=C2=A0 =C2=A0 = =C2=A0 =C2=A0 1) TLS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-bonaventure-mpt= cp-tls-00
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-paasch-mptcp-tls-authentication-00

=C2= =A0 =C2=A0 =C2=A0 =C2=A0 2) Utilize proposals from tcpinc?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 3) Elliptic Curve Cryptography
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 draft-kim-mptcp-semptcp-00

=C2=A0= =C2=A0 d) Solutions for operational issues
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01) how= to handle nat64 issue proposed by Quentin
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02) how = to handle load balancer proposed by Fabien, Christoph, Costin

3: Congestion Control (This topic itself should probably be discusse= d at ICCRG. But, it may trigger some updates of the protocol or APIs later)= =C2=A0
= =C2=A0 =C2=A0 =C2=A0a) OLIA
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-khalili-mptcp-= congestion-control-05

=C2=A0 =C2=A0 =C2=A0b) mptcp + BBR?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 pre= sented by Jing

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




--0000000000000c86b1056f03eb98-- From nobody Tue Jun 19 23:54:57 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A9BB131028 for ; Tue, 19 Jun 2018 23:54:53 -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, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZrBlAmqgpal for ; Tue, 19 Jun 2018 23:54:49 -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 887C2131057 for ; Tue, 19 Jun 2018 23:54:48 -0700 (PDT) Received: from mail-it0-f42.google.com (mail-it0-f42.google.com [209.85.214.42]) by mail.sfc.wide.ad.jp (Postfix) with ESMTPSA id 65FC72784A1 for ; Wed, 20 Jun 2018 15:54:46 +0900 (JST) Received: by mail-it0-f42.google.com with SMTP id p185-v6so4033723itp.4 for ; Tue, 19 Jun 2018 23:54:46 -0700 (PDT) X-Gm-Message-State: APt69E39d4KrBzUSTOXwpr6S/151cqmuMyWHuQ5v6o6BEbquWW1mS/tU UDnO37vbP2mc+qHcqus3HfnXytVC7fA23aEgi4U= X-Google-Smtp-Source: ADUXVKK06dR7DCkc3UWMl7am+fVVW5zlZiUmQ//AJvO2v2zs2p2IbrM21yFtJ5qvXBZGTtRhMMCPnzUzvCM20MDrZvU= X-Received: by 2002:a02:9914:: with SMTP id r20-v6mr15605716jaj.144.1529477685169; Tue, 19 Jun 2018 23:54:45 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4f:11c4:0:0:0:0:0 with HTTP; Tue, 19 Jun 2018 23:54:44 -0700 (PDT) In-Reply-To: References: From: Yoshifumi Nishida Date: Tue, 19 Jun 2018 23:54:44 -0700 X-Gmail-Original-Message-ID: Message-ID: To: Xavier de Foy Cc: Yoshifumi Nishida , multipathtcp Content-Type: multipart/alternative; boundary="0000000000001ddad6056f0d46dc" Archived-At: Subject: Re: [multipathtcp] Possible future items for mptcp WG X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 06:54:53 -0000 --0000000000001ddad6056f0d46dc Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Xavier, Thanks. I think the timing you mentioned won't be a critical issue by itself. However, one question is how soon we can have concrete proposals to MPTCP for 5G networks. If there are already some solid features in 5G and we have explicit ideas to update or extend MPTCP for them, I think there will be possibilities. -- Yoshi On Tue, Jun 19, 2018 at 12:45 PM, Xavier de Foy wrote: > Hi Yoshi, > > Thanks for the answer. In term of timing: 5G global deployment should > occur in 2020 (with smaller/test deployments before this), so work relate= d > to 5G adaptation may be best completed within 12 to 18 months (just my > understanding, maybe others on the list can share their views on the best > timing for this type of work). Do you think it is too far ahead, or would > it make sense to include 5G related investigations in the list? > > Best Regards, > > Xavier > > On Fri, Jun 15, 2018 at 4:04 AM, Yoshifumi Nishida > wrote: > >> Hi Xavier, >> >> Thank you so much! >> Yes, we have thought about 5G stuff as well. >> The reason why we haven't included in the list below was it might not be >> a short term topic while it can be important for mptcp in future. >> New suggestions to mptcp with regard to this topic will always be very >> welcome. >> -- >> Yoshi >> >> >> On Thu, Jun 14, 2018 at 2:01 PM, Xavier de Foy >> wrote: >> >>> Yoshifumi & Phil, >>> >>> Another potential item under "Feature Extensions" could be dedicated >>> to interoperability with 5G. We are preparing an update to the "5G >>> considerations" draft presented in the last session, which can be used = as >>> input for the group to decide if it should be on this list. >>> >>> Best Regards, >>> Xavier >>> >>> On Thu, Jun 14, 2018 at 3:16 AM, Yoshifumi Nishida < >>> nishida@sfc.wide.ad.jp> wrote: >>> >>>> Hello everyone, >>>> >>>> Phil and I have been discussing the next step for the WG. >>>> After we finish 6824bis, we =EF=BD=97on't have active WG items as the = proxy work >>>> will be discussed at tcpm WG. >>>> One suggestion might be to close the WG or to put it in dormant state, >>>> however, we are thinking there still might be some more working items >>>> as we've seen interesting presentations for new ideas, experiment >>>> results and so on at the meetings and on the ML. >>>> >>>> Below is the list of potential working items from the chairs' point of >>>> view. >>>> Please let us know if you think some of them are important items for t= he >>>> WG (and your willingness to contribute if possible) or there are some >>>> more items, or this is not something we should work on, etc. >>>> >>>> Also, if you have some opinions on the status of the WG or suggestions= to >>>> the chairs, please let us hear! >>>> >>>> We appreciate your feedback >>>> >>>> Thanks, >>>> -- >>>> Yoshi & Phil >>>> >>>> >>>> >>>> >>>> 1: API extensions (This is already in our charter) >>>> draft-hesmans-mptcp-socket >>>> draft-samar-mptcp-socketapi >>>> >>>> 2: Feature extensions >>>> a) robust initial setup >>>> proposed by Markus, also Kien presented a similar idea >>>> >>>> b) fast subflow setup >>>> proposed by Quentin >>>> >>>> c) security enhancement >>>> 1) TLS >>>> draft-bonaventure-mptcp-tls-00 >>>> draft-paasch-mptcp-tls-authentication-00 >>>> >>>> 2) Utilize proposals from tcpinc? >>>> >>>> 3) Elliptic Curve Cryptography >>>> draft-kim-mptcp-semptcp-00 >>>> >>>> d) Solutions for operational issues >>>> 1) how to handle nat64 issue proposed by Quentin >>>> 2) how to handle load balancer proposed by Fabien, Christoph, >>>> Costin >>>> >>>> 3: Congestion Control (This topic itself should probably be discussed >>>> at ICCRG. But, it may trigger some updates of the protocol or APIs lat= er) >>>> a) OLIA >>>> draft-khalili-mptcp-congestion-control-05 >>>> >>>> b) mptcp + BBR? >>>> presented by Jing >>>> >>>> _______________________________________________ >>>> multipathtcp mailing list >>>> multipathtcp@ietf.org >>>> https://www.ietf.org/mailman/listinfo/multipathtcp >>>> >>>> >>> >> > --0000000000001ddad6056f0d46dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Xavier,

Thanks. I think the timing y= ou mentioned won't be a critical issue by itself.
However, on= e question is how soon we can have concrete proposals to MPTCP for 5G netwo= rks.=C2=A0
If there are already some solid features in 5G and we = have explicit ideas to update or extend MPTCP for them, I think there will = be possibilities.
--
Yoshi


On Tue, Jun 19, = 2018 at 12:45 PM, Xavier de Foy <x.defoy.ietf@gmail.com> wrote:
Hi Yoshi,

=C2=A0 Thanks for the answer. In term of timing: 5G global= =20 deployment should occur in 2020 (with smaller/test deployments before=20 this), so work related to 5G adaptation may be best=20 completed within 12 to 18 months (just my understanding, maybe others on the list can share their views on the best timing for this type of=20 work). Do you think it is too far ahead, or would it make sense to=20 include 5G related investigations in the list?
=C2=A0=C2=A0=C2=A0
= =C2=A0 Best Regards,
=C2= =A0
Xavier

On Fri, Jun 15, 2018 at 4:0= 4 AM, Yoshifumi Nishida <nishida@sfc.wide.ad.jp> wrote:=
Hi Xavier,

Thank you so much!
Yes, we have thought about 5G stuff as = well.=C2=A0
The reason why we haven't included in the list be= low was it might not be a short term topic while it can be important for mp= tcp in future.
New suggestions to mptcp with regard to this topic= will always be very welcome.
--
Yoshi


On Thu, Jun 14, 2018 at 2:01 PM, Xavier de Foy <x.= defoy.ietf@gmail.com> wrote:
Yoshifumi &=20 Phil,

=C2=A0 Another potential item under "Fe= ature Extensions" could be dedicated to interoperability with 5G. We a= re preparing an update to the "5G considerations" draft presented= in the last session, which can be used as input for the group to decide if= it should be on this list.

=C2=A0 Best Regards,
Xavier

On Thu, Jun 14, 2018 at 3:16 AM, Yoshifumi Nishid= a <nishida@sfc.wide.ad.jp> wrote:
Hello everyone,

Phil and I have been discussi= ng the next step for the WG.
After we finish 6824bis, we =EF=BD=97on't have acti= ve WG items as the proxy=C2=A0work wi= ll be discussed at tcpm WG.
One s= uggestion might be to close the WG or to put it in dormant state, however,= =C2=A0we are thinking there still mig= ht be some more working items as we've seen=C2=A0interesting presentations for new ideas, experiment results= and so on at the=C2=A0meetings and o= n the ML.

<= span style=3D"font-size:16px">Below is the list of potential working items = from the chairs' point of view.
Please let us know if you think some of them are= important items for=C2=A0the WG (and= your willingness to contribute if possible) or there are=C2=A0some more items, or this is not something we shou= ld work on, etc.

Also, if you have some opinions on the= status of the WG or suggestions=C2=A0to the chairs, please let us hear!

We appreciate your = feedback

Thanks,
--
Yoshi & Phil
<= br>


1: API extensions (This is already in our charter)
=C2=A0 =C2= =A0 draft-hesmans-mptcp-socket
=C2=A0 =C2=A0 draft-samar-mptcp-socketapi

2: Feature extensions
=C2=A0 =C2=A0 a) robust initial setup
=C2=A0 =C2=A0 =C2=A0 =C2= =A0 proposed by Markus,=C2=A0also Kie= n presented a similar idea

=C2=A0 =C2=A0 b) fast subflo= w setup
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 proposed by Quentin=C2=A0

= =C2=A0 =C2=A0 c) security enhancement
=C2=A0 =C2=A0 =C2=A0 =C2=A0 1) TLS
=C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 draft-bonaventure-mptcp-tls-00
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 draft-paasch-mptcp-tls-aut= hentication-00

=C2=A0 =C2=A0 =C2=A0 =C2=A0 2) Util= ize proposals from tcpinc?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 = 3) Elliptic Curve Cryptography
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-kim-m= ptcp-semptcp-00

=C2=A0 =C2=A0 d) Solutions for operatio= nal issues
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A01) how to handle nat64 issue proposed b= y Quentin
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A02) how to handle load balancer proposed = by Fabien, Christoph, Costin

3: Congestion Control (T= his topic itself should probably be discussed at ICCRG. But, it may trigger= some updates of the protocol or APIs later) =C2=A0
=C2=A0 =C2=A0 =C2=A0a) OLIA
=C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0 draft-khalili-mptcp-congestion-control-05

=C2=A0 =C2=A0 =C2=A0b) = mptcp + BBR?
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 presented by Jing

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





--0000000000001ddad6056f0d46dc-- From nobody Wed Jun 20 11:25:23 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD73A130E02 for ; Wed, 20 Jun 2018 11:25:21 -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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VABkoL16jOvb for ; Wed, 20 Jun 2018 11:25:19 -0700 (PDT) Received: from mail-qt0-x22d.google.com (mail-qt0-x22d.google.com [IPv6:2607:f8b0:400d:c0d::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29780130DFA for ; Wed, 20 Jun 2018 11:25:19 -0700 (PDT) Received: by mail-qt0-x22d.google.com with SMTP id q6-v6so498328qtn.7 for ; Wed, 20 Jun 2018 11:25:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=EsMHVk++S7T40Osl4rGSV27Zv4w7oR7mS7lB+BCLG/c=; b=AhcKgmF1IBrY6DQDJ6lXW/v37jFwuaGPqAKF5s4TIU0ECh7gMF9l4t0dIPOiX7c4rd z6HgsvVAm3LujRCertZy1uq/RkarFCXWKhXXGNoSGLv7qujj8mbhvGbOQ+7vhcKGpFXJ LHi9je9S9Ip0BLwtRwTpJO6j7217MFFaFMu5eOiNQqxLhGHdHZ6AxP011fTP4XKvCy13 8uMK4OYvZcjjFW2pp5YqW4v/b6B8fcsvCwh06qWewEd+r6POnYzzm1nMQZOdhY9yv7OZ WNCYl3BdP9dj0tYqh91759r26WTsy8duzeM4xxABeFCLnCxdGgtf2LtpOoJOQiNEJz8h DvoA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=EsMHVk++S7T40Osl4rGSV27Zv4w7oR7mS7lB+BCLG/c=; b=KOoNEeKmyzkgECicb5jYned7OKFUVsPAvp9g0/fC1uxX5zfT2ylky0nULw4r3FmsRp oWCCfMEZaGhCnvsPP7BKtY4bCUwkPUbkPHEOkuDOxtCzMhSk/q4UdBIG0d+0GAOv85Dx P+bydR2EoDADluRoCkJoxn5VBPnV9NAC7YV3PBj6Wa1W3WxJ365x5GmUJw83eqBwWZXa C+du7dqtMeszH5BWnv+iiEkzTlMNh6mjA0u9GHaTyaIOCT9/5XeBJZ7VVFfTV2S22x0C vTzqnP6D1qG89ST5eKqwAyFR1mDxnF7jNeP6OPB5x/UAcoWUbvL0tZjqaL3gZXjQuE8R 4Naw== X-Gm-Message-State: APt69E0eHYm5+o8vE4kRDBaMeETkZz5/YEOgEGgKduYQNoJspqe3w0/H DBZCjh7yWkHDz/E3T6HS792TsTxAMBnzjEoOQ+b+JQ== X-Google-Smtp-Source: ADUXVKLSgmRr6/HDHAnCk116cw3Wqu7DQzApoPbHTdvC4H4mSWo/4U6R5T7B2mQs868aBnxIpKiIvr/EUdhG41lbe/Q= X-Received: by 2002:a0c:870a:: with SMTP id 10-v6mr20005183qvh.169.1529519118064; Wed, 20 Jun 2018 11:25:18 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:2f5b:0:0:0:0:0 with HTTP; Wed, 20 Jun 2018 11:25:17 -0700 (PDT) In-Reply-To: References: From: Xavier de Foy Date: Wed, 20 Jun 2018 14:25:17 -0400 Message-ID: To: Yoshifumi Nishida Cc: multipathtcp Content-Type: multipart/alternative; boundary="000000000000b59e98056f16eb73" Archived-At: Subject: Re: [multipathtcp] Possible future items for mptcp WG X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 18:25:22 -0000 --000000000000b59e98056f16eb73 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Yoshi, thanks for the explanation, it makes sense to me. We will update the 5G considerations draft shortly, hopefully it will help defining a more concrete proposal. Best Regards, Xavier. On Wed, Jun 20, 2018 at 2:54 AM, Yoshifumi Nishida wrote: > Hi Xavier, > > Thanks. I think the timing you mentioned won't be a critical issue by > itself. > However, one question is how soon we can have concrete proposals to MPTCP > for 5G networks. > If there are already some solid features in 5G and we have explicit ideas > to update or extend MPTCP for them, I think there will be possibilities. > -- > Yoshi > > > On Tue, Jun 19, 2018 at 12:45 PM, Xavier de Foy > wrote: > >> Hi Yoshi, >> >> Thanks for the answer. In term of timing: 5G global deployment should >> occur in 2020 (with smaller/test deployments before this), so work relat= ed >> to 5G adaptation may be best completed within 12 to 18 months (just my >> understanding, maybe others on the list can share their views on the bes= t >> timing for this type of work). Do you think it is too far ahead, or woul= d >> it make sense to include 5G related investigations in the list? >> >> Best Regards, >> >> Xavier >> >> On Fri, Jun 15, 2018 at 4:04 AM, Yoshifumi Nishida < >> nishida@sfc.wide.ad.jp> wrote: >> >>> Hi Xavier, >>> >>> Thank you so much! >>> Yes, we have thought about 5G stuff as well. >>> The reason why we haven't included in the list below was it might not b= e >>> a short term topic while it can be important for mptcp in future. >>> New suggestions to mptcp with regard to this topic will always be very >>> welcome. >>> -- >>> Yoshi >>> >>> >>> On Thu, Jun 14, 2018 at 2:01 PM, Xavier de Foy >>> wrote: >>> >>>> Yoshifumi & Phil, >>>> >>>> Another potential item under "Feature Extensions" could be dedicated >>>> to interoperability with 5G. We are preparing an update to the "5G >>>> considerations" draft presented in the last session, which can be used= as >>>> input for the group to decide if it should be on this list. >>>> >>>> Best Regards, >>>> Xavier >>>> >>>> On Thu, Jun 14, 2018 at 3:16 AM, Yoshifumi Nishida < >>>> nishida@sfc.wide.ad.jp> wrote: >>>> >>>>> Hello everyone, >>>>> >>>>> Phil and I have been discussing the next step for the WG. >>>>> After we finish 6824bis, we =EF=BD=97on't have active WG items as the= proxy work >>>>> will be discussed at tcpm WG. >>>>> One suggestion might be to close the WG or to put it in dormant state= , >>>>> however, we are thinking there still might be some more working items >>>>> as we've seen interesting presentations for new ideas, experiment >>>>> results and so on at the meetings and on the ML. >>>>> >>>>> Below is the list of potential working items from the chairs' point o= f >>>>> view. >>>>> Please let us know if you think some of them are important items for = the >>>>> WG (and your willingness to contribute if possible) or there are some >>>>> more items, or this is not something we should work on, etc. >>>>> >>>>> Also, if you have some opinions on the status of the WG or suggestion= s to >>>>> the chairs, please let us hear! >>>>> >>>>> We appreciate your feedback >>>>> >>>>> Thanks, >>>>> -- >>>>> Yoshi & Phil >>>>> >>>>> >>>>> >>>>> >>>>> 1: API extensions (This is already in our charter) >>>>> draft-hesmans-mptcp-socket >>>>> draft-samar-mptcp-socketapi >>>>> >>>>> 2: Feature extensions >>>>> a) robust initial setup >>>>> proposed by Markus, also Kien presented a similar idea >>>>> >>>>> b) fast subflow setup >>>>> proposed by Quentin >>>>> >>>>> c) security enhancement >>>>> 1) TLS >>>>> draft-bonaventure-mptcp-tls-00 >>>>> draft-paasch-mptcp-tls-authentication-00 >>>>> >>>>> 2) Utilize proposals from tcpinc? >>>>> >>>>> 3) Elliptic Curve Cryptography >>>>> draft-kim-mptcp-semptcp-00 >>>>> >>>>> d) Solutions for operational issues >>>>> 1) how to handle nat64 issue proposed by Quentin >>>>> 2) how to handle load balancer proposed by Fabien, Christoph= , >>>>> Costin >>>>> >>>>> 3: Congestion Control (This topic itself should probably be discussed >>>>> at ICCRG. But, it may trigger some updates of the protocol or APIs la= ter) >>>>> a) OLIA >>>>> draft-khalili-mptcp-congestion-control-05 >>>>> >>>>> b) mptcp + BBR? >>>>> presented by Jing >>>>> >>>>> _______________________________________________ >>>>> multipathtcp mailing list >>>>> multipathtcp@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/multipathtcp >>>>> >>>>> >>>> >>> >> > --000000000000b59e98056f16eb73 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Yoshi, thanks for the explanation, it makes sense to me= . We will update the 5G considerations draft shortly, hopefully it will hel= p defining a more concrete proposal.
Best Regards,
Xavier.


On Wed, Jun 20= , 2018 at 2:54 AM, Yoshifumi Nishida <nishida@sfc.wide.ad.jp><= /span> wrote:
Hi Xavier,=

Thanks. I think the timing you mentioned won't be a= critical issue by itself.
However, one question is how soon we c= an have concrete proposals to MPTCP for 5G networks.=C2=A0
If the= re are already some solid features in 5G and we have explicit ideas to upda= te or extend MPTCP for them, I think there will be possibilities.
--
Yoshi


On Tue, Jun 19, 2018= at 12:45 PM, Xavier de Foy <x.defoy.ietf@gmail.com> wr= ote:
Hi Yoshi,

=C2=A0 Thanks for the answer. In term of timing: 5G global= =20 deployment should occur in 2020 (with smaller/test deployments before=20 this), so work related to 5G adaptation may be best=20 completed within 12 to 18 months (just my understanding, maybe others on the list can share their views on the best timing for this type of=20 work). Do you think it is too far ahead, or would it make sense to=20 include 5G related investigations in the list?
=C2=A0=C2=A0=C2=A0
= =C2=A0 Best Regards,
=C2=A0
Xavier

On Fri, Jun 15, 2018 at 4:04 AM, Yoshifumi Nishida <ni= shida@sfc.wide.ad.jp> wrote:
Hi Xavier,

Thank you so much!
Yes, we have thought about 5G stuff as well.=C2=A0
The reason = why we haven't included in the list below was it might not be a short t= erm topic while it can be important for mptcp in future.
New sugg= estions to mptcp with regard to this topic will always be very welcome.
--
Yoshi


On Thu, Jun 14, 2018 at 2:01 PM, Xavier de Foy <<= a href=3D"mailto:x.defoy.ietf@gmail.com" target=3D"_blank">x.defoy.ietf@gma= il.com> wrote:
Yoshifumi &=20 Phil,

=C2=A0 Another potential item under "Fe= ature Extensions" could be dedicated to interoperability with 5G. We a= re preparing an update to the "5G considerations" draft presented= in the last session, which can be used as input for the group to decide if= it should be on this list.

=C2=A0 Best Regards,
Xavier

On Thu, Jun 14, 2018 at 3:16= AM, Yoshifumi Nishida <nishida@sfc.wide.ad.jp> wrote:<= br>
Hello everyone,<= br style=3D"font-size:16px">
Phil and I have been discussing the next step for the WG.
After we fini= sh 6824bis, we =EF=BD=97on't have active WG items as the proxy=C2=A0work will be discussed at tcpm WG.
One suggestion might be to close the W= G or to put it in dormant state, however,=C2=A0we are thinking there still might be some more working items as w= e've seen=C2=A0interesting presen= tations for new ideas, experiment results and so on at the=C2=A0meetings and on the ML.

Belo= w is the list of potential working items from the chairs' point of view= .
Please = let us know if you think some of them are important items for=C2=A0<= span style=3D"font-size:16px">the WG (and your willingness to contribute if= possible) or there are=C2=A0some mor= e items, or this is not something we should work on, etc.

Also, if you have some opinions on the status of the WG or suggestions= =C2=A0to the chairs, please let us he= ar!

We appreciate your feedback

Tha= nks,
--
Yoshi &= ; Phil


=

1: API exte= nsions (This is already in our charter)
= =C2=A0 =C2=A0 draft-hesmans-mptcp-socket
=C2=A0 =C2= =A0 draft-samar-mptcp-socketapi

2: Feature extensions
=C2=A0 =C2= =A0 a) robust initial setup
=C2=A0 =C2=A0 =C2=A0 =C2=A0 proposed by Markus,=C2=A0also Kien presented a similar idea

=C2=A0 =C2=A0 b) fast subflow setup
=C2=A0 =C2=A0 =C2=A0 =C2=A0 prop= osed by Quentin=C2=A0

=C2=A0 =C2=A0 c) security enhance= ment
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 1) TLS
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-bona= venture-mptcp-tls-00
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-paasch-mptcp-tl= s-authentication-00

=C2=A0 =C2=A0 =C2=A0 =C2=A0 2) Utilize proposals from tcpinc?

=C2=A0 =C2=A0 =C2=A0 =C2=A0 3) Elliptic Curve Cryptography
=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-kim-mptcp-semptcp-00

=C2=A0 =C2=A0 d) Solutions for operational issues
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A01) how to handle nat64 issue proposed by Quentin
=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A02) how to handle load balancer proposed by Fabien, Christoph, Costin<= /span>

3: Congestion Control (This topic itself should probabl= y be discussed at ICCRG. But, it may trigger some updates of the protocol o= r APIs later) =C2=A0
=C2=A0 =C2=A0 =C2=A0a) OLIA
= =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 draft-kha= lili-mptcp-congestion-control-05=

=C2=A0 =C2=A0 =C2=A0b) mptcp + BBR?
=C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 presented by Jing

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






--000000000000b59e98056f16eb73-- From nobody Fri Jun 22 07:01:19 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE66F130E64 for ; Fri, 22 Jun 2018 07:01:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.31 X-Spam-Level: X-Spam-Status: No, score=-4.31 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, T_DKIMWL_WL_HIGH=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telekom.de Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mUaLGYTcUxda for ; Fri, 22 Jun 2018 07:01:13 -0700 (PDT) Received: from mailout34.telekom.de (MAILOUT34.telekom.de [194.25.225.146]) (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 5D9D7130E52 for ; Fri, 22 Jun 2018 07:01:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=telekom.de; i=@telekom.de; q=dns/txt; s=dtag1; t=1529676073; x=1561212073; h=from:to:subject:date:message-id: content-transfer-encoding:mime-version; bh=mHdBcriRiLZensAEODtci92pQaSiRo0T+sfY+0z52Uc=; b=KjAscn0nD744W5ZigLqnimkyPwPCRJafDXRYUpgf5o87RzWp8074f2ub PlUICglJaL6AUarGbqL5H8O9wFJDTo84zLHNQUTzvMs4xrY77NEH+hv8Z ceWf0sam8ONYy+PttRFM/KtR//jrSUSjHsYNZTSYTrjP0WDw9PfvQLjWN oBIliWX2+dDqtbug1P3Abt58O9Fu0+17VrLAP2XVJiw+L5zyc/BC3FYsi oCAVO40VpPnOqBwpcx+TJxtMcy+c2HQKdKz4b/APk9TL3l2HYJtsRbmGS pVR7i9C4h3wzzyFQYROOGfDFVbuA9MvWPnx6PmLj9wGLZ8ENEdOhjnYM5 Q==; Received: from qdezc2.de.t-internal.com ([10.171.255.37]) by MAILOUT31.dmznet.de.t-internal.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Jun 2018 16:01:11 +0200 X-IronPort-AV: E=Sophos;i="5.48,405,1517871600"; d="scan'208";a="832879286" Received: from he105685.emea1.cds.t-internal.com ([10.169.119.47]) by qde0ps.de.t-internal.com with ESMTP/TLS/AES256-SHA; 22 Jun 2018 16:01:11 +0200 Received: from HE105686.EMEA1.cds.t-internal.com (10.169.119.48) by HE105685.emea1.cds.t-internal.com (10.169.119.47) with Microsoft SMTP Server (TLS) id 15.0.1367.3; Fri, 22 Jun 2018 16:01:10 +0200 Received: from HE105686.EMEA1.cds.t-internal.com ([fe80::a951:f05b:3de5:32d9]) by HE105686.emea1.cds.t-internal.com ([fe80::a951:f05b:3de5:32d9%26]) with mapi id 15.00.1367.000; Fri, 22 Jun 2018 16:01:10 +0200 From: To: Thread-Topic: Possible future items for mptcp WG Thread-Index: AdQKMNmqpYIk5DurSQewXRqRqgFpDQ== Date: Fri, 22 Jun 2018 14:01:10 +0000 Message-ID: Accept-Language: de-DE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.117.17.19] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] Possible future items for mptcp WG X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 14:01:18 -0000 Hi Yoshi & Phil, I still follow the mentioned feature extension 2a) robust initial setup. Ma= ybe in late autumn, I want to publish an implementation inspired by https:/= /www.ietf.org/mail-archive/web/multipathtcp/current/msg03474.html. As soon = as this one is available, this might be a base for further discussions. Btw., I'm available @IETF 102 onsite. BR Markus > ---------------------------------------------------------------------- >=20 > Date: Thu, 14 Jun 2018 00:16:40 -0700 > From: Yoshifumi Nishida > To: multipathtcp > Subject: [multipathtcp] Possible future items for mptcp WG > Message-ID: > l.gmail.com> > Content-Type: text/plain; charset=3D"utf-8" >=20 > Hello everyone, >=20 > Phil and I have been discussing the next step for the WG. > After we finish 6824bis, we ?on't have active WG items as the proxy work = will > be discussed at tcpm WG. > One suggestion might be to close the WG or to put it in dormant state, > however, we are thinking there still might be some more working items as > we've seen interesting presentations for new ideas, experiment results an= d > so on at the meetings and on the ML. >=20 > Below is the list of potential working items from the chairs' point of vi= ew. > Please let us know if you think some of them are important items for the = WG > (and your willingness to contribute if possible) or there are some more i= tems, > or this is not something we should work on, etc. >=20 > Also, if you have some opinions on the status of the WG or suggestions to > the chairs, please let us hear! >=20 > We appreciate your feedback >=20 > Thanks, > -- > Yoshi & Phil >=20 >=20 >=20 >=20 > 1: API extensions (This is already in our charter) > draft-hesmans-mptcp-socket > draft-samar-mptcp-socketapi >=20 > 2: Feature extensions > a) robust initial setup > proposed by Markus, also Kien presented a similar idea >=20 > b) fast subflow setup > proposed by Quentin >=20 > c) security enhancement > 1) TLS > draft-bonaventure-mptcp-tls-00 > draft-paasch-mptcp-tls-authentication-00 >=20 > 2) Utilize proposals from tcpinc? >=20 > 3) Elliptic Curve Cryptography > draft-kim-mptcp-semptcp-00 >=20 > d) Solutions for operational issues > 1) how to handle nat64 issue proposed by Quentin > 2) how to handle load balancer proposed by Fabien, Christoph, Co= stin >=20 > 3: Congestion Control (This topic itself should probably be discussed at > ICCRG. But, it may trigger some updates of the protocol or APIs later) > a) OLIA > draft-khalili-mptcp-congestion-control-05 >=20 > b) mptcp + BBR? From nobody Fri Jun 22 08:03:25 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A803C130E8E for ; Fri, 22 Jun 2018 08:03:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u_hqEq0bavK8 for ; Fri, 22 Jun 2018 08:03:21 -0700 (PDT) Received: from mail-qt0-x22b.google.com (mail-qt0-x22b.google.com [IPv6:2607:f8b0:400d:c0d::22b]) (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 6407C130E88 for ; Fri, 22 Jun 2018 08:03:21 -0700 (PDT) Received: by mail-qt0-x22b.google.com with SMTP id y31-v6so6149275qty.9 for ; Fri, 22 Jun 2018 08:03:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=bbqtbuGTCebh+SDjP/STOPYeAbowFnEqZa0w2E+GneM=; b=Ljuyo5jMZVEYlnJrhdoSzwo+lUbMh9HWO6JOZSu0pbSkf58Cj58Rxbgp2nnyiMmetD KC2dmYc61FVwiWZH6IKJimW1e5WJW2QfyFmOj+Vq77kpK/kBNrsAdxniYQj3dAhnPS/y dXfdb7/KG+RxQNfaFIsnliRmb29JH0eo/Wv8jX9k54LrJTgESHzNQVfmmj21ANooajK0 xYS0vZVjITJ4IngmHH4gKIjF5cJHU6c7IFB2jtP5sYfISddkcKlTBkUD0pWPir+jL9Bo HsksRRZkLSZzoci60b43a0IRvMgkcekeE65tN9b5Frdg67SX9P3Ur+uSFhgEIJFXB9a2 rlvg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=bbqtbuGTCebh+SDjP/STOPYeAbowFnEqZa0w2E+GneM=; b=Ve98crOvV73rcC+nKIpJyDAs3UloMbd7w1EpRNXfX4zUTsgfAdPYDKp5ZHYU3H9by5 plIcx9HcA4mj5XOGUBE4QZbSvHWphrCt+fgU/gRlKDJ9of1YIwO3J85N6dj38Q7nqGHe XazbEzGhKdxoew2/lSTBBekXPn3Hpwz0Vsl5W3u2bbPJnutdynuD6pLNyAIJiiOswO50 oboehlKZeZDPEUDdC1mMQSxzqpqFa0q1aYPCAgoEcMbCLvh8tvqjXtlBRb70aW1qG8Ci u7tr9a69WCjumFALAvgx1blEb4qudQSEUZdbDy5ydoJIYFQgfzLFmEaOiKA7ggBnGAHG IsKw== X-Gm-Message-State: APt69E1OD85AaNro53Kp32SPAdjuuIJAjsqojgxb4ARV7/cYsGpTKj5X 7tk7OVpgh3bnuuoxn5XlhlWgyiw8u3bInCZO9txIpQ== X-Google-Smtp-Source: ADUXVKLTIpZjExVk8JbfoL6zRgHxtHHRbNskJn6eR4qfOPH66E0gaVGG8g8vWBN70kkDCE8xf5ecNW6TJh6L1fcpO2M= X-Received: by 2002:ac8:2c69:: with SMTP id e38-v6mr1686717qta.233.1529679800132; Fri, 22 Jun 2018 08:03:20 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:ac8:1613:0:0:0:0:0 with HTTP; Fri, 22 Jun 2018 08:03:19 -0700 (PDT) In-Reply-To: References: <152967671506.3644.8668562709318978649.idtracker@ietfa.amsl.com> From: Xavier de Foy Date: Fri, 22 Jun 2018 11:03:19 -0400 Message-ID: To: multipathtcp Content-Type: multipart/alternative; boundary="0000000000001b6894056f3c5549" Archived-At: Subject: [multipathtcp] Fwd: FW: New Version Notification for draft-defoy-mptcp-considerations-for-5g-01.txt X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 15:03:24 -0000 --0000000000001b6894056f3c5549 Content-Type: text/plain; charset="UTF-8" Hi, We have submitted a new version of "Considerations for MPTCP operation in 5G". Following comments at the last IETF meeting, we used the session continuity type defined in ietf-dmm-ondemand-mobility as primary input for local decisions in MPTCP stack. Session continuity type can also be associated with IP addresses in MPTCP signalling. More minor updates were made to the dual connectivity related topic (work is ongoing, there may be a more significant update later). Best Regards, Xavier. ---------- A new version of I-D, draft-defoy-mptcp-considerations-for-5g-01.txt has been successfully submitted by Xavier de Foy and posted to the IETF repository. Name:draft-defoy-mptcp-considerations-for-5g Revision:01 Title:Considerations for MPTCP operation in 5G Document date:2018-06-22 Group:Individual Submission Pages:13 URL: https://www.ietf.org/internet-drafts/draft-defoy-mptcp- considerations-for-5g-01.txt Status: https://datatracker.ietf.org/doc/draft-defoy-mptcp- considerations-for-5g/ Htmlized: https://tools.ietf.org/html/draft-defoy-mptcp- considerations-for-5g-01 Htmlized: https://datatracker.ietf.org/doc/html/draft-defoy-mptcp- considerations-for-5g Diff: https://www.ietf.org/rfcdiff?url2=draft-defoy-mptcp- considerations-for-5g-01 Abstract: This document describes scenarios where the behavior of the 5G mobility management framework is different from earlier cellular generations, and describes how it may benefit from some form of adaptation of MPTCP implementations and protocol aspects in the 5G system. This document also describes how MPTCP may be leveraged in 5G system specifications. Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. The IETF Secretariat [Banner] This e-mail is intended only for the use of the individual or entity to which it is addressed, and may contain information that is privileged, confidential and/or otherwise protected from disclosure to anyone other than its intended recipient. Unintended transmission shall not constitute waiver of any privilege or confidentiality obligation. If you received this communication in error, please do not review, copy or distribute it, notify me immediately by email, and delete the original message and any attachments. Unless expressly stated in this e-mail, nothing in this message or any attachment should be construed as a digital or electronic signature. --0000000000001b6894056f3c5549 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

=C2=A0 We have submitted= a new version of "Considerations for MPTCP operation in 5G".

=C2=A0 Following comments at the last IETF meeting, w= e used the session continuity type defined in ietf-dmm-ondemand-mobility as= primary input for local decisions in MPTCP stack. Session continuity type = can also be associated with IP addresses in MPTCP signalling. More minor up= dates were made to the dual connectivity related topic (work is ongoing, th= ere may be a more significant update later).

=C2=A0Best Regards,
Xa= vier.

----------

A new version of I-D, draft-defoy-mptcp-considerations-for-5g-01.txt has been successfully submitted by Xavier de Foy and posted to the IETF rep= ository.

Name:draft-defoy-mptcp-considerations-for-5g
Revision:01
Title:Considerations for MPTCP operation in 5G
Document date:2018-06-22
Group:Individual Submission
Pages:13
URL:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 https://www.ietf.org/internet-drafts/draf= t-defoy-mptcp-considerations-for-5g-01.txt
Status:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/draft-defoy-mptcp-= considerations-for-5g/
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://tools.ietf.org/html/draft-defoy-mptcp-consideration= s-for-5g-01
Htmlized:=C2=A0 =C2=A0 =C2=A0 =C2=A0https://datatracker.ietf.org/doc/html/draft-defoy-mptcp-<= wbr>considerations-for-5g
Diff:=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0https://www.ietf.org/rfcdiff?url2=3Ddraft-defo= y-mptcp-considerations-for-5g-01

Abstract:
=C2=A0 =C2=A0This document describes scenarios where the behavior of the 5G=
=C2=A0 =C2=A0mobility management framework is different from earlier cellul= ar
=C2=A0 =C2=A0generations, and describes how it may benefit from some form o= f
=C2=A0 =C2=A0adaptation of MPTCP implementations and protocol aspects in th= e 5G
=C2=A0 =C2=A0system.=C2=A0 This document also describes how MPTCP may be le= veraged in
=C2=A0 =C2=A05G system specifications.




Please note that it may take a couple of minutes from the time of submissio= n until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

[Banner]
This e-mail is intended only for the use of the individual or entity to whi= ch it is addressed, and may contain information that is privileged, confide= ntial and/or otherwise protected from disclosure to anyone other than its i= ntended recipient. Unintended transmission shall not constitute waiver of a= ny privilege or confidentiality obligation. If you received this communicat= ion in error, please do not review, copy or distribute it, notify me immedi= ately by email, and delete the original message and any attachments. Unless= expressly stated in this e-mail, nothing in this message or any attachment= should be construed as a digital or electronic signature.


--0000000000001b6894056f3c5549-- From nobody Tue Jun 26 00:33:09 2018 Return-Path: X-Original-To: multipathtcp@ietfa.amsl.com Delivered-To: multipathtcp@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 78758130DE6 for ; Tue, 26 Jun 2018 00:33:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tFwrI-74KYxh for ; Tue, 26 Jun 2018 00:33:03 -0700 (PDT) Received: from smtpb1.bt.com (smtpb1.bt.com [62.7.242.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8504712872C for ; Tue, 26 Jun 2018 00:33:02 -0700 (PDT) Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by EVMED04-UKBR.bt.com (10.216.161.34) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 26 Jun 2018 08:32:56 +0100 Received: from rew09926dag03b.domain1.systemhost.net (10.55.202.22) by rew09926dag03b.domain1.systemhost.net (10.55.202.22) with Microsoft SMTP Server (TLS) id 15.0.1293.2; Tue, 26 Jun 2018 08:32:59 +0100 Received: from rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e]) by rew09926dag03b.domain1.systemhost.net ([fe80::d514:fe50:560c:401e%12]) with mapi id 15.00.1293.004; Tue, 26 Jun 2018 08:32:59 +0100 From: To: Thread-Topic: WG Last Call for draft-ietf-mptcp-rfc6824bis Thread-Index: AdP8pPjqwq5n45WRS2ywhz4YK91ZcQAGiU/gBBgqcVA= Date: Tue, 26 Jun 2018 07:32:58 +0000 Message-ID: <8b63f3c2af9b4b1d93ec1ad73422be5b@rew09926dag03b.domain1.systemhost.net> References: <0dd5e48298ed4b4fb7344630abc794b7@rew09926dag03b.domain1.systemhost.net> <39fbc9f18384473398fca38670c73cf6@rew09926dag03b.domain1.systemhost.net> In-Reply-To: <39fbc9f18384473398fca38670c73cf6@rew09926dag03b.domain1.systemhost.net> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.55.202.243] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Archived-At: Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis X-BeenThere: multipathtcp@ietf.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: Multi-path extensions for TCP List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Jun 2018 07:33:07 -0000 Hi, Just a reminder about the WGLC for the protocol bis. Please send comments, Thanks! Phil & Yoshi -----Original Message----- From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of phil= ip.eardley@bt.com Sent: 05 June 2018 12:21 To: multipathtcp@ietf.org Subject: Re: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis As a reminder, this document Obsoletes: 6824 (if approved) and its Intended= status is Standards Track. As well as suggested changes or edits, positive review comments ("It's read= y") are also very valuable.=20 -----Original Message----- From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of phil= ip.eardley@bt.com Sent: 05 June 2018 09:14 To: multipathtcp@ietf.org Subject: [multipathtcp] WG Last Call for draft-ietf-mptcp-rfc6824bis This starts a WG Last Call for draft-ietf-mptcp-rfc6824bis. Please send com= ments by the end of June.=20 Please note there are three IPR disclosures (we're working on getting them = added to the rfc6824bis page):=20 * two are inherited from RFC6824 https://datatracker.ietf.org/ipr/search/?= submit=3Ddraft&id=3Ddraft-ietf-mptcp-multiaddressed =20 * one is inherited from draft-paasch-mptcp-syncookies (which got include in= rfc6824bis) https://datatracker.ietf.org/ipr/2678/=20 Thanks, Phil & Yoshi _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp _______________________________________________ multipathtcp mailing list multipathtcp@ietf.org https://www.ietf.org/mailman/listinfo/multipathtcp