some stuff on burst length and starlink in the attached ---------- Forwarded message --------- From: François Michel Date: Mon, Nov 7, 2022 at 8:59 AM Subject: Follow-up of QUIC-FEC discussion at IETF115 To: Cc: Christian Huitema , , < gorry@erg.abdn.ac.uk>, , , Olivier Bonaventure , Marie-Jose Montpetit < marie@mjmontpetit.com> Hi all, Thank you for all the feedback during the presentation. Let's continue the discussion here. I'll address some questions here that I did not have the time to address during the presentation. Christian & Yunfei asked for insight on the bursts lengths that were experienced. In fact it was in my backup slide that you can find in the WG material but the time was too short to mention it. :-( In short, we did our experiments on our Starlink access point that we studied in a recent IMC paper, https://dl.acm.org/doi/abs/10.1145/3517745.3561416. The bursts can be quite long in high percentiles and those long bursts are indeed hard to recover using FEC. The medium-sized ones are recoverable and we did so with our recent implem on quiche. I would say that an important factor is the number of packets you have remaining in your cwin as it defines the length of the bursts you'll be able to recover in one flight. There were also comments advising for doing "opportunistic" retransmissions, i.e. retransmitting in advance the last flight of packets. This is indeed a way to do Forward Erasure Correction without network coding. The FEC extension for QUIC allows doing so in a network- efficient manner. For instance, to recover from the loss of 3 packets, we only need to send 3 REPAIR frames while we need to duplicate the whole cwin with opportunistic retransmissions. It does not work either if both a packet and its opportunistic retransmission are lost. There is a large bandwidth gain in doing FEC with network coding instead of opportunistic retransmissions, at the cost of implementing FEC algorithms of course. Taken from the meeting notes: "Gorry: Very little about congestion control here. Are you going there?" Yes, the idea is to be conservative regarding the CC: we consider that a lost packet is a lost packet, regardless of the fact that is has been recovered through FEC or not. This is discussed Section 6 of the draft. We don't want to hide any congestion signal to the CC. REPAIR frames are congestion-controlled, meaning that none will be sent if the sender is cwin-blocked. This is what our implementation already does. We thus follow the principles of RFC9265. Finally, there is the discussion about protecting QUIC frames VS stream content only. We discussed it at nwcrg at the time and decided to protect frames. This document follows the same idea. By doing so, FEC can protect several streams. It also makes possible to protect several kinds of frames such as DATAGRAM frames and others that might have an interest in being received rapidly. DATAGRAM frames are indeed sent unreliably but I think there is still value for it to be received with a higher chance thanks to FEC. Datagrams may be used by an application especially because the data they contain are time-sensitive and have no interest in being retransmitted, so protecting them with FEC might help in this case. That being said, we can reconsider the level at which FEC is applied (streams or frames) and experiment with it too. Once again, thank you for the feedback and comments ! Let's make the design evolve and experiment with it. Don't hesitate to contact me for any comment or question. Regards, Franz -- Podcast: https://www.linkedin.com/feed/update/urn:li:activity:7058793910227111937/ Dave Täht CSO, LibreQos