Re: [multipathtcp] potential MPTCP proxy charter item

Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch> Mon, 07 November 2016 15:42 UTC

Return-Path: <mirja.kuehlewind@tik.ee.ethz.ch>
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 5BDDA1296A2 for <multipathtcp@ietfa.amsl.com>; Mon, 7 Nov 2016 07:42:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.697
X-Spam-Level:
X-Spam-Status: No, score=-5.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.497] 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 6-nwY3sn3WtV for <multipathtcp@ietfa.amsl.com>; Mon, 7 Nov 2016 07:42:38 -0800 (PST)
Received: from smtp.ee.ethz.ch (smtp.ee.ethz.ch [129.132.2.219]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0DF4F1295B9 for <multipathtcp@ietf.org>; Mon, 7 Nov 2016 07:42:37 -0800 (PST)
Received: from localhost (localhost [127.0.0.1]) by smtp.ee.ethz.ch (Postfix) with ESMTP id ED0D4D930D; Mon, 7 Nov 2016 16:42:35 +0100 (MET)
X-Virus-Scanned: by amavisd-new on smtp.ee.ethz.ch
Received: from smtp.ee.ethz.ch ([127.0.0.1]) by localhost (.ee.ethz.ch [127.0.0.1]) (amavisd-new, port 10024) with LMTP id GRnFGXMUbKIp; Mon, 7 Nov 2016 16:42:35 +0100 (MET)
Received: from [10.2.113.239] (public-docking-etx-0493.ethz.ch [10.2.113.239]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) (Authenticated sender: mirjak) by smtp.ee.ethz.ch (Postfix) with ESMTPSA id A89DCD9309; Mon, 7 Nov 2016 16:42:35 +0100 (MET)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 10.1 \(3251\))
From: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>
In-Reply-To: <4fceb7e5-a0b0-d4d2-8669-fad0df59095d@uclouvain.be>
Date: Mon, 07 Nov 2016 16:42:34 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <C0212561-63DA-4578-9795-928B51F2A71B@tik.ee.ethz.ch>
References: <CCD1A987-0F3C-4775-8B0E-5232965E7E22@nokia.com> <8bed05c5-9f6f-04aa-8aa8-690aa3ce30f4@uclouvain.be> <CAO249ydpdtR53VBniDczSt4zj_kk32c2W_FoZKs2XED0Jzk7Jw@mail.gmail.com> <787AE7BB302AE849A7480A190F8B933009D9577B@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <22907_1476946228_58086934_22907_5464_1_a7bca8d2-7656-4ff0-9f01-cf307f017148@OPEXCLILM42.corporate.adroot.infra.ftgroup> <57543A7A-1542-4C60-A5D3-E1658354BE5A@tik.ee.ethz.ch> <73a1c0dd64a843a5baa645d960c82886@rew09926dag03b.domain1.systemhost.net> <b8bfd5c6-21eb-4c4f-879a-851c3a71792a@OPEXCLILM31.corporate.adroot.infra.ftgroup> <56CE164A-9A62-4B57-9CFF-33DBD45BA8B2@gmail.com> <787AE7BB302AE849A7480A190F8B933009D9CA84@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <85D52AE4-FE5F-4977-8927-6BDB72614D07@gmail.com> <787AE7BB302AE849A7480A190F8B933009DAAA88@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <D2630820-7586-4361-A626-3278F22C319C@gmail.com> <B7D8197F-D833-41BB-A4A4-D6F31A3B8993@tik.ee.ethz.ch> <4fceb7e5-a0b0-d4d2-8669-fad0df59095d@uclouvain.be>
To: Olivier.Bonaventure@uclouvain.be
X-Mailer: Apple Mail (2.3251)
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/Hk2QEvyr2KRk_zN9WlF9GLh2sdk>
Cc: "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Subject: Re: [multipathtcp] potential MPTCP proxy charter item
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-path extensions for TCP <multipathtcp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/multipathtcp/>
List-Post: <mailto:multipathtcp@ietf.org>
List-Help: <mailto:multipathtcp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/multipathtcp>, <mailto:multipathtcp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 07 Nov 2016 15:42:40 -0000

Hi Olivier,

a few comments/questions below.


> Am 06.11.2016 um 22:12 schrieb Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>:
> 
> Mirja,
>> 
>> first, I agree with Alan that such a signal does not need to/should not be part of the MPTCP protocol.
> 
> Adding the signal inside MPTCP reduces the end-to-end delay compared with a pure application layer solution likes SOCKS and this is really important.
> 
>> MPTCP (as TCP is) is an end2end protocol. If you have one (or two) proxies in the middle, you split up the connection into multiple new ‚end2end‘ connections. If you need additional signaling information on one of the new connections, that a question for a high-layer protocol that uses MPTCP (which is what you do, when you propose it to be part of the payload).
> 
> SOCKS has been tried in some deployments with MPTCP and it increases the end-to-end delay given the additional rtt that are required.

I didn’t propose SOCKS. For me the solution could more or less be the same than you propose: you use TCP payload in the SYN for signal the needed information. I’m just saying this does not need to be part of the MPTCP protocol. I can simple be an own thing.

>> 
>> Second, I’m not a big fan of the a two side proxy scenario where one side simply assumes that the destination is not MPTCP-capable. This does not support MPTCP deployment but hinders native MPTCP deployment (basically ensuring that these proxies stay forever in the network and add additional complexity even if all endpoints are MPTCP-enabled one day). I guess a proxy should always first forward the MCTCP handshake and only if the reply does not support MPTCP, then termite the connection, reply the initiator accordingly and setup a new TCP to the destination. This might cause additional delay but it provides a big benefit if the destination is MPTCP-capable and supports native deployment.
> 
> It's clear that the MCP should send the MP_CAPABLE option in the SYN towards the destination server and fallback to TCP is this fails. Since there are some middleboxes that continue to silently drop the MP_CAPABLE option, the MCP should be able to maintain a list of destination servers where it had to fallback to regular TCP (e.g. after n retransmissions of the SYN with MP_CAPABLE as suggested in RFC6824) and no attempt to use MPTCP for these destinations. This cache should be reset on a regular basis to probe again the destination servers.

Do you mean the MCP forwards the original SYN (and basically does nothing if the server supports MPTCP) or does the MCP terminate the TCP connection and start a new TCP connection with MP_CAPABLE towards the server?

Mirja


> 
> 
> Olivier