IETF Logo Mail Archive

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

<mohamed.boucadair@orange.com> Thu, 20 April 2017 05:50 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 3335F129B44 for <multipathtcp@ietfa.amsl.com>; Wed, 19 Apr 2017 22:50:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.389
X-Spam-Level:
X-Spam-Status: No, score=-5.389 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_H2=-2.8, 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 jnZ1ol1Blibw for <multipathtcp@ietfa.amsl.com>; Wed, 19 Apr 2017 22:50:36 -0700 (PDT)
Received: from relais-inet.orange.com (mta135.mail.business.static.orange.com [80.12.70.35]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A74C5128AB0 for <multipathtcp@ietf.org>; Wed, 19 Apr 2017 22:50:35 -0700 (PDT)
Received: from opfednr07.francetelecom.fr (unknown [xx.xx.xx.71]) by opfednr25.francetelecom.fr (ESMTP service) with ESMTP id F0EAA180631; Thu, 20 Apr 2017 07:50:33 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.69]) by opfednr07.francetelecom.fr (ESMTP service) with ESMTP id BBB211C0067; Thu, 20 Apr 2017 07:50:33 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILMA2.corporate.adroot.infra.ftgroup ([fe80::bc1c:ad2f:eda3:8c3d%18]) with mapi id 14.03.0319.002; Thu, 20 Apr 2017 07:50:33 +0200
From: mohamed.boucadair@orange.com
To: Joe Touch <touch@isi.edu>, Yoshifumi Nishida <nishida@sfc.wide.ad.jp>
CC: multipathtcp <multipathtcp@ietf.org>
Thread-Topic: [multipathtcp] Consensus call on potential MPTCP proxy work
Thread-Index: AQHSuThvFYN3Pf6Ey0Kw29UUSw2QvaHNvQhA
Date: Thu, 20 Apr 2017 05:50:32 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009E50F66@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <99affa00-5118-1a0f-227a-b3f4b751ffd4@isi.edu> <CAO249ye4Yz2Fgf5=XG5F3JkODym1AXrZV3pXyVLgG-h2iVhLVw@mail.gmail.com> <8cd97018-1104-c647-45fc-9135097e7420@isi.edu> <CAO249ycQqVweB5TaQNa2s8uFvQhSQrESrNmF1+8a8_ZO+Yqkyg@mail.gmail.com> <8bef96b7-1b7d-94eb-2e59-7323c2a9b866@isi.edu> <787AE7BB302AE849A7480A190F8B933009E503E2@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <7dca446a-e890-6d47-41d9-4f21100e551c@isi.edu>
In-Reply-To: <7dca446a-e890-6d47-41d9-4f21100e551c@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.1]
Content-Type: multipart/alternative; boundary="_000_787AE7BB302AE849A7480A190F8B933009E50F66OPEXCLILMA3corp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/p3Pv2BdPA5BuojUCHB7IHCkI4GY>
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 05:50:37 -0000

Hi Joe,

I don’t understand your comments here:

·         The use of a 32-bit magic number is meant to distinguish application-supplied data from the one inserted by the proxy. There are other fields in the MP_CONVERT information element that help in that aim too (validation of the TLV, M-bit, for example).

·         Both entities that supply and process the data are under the control of the same operator.

·         The network-located proxy is explicitly configured on the CPE. The destination IP address of the packet is an address of that proxy, not the address of a legacy node.

·         The proxy must echo supplied data in a SYN/ACK. If a mismatch is detected by the CPE, that proxy WON’t be used for subsequent connections till a new proxy is configured, TTL expires, etc.

To sum:

·         We are acting on one single SYN of an MPTCP connection.

·         If a mismatch is detected for one single SYN of a given connection, all subsequent connections (with any remote server) won’t be relayed to that proxy.

How is this “hazardous”?

Thank you.

Cheers,
Med

De : Joe Touch [mailto:touch@isi.edu]
Envoyé : mercredi 19 avril 2017 20:12
À : BOUCADAIR Mohamed IMT/OLN; Yoshifumi Nishida
Cc : multipathtcp
Objet : Re: [multipathtcp] Consensus call on potential MPTCP proxy work




On 4/18/2017 10:46 PM, mohamed.boucadair@orange.com<mailto:mohamed.boucadair@orange.com> wrote:
...
Using the SYN data as control information is the hazardous part.
[Med] It isn’t for the for the simple reason that legacy Internet nodes will never receive a SYN with CPE-supplied data and that the TCP peer is known to process the supplied data. A Guard against misconfigurations is supported: echo in a SYN/ACK.

The idea of using a magic number to protect against miscommunication virtually ensures that there will be reliable connections with errors. That changes TCPs semantics.

Putting data in the SYN of TFO is permitted only because of previous state.

MPTCP doesn't have that state and so it is hazardous to put data in the SYN.

I.e., if you want TFO-like performance, figure out how to use TFO. Period.

Joe

v2.23.0 | Report a Bug | By Email