Hello,
On 28/10/22 17:47, Samuel Hurst wrote:
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.
We should definitely meet. I'll be there the whole week with my
colleague.
* 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?
Yes, I try to do so for every sent packet that is protected by FEC so
that REPAIR frames fit one packet. :-)
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?
In fact, I was doing exactly this during the previous iterations of the
design. I stopped doing so as using the wrapping frame looked more
flexible, but it might also be more complicated, so we could stick to
deciding in advance what frames are protected instead of the wrapped
design.
Another view could also be the SID frame proposed in Section 5.2.2.
The drawback is that it is not idempotent while every other QUIC frame is.
I am not totally sure which way is the best right now. My intuition is that
whatever alternative we choose, the actual implementation code will be
nearly the exact same as the wire format is the exact same (you can
implement the SOURCE_SYMBOL frame without having actual wrapped structures
in your code).
I also think FEC could benefit from the multiple packet number spaces
brought by the multipath extension if we want to use the packet numbers
as symbol IDs.
Really looking forward to seeing you in London !
Regards,
François
Best regards,
-Sam
