Re: [Bloat] ADSL, ATM drivers, bloat, education & confusion

[Sebastian Moeller <moeller0@gmx.de>]

Hi Kevin,

On Jun 6, 2015, at 15:38 , Kevin Darbyshire-Bryant <kevin@darbyshire-bryant.me.uk> wrote:

> Hi Chaps,
> 
> Guess who  :-)  Following on from my probably rash assertion that BT here in the UK probably aren't as bad at bufferbloat from them to end user due to rate limiting as I think, it has reminded me of my parents' situation and efforts to help them.
> 
> Scenario is: ADSL very long line (hopefully they've got the copper repaired now) so on a good day the ADSL sync is something like 2Mbit down, 512kbit up.  I bought them a Netgear DGN3500 which is now running OpenWrt CC (+cake) This is not my preferred solution in hardware terms but it has a supported built-in ADSL modem so is a one box solution.
> 
> The problem I have is setting outbound rate limiting.  I was hoping that 'cake' without the 'bandwidth' parameter would work on the 'backpressure' from the ATM(?) driver, sadly this wasn't the case and so setting a bandwidth limit (I'm not in a position to test the new keywords for ATM encapsulation etc yet) was the only way forward.  

	This is rather important to get right, ATM’s arcane 48/53 encapsulation only leaves 100*48/53 = 90.5% of the sync rate for useable bits, and even those need to contain all the headers specific to your line (plus AAL5’s unfortunate choice of fitting each packet into an integer number of ATM cells), mean that without AQM taking the link layer encapsulation into account you need to aim for roughly 80-85% of the sync rates on and ATM link. With a link that disappears often I currently would recommend sqm-scripts as weapon of choice (you should be able to get cake into sqm-scripts) as the IFB needs to be set up again after the “connected” interface reappears, which current sqm-scripts should do for you...


> Unfortunately the ADSL link isn't rock solid stable so the negotiated rates for in & out flap around a bit.  So a few questions:

	That is bad and will need special care; on the positive side we might be able to include your solution for this issue into sqm-scripts so that this only needs solving/working-around once ;)

> 
> 1) ATM interface 'backpressure' - is this Byte Queue Limits? (ifxmips_atm)

	Is there actual backpreassure from your ATM diver at all? As rar as I know france’s free had their boxes ATM driver modified to keep buffering low, and I believe David Woodhouse dd some work on another driver/the generic ATM layer, but I am not sure that any ATM driver actually defaults to sane buffering and sane back pressure.

> 2) Do byte queue limits apply to outbound only?

	Don’t know, they certainly affect outbound on drivers that actually implement that feature, as far as I know all ethernet so far.

> 3) Horrid thought - this probably isn't just the ATM driver as IP is provisioned over PPP.  PPP driver needs BQL too?

	Don’t think so, I have cerowrt terminating a PPPoE link and outbound shaping just works as expected. Then again I actually have a shaper set to 95% of the sync rate, but that is caused by my ISP being daft and implementing a throttle at the BRAS level which I need to target for shaping, but that’s why I do not reach 100% on egress ;) YMMV.

> 
> 
> So another approach is to query the ATM interface on every IF up (which should get reflected into the the PPP interface up) for its current negotiated sync rates and use those as input into the SQM scripts.

	That sounds like a decent approach, but why not simply do this every hour instead/in addition?

> 
> There's a question here that's niggling me at the back of my mind: How is this supposed to work with a two box modem and router solution?  I guess the modem should ideally be running some sort of outbound AQM and dropping packets on its ethernet interface that just won't fit/queue too long.

	How this is supposed to work? In an ideal work the CPE and the DSLAM would not over-buffer and www would not have to dedicate grey matter to work around their sort-commings ;) But as far as I can tell DSL sync rates for many lines are stable over weeks to months, so setting the shaper rarely is sufficient. Like when you notice that latency under load got worse…


Best Regards
	Sebastian

> 
> Sorry, too many questions and I've not enough programming experience let alone linux kernel experience to be able to help.  I'll try if someone can point me in a direction.
> 
> Kevin
> 
> 
> 
> _______________________________________________
> Bloat mailing list
> Bloat@lists.bufferbloat.net
> https://lists.bufferbloat.net/listinfo/bloat