On Sat, Dec 4, 2021 at 2:30 PM David P. Reed <[email protected]> wrote: > > I just watched it. His assumption that "carrier networks can't solve the > problem because they can't control the hosts" is JUST WRONG!
Step 1: Understand that microbursts exist: Win Step 2: Find a way to measure them at 100Gbit scale using the tofino switch and a viable data structure: Big win Step 3: Find a way to use that measurement in that switch to "do something":: ok, you object to this Step 4: Publish at conext: Normal Alternate step 3: Being able to leverage this tool to gain data about e2e behavior at these scales and make better applications is a huge win. From looking at the before sawtooth in what they did, they had a brick wall ecn configuration going against RFC3168 flows, and originally marked all packets over the threshold, leveraging RFC3168's non-response for more than one packet marked per RTT. The graph missing for me (and perhaps I should look again) was the effect of that, vs not marking at all, or marking more smartly, as they did. The second question for me has always been to what extent ECN of any form is being used in the datacenter today, in RFC3168 semi-compliant ways like this. It is, essentially, half on by default.... > > > The Internet solution is to require the flows' source hosts to regulate their > transmission based on dynamic feedback. From where? tcp timestamps aren't granular enough. > > > > And this ignorance on his part is clearly his advisors' fault. > > > > The pattern here is: > > > > I make assumption that rules out better solutions. > > > > I then invent some complicated kludge "inside the network" and claim it > solves the problem. > > > > Then I demand that networks put this kludge into the network. > > > > In other words, he takes an end-to-end problem (regulating source rates to > achive low internal queue delay), and instead of implementing a solution at > the ends, he adds much more complexity inside the network. > > > > Violating the whole end-to-end argument. > > > > Or, simplifying the point: "we have smarts in the routers, that we aren't > using, so let's invent something to use them, even though there are better > solutions." > > > > Yuck! > > > > This is how we ended up with CISC computers, with operating systems that > shove huge amounts of function into protected mode with heavy use of shared > global variables protected by complicated locks. > > > > OK, this creates the need for complicated PhD theses where the coolness is > how complicated the code was to get working. > > > > > > > > On Saturday, December 4, 2021 1:44pm, "Dave Taht" <[email protected]> said: > > > It was the conquest tool they referenced that really caught my eye > > > > https://www.youtube.com/watch?v=Q3FFzB0SUjc > > > > "ConQuest: Fine-Grained Queue Measurement in the Data Plane" > > > > On Fri, Dec 3, 2021 at 4:09 PM Jonathan Morton <[email protected]> > > wrote: > > > > > > > On 4 Dec, 2021, at 12:27 am, Dave Taht <[email protected]> > > wrote: > > > > > > > > > > https://jonathankua.github.io/preprints/jkua-ieeelcn2021_understanding_ar_preprint-20jul2021.pdf > > > > > > > > I would love it if somehow the measured effects of chunklets against > > cake's per-host/per flow fq was examined one day. > > > > > > I haven't actually measured it, but based on what the above paper says, I > > > can > > make some firm predictions: > > > > > > 1: When competing against traffic to the same local host, the performance > > effects they describe will be present. > > > > > > 2: When competing against traffic to a different local-network host, the > > performance effects they describe will be attenuated or even entirely > > absent. > > > > > > 3: They noted one or two cases of observable effects of hash collisions in > > their tests with FQ-Codel. These will be greatly reduced in prevalence with > > Cake, > > due to the set-associative hash function which specifically addresses that > > phenomenon. > > > > > > - Jonathan Morton > > > > > > > > -- > > I tried to build a better future, a few times: > > https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org > > > > Dave Täht CEO, TekLibre, LLC > > _______________________________________________ > > Cake mailing list > > [email protected] > > https://lists.bufferbloat.net/listinfo/cake > > -- I tried to build a better future, a few times: https://wayforward.archive.org/?site=https%3A%2F%2Fwww.icei.org Dave Täht CEO, TekLibre, LLC _______________________________________________ Cake mailing list [email protected] https://lists.bufferbloat.net/listinfo/cake
