Testing with bi-directional traffic? about sce-l4s-bakeoff HOT 3 OPEN

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

from sce-l4s-bakeoff.

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

from sce-l4s-bakeoff.

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.

from sce-l4s-bakeoff.