Re: [EToSat] Interop runner with satellite links

["Su, Chi-Jiun" <[e-mail]>]

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 <[e-mail]> on behalf of Christian Huitema <[e-mail]>
Sent: Sunday, February 27, 2022 12:58 AM
To: Nicolas Kuhn <[e-mail]>
Cc: Su, Chi-Jiun <Chi-Jiun.Su=[e-mail]>; [e-mail] <[e-mail]>; Sebastian Endres <[e-mail]>; [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
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