On Mon, Jan 26, 2015 at 8:46 AM, Ewen McNeill
Hi Dave,
On 26/01/15 7:45, Dave Taht wrote:
I am curious as to what aspects of bufferbloat I should cover more deeply in my upcoming talk at nznog this friday? [... and] [t]alk abut new stuff going on, and wifi, if desired... talk more to bandwidth management and traffic engineering tools,
I think at this point there's pretty reasonable understanding of how bufferbloat happens -- and less understanding of how to practically deal with it, especially within an operator network which faces a variety of latency challenges, eg, cross-town, within-NZ, various distances outside US, satellite. Clearly the transfer speeds for some of those are improved by using non-trivial buffers, and the transfer speeds of others are made drastically worse by having too much in flight. I suspect many operators have a mix of all of them. (Obviously if the customer has their own buffer bloat issues the operator can't magically fix things completely -- but "do no harm", ie don't make things worse, seems a reasonable aim.)
If you had any insights on, eg, how bufferbloat interoperated with upstream provider policing policies and how to deal with that that'd likely be of interest too.
Well, I would love it if I could get more data from folk willing to install netperf-wrapper and run a 5 minute test that would be good. In particular, I'd like to know how the 100mbit fiber links in the cities are behaving, a typical slow DSL connection, a faster VDSL connection, and I see there are tons and tons of wifi links here, so if I could get some folk here to install netperf-wrapper and run it's test suite and supply some results run across those technologies, I'd be able to get a bit of a grip on what is going on here, and talk to those results over beer. Speedtest results don't cut it. - they don't test for latency under load. get netperf-wrapper from: https://github.com/tohojo/netperf-wrapper I note that bandwidth at the hotel here is quite poor, so if you can install the needed dependencies before arriving at the conference, I'm sure everyone would be grateful. on debian derived linux those are: apt-get install python-matplotlib python-qt4 fping apt-get build-dep netperf git clone https://github.com/dtaht/netperf.git git clone https://github.com/tohojo/netperf-wrapper.git cd netperf; ./configure --enable-demo; make; sudo make install cd ../netperf-wrapper; sudo python setup.py install An example script is here: http://snapon.lab.bufferbloat.net/~d/nz/ - note I dont have a decent server setup in country... It is also possible to get this to build on a mac, that's more involved, requires macports, time, and beer.
I'm guessing is "shape within the upstream policing envelope"
I would rather like folk to shape rather than police wherever possible.
-- but that's sometimes easier said than done if the upstream providers policing is very sensitive to instantaneous bursts of packets.
And they are. Policing is based on a radically incorrect assumption on how flows behave. It *IS* possible to build a kinder, gentler, policer, but I'll get to it in my talk.
And any advice on defining such operator shaping/policing policies to make them less likely to cause adverse behaviour (eg, being less sensitive to packet arrival time of the "last packet of the burst arrived 1ms too soon, so we threw it away, have a nice day" variety).
Demand shaped, rather than policed connections in your SLAs?
there is someone here today doing mikrotik training, and as yet only mikrotik only supports SFQ, not fq_codel. [...] I have a pair of slides on the differences between SFQ and fq_codel.
I think it would be great to talk about this too. And also if there's any thing that can be done with the Mikrotik (and hence SFQ) to mitigate the disadvantages. There are lots of Mikrotiks deployed in New Zealand, including a whole bunch on not-entirely-predictable-bandwidth (unlicensed) multi-mile radio links.
Got it.
And so on. I'm here all week... I've borrowed a NZ vm, run a few experiments worldwide, am fiddling with some parameters...
I think many would be interested in any parameters that worked well for in-NZ, to Australia (relatively low latency, several CDNs/Amazon/etc there), to USA (much of content there) and to Europe. So any results you find would be great.
It turns out very few parameter changes were required for any of these destinations (all sub 250ms) with fq_codel. I saw only a modest improvement if I changed the defaults to fully account for 250ms transit. It was pretty hopeless with everything else I tried! Of what was left SFQ was best, things like RED, hopeless on wildly varying RTTs. In my present location, however, I am seeing a *450ms* RTT to the eu, which I sure hope isn't normal for NZ, just this hotel. ( ping netperf-eu.bufferbloat.net ). dair-833:~ d$ ping netperf-eu.bufferbloat.net PING kau.toke.dk (130.243.26.64): 56 data bytes 64 bytes from 130.243.26.64: icmp_seq=0 ttl=42 time=409.153 ms 64 bytes from 130.243.26.64: icmp_seq=1 ttl=42 time=432.350 ms 64 bytes from 130.243.26.64: icmp_seq=2 ttl=42 time=455.123 ms If anyone has a power supply suitable for a wndr3800 and NZ power standards, I brought one, might be able to fix matters here.....
Plus of course if there are specific things that, eg, operator helpdesks should be recommending to customers that complain of transfer speed issues that seem like bufferbloat related that'd also be useful. But could possibly just be some slides pointing to useful resources for end users.
Sort of why I just asked if openwrt derived gear was a problem here. That stuff is the farthest along by far, for home cpe.
Ewen
-- Dave Täht thttp://www.bufferbloat.net/projects/bloat/wiki/Upcoming_Talks