[Bloat] RED against bufferbloat

[Sebastian Moeller]

Hallo Mikael,

On Feb 25, 2015, at 11:47 , Mikael Abrahamsson <swmike at swm.pp.se> wrote:

> On Wed, 25 Feb 2015, Toke Høiland-Jørgensen wrote:
> 
>> While the academic side of me enjoys studying AQMs (and I'm still far from anything resembling a thorough understanding of them), the practical "I just want my network to work" side of me has become increasingly convinced (in part by doing the experiments in the above mentioned talk) that FQ is more important than AQM in many scenarios. As such, I think that excluding FQ from the conversation is mostly of, well, academic interest ;)
> 
> 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").
> 
> 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.
> 
> So one question that I would be interested in understanding is this scenario:
> 
> INTERNET----AR---CPE--HOST
> 
> Let's now say the AR has a stupid token bucket based policer (which doesn't queue, just drops packets) rate-limiting the traffic input/output towards the CPE to, let's say 120 megabit/s averaged with 1 second worth of burst bytes (because the ISP wants to make sure the customer can speed-test to 100 megabit/s of TCP throughput).
> 
> 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.

	Yes, we can. Openwrt’s qos-scripts and cerowrt’s sqm-scripts allow exactly that. But we really could need some help from the station on the other end of the bottleneck-link, so either a cmts or a dslam (what ever these are called today). The shaper for the ingress link to the CPE is best positioned in front of the boot;neck instead of behind it in the CPE (in the CPE we need to sacrifice more bandwidth and in case of a sudden inrush of packets ill still see more AR policer action than we would like).
 	The only argument for ingress shaping on the CPE is that this allows the end user to define her own QOS criteria independent of the ISPs wishes. Best of both worlds would be user configurable QOS-shaping on the slam/bras/whatever…

Best Regards
	Sebastian

> 
> What about 12 megabit/s policer to a 10 megabit/s service? What about a 12 megabit/s FIFO shaper (that would actually delay packets, but because it's FIFO we just rarely want to see buffering there).
> 
> 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.
> 
> I am using terminology that is explained in this article:
> http://www.cisco.com/c/en/us/support/docs/quality-of-service-qos/qos-policing/19645-policevsshape.html
> 
> -- 
> Mikael Abrahamsson    email: swmike at swm.pp.se_______________________________________________
> Bloat mailing list
> Bloat at lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat