Hello Francois,
On 21/10/2022 13:49, François Michel wrote:
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.
Thanks very much for publishing and sharing your draft with the group.
The use of FEC with QUIC is of interest to me and I have previously
looked at the applicability of AL-FEC to our Multicast QUIC draft [1].
We also have interesting real-network results that we would be happy to show to
motivate the interest for this extension.
I for one would be very interested in your results.
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.
I've given your draft a quick read through this afternoon and I have a
few bits of feedback:
* I'm not entirely convinced that being able to protect only part of a
QUIC packet is that useful, as I worry that while you might be able to
repair the protected contents, how do you know what else was in a
packet? You're still going to have to get a retransmission of the whole
packet, which increases network load. I personally think it would be
more helpful to be able to prevent the emission of a packet if the whole
thing can be recovered using FEC.
* In section 5.2, you correctly identify that QUIC packet numbers may
not necessarily increase contiguously, but have you considered perhaps
writing your extension in such a way that your profile of QUIC transport
requires that senders increase packet numbers contiguously so that you
don't need yet another packet identifier?
* Also in section 5.2, you talk about carrying the symbol ID in a frame
or a dedicated header field, then specify that the latter is
incompatible with QUICv1 and that it is not discussed further in this
document. This then tripped me up when I read the following two
alternatives, mistakenly believing that the second one was incompatible.
I believe that removing the reference to the header field option if
you're not otherwise going to describe it would aid comprehension.
* Have you considered referencing and using the IETF FECFRAME from
RFC6363? It might help when it comes to adopting existing FEC mechanisms
into QUIC, such as using the RMT FEC Encoding IDs as the basis for your
identifier in the decoder_fec_scheme transport parameter.
The draft is a great start, and I look forward to seeing where it goes next.
Best regards,
-Sam
--
[1]: https://www.ietf.org/archive/id/draft-pardue-quic-http-mcast-11.html
