Hi,
I'm glad to finally see some interesting discussion about some multipath
proposals :-)
As one of the authors of the draft-deconinck-quic-multipath, I would
like to discuss a little about the design differences between both
drafts, which I currently understand to be small. Basically, all the
basic design points you list are also valid for
draft-deconinck-quic-multipath (reuse of QUICv1 mechanisms, unmodified
header, PSN per path,...), except that we associate a separate "Uniflow
ID" (which identifies the path) to a Connection ID . That is, we do not
directly use the sequence number of the CID as the path identifier.
You propose to use the Connection IDs to identify the path in each
direction. Its sequence number determines the Path ID. I see that in
your Figure 1, you propose an example where you start a new "path" by
using the sequence number 2 towards the server and the sequence number 1
towards the client. So your proposal does not require to use the same
path ID over a same network path, am I right?
In your same example, you state that the client must check that are
unused available connection IDs at both sides before starting a new
path. So if the client wants to reach the server over a new network path
but the server does not start using a new path ID, what happens? Is the
client unable to send data over it? It also seems odd to create a
(bidirectional?) "path" with different identifiers at both sides.
For the scheduling section, I wonder what is really specific to
Multipath QUIC. For me, many of the proposed schemes are applicable to
any multipath transport protocol (like MPTCP). Why not discussing them
in a document like draft-bonaventure-iccrg-schedulers-01? Also, why is
the per-stream policy multipath specific?
I wonder why there is a MUST enforcing the ACK frame to return on the
same path. Couldn't the ACK frame just refer to a specific, well-known
path ID? For the remaining, the ACK_MP frame is identical to the MP_ACK
frame.
Regarding the section discussing the differences with our draft:
1- Your draft states that your extension builds on the concept of
bidirectional paths. But I see nothing in your description preventing a
host from using only the initial path while receiving data on the other
path. For instance, a server could receive data on two different paths
but send all its data (including ACK_MP, PATH_RESPONSE,...) over the
initial path, which is quite a unidirectional (or at least asymmetrical)
usage of the second path.
2- I'm not sure to understand the difference here regarding
"feedback-based dynamic scheduling strategy" using "ACK packet". Could
you elaborate a bit more on this?
Again, thanks for bringing this to this list. I would be glad if we
could at some point merge our both drafts into a single one and I am
willing to contribute to this effort :-)
Best,
Quentin
Hi all,
Here is an updated version of the draft which was posted in the
mailing list last Friday. Please check this link:
https://tools.ietf.org/html/draft-liu-multipath-quic-01
<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-liu-multipath-quic-01&data=04%7C01%7Cquentin.deconinck%40uclouvain.be%7C281d8515dee042881e9e08d89ff77c50%7C7ab090d4fa2e4ecfbc7c4127b4d582ec%7C0%7C0%7C637435233091447064%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=PNExv4lCxGy5uVoMRc1g8X52IZBMpjEk7NOx%2FWF55mk%3D&reserved=0>
Regarding the questions in the mailing list for the previous version:
1. We have fixed the IANA registry problem in the new version. Thanks
Lucas for pointing out this problem.
2. We currently use Github for editing, and we prefer discussions on
the mailing list, so we removed the Github link in this draft.
This version merges our draft and Christian’s draft, and here are some
of the key features:
* Re-use as much as possible mechanisms of QUIC-v1, which has
supported connection migration and path validation.
* To avoid the risk of packets being dropped by middleboxes (which
may only support QUIC-v1), use the same packet header formats as
QUIC V1.
* Endpoints need a Path Identifier for each different path which is
used to track states of packets. As we want to keep the packet
header formats unchanged [QUIC-TRANSPORT], Connection IDs (and the
sequence number of Connection IDs) would be a good choice of Path
Identifier.
* For the convenience of packet loss detection and recovery,
endpoints use a different packet number space for each Path
Identifier.
* Congestion Control, RTT measurements and PMTU discovery should be
per-path (following [QUIC-TRANSPORT])
Thanks Jana and Kazuho for reviewing the proposal.
We would like to know how people think about the draft, and all
feedbacks and suggestions are welcome!
Thanks,
Yanmei
------------------------------------------------------------------
From: internet-drafts <[email protected]>
Date: 2020年12月14日(星期一) 12:36
To：安勍(莳逸) <[email protected]>; "Ma, Yunfei"
<[email protected]>; 刘彦梅(喵吉)
<[email protected]>; Christian Huitema
<[email protected]>; 李振宇 <[email protected]>
Subject: New Version Notification for draft-liu-multipath-quic-01.txt
A new version of I-D, draft-liu-multipath-quic-01.txt
has been successfully submitted by Yanmei Liu and posted to the
IETF repository.
Name: draft-liu-multipath-quic
Revision: 01
Title: Multipath Extension for QUIC
Document date: 2020-12-14
Group: Individual Submission
Pages: 18
URL:
https://www.ietf.org/archive/id/draft-liu-multipath-quic-01.txt
<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Farchive%2Fid%2Fdraft-liu-multipath-quic-01.txt&data=04%7C01%7Cquentin.deconinck%40uclouvain.be%7C281d8515dee042881e9e08d89ff77c50%7C7ab090d4fa2e4ecfbc7c4127b4d582ec%7C0%7C0%7C637435233091457023%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=qr8JPusFk9FKI26mNbYTtde1t4G1zyQSEibBqTbMIG0%3D&reserved=0>
Status: https://datatracker.ietf.org/doc/draft-liu-multipath-quic/
<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fdraft-liu-multipath-quic%2F&data=04%7C01%7Cquentin.deconinck%40uclouvain.be%7C281d8515dee042881e9e08d89ff77c50%7C7ab090d4fa2e4ecfbc7c4127b4d582ec%7C0%7C0%7C637435233091457023%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=2lNP%2BDxp3qlRncBcf6IPvoSUHx5cs7N7BqUkaMarQ5k%3D&reserved=0>
Htmlized:
https://datatracker.ietf.org/doc/html/draft-liu-multipath-quic
<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdatatracker.ietf.org%2Fdoc%2Fhtml%2Fdraft-liu-multipath-quic&data=04%7C01%7Cquentin.deconinck%40uclouvain.be%7C281d8515dee042881e9e08d89ff77c50%7C7ab090d4fa2e4ecfbc7c4127b4d582ec%7C0%7C0%7C637435233091466978%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=uBBdwodffWgFbeR7e6PESxrSkxPT9pu4tYwyPdx16A4%3D&reserved=0>
Htmlized: https://tools.ietf.org/html/draft-liu-multipath-quic-01
<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-liu-multipath-quic-01&data=04%7C01%7Cquentin.deconinck%40uclouvain.be%7C281d8515dee042881e9e08d89ff77c50%7C7ab090d4fa2e4ecfbc7c4127b4d582ec%7C0%7C0%7C637435233091466978%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=0F1QrItnLruPTm4cRISETmA4pn0F0ygPqqmGWr9NLtk%3D&reserved=0>
Diff:
https://www.ietf.org/rfcdiff?url2=draft-liu-multipath-quic-01
<https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Frfcdiff%3Furl2%3Ddraft-liu-multipath-quic-01&data=04%7C01%7Cquentin.deconinck%40uclouvain.be%7C281d8515dee042881e9e08d89ff77c50%7C7ab090d4fa2e4ecfbc7c4127b4d582ec%7C0%7C0%7C637435233091466978%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=WBUZ%2Fm9vYpzuQ1a57XhKVlF8gdpYMXl02PiTDXmXpZ8%3D&reserved=0>
Abstract:
This document specifies multipath extension for the QUIC protocol to
enable the simultaneous usage of multiple paths for a single
connection. The extension is compliant with the single-path QUIC
design. The design principle is to support multipath by adding
limited extension to [QUIC-TRANSPORT].
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
