Re: [multipathtcp] Increasing usage of MPTCP [was: Consensus call...]

<mohamed.boucadair@orange.com> Wed, 26 April 2017 06:38 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 48072131853 for <multipathtcp@ietfa.amsl.com>; Tue, 25 Apr 2017 23:38:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level:
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, 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 UZKgjK51NFwk for <multipathtcp@ietfa.amsl.com>; Tue, 25 Apr 2017 23:38:42 -0700 (PDT)
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 626A3131855 for <multipathtcp@ietf.org>; Tue, 25 Apr 2017 23:38:42 -0700 (PDT)
Received: from opfedar00.francetelecom.fr (unknown [xx.xx.xx.11]) by opfedar22.francetelecom.fr (ESMTP service) with ESMTP id 2077D60550; Wed, 26 Apr 2017 08:38:41 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.24]) by opfedar00.francetelecom.fr (ESMTP service) with ESMTP id 054CA180055; Wed, 26 Apr 2017 08:38:41 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7D.corporate.adroot.infra.ftgroup ([fe80::9044:c5ee:4dd2:4f16%19]) with mapi id 14.03.0319.002; Wed, 26 Apr 2017 08:38:40 +0200
From: <mohamed.boucadair@orange.com>
To: Juliusz Chroboczek <jch@irif.fr>, SungHoon Seo <sh.seo@kt.com>
CC: "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Thread-Topic: [multipathtcp] Increasing usage of MPTCP [was: Consensus call...]
Thread-Index: AQHSvbixRQbMuzi5EkWLuCvpR3koVqHXLPRA
Date: Wed, 26 Apr 2017 06:38:40 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009E5395D@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <8c5ffa879686472594bfd3db2fa06076@rew09926dag03b.domain1.systemhost.net> <3F6DAF4F-87AD-411E-96A6-4FB52FF83F6D@netapp.com> <787AE7BB302AE849A7480A190F8B933009E51D3E@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <225E7ED6-F614-4216-BF01-1E6E30605A3B@netapp.com> <787AE7BB302AE849A7480A190F8B933009E51D65@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <fde4be28d9b6474bbde2d92c817dfecb@rew09926dag03b.domain1.systemhost.net> <AAA2913CE97A474D937BF3C760E855A7608BCB05@MAIL-MBX-02> <7ishkwu35f.wl-jch@irif.fr>
In-Reply-To: <7ishkwu35f.wl-jch@irif.fr>
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: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/nJc_Nu9PnrmIW3cWLuMK-I19-Do>
Subject: Re: [multipathtcp] Increasing usage of MPTCP [was: Consensus call...]
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: Wed, 26 Apr 2017 06:38:44 -0000

Hi Juliusz, 

I echo Olivier here.

That's said, you are making a valid point: how to avoid the risk that proxies may prevent end-to-end MPTCP connections (if it happens that servers support MPTCP). 

This is exactly why we need a standard solution and why we have this design objective: "Avoid interference with native MPTCP connections". 

The solution we have on the table allows for this. 

Better, it allows to make use of path diversity whenever available and without requiring changes to hosts:
- That path diversity may not even be visible to an MPTCP-aware client, e.g., a host connected in LAN network that is multi-homed.
- That path diversity may not even be usable by a host, e.g., multi-path server and MPTCP-unaware client.
- That path diversity may not even be usable for MPTCP-aware endpoints, e.g., a host provided with an IPv4 address from network1 and IPv6-only prefix from network2 while the server is IPv4-only.

As a bonus, the proposal allows to withdraw a proxy from the path based on policies.

We are proposing a design that avoids to include locks out there. 

Thank you.

Cheers,
Med

> -----Message d'origine-----
> De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de
> Juliusz Chroboczek
> Envoyé : mardi 25 avril 2017 13:40
> À : SungHoon Seo
> Cc : multipathtcp@ietf.org
> Objet : [multipathtcp] Increasing usage of MPTCP [was: Consensus call...]
> 
> > Use case with this proxy work may increase the usage of the MPTCP, since
> > most of the existing servers do not have MPTCP capability.
> 
> It may also have the opposite effect -- to lock up MPTCP in the ghetto of
> proxy-to-proxy protocols, and destroy the (positive) perception of MPTCP
> as a suitable end-to-end protocol.
> 
> (IMHO, upstreaming MPTCP into the Linux kernel would do more for MPTCP
> deployment than anything that the IETF may do, but I guess that's somewhat
> off-topic for this discussion.)
> 
> -- Juliusz
> 
> _______________________________________________
> multipathtcp mailing list
> multipathtcp@ietf.org
> https://www.ietf.org/mailman/listinfo/multipathtcp