This problem in the test may be gone with the new fix. "Although only a file of 10 MiB is transferred, this leads to approximately 60 to 80 MiB of data being sent."
thanks. cj ________________________________ From: EToSat <[email protected]> on behalf of Christian Huitema <[email protected]> Sent: Sunday, February 27, 2022 12:58 AM To: Nicolas Kuhn <[email protected]> Cc: Su, Chi-Jiun <[email protected]>; [email protected] <[email protected]>; Sebastian Endres <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Re: [EToSat] Interop runner with satellite links **EXTERNAL EMAIL** 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<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-irtf-nwcrg-coding-and-congestion-12__;!!Emaut56SYw!jNkAqwXdSBCHAMUuYW8PPcglW-20gL3A6g374RkqkAJtdwP1lCyedBGvudZYRl-1xA$> 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://urldefense.com/v3/__https://datatracker.ietf.org/doc/html/draft-swett-nwcrg-coding-for-quic-04__;!!Emaut56SYw!jNkAqwXdSBCHAMUuYW8PPcglW-20gL3A6g374RkqkAJtdwP1lCyedBGvudY_7bqPLg$> - https://datatracker.ietf.org/doc/draft-roca-nwcrg-rlc-fec-scheme-for-quic/<https://urldefense.com/v3/__https://datatracker.ietf.org/doc/draft-roca-nwcrg-rlc-fec-scheme-for-quic/__;!!Emaut56SYw!jNkAqwXdSBCHAMUuYW8PPcglW-20gL3A6g374RkqkAJtdwP1lCyedBGvudYazujiig$> - https://inl.info.ucl.ac.be/publications/quic-fec-bringing-benefits-forward-erasure-correction-quic.html<https://urldefense.com/v3/__https://inl.info.ucl.ac.be/publications/quic-fec-bringing-benefits-forward-erasure-correction-quic.html__;!!Emaut56SYw!jNkAqwXdSBCHAMUuYW8PPcglW-20gL3A6g374RkqkAJtdwP1lCyedBGvudZKbpdRNw$> 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
