[Starlink] Fwd: Follow-up of QUIC-FEC discussion at IETF115

[Dave Taht]

some stuff on burst length and starlink in the attached

---------- Forwarded message ---------
From: François Michel <francois.michel at uclouvain.be>
Date: Mon, Nov 7, 2022 at 8:59 AM
Subject: Follow-up of QUIC-FEC discussion at IETF115
To: <quic at ietf.org>
Cc: Christian Huitema <huitema at huitema.net>, <yfmascgy at gmail.com>, <
gorry at erg.abdn.ac.uk>, <jri.ietf at gmail.com>, <mt at lowentropy.net>, Olivier
Bonaventure <olivier.bonaventure at uclouvain.be>, Marie-Jose Montpetit <
marie at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20230508/1a0bf481/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: a_first_look_at_starlink_performance.pdf
Type: application/pdf
Size: 1252563 bytes
Desc: not available
URL: <https://lists.bufferbloat.net/pipermail/starlink/attachments/20230508/1a0bf481/attachment-0001.pdf>