Re: [Bloat] RED against bufferbloat

["Bill Ver Steeg (versteb)" <versteb@cisco.com>]

Regarding the statement
> We're not going to see FQ_CODEL on a 200 interface large router 
> designed to push 100 gigabit/s of traffic, at least not in any 
> interesting price point.

There are two points under the covers here. I would say a 2 more accurate statements would be -

1- "We are unlikely to see any AQM scheme that includes many queues in a core router." This includes FQ_CODEL, FQ_PIE, and any other scheme that uses a statistical hashing of flows into a large number of queues. The required silicon to support so many queues is simply too expensive. There may be new silicon designs that make this more feasible, but this is non-trivial.
2- "There are several AQMs under consideration for use in a core router. There are advantages to <doing work> at enqueue time rather than dequeue time, and this may drive some designs." In other words, AQM algorithms that are similar to PIE are likely to be in large aggregation devices (like a CMTS) and core routers. You could probably design new silicon that did work at de-queue time, but that is simply not how the current designs operate. 

The good news is that as we debate the relative merits of the new AQM schemes, they are all MUCH better than the legacy algorithms. Putting FQ_XXX (where XXX== CODEL today, and perhaps other algorithms in the future) into devices that do queue management in software is a big win. Putting CODEL/PIE (using a handful of QOS mapped queues, using microcode running on current generation silicon) into the big iron is also a big win.

So, let's get modern AQM pushed into all of the devices. One design will not fit all devices........


Bill Ver Steeg
DISTINGUISHED ENGINEER 
versteb@cisco.com












-----Original Message-----
From: bloat-bounces@lists.bufferbloat.net [mailto:bloat-bounces@lists.bufferbloat.net] On Behalf Of Toke Høiland-Jørgensen
Sent: Wednesday, February 25, 2015 6:05 AM
To: Mikael Abrahamsson
Cc: bloat@lists.bufferbloat.net
Subject: Re: [Bloat] RED against bufferbloat

Mikael Abrahamsson <swmike@swm.pp.se> writes:

> To me, FQ is important especially for lower speeds. This also maps 
> well into the CPU based nature of FQ (that it's hard to do in 
> "silicon").

Well my research has been mainly focused on the consumer / edge case.
I.e. things a Linux box can drive in hardware, so up to 100Mbit to a Gbit depending on the size of the box. In these cases, fq_codel adds no measurable overhead compared to the CPU load of just pushing the packets.

> We're not going to see FQ_CODEL on a 200 interface large router 
> designed to push 100 gigabit/s of traffic, at least not in any 
> interesting price point.

Maybe not; but note that recent work in the Linux kernel makes it quite capable of pushing 40GigE, and I believe sched_fq (which does 'real'
fairness queueing with a queue per flow, not hash buckets as fq_codel
does) has been shown to scale to millions of concurrent flows.

> Can we do bidirectional traffic FQ_CODEL on the CPE to try to achieve 
> basically zero loss in the AR policer for any normal kind of use 
> scenario using TCP. I have not seen any simulations looking at this.

Well this is basically what we're doing with the SQM scripts in CeroWRT:
put a software rate limiter in the CPE and configure it to a slightly lower value than whatever the cable/DSL modem runs at. This works quite well, but the software rate limiter is fairly CPU hungry, so small boxes struggle. I had to substitute a full x86 box for my Netgear router to run at 100Mbit for my home connection.

> Because my belief is that even though we might say we love FQ here, 
> we're not going to see high speed FQ on higher end ISP aggregation 
> routers. So if we want FQ, we're going to have to do it in the CPEs.

Well OpenWRT turns on fq_codel by default now. :)

And yeah, I'm not holding by breath for big iron vendors to include fq_codel in their products. But that doesn't mean it can't go into CPEs.
And end hosts and access points. And inside tunnels (VPN daemons for instance).

-Toke
_______________________________________________
Bloat mailing list
Bloat@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/bloat