What To Do With Multiple Active Paths in QUIC

Document Type Expired Internet-Draft (individual)
Author Spencer Dawkins 
Last updated 2021-07-10 (latest revision 2021-01-06)
Stream (None)
Intended RFC status (None)
Expired & archived
plain text xml htmlized pdfized bibtex
Stream Stream state (No stream defined)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state Expired
Telechat date
Responsible AD (None)
Send notices to (None)

This Internet-Draft is no longer active. A copy of the expired Internet-Draft can be found at


The IETF QUIC working group has been chartered to produce extensions that would "enable ... multipath capabilities" since the working group was formed in 2016, but because multipath was an extension, work on multipath, and the other extensions named in the charter, waited while work proceeded on the core QUIC protocol specifications. After the QUIC working group chairs requested publication for the core QUIC protocol specifications, they scheduled a virtual interim meeting to understand the use cases that various groups inside and outside the IETF were envisioning for multipath with QUIC. As part of that discussion, it became obvious that people had a variety of ideas about how multiple paths would be used, because they weren't looking at the same use cases. This document is intended to capture that variety of ideas, to inform further discussion in the working group.


Spencer Dawkins (spencerdawkins.ietf@gmail.com)

(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)