Re: [multipathtcp] Possible future items for mptcp WG

Olivier Bonaventure <> Thu, 14 June 2018 13:39 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A0F50131072 for <>; Thu, 14 Jun 2018 06:39:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.301
X-Spam-Status: No, score=-4.301 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EFFrV14yRGFC for <>; Thu, 14 Jun 2018 06:39:45 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D9735130F1B for <>; Thu, 14 Jun 2018 06:39:44 -0700 (PDT)
Received: from mbpobo.local (unknown []) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: by (Postfix) with ESMTPSA id 9216A67DA3A; Thu, 14 Jun 2018 15:39:34 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple;; s=selucl; t=1528983574; bh=E7yutWvGOTlnnySXnY7HxdZ+gLSmUUTQOj37A5ABF9A=; h=Reply-To:Subject:To:References:From:Date:In-Reply-To:From; b=nqop8BPfEGK2NgK0GCUTrRxMAPjzdqdKHS99K0AkUgU9oZLme0Ngpycsf2qzsH5sZ DJFIDoGy+xdosyLSdXGyVjD1zhdelkQlihsjG4UJBgfCqOMJAnat0/QIlGinVy1B5j wBonqjkHbDJVCPcbTlqAXRlz+NT2aibT8ZeDojnI=
X-Virus-Status: Clean
X-Virus-Scanned: clamav-milter 0.99.3-beta2 at smtp-1
To: Yoshifumi Nishida <>, multipathtcp <>
References: <>
From: Olivier Bonaventure <>
Message-ID: <>
Date: Thu, 14 Jun 2018 15:39:34 +0200
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset="utf-8"; format="flowed"
Content-Language: fr-classic
Content-Transfer-Encoding: 8bit
X-Sgsi-Spamcheck: SASL authenticated,
X-SGSI-MailScanner-ID: 9216A67DA3A.A85AA
X-SGSI-MailScanner: Found to be clean
X-SGSI-Spam-Status: No
Archived-At: <>
Subject: Re: [multipathtcp] Possible future items for mptcp WG
X-Mailman-Version: 2.1.26
Precedence: list
List-Id: Multi-path extensions for TCP <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 14 Jun 2018 13:39:48 -0000

Phil, Yoshifumi,
> Phil and I have been discussing the next step for the WG.
> After we finish 6824bis, we won't have active WG items as the proxy 
> work will be discussed at tcpm WG.
> One suggestion might be to close the WG or to put it in dormant state, 
> however, we are thinking there still might be some more working items as 
> we've seen interesting presentations for new ideas, experiment results 
> and so on at the meetings and on the ML.
> Below is the list of potential working items from the chairs' point of view.
> Please let us know if you think some of them are important items for the 
> WG (and your willingness to contribute if possible) or there are some 
> more items, or this is not something we should work on, etc.

I think that the socket API still makes sense and it would be useful to 
have an agreement on an API that is supported by different 
implementations. At this point, I'm only aware of API efforts on the 
Linux implementation.

Concerning the extensions, I think that it makes sense to reconsider the 
extensions that we have not included in rfc6824bis and evaluate whether 
they could be of benefit for Multipath TCP.

Congestion control is probably a more difficult topic since ICCRG is the 
natural place for work on new congestion control schemes. Maybe we 
should encourage the development of new coupled congestion control schemes.

Another direction that the WG could pursue are the interactions with 
other working groups where Multipath TCP could play a role.

For example, v6ops and spring develop the Segment Routing architecture. 
The IPv6 variant of SR brings a nice framework to allow the 
establishment of Multipath TCP subflows over specific paths. As IPv6 SR 
is available on Linux, it becomes possible to perform experiments and 
think about the interactions between SR and MPTCP.

Another example is happy eyeballs. This technique works with HTTP on 
dual-stack machines. It could also be applied to MPTCP (e.g. with the 
parallel establishment idea)

A third example are the interactions between MPTCP and applications. It 
would be interesting to interact with WG developing application level 
protocols to see how to map them on MPTCP.

A fourth example is IPv6 multihoming. The rtgwg will soon publish a 
recommendation on techniques to support IPv6 multihoming. This document 
mainly assumes that endhosts use single path transport protocols. It 
would be interesting to work with rtgwg to describe the benefits that 
MPTCP could bring in this environment.

Another example is intermittent connectivity. MPTCP can use multiple 
paths simultaneously, but it also supports seamless handovers on mobile. 
On mobiles that have only WiFi connectivity, MPTCP could support 
intermittent connectivity, i.e. connections that start on one AP, then 
move a few seconds, minutes or hours later on another AP. This could 
require to maintain MPTCP connections without an associated subflow for 
a longer period of time that the default used by TCP.

I guess that there are many other possiblities

Best regards,