Re: [multipathtcp] potential MPTCP proxy charter item

<mohamed.boucadair@orange.com> Tue, 08 November 2016 14:31 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 9D762129CBC for <multipathtcp@ietfa.amsl.com>; Tue, 8 Nov 2016 06:31:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.115
X-Spam-Level:
X-Spam-Status: No, score=-3.115 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, 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=-1.497, SPF_PASS=-0.001, 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 yTvaUnP0LUrc for <multipathtcp@ietfa.amsl.com>; Tue, 8 Nov 2016 06:31:19 -0800 (PST)
Received: from relais-inet.orange.com (mta134.mail.business.static.orange.com [80.12.70.34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 80294129CBA for <multipathtcp@ietf.org>; Tue, 8 Nov 2016 06:31:19 -0800 (PST)
Received: from opfednr04.francetelecom.fr (unknown [xx.xx.xx.68]) by opfednr21.francetelecom.fr (ESMTP service) with ESMTP id 78987C0284; Tue, 8 Nov 2016 15:31:17 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.57]) by opfednr04.francetelecom.fr (ESMTP service) with ESMTP id 442ED4011D; Tue, 8 Nov 2016 15:31:17 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3%19]) with mapi id 14.03.0319.002; Tue, 8 Nov 2016 15:31:17 +0100
From: <mohamed.boucadair@orange.com>
To: Alan Ford <alan.ford@gmail.com>
Thread-Topic: [multipathtcp] potential MPTCP proxy charter item
Thread-Index: AQHSOb1tnemdljzUmEGiGID3gGUCC6DPJB+g
Date: Tue, 8 Nov 2016 14:31:16 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009DAE28B@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
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> <e81c001b-ba6b-2990-9a62-09622e1339e1@uclouvain.be> <ACE6C987-A8AD-477B-986C-CFB4A438323F@gmail.com> <8074e8da-71ba-633d-dd67-6fc37adf19e5@uclouvain.be> <E9ECBC32-A8F1-4C9A-9D26-A3FF64C815FA@gmail.com> <3fb34255-bfdd-832e-4143-3872ed4b5d93@uclouvain.be> <7601A655-137D-4197-A2B7-4BB10ED0CB32@gmail.com> <d9f1f3b7-9a2c-e678-45ba-c5987f878254@uclouvain.be> <85EB3C4A-A04F-4259-85A0-BB48A7B46C7D@gmail.com> <787AE7BB302AE849A7480A190F8B933009DADF3F@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <C406A85B-DBC6-4FB6-A88F-5F1000A729B4@gmail.com>
In-Reply-To: <C406A85B-DBC6-4FB6-A88F-5F1000A729B4@gmail.com>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.1]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009DAE28BOPEXCLILMA3corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/PZDHUBIzoLvit0WJej8fGn9UQ5k>
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: Tue, 08 Nov 2016 14:31:21 -0000

Re-,

Please see inline.

Cheers,
Med

De : Alan Ford [mailto:alan.ford@gmail.com]
Envoyé : mardi 8 novembre 2016 13:41
À : BOUCADAIR Mohamed IMT/OLN
Cc : Olivier.Bonaventure@uclouvain.be; multipathtcp@ietf.org
Objet : Re: [multipathtcp] potential MPTCP proxy charter item

Hi Med,

Inline...


De : Alan Ford [mailto:alan.ford@gmail.com]
Envoyé : lundi 7 novembre 2016 17:37
À : Olivier.Bonaventure@uclouvain.be<mailto:Olivier.Bonaventure@uclouvain.be>
Cc : BOUCADAIR Mohamed IMT/OLN; multipathtcp@ietf.org<mailto:multipathtcp@ietf.org>
Objet : Re: [multipathtcp] potential MPTCP proxy charter item

Hi Olivier,

On 7 Nov 2016, at 07:50, Olivier Bonaventure <Olivier.Bonaventure@uclouvain.be<mailto:Olivier.Bonaventure@uclouvain.be>> wrote:


Why is it an /option/, however? When you are explicitly targeting a
proxy node, surely the proxy is just as capable of pulling the data out
of the payload here?

Because the addressing information that is used for the proxy is part of the control plane and not part of the bytestream. I think that it is very important from an architectural viewpoint to maintain a clean separation between the byte stream that is exchanged between the applications and all control information that should be placed inside options.

We explore the possibility of adding information in the bytestream for MPTCP and eventually decided to place all control information in options. If you look at HTTP, proxy-related information is part of the HTTP headers and not part of the payload. This is the same type of problem.

And this appears to be where we fundamentally disagree. I don’t see this as part of the control plane, I see proxying (at least in explicit mode) as an application of MPTCP, and should be at the application layer.

[Med] I still don’t understand this subtlety between “application of MPTCP” (you claim) and “MPTCP-specific use case” (we claim). If we extrapolate your argument, one can object that multi-pathing is an “application of TCP” (not even specific to TCP), and should not be defined as a TCP option. But the reality is that there is a TCP option for multi-patting.

This is a layering issue. MPTCP provides an end-to-end transport. Proxying solutions are also end-to-end protocols - one end encapsulates in a different transport (from TCP to MPTC), and the other end decapsulates (from MPTCP to TCP). It does not make sense (to me) to apply an end-to-end application (proxying) at the transport layer.
[Med] Yes, the MPTCP connection in the network-assisted case is managed between two MCPs or between an MPTCP-capable host and an MCP. I don’t see why defining an MPTCP option to help the gluing of MPTCP/TCP or avoid breaking an MPTCP connection is harmful.

Network translation is different and relies on changing fields in the same transport, not changing to a different one (I am coming at this from the perspective that MPTCP, although an extension to TCP, provides sufficiently different functionality that it it a different transport for the purposes of this discussion).


It seems too specific an application to be embedded in the protocol. This does not seem equivalent to NAT, since it is requiring additional signalling.

[Med] FWIW, instructing NAT state with in-band signaling information is specified by the IETF and widely deployed:
•         https://tools.ietf.org/html/rfc6052https://tools.ietf.org/html/rfc6146https://tools.ietf.org/html/rfc6877


As far as I can see, none of those involve changes at the transport layer.
[Med] I didn’t claimed that. I was answering to this part of your answer “This does not seem equivalent to NAT, since it is requiring additional signaling.”. What I’m saying is that there are NATs that require (in-band) signaling.

Regards,
Alan