Subject: Adding Multipath Capabilities to QUIC

From: Quentin De Coninck <[email-masked]>
Date: Tue, 11 Jul 2017 13:54:56 +0200

Hello all,

With the large interest of QUIC and the promises of using multiple paths 
in the network, we have worked on adding Multipath capabilities to QUIC. 
With only a few changes to the QUIC protocol that remain 
backward-compatible with the current (implicit) single-path one, we 
managed to have a fully working prototype on the open-source quic-go 
implementation, including various heuristics relevant to multipath 
protocols such as coupled congestion control. Compared to Multipath TCP, 
the multipath design for QUIC is much simpler and cleaner. Furthermore, 
our first evaluations show that Multipath can be more beneficial to QUIC 
than to TCP.

If you are interested to discuss with us about our design, our 
implementation or our results, we will be present at Prague for both the 
Hackathon and the IETF.

Regards,

-- 

Quentin De Coninck
FNRS Research Fellow - PhD Student
Universite Catholique de Louvain
B – 1348 LOUVAIN-LA-NEUVE (Belgium)

---

From: Erik Kline <[email-masked]>
Date: Tue, 11 Jul 2017 21:18:22 +0900

Sounds fantastic.  Will you be able to write up some brief
description?  I know of some folks who are interested in this but not
currently following the working group developments...

On 11 July 2017 at 20:54, Quentin De Coninck
<[email-masked]> wrote:
> Hello all,
>
> With the large interest of QUIC and the promises of using multiple paths in
> the network, we have worked on adding Multipath capabilities to QUIC. With
> only a few changes to the QUIC protocol that remain backward-compatible with
> the current (implicit) single-path one, we managed to have a fully working
> prototype on the open-source quic-go implementation, including various
> heuristics relevant to multipath protocols such as coupled congestion
> control. Compared to Multipath TCP, the multipath design for QUIC is much
> simpler and cleaner. Furthermore, our first evaluations show that Multipath
> can be more beneficial to QUIC than to TCP.
>

---

From: Ian Swett <[email-masked]>
Date: Tue, 11 Jul 2017 10:45:55 -0400

It's great you chose an approach that's backwards compatible with single
path QUIC.  To clarify, does that mean it doesn't require any framing
changes and multipath looks like multiple single path connections on the
wire?

Agreed I'd be interested in a description, either text or slides.

On Tue, Jul 11, 2017 at 8:18 AM, Erik Kline <[email-masked]> wrote:

> in

---

From: Dmitri Tikhonov <[email-masked]>
Date: Tue, 11 Jul 2017 10:47:28 -0400

> Agreed I'd be interested in a description, either text or slides.

*Throws his hat in:*  Me, too!

  - Dmitri.

---

From: Lucas Pardue <[email-masked]>
Date: Tue, 11 Jul 2017 14:57:45 +0000

> > Agreed I'd be interested in a description, either text or slides.

+1

-----------------------------
http://www.bbc.co.uk
This e-mail (and any attachments) is confidential and
may contain personal views which are not the views of the BBC unless specifically stated.
If you have received it in
error, please delete it from your system.
Do not use, copy or disclose the
information in any way nor act in reliance on it and notify the sender
immediately.
Please note that the BBC monitors e-mails
sent or received.
Further communication will signify your consent to
this.
-----------------------------

---

From: Quentin De Coninck <[email-masked]>
Date: Tue, 11 Jul 2017 18:13:13 +0200

> Agreed I'd be interested in a description, either text or slides.
If the agenda permits, I would be glad to prepare a short presentation 
at Prague highlighting the main points allowing multipath in QUIC.

-- 

Quentin De Coninck