And in nwcrg we had tried to avoid physical layer terms - I know channel is still there but we are more talking about a “link”.
It’s nits. Marie-José Montpetit, Ph.D. [email protected] From: François Michel <[email protected]> <[email protected]> Reply: François Michel <[email protected]> <[email protected]> Date: November 4, 2022 at 4:39:22 AM To: Nicolas Kuhn <[email protected]> <[email protected]> Cc: [email protected] <[email protected]> <[email protected]>, Olivier Bonaventure <[email protected]> <[email protected]>, Marie-Jose Montpetit <[email protected]> <[email protected]>, [email protected] <[email protected]> <[email protected]>, Samuel Hurst <[email protected]> <[email protected]> Subject: Re: New Version Notification for draft-michel-quic-fec-00.txt Hi Nico, On 26/10/22 10:04, Nicolas Kuhn wrote: > Dear François, all, > > Thank you for this document. This is very important for the > lossy-GEO-satellite scenario, so thank you! > > I have some questions/comments on the document : > - Taxonomy : you may want to refer to RFC8406 on the taxonomy related to > coding > - On the coding channel : > "A coding channel can be seen as a > communication channel between a QUIC receiver and a FEC decoder." > => This is in contradiction with the notion proposed in RFC 9265. > I think that the coding channel should be seen between the FEC-coder > and the FEC-decoder. True, I should avoid those ambiguities. :-) > - The notion of APP_DATA in Figure 1 is not clear to me. IMHO the > presentation on this should be improved. I've put APP_DATA to represent any data sent by applications transiting through streams or datagrams. We sould find a way to make it easy to understand that the APP_DATA are part of the source symbols. > - On DATAGRAMS : I agree that if a solution can also protect DATAGRAMS, > this could help in lossy scenarios > - "In this document, > we propose to consider whole frames as part of the source symbols." > => This is important and should be highlighted in the document. It > may be worth expliciting what is meant by "whole frames" and maybe > provide examples. > - Alternative 1 vs Alternative 2 : alternative 2 has an impact on the > QUIC packet scheduler. For this reason, I am not sure whether it is > relevant. (+Sam that might be interested as we had similar discussions on another mail loop) I also prefer a bit the concepts behind Alternative 1 but it may seem harder to implement than Alternative 2 and introduces the concept of wrapped frames that may be puzzling too. I guess time and implementations may tell us which alternative is the best with running code. > > I hope this helps, This helps ! Thank you for your comments. Franz > Kind regards, > > Nicolas > > On Fri, Oct 21, 2022 at 2:50 PM François Michel > <[email protected] <mailto:[email protected]>> wrote: > > Dear all, > > Here is a draft discussing the addition of Forward Erasure > Correction to > QUIC. > > We wrote this draft to discuss FEC in QUIC and experiment with people. > It is inspired by our previous work at the nwcrg. We also have > interesting real-network results that we would be happy to show to > motivate the interest for this extension. > > The design is at an early stage and is intended to evolve. Do not > hesitate to provide us with comments on the document or the > extension in > general. > > Regards, > > François > > > -------- Message transféré -------- > Sujet : New Version Notification for draft-michel-quic-fec-00.txt > Date : Fri, 21 Oct 2022 05:11:22 -0700 > De : [email protected] <mailto:[email protected]> > Pour : François Michel <[email protected] > <mailto:[email protected]>>, Francois Michel > <[email protected] > <mailto:[email protected]>>, Olivier Bonaventure > <[email protected] > <mailto:[email protected]>>, Olivier Bonaventure > <[email protected] > <mailto:[email protected]>> > > > A new version of I-D, draft-michel-quic-fec-00.txt > has been successfully submitted by François Michel and posted to the > IETF repository. > > Name: draft-michel-quic-fec > Revision: 00 > Title: Forward Erasure Correction for QUIC loss recovery > Document date: 2022-10-21 > Group: Individual Submission > Pages: 14 > URL: https://www.ietf.org/archive/id/draft-michel-quic-fec-00.txt > <https://www.ietf.org/archive/id/draft-michel-quic-fec-00.txt>> Status: https://datatracker.ietf.org/doc/draft-michel-quic-fec > <https://datatracker.ietf.org/doc/draft-michel-quic-fec>> Html: > https://www.ietf.org/archive/id/draft-michel-quic-fec-00.html > <https://www.ietf.org/archive/id/draft-michel-quic-fec-00.html>> Htmlized: > https://datatracker.ietf.org/doc/html/draft-michel-quic-fec > <https://datatracker.ietf.org/doc/html/draft-michel-quic-fec>> > Abstract: > This documents lays down the QUIC protocol design considerations > needed for QUIC to apply Forward Erasure Correction on the data > sent > through the network. > > > > > The IETF Secretariat > >
