IETF Logo Mail Archive

Re: [multipathtcp] MPTCP carrying UDP

<mohamed.boucadair@orange.com> Wed, 16 November 2016 09:53 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 EA871129664 for <multipathtcp@ietfa.amsl.com>; Wed, 16 Nov 2016 01:53:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.416
X-Spam-Level:
X-Spam-Status: No, score=-3.416 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, 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 YK0XdOidoG6U for <multipathtcp@ietfa.amsl.com>; Wed, 16 Nov 2016 01:53:32 -0800 (PST)
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 C25F0129695 for <multipathtcp@ietf.org>; Wed, 16 Nov 2016 01:53:30 -0800 (PST)
Received: from opfedar05.francetelecom.fr (unknown [xx.xx.xx.7]) by opfedar20.francetelecom.fr (ESMTP service) with ESMTP id C8ADF120123; Wed, 16 Nov 2016 10:53:27 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.61]) by opfedar05.francetelecom.fr (ESMTP service) with ESMTP id 042AF60062; Wed, 16 Nov 2016 10:53:29 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7E.corporate.adroot.infra.ftgroup ([fe80::b91c:ea2c:ac8a:7462%19]) with mapi id 14.03.0319.002; Wed, 16 Nov 2016 10:53:28 +0100
From: mohamed.boucadair@orange.com
To: "Olivier.Bonaventure@uclouvain.be" <Olivier.Bonaventure@uclouvain.be>, "cpaasch@apple.com" <cpaasch@apple.com>
Thread-Topic: [multipathtcp] MPTCP carrying UDP
Thread-Index: AQHSP+jJK0Z1pSm/9UWs1LVwkQfSsqDbWvGA
Date: Wed, 16 Nov 2016 09:53:28 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009DB4C55@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <4d11a19b2b6644848ce79f55cdbd6ab5@rew09926dag03b.domain1.systemhost.net> <787AE7BB302AE849A7480A190F8B933009DB40D0@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <20161115172159.GX4269@Chimay.local> <787AE7BB302AE849A7480A190F8B933009DB49A7@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <53c65dc1-7687-4265-d7a6-a213210af316@uclouvain.be>
In-Reply-To: <53c65dc1-7687-4265-d7a6-a213210af316@uclouvain.be>
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: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/Sr1JWtP7xDsbQpAn9GjMWj5L6QE>
Cc: "multipathtcp@ietf.org" <multipathtcp@ietf.org>, "Markus.Brunner3@swisscom.com" <Markus.Brunner3@swisscom.com>
Subject: Re: [multipathtcp] MPTCP carrying UDP
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, 16 Nov 2016 09:53:37 -0000

Hi Olivier, 

I'm not questioning the importance of implementations. Their importance is obvious to me. 

If we want to proceed to a "reality check" as you mentioned, there should be an agreement of what "reality" is to be checked at the first place!

"tunnel UDP over MPTCP" is too generic. We need to point to a given specification so that interpreting results is not biased. For example, comparing the experimental results of these proposals does not make sense: 

* nc command to relay TCP to UDP and vice versa: http://www.tutorialspoint.com/unix_commands/nc.htm 
* http://www.komodia.com/komodia-relay 
* http://www.cs.columbia.edu/~lennox/udptunnel/ 
* SOCKS (as mentioned by Markus). 

Cheers,
Med

> -----Message d'origine-----
> De : Olivier Bonaventure [mailto:Olivier.Bonaventure@uclouvain.be]
> Envoyé : mercredi 16 novembre 2016 10:07
> À : BOUCADAIR Mohamed IMT/OLN; cpaasch@apple.com
> Cc : multipathtcp@ietf.org; Markus.Brunner3@swisscom.com
> Objet : Re: [multipathtcp] MPTCP carrying UDP
> 
> Med,
> >
> > I would like to make two comments:
> > * The implementers I have in mind are CPE vendors and Carrier-Grade
> platform manufacturers.
> > * Implementation does not come for free.
> >
> 
> Independently of the topic of this email, I'd like to point out that in
> the MPTCP working group most of the important decisions have been
> validated by early prototypes that have been evaluated and discussed in
> the working group. I think that this has served as an important "reality
> check" in the working group and has probably contributed to the good
> results that we have achieved with the various deployments that have
> been documented. With the open-source implementation of Multipath TCP in
> the Linux kernel, the cost of developing a prototype is not as high as
> developing a hardware implementation in some working groups.
> 
> Coming back to the proxy topic, TCP/MPTCP proxies have already been
> demonstrated, e.g. in
> http://inl.info.ucl.ac.be/publications/multipath-middlebox
> and extensions of this idea are deployed in the field.
> I'm not aware of similar work showing that UDP can be safely
> encapsulated inside MPTCP for reactive applications.
> 
> Best regards,
> 
> Olivier

v2.23.0 | Report a Bug | By Email