Re: [multipathtcp] Towards a Multipath TCP Proxy work item

Alan Ford <> Mon, 14 November 2016 06:11 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A7532129674 for <>; Sun, 13 Nov 2016 22:11:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.989
X-Spam-Status: No, score=-1.989 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 1Sux8XGDjI5R for <>; Sun, 13 Nov 2016 22:11:27 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c00::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 93D3D129622 for <>; Sun, 13 Nov 2016 22:11:27 -0800 (PST)
Received: by with SMTP id 189so27583846pfz.3 for <>; Sun, 13 Nov 2016 22:11:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:subject:from:in-reply-to:date:cc:message-id:references :to; bh=2YpSw5GYgi8NkcJULrP9rpfEzCj4JVkCv9YdK93L7oo=; b=V6uSR/vzngddOR0TsKjxuxOx8aFGNMKBpt1etH4irigH0eIj8bohrNNsf0xtpIwBct PbX8H50aCyKd6yCdxCC/L8kgYZTlpsRVFMmTB6j2jP8p4U5sCHGyoetza0ekxd9qqG2q iZrj+y92vWAkGrd6XVEFkfo+q2g6i+NogCNj0ddesSkIF2P+u309Gr1I3j8y+Gc6VoM8 4gHw5NbTuzIB7w0LhGgM3eJc+47MtGGXAXfR4BQhuOJ8kA9OyhoGRG2pL/OhZQH02CqF gouCa7DhZI4i+Mha0yQ+qsiOue2/Zkx3erQcUIZt9Jgy4M9Zr9zVHBLrvVmecK/C5dCR 3okg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :message-id:references:to; bh=2YpSw5GYgi8NkcJULrP9rpfEzCj4JVkCv9YdK93L7oo=; b=K9F6H9zRoJs6Qkn1tm2fT6s3F2MzIeXSUxylvBsPS7pfHy0m+fPuZGzuBAE9pUYGjP EiTVV0rXTXcFf01s7XLejziOjIuI6fBmNHs49tVtIoxRWhDKD2/tneGgTRnU60NO8ZjS G5fkWoLynys6OHEIxM5FW+fg/LL7Vij6a5wJaRDc3CBIFbtdPN/SKsqekpuCzrSGotbo 2+cranOTFeeXpbifPCOxFecbh6/TrmaomNB2Z2+Ze34RVot9WAaZplXi/JbyTu+tnq90 mPx1/3Z64eACwhBjXED/c5uiknrRFYMAIIGAWaqUBEXZiIAmrwQh6hRu+6koaHuUATQV FmwA==
X-Gm-Message-State: ABUngvdDF2MKx9wrS2sWmgDQqVcGwGMfOsPgXQf6oqer/5WVmPoC5VGdNKdgNGo+laEHHw==
X-Received: by with SMTP id n15mr64054444pgc.7.1479103887158; Sun, 13 Nov 2016 22:11:27 -0800 (PST)
Received: from ( []) by with ESMTPSA id 89sm26923371pfi.70.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Sun, 13 Nov 2016 22:11:26 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_1DBFA266-6E22-47DE-A3E6-31FE097E73E2"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Alan Ford <>
In-Reply-To: <>
Date: Mon, 14 Nov 2016 06:11:22 +0000
Message-Id: <>
References: <>
X-Mailer: Apple Mail (2.3124)
Archived-At: <>
Subject: Re: [multipathtcp] Towards a Multipath TCP Proxy work item
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Multi-path extensions for TCP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 14 Nov 2016 06:11:30 -0000

I think this work item is achievable by simply removing references to “at least one end” from the existing charter item on the proxy. So the item would now read:

Finally, the working group will explore whether an MPTCP-aware
middlebox would be useful. For example, potentially helping MPTCP’s 
incremental deployment by allowing only one end host to be MPTCP-enabled 
and the middlebox acts as an MPTCP proxy for the other end host, which runs 
TCP; and potentially helping some mobility scenarios, where the middle box 
acts as an anchor between two MPTCP-enabled hosts. Alternatively, neither 
end host could be MPTCP-enabled but a pair of proxies could work together to 
bring MPTCP benefits to such connections. The working group will detail what real
problems an MPTCP-enabled middlebox might solve, how it would impact the
Multipath TCP architecture (RFC6182), what proxy approach might be
justified as compared against alternative solutions to the problems, and
the likely feasibility of solving the technical and security issues.

In some ways, the two ended proxy work could even be seen as an extension of the previous operational experience work within this WG.


> On 10 Nov 2016, at 19:17, wrote:
> Hi,
> Perhaps this is speaking too soon, but it looks like the very active discussion is reaching some common understanding?
> We’re trying to work out what a work item might look like, so would like to understand what assumptions we would make, eg about the scenario, & what common agreements we’d assume & restrictions on how the solution works. This seems important to frame work by WG. If possible we’d like discussion on these points to avoid getting into the fine details of one particular existing proposal.
> What we’d appreciate is a summary of what the assumptions /understandings are about:
> ·         The scenario (for instance: the MPTCP-enabled host knows the address of the proxy (eg through configuration); and it knows the address of the ‘legacy’ host it wants to communicate with)
> ·         If any impact is already envisaged on the current MPTCP protocol’s fallback behaviour and coping with middleboxes
> ·         If we can agree that the solution is based on a new MPTCP option
> ·         If any impact is already envisaged on the current MPTCP protocol’s semantics (other than the new option) eg in terms of <>  
> ·         If any impact is already envisaged on TCP’s semantics, or any mods are needed, or assumptions about its behaviour, etc
> ·         If any impact is already envisaged on other existing transport protocol’s semantics (presuming people still would like non-TCP in scope?)
> ·         Anything else that you think is needed in order to frame the work item
> It may be clearer to do this for the two use cases (single-ended proxy, ie where only one host is MPTCP-enabled; and double-ended proxy, ie where neither host is MPTCP-enabled).
> This may seem like a long list, but most of the answers can be “none” – we’ll end up with just a short paragraph or a few bullets in the charter.
> We’d also have to work out interactions with non-MPTCP WGs, but Mirja and IESG will probably want the main input on this.
> Thanks
> Phil & Yoshi
> _______________________________________________
> multipathtcp mailing list
> <>
> <>