heistp / sce-l4s-bakeoff Goto Github PK

Hi Pete,

I just noticed that the dual q AQM seems to default to 15ms, which might contribute to the observed unfairness between cubic and prague @0ms RTT. According to Oliver, under load the effective RTTs change from ~0:~0 to 1:15 which he takes as sufficient justification to excuse the unfairness. Now, according to codel theory 15ms target and interval 100 are a really bad match for a 0ms RTT path, as target should be well below 1ms. at 1ms RTT and at 5ms for interval 100.
So would it be interesting to repeat the L4S scenario 1 tests with (RTT_typ = 5 ms) instead of the default 15, or even smaller values to see whether that ameliorates the observed bias?

While I never much cared for kathie calling Fig 7 of the codel paper a "wireless" emulation,
duplicating that experiment for purposes of your testing here would give a nice comparable result to:

https://queue.acm.org/detail.cfm?id=2209336

My prediction would be SCE with the CE marking under duress would much more rapidly get back under control than the L4S alternative. massive loss, however, on one of the more extreme examples of a rate change should (in a proper tcp, probably not L4S in its present state) reset cwnd entirely.

current:

For comparison, the full results for an
L4S run with the modified pacing are
[here](bakeoff-2019-09-12T021200-pacing-100).

From the README page this resolves to "https://github.com/heistp/sce-l4s-bakeoff/blob/master/bakeoff-2019-09-12T021200-pacing-100", which gives a 404.

I think you probably mean to have:

For comparison, the full results for an
L4S run with the modified pacing are
[here](https://www.heistp.net/downloads/sce-l4s-bakeoff/bakeoff-2019-09-12T021200-pacing-100).

Dear Pete, dear Jonathan,

would it be an option to run all the same tests as before but with all loads running in both directions and potentially with a path asymmetry similar to what is seen out in the wild (e.g. 1:10 to 1:20 up- to download). This might show issues with ACK traffic for the different schemes. As far as I can tell most official L4S testing has been done with the reverse link unloaded, so I wonder how robust this scheme is against real-world saturation conditions?

Excellent! Thank you all for doing all this testing to put things on a solid footing!

I do have a question about scenario5/6 that I could not figure out myself yet.

In the beginning it says:

"All bottlenecks restrict to 50Mbit, unless otherwise noted."

Does this mean that in the scenario 5 and 6 all of the the (L4S/SCE, the) FiFO and the FQ-AQM are set to exactly 50 Mbps? I would assume that to be wrong and the bottlenecks to be successively narrower, but I fail to see exactly where this is configured?

And does the FQ-AQM shape on the ingress or egress side (not that that should matter much)?