[Cake] Understanding the Achieved Rate Multiplication Effect in FlowQueue-based AQM Bottleneck

[Dave Taht]

On Sat, Dec 4, 2021 at 2:30 PM David P. Reed <dpreed at deepplum.com> 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" <dave.taht at gmail.com> 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 <chromatix99 at gmail.com>
> > wrote:
> > >
> > > > On 4 Dec, 2021, at 12:27 am, Dave Taht <dave.taht at gmail.com>
> > 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
> > Cake at lists.bufferbloat.net
> > 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