[Bloat] DETNET

[Dave Taht]

Matthias Tafelmeier <matthias.tafelmeier at gmx.net> writes:

> On 11/15/2017 08:31 PM, Dave Taht wrote:
>
>     Nonetheless, it's important to have a debate about where to go to next.
>     Personally I don't think fq_CoDel alone has legs to get (that) much better. 
>
>     The place where bob and I always disconnect is that I care about
> interflow latencies generally more than queuing latencies and prefer to
> have strong incentives for non-queue building flows in the first
> place. This results in solid latencies of 1/flows at your bandwidth. At
> 100Mbit, a single 1500 byte packet takes 130us to deliver, gbit, 13us,
> 10Gbit, 1.3us.
>
> A not necessarily informed enough question to that: couldn't this marking based
> virtual queueuing get extended to a per flow mechanism if the marking loop was
> implemented in an efficient way?

Bob's mechanism splits into 2 queues based on the presence of ecn in the
header. It is certainly possible to do fq with more queues within their
concept. :)

I've tossed fq_codel onto their groups' demo. Which, if you toss any but
their kind of traffic through it, seemed to perform pretty good, and
even with... well, I'd like to see some long RTT tests of their stuff vs
fq_codel.


At the moment, I'm heads down on trying to get sch_cake (
https://www.bufferbloat.net/projects/codel/wiki/CakeTechnical/ ), maybe
even the "cobalt" branch which has a codel/blue hybrid in it,
upstream.

Mellonox is making available a toolkit for some of their boards, I've
been meaning to take a look at it. ENOTIME.

On the high end, ethernet hardware is already doing the 5 tuple hash
needed for good FQ for us (this is used for sch_fq, fq_codel, and even
more importantly RSS steering), but cake uses a a set associative hash
and some other tricks that would be best also to push into hardware. I'd
love (or rather, an ISP would love) to be able to run 10k+ good shapers
in hardware.

...

At some point next year I'll take a look at detnet. Maybe.