Re: [Bloat] RED against bufferbloat

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

I have seen some (to date unpublished) studies that show a ~5% "guard band" below the link rate can be enough to provide both good performance and bloat resistance. Take that with a grain of salt, though.

The real-world problem is that the anti-bloat proxy does not really know the bottleneck link rate. At 2 in the morning on an SP network (aka HFC, DSL or FTTx) , you are quite likely to get your SLA rate. At 7PM on a Friday afternoon, the link rate will probably be degraded. If you shape to the SLA rate when the network is busy, you are very likely to not have the desired behavior.

Throw in some "turbo boost" (where the network operator allows a large spike of traffic if the subscriber has been idle for a while) and the problem gets even harder. Turbo boost has very favorable benefits for bursty HTTP browsing traffic, and you do not want to miss out on that benefit by having a bump-in-the-wire doing rate shaping.

IMHO, the correct answer is to run a modern AQM algorithm (take your pick, they are all better than tail drop) on all devices. If the bottleneck link has a variable link speed, it is in a position to manage the buffer effectively.  Until we get to that point, there may be some benefit in proxy solutions, but there are dragons here.


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 Mikael Abrahamsson
Sent: Wednesday, February 25, 2015 9:06 AM
To: Toke Høiland-Jørgensen
Cc: bloat@lists.bufferbloat.net
Subject: Re: [Bloat] RED against bufferbloat

On Wed, 25 Feb 2015, Toke Høiland-Jørgensen wrote:

> So you mean comparing the scenario where the AQM runs on both sides of 
> the bottleneck to one where it runs as an ingress shaper on one side 
> only?

Yes. How much lower speed/rate would the CPE ingress (internet->CPE) AQM have to run at to have a reasonable low probability of traffic being delayed by that shaper (or dropped by the policer).

I realise this would be different depending on speed of the access, but some data points would be interesting.

For instance, some ISPs I've heard will have a policer and 2 seconds worth of burst, before they drop packets. Some others might have lower burst values. Some will have a pretty decent FIFO shaper. There are some different scenarios, how much lower speed do I need to run my AQM at in order to try to avoid this policer or shaper to affect my traffic? Gut feeling would be 10-20% should be enough, but I don't know.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se