Re: Fwd: New Version Notification for draft-michel-quic-fec-00.txt

[Samuel Hurst <[e-mail]>]

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