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
<francois.mic...@uclouvain.be <mailto:francois.mic...@uclouvain.be>> 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 : internet-dra...@ietf.org <mailto:internet-dra...@ietf.org>
Pour : François Michel <francois.mic...@uclouvain.be
<mailto:francois.mic...@uclouvain.be>>, Francois Michel
<francois.mic...@uclouvain.be
<mailto:francois.mic...@uclouvain.be>>, Olivier Bonaventure
<olivier.bonavent...@uclouvain.be
<mailto:olivier.bonavent...@uclouvain.be>>, Olivier Bonaventure
<olivier.bonavent...@uclouvain.be
<mailto:olivier.bonavent...@uclouvain.be>>
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
