Re: [EToSat] Interop runner with satellite links

[Christian Huitema <[e-mail]>]

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