App limited implementation

[hfstco]

We need some measurements and test cases for the implementation of app limited senders in PR #1818. These effects (D)CUBIC and Prague.

The maximum execution time for some test cases is increased slightly.

l4s_congestion_test h3zero_satellite_test h09_satellite_test satellite_basic_test satellite_seeded_bbr1_test

Why, where and when does app limited prevents CWIN from rising?

App limited should also implemented for NewReno. But there are too much changes in the test suite required.

packet_trace qlog_trace qlog_trace_auto qlog_trace_only qlog_trace_ecn l4s_reno pacing_update quality_update app_limited_reno multipath_callback multipath_quality

Should NewReno simulation also be effected by app limited senders?

[huitema]

Part of this issue is checking whether the evaluation of the app blocked status in the main code is correct, or, for that matter, is even needed.

Congestion algorithms that are based on controlling the congestion window could do with a simple test: verifying that the bytes in flight are larger than CWIN. There are nuances, of course. Technically what matters are the number of bytes in flight at the time the acknowledged packet was sent. That's the load handled by the network between the times that packet was sent and that packet was received. If we notice a congestion signal, that's the load that caused the congestion. If we don't, that's the "confirmed" value of CWIN that is known to not cause congestion, and the algorithm can try higher values.

BBR, in contrast, mostly uses the pacing rate as the congestion control variable. An app is limited if it sends at a lower rate than the pacing rate. What matters there is the average send rate between the time the packet was sent and the time it was received. That's a different test from the CWIN test, and maybe we should think about it a bit more.

[huitema]

@hfstco Do we need to keep this issue open?