Re: [multipathtcp] Consensus call on potential MPTCP proxy work

<mohamed.boucadair@orange.com> Thu, 20 April 2017 06:34 UTC

Return-Path: <mohamed.boucadair@orange.com>
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 AF28212EB04 for <multipathtcp@ietfa.amsl.com>; Wed, 19 Apr 2017 23:34:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.609
X-Spam-Level:
X-Spam-Status: No, score=-2.609 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, UNPARSEABLE_RELAY=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 5lbGdVu-I3yA for <multipathtcp@ietfa.amsl.com>; Wed, 19 Apr 2017 23:34:48 -0700 (PDT)
Received: from relais-inet.orange.com (mta239.mail.business.static.orange.com [80.12.66.39]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F8F6120724 for <multipathtcp@ietf.org>; Wed, 19 Apr 2017 23:34:48 -0700 (PDT)
Received: from opfedar04.francetelecom.fr (unknown [xx.xx.xx.6]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id 6EBFCC0346; Thu, 20 Apr 2017 08:34:46 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.60]) by opfedar04.francetelecom.fr (ESMTP service) with ESMTP id 5282240069; Thu, 20 Apr 2017 08:34:46 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7F.corporate.adroot.infra.ftgroup ([fe80::c1d7:e278:e357:11ad%19]) with mapi id 14.03.0319.002; Thu, 20 Apr 2017 08:34:46 +0200
From: <mohamed.boucadair@orange.com>
To: Jordan Melzer <Jordan.Melzer@telus.com>
CC: "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work
Thread-Index: AdK5n8HwPVdmWlqIT+qt6bBQdKeelg==
Date: Thu, 20 Apr 2017 06:34:45 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009E50FB1@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.1]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009E50FB1OPEXCLILMA3corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/3dozCjfc_EAKPADdIeXKK_6WbPM>
Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work
X-BeenThere: multipathtcp@ietf.org
X-Mailman-Version: 2.1.22
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: Thu, 20 Apr 2017 06:34:51 -0000

Hi Jordan,

SOCKS + TFO was discussed in the mailing list and also during the meeting in Chicago. Modifying SOCKS to provide 0-RTT will need to be yet specified...and therefore will need a new RFCed. There was clear consensus during the Chicago meeting to not work on SOCKS.

Modifying SOCKS will at best provide what we are doing in the plain mode, but still it does not provide address preservation feature that we want to ensure for IPv6.

Cheers,
Med

De : Jordan Melzer [mailto:Jordan.Melzer@telus.com]
Envoyé : mercredi 19 avril 2017 20:59
À : Joe Touch; BOUCADAIR Mohamed IMT/OLN; philip.eardley@bt.com; multipathtcp@ietf.org
Objet : RE: [multipathtcp] Consensus call on potential MPTCP proxy work

It's a conventional proxy.  There are different sockets on each side of the proxy, different RTTs, different congestion control.  The proposal is to find a near-zero overhead way to do this when the proxy is off-path (ie, when it's not a simple connection hijack).  This may be totally possible without a new RFC - Christoph Paasch suggested that SOCKS + TFO could basically become this, but I am not sure anyone who cared either caught it or agreed.

Re b), it's off-topic, but what would you think of a multipath tunnel that was basically MPTCP with the retransmissions gutted out?  I had thought this would be what BANANA is doing, but I am not clear there are any two people in BANANA who agree on what it is.


From: multipathtcp [mailto:multipathtcp-bounces@ietf.org] On Behalf Of Joe Touch
Sent: April 19, 2017 02:17 PM
To: mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com>; philip.eardley@bt.com<mailto:philip.eardley@bt.com>; multipathtcp@ietf.org<mailto:multipathtcp@ietf.org>
Subject: Re: [multipathtcp] Consensus call on potential MPTCP proxy work




On 4/18/2017 10:26 PM, mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com> wrote:
As explained in my previous message, there is no layered congestion control. All packets are transported over plain TCP: no encap, no tunnel.
I did say "if"; I now understand better what you're trying to do, but there are plenty of parts still not addressed:

 I really reiterate my comment to read https://www.ietf.org/proceedings/98/slides/slides-98-mptcp-sessa-network-assisted-mptcp-03.pdf
Here's what those slides do not explain:

- is this system 1:1 per client TCP connection, or are you expecting a single MPTCP between proxies to support multiples?
- what is the congestion control interaction? I.e., does the client think the RTT is to the proxy (which will work), or to the TCP receiver past the end of the MPTCP connection?
    NOTE: if the latter, then you still end up with layered congestion control
- what is the proxy relaying?
    is it TCP data, or is it somehow trying to tunnel and reconstitute the entire packet?

    NOTE: if it reconstitutes the packet, what happens when you get an option you don't understand? E.g., EDO?

There are still plenty of more concerns with this system. Overall, you *still* appear to be doing one of two things:

    a) acting like a conventional application-layer proxy, which would be fine but would not require any new RFCs
    b) tunneling - or acting exactly like you're tunneling, by reconstituting packets on the other end - a TCP connection over TCP, which is a bad idea

So which is it? Or is it something else?

Joe