Re: [multipathtcp] MPTCP proxies, and the BANANA BoF

<mohamed.boucadair@orange.com> Fri, 04 November 2016 14:05 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 18962129418 for <multipathtcp@ietfa.amsl.com>; Fri, 4 Nov 2016 07:05:50 -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, 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 fhlYDzKBYewr for <multipathtcp@ietfa.amsl.com>; Fri, 4 Nov 2016 07:05:48 -0700 (PDT)
Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 211AA1294FE for <multipathtcp@ietf.org>; Fri, 4 Nov 2016 07:05:48 -0700 (PDT)
Received: from omfedm08.si.francetelecom.fr (unknown [xx.xx.xx.4]) by omfedm14.si.francetelecom.fr (ESMTP service) with ESMTP id 7D34522CAC2; Fri, 4 Nov 2016 15:05:46 +0100 (CET)
Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.60]) by omfedm08.si.francetelecom.fr (ESMTP service) with ESMTP id 54DA723809C; Fri, 4 Nov 2016 15:05:46 +0100 (CET)
Received: from OPEXCLILMA3.corporate.adroot.infra.ftgroup ([fe80::60a9:abc3:86e6:2541]) by OPEXCLILM7F.corporate.adroot.infra.ftgroup ([fe80::c1d7:e278:e357:11ad%19]) with mapi id 14.03.0319.002; Fri, 4 Nov 2016 15:05:46 +0100
From: mohamed.boucadair@orange.com
To: Brian Trammell <ietf@trammell.ch>, "multipathtcp@ietf.org" <multipathtcp@ietf.org>
Thread-Topic: [multipathtcp] MPTCP proxies, and the BANANA BoF
Thread-Index: AQHSNp8yZAtQiuv0JkaiuzyhCmTt8qDI1uUw
Date: Fri, 04 Nov 2016 14:05:45 +0000
Message-ID: <787AE7BB302AE849A7480A190F8B933009DAC7C2@OPEXCLILMA3.corporate.adroot.infra.ftgroup>
References: <8741F579-D97F-4325-81A0-CA6FF40FA2D9@trammell.ch>
In-Reply-To: <8741F579-D97F-4325-81A0-CA6FF40FA2D9@trammell.ch>
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="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.11.4.124517
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/wZ3ihepenGo0IVlhV1nnvKNLRvc>
Subject: Re: [multipathtcp] MPTCP proxies, and the BANANA BoF
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: Fri, 04 Nov 2016 14:05:50 -0000

Hi Brian, 

I don't understand the causality effect in your statement:

That pretty much requires that the MPTCP part remain
> end-to-end, while the proxy selection (and any other interproxy
> communication) happen out of that band.

https://tools.ietf.org/html/draft-nam-mptcp-deployment-considerations-00.html describes how native MPTCP communications can be established by an MPTCP-capable host without involving any proxy with in-band signaling!

In those deployment models, the MPTCP connections is establish (obviously) between MPTCP-capable nodes:
* either between an MPTCP-capable client and a proxy
* between two MPTCP proxies.

I don't also quit understand your comment about "proxy selection" given that all the proposals on the table for selecting a proxy are out of band (e.g., https://tools.ietf.org/html/draft-boucadair-mptcp-dhc-06).

Out of band communications suffer from an extra delay to establish MPTCP communications vs TCP ones. Several 10s of ms are required in some cases before the MPTCP connection flies. We don't have such problems with in-band signaling.

Cheers,
Med

> -----Message d'origine-----
> De : multipathtcp [mailto:multipathtcp-bounces@ietf.org] De la part de
> Brian Trammell
> Envoyé : vendredi 4 novembre 2016 14:27
> À : multipathtcp@ietf.org
> Objet : [multipathtcp] MPTCP proxies, and the BANANA BoF
> 
> Greetings, all,
> 
> First, for those of you who aren't aware, there's a non-WG forming BoF in
> Seoul on Thursday afternoon, on using multipath bonding for broadband
> access networks, BANANA. One of the solutions we'll be looking at is
> MPTCP-proxy based; those interested, please come by!
> 
> On this point, Mirja said:
> 
> > first, I agree with Alan that such a signal does not need to/should not
> be part of the MPTCP protocol. MPTCP (as TCP is) is an end2end protocol.
> If you have one (or two) proxies in the middle, you split up the
> connection into multiple new ‚end2end‘ connections. If you need additional
> signaling information on one of the new connections, that a question for a
> high-layer protocol that uses MPTCP (which is what you do, when you
> propose it to be part of the payload).
> 
> +1. One of the attractive things about MPTCP-based solutions for this
> particular use case, IMO, is that there's a clear path from a two-proxy
> situation (which is what BANANA foresees) to a one-proxy situation (MPTCP
> aware smartphones can use their LTE connection natively, and connect to
> the far-side bonding proxy directly, if they can be so configured), and
> eventually to a zero-proxy situation (when content providers also provide
> multipath services). That pretty much requires that the MPTCP part remain
> end-to-end, while the proxy selection (and any other interproxy
> communication) happen out of that band.
> 
> Cheers,
> 
> Brian