Fwd: New Version Notification for draft-huitema-quic-mpath-option-00.txt

[Christian Huitema <[e-mail]>]

Since everybody seems intent on discussing Multipath, I just wrote this
short draft that presents a minimalist design for adding Multipath
support to QUIC. Basically, it puts the onus entirely on the sender. The
receiver side would just require support for a couple of management
frames to explicitly abandon or promote a path. The sender will have to
track the relation between packet number and path, possibly manage
ranges of packet numbers, manage the per-path congestion control, update
the packet loss detection to take path delays into account, and of
course chose an algorithm for scheduling packets to paths.

-- Christian Huitema



-------- Forwarded Message --------
Subject: 	New Version Notification for
draft-huitema-quic-mpath-option-00.txt
Date: 	Tue, 20 Oct 2020 23:42:14 -0700
From: 	[e-mail]
To: 	Christian Huitema <[e-mail]>




A new version of I-D, draft-huitema-quic-mpath-option-00.txt
has been successfully submitted by Christian Huitema and posted to the
IETF repository.

Name: draft-huitema-quic-mpath-option
Revision: 00
Title: QUIC Multipath Negotiation Option
Document date: 2020-10-20
Group: Individual Submission
Pages: 8
URL: https://www.ietf.org/archive/id/draft-huitema-quic-mpath-option-00.txt
Status: https://datatracker.ietf.org/doc/draft-huitema-quic-mpath-option/
Htmlized:
https://datatracker.ietf.org/doc/html/draft-huitema-quic-mpath-option
Htmlized: https://tools.ietf.org/html/draft-huitema-quic-mpath-option-00


Abstract:
The initial version of QUIC provides support for path migration. In
this draft, we argue that there is a very small distance between
supporting path migration and supporting simulatneous traffic on
multipath. Instead of using an implicit algorithm to discard unused
paths, we propose a simple option to allow explicit management of
active and inactive paths. Once paths are explicitly managed, pretty
much all other requirements for multipath support can be met by
appropriate algorithms for scheduling transmissions on specific
paths. These algorithms can be implemented on the sender side, and
do not require specific extensions, except maybe a measurement of one
way delays.



Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat