search

heistp / sce-l4s-bakeoff

Flent tests that compare SCE and L4S
BSD 2-Clause "Simplified" License
5 stars 5 forks source link

Testing with bi-directional traffic? #3

Open moeller0 opened 5 years ago

moeller0 commented 5 years ago

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?

chromi commented 5 years ago

We could reasonably resurrect a couple of tests from Cake's development for this purpose, I think. The RRUL and the 50-up-1-down tests represent much more challenging scenarios than the 1- and 2-flow tests we've presented here.

However, I also think that what we've uncovered with these simpler tests is already very illustrative of L4S' problems. It might be seen as beating a dead horse. :-)

heistp commented 5 years ago

Ok, bumped up these cases into the Up Next area, so will get to them "soon-ish", when the next round of testing begins. For bi-directional traffic, I would start with rrul_be if that's enough to show anything new, and if not, rrul_be_nflows to some interesting N. For asymmetric links, I would try 1:N where N is something high enough that throughput is limited by the ACK path, otherwise for uni-directional traffic I don't expect anything less than that to show something new, though it may exacerbate any potential problems with bi-directional traffic.

I do want to leave the existing scenarios as is, as opposed to re-running them with new parameters, so I'll just add new scenarios. Along the lines of what Jon's saying, I'd like to find the simplest scenarios that show new behavior, then milk them for what they're worth, leaving as little as possible unexplained or undocumented. Each new scenario also means 30 minutes of test time for each proposal during a full run, and we're only testing with a few RTTs and a few CC algorithms, so at some point, barring more hardware and work, keeping the scenario count down will also be desirable. :)

moeller0 commented 5 years ago

Excellent, thanks. I fully agree to keep things simple, so maybe adding a bi-directiomal run to any scenario might be over-kill. And sure RRUL or one of its variants would do fine, I like rrul_cs8 as it uses 8 flows and should easily saturate both legs even with a symmetric configuration.