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