The transport layer is one of the key layers of the Internet protocol stack. It enrichs the network layer service to make it suitable for applications. Almost 40 years after its initial design, TCP remains the most widely used transport protocol. In the early 2000s, SCTP was proposed as an alternative to TCP. Despite a clean and extensible design and many useful features, it did not reach wide deployment. This failure is mainly caused by middleboxes. We’ll describe their operation and explain why Multipath TCP, which is a backward compatible evolution to TCP, has better chances of being deployed. We’ll explain the main principles behind Multipath TCP and the lessons that can be drawn from its design. We’ll then analyse why Internet giants like Google and Microsoft now consider application-layer solutions like QUIC to replace standard protocols like TCP

Olivier Bonaventure. Keynote. October 2015 CNSM.

Quentin De Coninck, Matthieu Baerts, Benjamin Hesmans, Olivier Bonaventure. Poster. September 2015 Mobicom.

Different articles in Korea show the impact that MPTCP deployment is havin in this country.

“Domestically (In Korea), MPTCP which is technology can utilize LTE and WiFi was commercialized. These services are future network technology which improves network speed by combining LTE and WiFi. The service names are ‘GiGA LTE’, ‘Band LTE WiFi’ and ‘GiGA multipath’ at KT, SKT and LG U+ respectively and these services are based on the same technology.”
Source ETNEWS.com

“Evolution of network speed = Domestically, in last June, MPTCP which is similar with LWA was commercialized. This is future network technology which can improve network speed (capacity) by combining LTE and WiFi.
Domestically(In Korea), this service is called ‘GiGA LTE’ at KT. SKT and LG U+ use brand names ‘Band LTE WiFi’ and ‘GiGA multipath’ respectively.”
Source NEXTDAILY

Abstract and paper link will be available soon

Viet-Hoang Tran, Quentin De Coninck, Benjamin Hesmans, Ramin Sadre, Olivier Bonaventure. 2016. Elsevier Computer Communications

Abstract and paper link will be available soon

Quentin De Coninck, Matthieu Baerts, Benjamin Hesmans, Olivier Bonaventure. March 2016. Communications Magazine: Network Testing Series

This document describes an abstract mechanism by which senders inform the network about the congestion recently encountered by packets in the same flow. Today, network elements at any layer may signal congestion to the receiver by dropping packets or by Explicit Congestion Notification (ECN) markings, and the receiver passes this information back to the sender in transport-layer feedback. The mechanism described here enables the sender to also relay this congestion information back into the network in-band at the IP layer, such that the total amount of congestion from all elements on the path is revealed to all IP elements along the path, where it could, for example, be used to provide input to traffic management. This mechanism is called Congestion Exposure, or ConEx. The companion document, “Congestion Exposure (ConEx) Concepts and Use Cases” (RFC 6789), provides the entry point to the set of ConEx documentation.

M. Mathis (Google, Inc.), B. Briscoe (BT). Internet Engineering Task Force (IETF). Request for Comments 7713. December 2015

In Trilogy 2, the target standardization forum has been the IETF/IRTF.

For this reason the standardization workshop was organized as a special interim session of the IRTF Network Functions Virtualization Research Group (NFVRG) as we deemed the best in scope for disseminating the activities of Trilogy2. The workshop has been organized by NEC with the collaboration of Telefonica I+D at the NEC Laboratories Europe premises in Heidelberg, Germany, with the objective of disseminating Trilogy2 ideas and foster their adoption into a wider community.

More information can be obtained here (slides, agenda, etc.)

Multipath TCP was designed and implemented as a backward compatible replacement for TCP. For this reason, it exposes the standard socket API to the applications that cannot control the utilisation of the different paths. This is a key feature for applications that are unaware of the multipath nature of the network. On the contrary, this is a limitation for applications that could benefit from specific knowledge to use multiple paths in a way that fits their needs. As the specific knowledge of an application can not be known in advance, we propose a Multipath TCP path manager that delegates the management of the paths to the applications. This path manager enables applications to control how the different paths are used to transfer data. We implement
this path manager above the Linux Multipath TCP kernel. It is composed of a kernel part that exposes events and commands to an userspace application that controls the key functions of Multipath TCP such as the creation/suppression of subflows or reactions to retransmissions. We demonstrate the benefits of this path manager on different use cases.

Benjamin Hesmans (UCLouvain) Gregory Detal (Tessares) Sebastien Barre (Tessares) Raphael Bauduin (UCLouvain) Olivier Bonaventure (UCLouvain). ACM CONEXT’15 (International Conference on emerging Networking EXperiments and Technologies). December 1-4 2015.

Selected for the IRTF ARNP award 2016 and will be presented at one of the IETF meetings in 2016