[multipathtcp] MPTCP proxies, and the BANANA BoF

Brian Trammell <ietf@trammell.ch> Fri, 04 November 2016 13:27 UTC

Return-Path: <ietf@trammell.ch>
X-Original-To: multipathtcp@ietfa.amsl.com
Delivered-To: multipathtcp@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id A4E481294FF for <multipathtcp@ietfa.amsl.com>; Fri, 4 Nov 2016 06:27:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.399
X-Spam-Status: No, score=-3.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.497, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id fZ0OFVkaKazE for <multipathtcp@ietfa.amsl.com>; Fri, 4 Nov 2016 06:27:24 -0700 (PDT)
Received: from trammell.ch (trammell.ch []) by ietfa.amsl.com (Postfix) with ESMTP id 02206129401 for <multipathtcp@ietf.org>; Fri, 4 Nov 2016 06:27:20 -0700 (PDT)
Received: from [] (dynamic-94-247-222-033.catv.glattnet.ch []) by trammell.ch (Postfix) with ESMTPSA id 3AF7F1A112C for <multipathtcp@ietf.org>; Fri, 4 Nov 2016 14:27:18 +0100 (CET)
From: Brian Trammell <ietf@trammell.ch>
X-Pgp-Agent: GPGMail
Content-Type: multipart/signed; boundary="Apple-Mail=_5686C1B8-AA80-4C63-A1ED-2805136C63B5"; protocol="application/pgp-signature"; micalg="pgp-sha512"
Date: Fri, 04 Nov 2016 14:27:17 +0100
Message-Id: <8741F579-D97F-4325-81A0-CA6FF40FA2D9@trammell.ch>
To: multipathtcp@ietf.org
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
Archived-At: <https://mailarchive.ietf.org/arch/msg/multipathtcp/BGW8iKb4q21RXYPVxRGaPXbQQDs>
Subject: [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 13:27:25 -0000

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.