Discussing recovery: Forward Erasure Correction, negative acknowledgments and data expiration

[louisna]

Hello!

Here is some text about the recovery mechanism of Multicast QUIC. This is based on the Arxiv paper. It discusses:

• Adding Forward Erasure Correction as an efficient recovery mechanism on the multicast path
• Negative acknowledgment from the receivers whenever they see a gap in the received packet number sequence
• Data expiration upon which the source must not retransmit data, enabling continued transmission even in the presence of a bottleneck client.

The text is just here to trigger discussion, and to converge into something that can fit in the draft.

[MaxF12]

Thanks for this PR as well. I think the part about FEC is great and can go into the draft as is or with minor changes. I don't think the expiration timer and mechanic are necessary as that can still happen with regular QUIC, it's also already noted in the security considerations of RFC9000 (21.7). It's probably fine to not have this mechanic in the standard as it just makes things more complicated and servers can just decide that a client is malicious and top it.

As for the NACKs, I personally still think the overhead created by (bundled) ACKs is an acceptable trade off if it allows the server to more quickly react to issues on a multicast channel. Maybe that's also something we can discuss with the WG(s) to get some other opinions on as well though.

[louisna]

It can be made more implicit, but the "expiration timer" concept will at some point be used to consider if a client should leave the multicast channel if it cannot receive all data quickly enough.

I can remove this part for this PR and focus on FEC only so that it can be merged, and start another one later for the data expiration.

[louisna]

Updated the text to keep only FEC-related information