Re: [multipathtcp] potential MPTCP proxy charter item

<mohamed.boucadair@orange.com> Wed, 09 November 2016 07:06 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 41C86129451 for <multipathtcp@ietfa.amsl.com>; Tue, 8 Nov 2016 23:06:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.108
X-Spam-Level:
X-Spam-Status: No, score=-2.108 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, RCVD_IN_SORBS_SPAM=0.5, 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 WWooFEOtCYZG for <multipathtcp@ietfa.amsl.com>; Tue, 8 Nov 2016 23:06:09 -0800 (PST)
Received: from relais-inet.francetelecom.com (relais-ias92.francetelecom.com [193.251.215.92]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2392912946D for <multipathtcp@ietf.org>; Tue, 8 Nov 2016 23:06:08 -0800 (PST)
Received: from omfedm07.si.francetelecom.fr (unknown [xx.xx.xx.3]) by omfedm13.si.francetelecom.fr (ESMTP service) with ESMTP id 15A543246BB; Wed, 9 Nov 2016 08:06:07 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.75]) by omfedm07.si.francetelecom.fr (ESMTP service) with ESMTP id E363C4C078; Wed, 9 Nov 2016 08:06:06 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA4.corporate.adroot.infra.ftgroup ([fe80::65de:2f08:41e6:ebbe%18]) with mapi id 14.03.0319.002; Wed, 9 Nov 2016 08:06:06 +0100
From: mohamed.boucadair@orange.com
To: Joe Touch <touch@isi.edu>, Mirja Kühlewind <mirja.kuehlewind@tik.ee.ethz.ch>, "Olivier.Bonaventure@uclouvain.be" <Olivier.Bonaventure@uclouvain.be>
Thread-Topic: [multipathtcp] potential MPTCP proxy charter item
Thread-Index: AQHSOd9EnemdljzUmEGiGID3gGUCC6DQNZgQ
Date: Wed, 09 Nov 2016 07:06:06 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009DAE767@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <CCD1A987-0F3C-4775-8B0E-5232965E7E22@nokia.com> <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> <C0212561-63DA-4578-9795-928B51F2A71B@tik.ee.ethz.ch> <c93d9d6b-f46b-2b11-da6b-a308159ef7c0@isi.edu> <00ba6ab8-8fbf-ab19-b996-b84b87ad5520@isi.edu> <F9AAAF6C-DF82-412E-9C88-9043CC1EC3AA@isi.edu> <787AE7BB302AE849A7480A190F8B933009DAE088@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <ca2610f2-4f1b-5123-1e6e-697dfbe7cdc7@isi.edu> <787AE7BB302AE849A7480A190F8B933009DAE31D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <fe18560f-098e-6953-55b9-f9d147b87c48@isi.edu>
In-Reply-To: <fe18560f-098e-6953-55b9-f9d147b87c48@isi.edu>
Accept-Language: fr-FR, en-US
Content-Language: fr-FR
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.168.234.5]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009DAE767OPEXCLILMA3corp_"
MIME-Version: 1.0
X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.11.9.63617
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/MeHnuy6Xrbdwvh9quXWoYLtzUlI>
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: Wed, 09 Nov 2016 07:06:12 -0000

Hi Joe,

Please see inline.

Cheers,
Med

De : Joe Touch [mailto:touch@isi.edu]
Envoyé : mardi 8 novembre 2016 17:44
À : BOUCADAIR Mohamed IMT/OLN; Mirja Kühlewind; Olivier.Bonaventure@uclouvain.be
Cc : multipathtcp@ietf.org
Objet : Re: [multipathtcp] potential MPTCP proxy charter item




On 11/8/2016 7:06 AM, mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com> wrote:

Please explain. If there is option information in the SYN data, then a

> legacy peer is allowed to keep that data (and ACK it) in the SYN ACK.

>

> So now it has option info that it interprets as data.

[Med] But a legacy node is not allowed to pass it to the application till the 3WHS is completed. https://tools.ietf.org/html/rfc793#section-3.4 says the following:
Agreed.

So now you have an option that violates 1122 because the receiver is ignoring an option it doesn't understand
[Med] This is not violating RFC1122.
but it would be an error to continue with that connection.
[Med] The receiver does not crash or generate an error, all is handled at the sender side. The sender side can decide to continue with the connection or to fallback. For example, the sender can continue with the connection if the MP_CONVERT option was included as part of the implicit mode (that is say to MPTCP proxy: “this is an MPTCP connection, please don’t revert it to TCP”). The sender can also decide for this connection and only this connection, to RST the ongoing connection and fallback to TCP.

Even if you assume that's true, you have another problem.

You've just opened a connection using a pair of ports. You sent a RST, but RSTs are not reliable. So you can't reuse that port pair until TIME-WAIT expires.
[Med] This a fair observation. Another source port number will be used for the fallback connection (if any).

If you declare it "off" for an endpoint, do you ever check again?
[Med] Yes, e.g.,

·         When a new MPTCP proxy is discovered (e.g., https://tools.ietf.org/html/draft-boucadair-mptcp-dhc-05)

·         Upon reboot of the host

·         When attaching to a new network

·         When a timer expires

Also, you can never use this option with TFO (which *would* try to pass the data to the app) . I think you mentioned that, but then it's clearly not generic.
[Med] This is more subtle, Joe:

·         MP_CONVERT negotiation is done per MPTCP Proxy. In particular, the procedure is not repeated for each new connection with an ultimate server.

·         TFO is negotiated per server not per MPTCP proxy.

·         Using TFO requires an initial connection to get the cookie prior to making use of it.

·         If MP_CONVERT negotiation happened before TFO negotiation, there are no implications on TFO.

·         If the MP_CONVERT negotiation and TFO negotiation happen in the same connection, there are again no implications on TFO.

·         If TFO negotiation happens after MP_CONVERT negotiation, there are two cases:

o    If it is safe to use MP_CONVERT and TFO, then the TFO data in the payload is clearly delimited because we are using EOL as a marker. The proxy will unambiguously identify TFO data that it will forward in an upstream packet to the ultimate server.

o    If it is not safe to use MP_CONVERT, there are again no implications on TFO.


Joe