Re: [Bloat] RED against bufferbloat

[Sebastian Moeller <moeller0@gmx.de>]

Hi Mikael,


On Feb 25, 2015, at 14:36 , Mikael Abrahamsson <swmike@swm.pp.se> wrote:

> On Wed, 25 Feb 2015, Sebastian Moeller wrote:
> 
>> 	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…
> 
> As I said before, doing FQ_CODEL in the AR is an expensive proposition for medium and high speed access.

	Well a vectoring DSLAM is not too wimpy and needs to do plenty of processing per line, so fq_codel on there should be more finically sane than on a device with more concurrent users, I would guess...

> So if this could successfully be pushed to the CPE it would mean it would be more widely deployed.

	But there we face the same problem, the wimpy CPEs that ISPs like to distribute do not have enough pomp for shaping a reasonably fast lane, the saving grace might be that end customers can upgrade on their own cost. And I notice a number of specialized home routers appearing on the market targeting people wiling to spend $$ for better behavior under load.

> 
> I am very much aware that this is being done (I have done it myself), but my question was if someone had actually done this in a lab and found out how well it works in RRUL tests etc.

	Not in the lab, no; I have no lab, but I used RRUL iteratively to figure out empirically what shaping percentage I need on my line to keep latency under load in bounds I consider reasonable. In my case DTAG vdsl50 this turned out to be 90% of downlink sync and 95% of uplink sync (but I since learned that DTAG has a BRAS policer that has a lower rate than the VDSL-line, so I guess I was closer to 95% and 99% percent of the BRAS policer, but heaven knows which encapsulation the BRAS accounts for…)
	So I would guess the collection of cerowrt users should be able to cough up a number of empirical shaping percentages for different link speeds and technologies.

Here is my data, the empirically derived shaping values puzzled me until I learned about the BRAS policer. I had expected that the uplink shaper could run almost at 100%, which turned out to be correct if referenced to the BRAS policer and not the vdlx sync. Anyway here is my data, maybe others want to add their’s:

Tech				downlink_kbps							uplink_kbps							CPE_shaper
				sync		ISP_policed	CPE_shaped		sync		ISP_policed	CPE_shaped		overhead_B	linklayer
VDSL2.vectoring	51390	45559		46178			10047	9460		9500			16			ethernet


Best Regards
	Sebastian

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