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

[François Michel <[e-mail]>]

Hello Sam,

Sorry for the delay, I was quite busy with IMC2022 until now.

On 21/10/2022 17:55, Samuel Hurst wrote:
> 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].

Thank you very much ! Multicast is also a scenario we would like to
consider on our side. There are people working on multicast protocols in
our lab that you might be interested to discuss with.

>> 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.

I might (or might not) have the time to present it as time permits in 
London.

> 
>> 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:

Thank you !

> 
> * 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.

I was especially thinking of avoiding to protect information that is
already sent redundantly. By that, I especially mean ACK frames that are
regularly sent or MAX_DATA frames that may be sent in
successive packets when needed. The only advantage of this approach is to
be able to protect a MTU-sized packet. Repair symbols are often larger than
source symbols as they can contain additional metadata (e.g. the number of
source symbols they protect). If one wants to protect MTU-sized packets,
the REPAIR frame might not fit inside a single packet due to these
that could make the frame grow larger than the MTU metadata. If we strip
away the ACK frames we might be able to send MTU-sized packets, protect
only the "valuable" parts and send REPAIR frames that fit in a single
packet.

> 
> * 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?

Yes, this was part of the solution at some point. I am still not sure about
what solution is the best. The thing is that if we do use the packet number
as the symbol ID (and then force to increase the pn contiguously), then we
consider each packet as being a source symbol. If your only latency-
sensitive packets are the packets containing e.g. DATAGRAM frames, this 
means
that you still need to receive all the other packets to recover from losses,
and the recovery process might be more difficult.
But we could try to implement the idea and benchmark, similarly to what has
been done with the packet number spaces for MPQUIC.

> 
> * 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.

I agree, I think it can disappear from the draft for the next version.
> 
> * 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.

Yes, totally. The design in this document is inspired from FECFRAME
(RFC6363 & RFC8680) and leverages its concepts. The idea would be to
define a whole set of IDs that would represent FECFRAME designs (e.g.
RFC 6865 for Reed Solomon or draft-irtf-nwcrg-tetrys, both patent-free)
so that we could use existing (en|de)coders.


> 
> The draft is a great start, and I look forward to seeing where it goes 
> next.

Thank you, for all your thoughtful comments ! We are totally open to
comments and contributions of any kind (design, implementations,
experimenting on diverse use-cases, and so on).

Regards,

François

> 
> Best regards,
> -Sam
> -- 
> 
> [1]: 
> https://www.ietf.org/archive/id/draft-pardue-quic-http-mcast-11.html>