Dear Quentin, Thanks so much for your comments. Indeed, we are looking forward to further collaboration. For the time being, the most critical thing is to get as much experimental experience as possible. We would love to talk in further detail with you and Oliver.
Cheers, Yunfei On Tue, Dec 15, 2020 at 3:47 AM Quentin De Coninck < [email protected]> wrote: > 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]> > <[email protected]> > Date: 2020年12月14日(星期一) 12:36 > > To：安勍(莳逸) <[email protected]> <[email protected]>; "Ma, > Yunfei" <[email protected]> <[email protected]>; 刘彦梅(喵吉) > <[email protected]> <[email protected]>; Christian Huitema > <[email protected]> <[email protected]>; 李振宇 <[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 > > >
