Re: [multipathtcp] potential MPTCP proxy charter item

Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be> Sun, 06 November 2016 21:12 UTC

Return-Path: <olivier.bonaventure@uclouvain.be>
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 925D1129855 for <multipathtcp@ietfa.amsl.com>; Sun, 6 Nov 2016 13:12:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level:
X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=uclouvain.be
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gQStRoWjuOAZ for <multipathtcp@ietfa.amsl.com>; Sun, 6 Nov 2016 13:12:15 -0800 (PST)
Received: from smtp2.sgsi.ucl.ac.be (smtp.sgsi.ucl.ac.be [130.104.5.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52D60129851 for <multipathtcp@ietf.org>; Sun, 6 Nov 2016 13:12:15 -0800 (PST)
Received: from [192.168.1.9] (unknown [87.66.241.61]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: obonaventure@smtp2.sgsi.ucl.ac.be) by smtp2.sgsi.ucl.ac.be (Postfix) with ESMTPSA id AE63767DB83; Sun, 6 Nov 2016 22:12:05 +0100 (CET)
DKIM-Filter: OpenDKIM Filter v2.9.2 smtp2.sgsi.ucl.ac.be AE63767DB83
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=uclouvain.be; s=selucl; t=1478466726; bh=vnEVqXCkXmuDD7jo/rdqF13yID1Ehu8XFNnmw55NkNA=; h=Reply-To:Subject:References:To:Cc:From:Date:In-Reply-To; b=iuBR0yHC53Eubeacd2Zzwz/HDrWe6bxGts9wUCmD4c4nMHw7uP172+WkXQbOFGBG3 5RcJoztbgYX36YTw1uX8ALbTLHLPol9AAIiY5r4YLHgEBJmEAW9yKzQyGu8MoH1PrW VLtDDap2hKRnRXYP7lr3skGeTQ5IUJ3h6hebRXuw=
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.99 at smtp-2
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>
To: Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>, Mohamed Boucadair <mohamed.boucadair@orange.com>, Alan Ford <alan.ford@gmail.com>
From: Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be>
Message-ID: <4fceb7e5-a0b0-d4d2-8669-fad0df59095d@uclouvain.be>
Date: Sun, 06 Nov 2016 22:12:05 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.4.0
MIME-Version: 1.0
In-Reply-To: <B7D8197F-D833-41BB-A4A4-D6F31A3B8993@tik.ee.ethz.ch>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Transfer-Encoding: 8bit
X-Sgsi-Spamcheck: SASL authenticated,
X-SGSI-Information:
X-SGSI-MailScanner-ID: AE63767DB83.A603B
X-SGSI-MailScanner: Found to be clean
X-SGSI-From: olivier.bonaventure@uclouvain.be
X-SGSI-Spam-Status: No
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/WAKGyiViSp7aVEcJK2UpWR8Mvao>
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
Reply-To: Olivier.Bonaventure@uclouvain.be
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: Sun, 06 Nov 2016 21:12:16 -0000

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.
>
> 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.


Olivier