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
- [multipathtcp] Consensus call on potential MPTCP … philip.eardley
- Re: [multipathtcp] Consensus call on potential MP… christian.jacquenet
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Juliusz Chroboczek
- Re: [multipathtcp] Consensus call on potential MP… Stefano Secci
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]
- Re: [multipathtcp] Consensus call on potential MP… Henderickx, Wim (Nokia - BE/Antwerp)
- Re: [multipathtcp] Consensus call on potential MP… Henderickx, Wim (Nokia - BE/Antwerp)
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Yoshifumi Nishida
- Re: [multipathtcp] Consensus call on potential MP… David Allan I
- Re: [multipathtcp] Consensus call on potential MP… Juliusz Chroboczek
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Yoshifumi Nishida
- Re: [multipathtcp] Consensus call on potential MP… Olivier Bonaventure
- Re: [multipathtcp] Consensus call on potential MP… Costin Raiciu
- Re: [multipathtcp] Consensus call on potential MP… Olivier Bonaventure
- Re: [multipathtcp] Consensus call on potential MP… philip.eardley
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Markus.Brunner3
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Robert Skog
- Re: [multipathtcp] Consensus call on potential MP… Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]
- Re: [multipathtcp] Consensus call on potential MP… Jordan Melzer
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Juliusz Chroboczek
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Juliusz Chroboczek
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Sargent, Matthew T. (GRC-LCA0)[Peerless Technologies]
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Juliusz Chroboczek
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Eggert, Lars
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Eggert, Lars
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Yoshifumi Nishida
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Juliusz Chroboczek
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… philip.eardley
- Re: [multipathtcp] Consensus call on potential MP… Sébastien Barré
- Re: [multipathtcp] Consensus call on potential MP… Wouter Cloetens
- [multipathtcp] Increasing usage of MPTCP [was: Co… Juliusz Chroboczek
- Re: [multipathtcp] Consensus call on potential MP… SungHoon Seo
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Increasing usage of MPTCP [was… Olivier Bonaventure
- Re: [multipathtcp] Consensus call on potential MP… Matt Sargent
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Increasing usage of MPTCP [was… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Meyer, Ullrich, Vodafone DE
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Juliusz Chroboczek
- Re: [multipathtcp] Consensus call on potential MP… Juliusz Chroboczek
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair
- Re: [multipathtcp] Consensus call on potential MP… Joe Touch
- Re: [multipathtcp] Consensus call on potential MP… Yoshifumi Nishida
- Re: [multipathtcp] Consensus call on potential MP… mohamed.boucadair