On 2/25/2022 10:24 PM, Nicolas Kuhn wrote:
On the interaction between congestion control and coding, you may be
interested in looking at :
https://datatracker.ietf.org/doc/html/draft-irtf-nwcrg-coding-and-congestion-12
There have been other interesting contributions on the integration of FEC
in QUIC :
-https://datatracker.ietf.org/doc/html/draft-swett-nwcrg-coding-for-quic-04
-https://datatracker.ietf.org/doc/draft-roca-nwcrg-rlc-fec-scheme-for-quic/
-
https://inl.info.ucl.ac.be/publications/quic-fec-bringing-benefits-forward-erasure-correction-quic.html
I think the proposed approach (sending FEC packets when the file
transmission is over) had been experimented and will investigate whether
the results can be shared.
I will look, thanks.
In any case, I think that the adverse effects found by Sebastian are now
fixed. There was an issue when the client did not increase the flow
control window quickly enough. If the value of MAX_DATA or
MAX_STREAM_DATA is too small, the sender becomes blocked. In the old
builds, when the sender was blocked by flow control, the code decided
that it could just as well repeat packets preemptively rather than doing
nothing. This is somewhat debatable. It generally does not speed up
transfer, because flow control does not affect loss recovery. The new
code only does preemptive repeat at the end of file transfers: fewer
transmission, probably lower energy consumption, and slightly faster
completion of the file transfer compared to the old code.
I have uploaded a docket image with the new code in the interop runner.
I don't know whether I need to do something special for the satellite
interop runner.
-- Christian Huitema
