Re: QUIC - Our schedule and scope

[Olivier Bonaventure <[e-mail]>]

Spencer,

> When we were discussing the QUIC charter, I was very reluctant to 
> charter a new transport protocol in 2016 that didn't address multipath 
> (other people have suffered more while adding multipath to a protocol 
> that didn't anticipate multipath than I have, but I've seen enough 
> suffering). That may be the point I pressed on most strongly while 
> editing the current charter. So even though we wanted to minimize the 
> initial charter scope, I included multipath in the charter I took to the 
> IESG.
> 
> I had assumed (without asking anyone) that
> 
>     - Enabling multipath and forward error correction extensions
> 
> (listed as one of the key goals in the current charter) would put 
> "making sure that extensions were possible" in scope for v1.


Having spent many cycles at making sure that Multipath TCP can work and 
be deployed, I confirm that it is important to take multipath into 
account early in the design of a new protocol like QUIC.

Quentin De Coninck has been working on Multipath QUIC and has submitted 
a draft that proposes minimal changes to QUIC v1 to support multipath 
capabilities. This could be a good starting point for the working group 
to ensure that the QUIC v1 design does not get stuck in a state where 
middlebox ossification makes multipath much more difficult than it 
should be.

Name:		draft-deconinck-multipath-quic
Revision:	00
Title:		Multipath Extension for QUIC
Document date:	2017-10-30
Group:		Individual Submission
Pages:		20
URL: 
https://www.ietf.org/internet-drafts/draft-deconinck-multipath-quic-00.txt
Status: 
https://datatracker.ietf.org/doc/draft-deconinck-multipath-quic/
Htmlized: 
https://tools.ietf.org/html/draft-deconinck-multipath-quic-00
Htmlized: 
https://datatracker.ietf.org/doc/html/draft-deconinck-multipath-quic-00


Abstract:
    Multipath TCP has shown how a reliable transport protocol can
    efficiently use multiple paths for a given connection.  We leverage
    the experience gained with Multipath TCP to propose simple extensions
    that enable QUIC to efficiently use multiple paths during the
    lifetime of a QUIC connection.


The draft shows that with small extensions and the ability to encode a 
path identifier in the public header, it is possible to have a Multipath 
QUIC design that is both clean and extensible. Quentin also has an 
implementation of Multipath QUIC as an extension of the QUIC-go 
implementation (thus not totally aligned with QUIC v1). His measurements 
that will appear in a forthcoming paper show that Multipath QUIC 
provides very good performance compared with Multipath TCP.


Best regards,


Olivier Bonaventure

-- 

------------------------------
DISCLAIMER.
This email and any files transmitted with it are confidential and intended 
solely for the use of the individual or entity to whom they are addressed. 
If you have received this email in error please notify the system manager. 
This message contains confidential information and is intended only for the 
individual named. If you are not the named addressee you should not 
disseminate, distribute or copy this e-mail. Please notify the sender 
immediately by e-mail if you have received this e-mail by mistake and 
delete this e-mail from your system. If you are not the intended recipient 
you are notified that disclosing, copying, distributing or taking any 
action in reliance on the contents of this information is strictly 
prohibited.