On 25/10/2022 16:53, François Michel wrote:
On 21/10/2022 17:55, Samuel Hurst wrote:
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.
Certainly, feel free to put them in contact with me privately if you wish.
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.
Even if you don't get chance to present, I will be in London so I'd be
happy to meet up between sessions and talk about it if needs be.
* 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.
I understand where you're coming from. However, have you considered
profiling QUIC in such a way that you could prevent the sender from
using the full MTU on every source packet in order to keep the size
compatible?
Along those lines, maybe profiling it so that your protection mechanism
by design does not cover all frame types, and frames like ACK and
PADDING that you're not interested in are excluded, rather than having
to use wrapping frames?
Best regards,
-Sam
