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?

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)?

Hi
Im trying to generate tcp_rtt plots but when I run rrul command but the tcp plots like tcp_rtt,tcp_cwnd,tcp_rtt_cdf are not generated when I run the rrul test using:
sudo flent rrul -H <server_ip>
Im testing with a custom L4S kernel(https://github.com/L4STeam/linux). I have two linux machines both loaded with the custom kernel with tcp congestion control set as prague for test purposes.
I went through the issue #163 created bt @heistp and tried recompiling my kernel with CONFIG_INET_DIAG but still didn't work. This is the output of ss.

$sudo ss -tipn
State   Recv-Q   Send-Q       Local Address:Port           Peer Address:Port    Process                                                                         
ESTAB   0        0            10.100.67.111:55320         10.100.131.33:40185    users:(("netperf",pid=30111,fd=4))
	 prague wscale:7,7 rto:1256 rtt:417.525/208.762 mss:1238 pmtu:1500 rcvmss:536 advmss:1448 cwnd:10 bytes_acked:1 segs_out:2 segs_in:1 send 237207bps lastsnd:120 lastrcv:120 lastack:120 pacing_rate 494320bps delivered:1 rcv_space:14480 rcv_ssthresh:64088 minrtt:417.525

I dont know where the issue is or is there any step I'm missing?

Also have attached the flent data files and verbose output.

flenttest.txt
rrul-2024-04-25T142545.780570.flent.gz

Hi.I just wanna know how your using flent.Im just new to these stuffs.So basically your getting the log and pcap files using tcpdump and then generating the various plots?Like what kind of traffic is generated to test the dualpi2?Ive heard flent has various tests but what is done here to generate the traffic required for benchmarking?Again Im just getting to know these stuffs so pardon me if im basic

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.

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?

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).