IETF Logo Mail Archive

Re: [Int-area] Middleboxes to aid the deployment of MPTCP

<mohamed.boucadair@orange.com> Wed, 19 July 2017 08:46 UTC

Return-Path: <mohamed.boucadair@orange.com>
X-Original-To: int-area@ietfa.amsl.com
Delivered-To: int-area@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B10DB131C2F; Wed, 19 Jul 2017 01:46:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.619
X-Spam-Level:
X-Spam-Status: No, score=-2.619 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, URIBL_BLOCKED=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 HSWdxzapeEhq; Wed, 19 Jul 2017 01:46:41 -0700 (PDT)
Received: from relais-inet.orange.com (mta240.mail.business.static.orange.com [80.12.66.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40400131C38; Wed, 19 Jul 2017 01:46:41 -0700 (PDT)
Received: from opfedar06.francetelecom.fr (unknown [xx.xx.xx.8]) by opfedar24.francetelecom.fr (ESMTP service) with ESMTP id E1A5CC0715; Wed, 19 Jul 2017 10:46:39 +0200 (CEST)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [xx.xx.31.62]) by opfedar06.francetelecom.fr (ESMTP service) with ESMTP id B3F4F800BC; Wed, 19 Jul 2017 10:46:39 +0200 (CEST)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM5E.corporate.adroot.infra.ftgroup ([fe80::2912:bfa5:91d3:bf63%18]) with mapi id 14.03.0352.000; Wed, 19 Jul 2017 10:46:39 +0200
From: mohamed.boucadair@orange.com
To: Erik Kline <ek@google.com>
CC: Tom Herbert <tom@herbertland.com>, Joe Touch <touch@isi.edu>, Internet Area <int-area@ietf.org>, "tsv-area@ietf.org" <tsv-area@ietf.org>
Thread-Topic: [Int-area] Middleboxes to aid the deployment of MPTCP
Thread-Index: AQHTAGlI/K5LY2P7TE6q+ZKxS6zSn6Ja0ebg
Date: Wed, 19 Jul 2017 08:46:38 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B93300A00ECBE@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <fe384d2b-a0ba-9444-2ee9-cd0de6d24b7c@tessares.net> <61608b70-6861-e7f8-96de-5679718a9680@isi.edu> <CALx6S35LpE=Z8DhanPuVcN9sVR2rkxtFPUZMd6Z4v1PHsnzF0w@mail.gmail.com> <787AE7BB302AE849A7480A190F8B93300A00EA6D@OPEXCLILMA3.corporate.adroot.infra.ftgroup> <CAAedzxqqNM-oc85HLXTQtkQ4Sh+VE=Jsd7wQMjab99ib37_8YQ@mail.gmail.com>
In-Reply-To: <CAAedzxqqNM-oc85HLXTQtkQ4Sh+VE=Jsd7wQMjab99ib37_8YQ@mail.gmail.com>
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/int-area/va40ZBcdS96FawJZs_lvDhTqgNc>
Subject: Re: [Int-area] Middleboxes to aid the deployment of MPTCP
X-BeenThere: int-area@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: IETF Internet Area Mailing List <int-area.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/int-area>, <mailto:int-area-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/int-area/>
List-Post: <mailto:int-area@ietf.org>
List-Help: <mailto:int-area-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/int-area>, <mailto:int-area-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 19 Jul 2017 08:46:43 -0000

Hi Erik,

That's the intuitive approach to follow but unfortunately the situation is not that obvious to get into. 

Network providers do not have a control on the servers and the terminals that are enabled by customers behind the CPE. So making use of MPTCP to grab more resources (when available) or to provide better resiliency (when a network attachment is lost) will require both endpoints to be MPTCP-capable. 

We are in a situation where customers are provided with multiple accesses but these customers do only have the QoE as if they are single-connected. 

The network-assisted MPTCP is a feature to have immediately the benefits of MPTCP without requiring that all terminals and servers are MPTCP-capable.

The design we are advocating for allows for the use of MPTCP along the path when both endpoints are MPTCP-capable and to bypass the proxy when it makes sense.

Cheers,
Med

> -----Message d'origine-----
> De : Erik Kline [mailto:ek@google.com]
> Envoyé : mercredi 19 juillet 2017 10:30
> À : BOUCADAIR Mohamed IMT/OLN
> Cc : Tom Herbert; Joe Touch; Internet Area; tsv-area@ietf.org
> Objet : Re: [Int-area] Middleboxes to aid the deployment of MPTCP
> 
> > [Med] We would love to avoid requiring adding a function in the network
> to assist devices to make use of their multiple interfaces/paths.
> Nevertheless, the situation is that servers do not support MPTCP.
> 
> If server infrastructures aren't supporting MPTCP, maybe that's the
> thing that needs to be looked at...if in fact it can be helped.

v2.23.0 | Report a Bug | By Email