Verizon Policy Statement on Net Neutrality

Dave Taht dave.taht at gmail.com
Sun Mar 1 18:35:50 UTC 2015


I am not normally, willingly, on nanog. My emailbox is full enough. I
am responding, mostly, to a post I saw last night, where the author
complained about the horrid performance he got when attempting a
simultaneous up and download on a X/512k upload DSL link.

That is so totally fixable now, at speeds below 60mbit, with any old
cast off home router that I had to reply...

Honestly I had assumed that everyone here has the chops to fix their
own networks (home and business), in circumstances of high latency
under load caused by bufferbloat - *by now* - and I hadn't spent any
time on this list at all.

A DSL product, running openwrt, made in australia, - was the first DSL
device to get the excess buffering in the DSL driver ripped out and
fq_codel tested. I was over at David Woodhouse's house in England
while he fixed it - which was at LEAST 3 years ago. And he's been
running it with openwrt and those fixes ever since. The name began
with a T, it was a geode, I can't remember the name of it now.

These were the results we got on DSL on an old modem that supported
pause frames:

http://planet.ipfire.org/post/ipfire-2-13-tech-preview-fighting-bufferbloat

These are the improvements in bandwidth and latency under load - in
both directions - we commonly get on cable modems, using the
sqm-scripts now in openwrt and working on any linux box you care to
use.

http://snapon.lab.bufferbloat.net/~cero2/jimreisert/results.html

http://burntchrome.blogspot.com/2014/05/fixing-bufferbloat-on-comcasts-blast.html

Probably the shortest talk I have ever given on these topics (23
minutes long) was at uknof here, where in particular, I demoed the
improvements in web load time that are now possible. 2 years ago.

https://plus.google.com/u/0/103994842436128003171/posts/Kpogana4pze

See also:

https://plus.google.com/u/0/explore/bufferbloat

And recently I gave much longer talk, which FINALLY includes some bits
on how we intend to now focus on *vastly improving wifi*, at nznog,
which starts at 2:05 on friday morning here:

http://new.livestream.com/i-filmservices/NZNOG2015/videos/75358960

I am tired of looking at myself, and I have to say that the talk
before mine was WONDERFUL - the guy went into all sorts of new ways to
find latency events, and filter out any false positives and provide
new kinds of alerts to operators.

And the talk after, from cloudflare, depressing as hell.

I will gladly give another bloat talk to nannogers if that helps at
some future conference, but jeeze, this stuff is so easy to fix now,
and everyone involved is tired of repeating themselves, especially me.
but since I haven't ranted here yet... and only intend to do this
once, here I go....

...

Since being developed, the core BQL and fq_codel code has become fully
available in every linux distribution I know of. The most advanced
versions of it are in the "sqm-scripts" that are part of the openwrt
"chaos calmer" work - notably - unlike every other shaper I know of,
it can correctly compensate for PPPoe and DSL framing problems, and it
automatically handles the problems that codel has on links below
2.5Mbits. We worked for over a year to get that right - fixed all the
bugs in htb, mainlined and made available for free how to do it all
right, as of Linux 3.10.12 and later, and all that logic is in those
sqm-scripts - which work best on openwrt but also work on any linux
distro with a couple tweaks.

(and since then we have worked to pour it all into C with even simpler
configuratiojn, that work is not done yet, please feel free to come
help).

So anyone here, with a spare 60-90 bucks, 5 minutes, and the right
re-flashable router
no longer has cause to complain about high jitter and latency, even on
the slowest
and most asymmetric links at home, or in their businesses.

Benchmarks of the "fq" portion of fq_codel show it as better than
"sfq", and the codel portion, way better than RED.

It helps of course, to do valid benchmarking of the real problems in
your links - in your switches - and in your routers - at nanog scales
- so we have developed a suite of tests you can use called "rrul" real
time response under load - available for free as part of
"netperf-wrappers" -

https://github.com/tohojo/netperf-wrapper

The server for which works on everything (netperf is very portable),
and the test client driver, analysis tools and gui, work on any linux
system and can be made to work on OSX via macports (I was unsuccessful
at brew). The data it collects is your own, and aggregatable, and you
don't need to share it with anyone if you don't want to.

I would certainly like it, if after evaluating and then fixing bits of
your own network that way, that anyone doing so, would volunteer to go
fix two other networks, and get the people running those networks to
go fix two other networks, each, and so on. And of course, feel free
to nag and publicly embarrass those providing busted, bloated CPE,
DSLAMS, BRAMS, and CMTSes, etc to actually deploy this stuff on their
side, so we all can move on, and all have way better networks.

Anyone here *making linux based CPE*, can merely update their code to
something modern, containing these algorithms.  Backports are
possible, but so far, I have been quite depressed by the overall buggy
results I have seen from the home router makers attempting to so. All
the streamboost products I have tested are defective in some respect
or another - so I am back to recommending people just reflash their
firmware ("friends don't let friends run factory firmware") with
something readily available and good off of openwrt's unbelievable
large list.

https://downloads.openwrt.org/snapshots/trunk/

I have a fondness for the ar71xx products as those generally have the
best drivers (ath9k) for wifi.

I know full well, that Linux does not rule the world (yet), and most
of my ire these days is aimed at those that are not paying attention
or helping fix their crappy systems.

While half of the solution - codel - is already available as patches
to at least one BSD version... I am still waiting patiently for
someone to code up a version of fq_codel for BSD. fq_codel was written
in a single saturday afternoon, and mainlined in the next week - and
despite trying, we have been unable to come up with anything more than
marginally better. I have been reluctant to do that port personally as
transliterating from GPL to BSD is something that someone else should
do, based on the IETF internet draft we produced.

https://tools.ietf.org/html/draft-hoeiland-joergensen-aqm-fq-codel-01

We (on the codel or bloat email lists) will gladly review patches and
performance data, however.

If you are stuck with older gear that can't be updated, perhaps you
can apply HFSC + SFQ which works pretty well at lower bandwidths, but
has problems that I documented here:

http://www.bufferbloat.net/projects/cerowrt/wiki/Wondershaper_Must_Die

As for fixing your interconnects - or any other places you have *any*
bufferbloat and/or bad latency - the fq_codel algorithm is incredibly
light-weight, and works at 10GE and above. (software rate shaping, not
so much)

Netperf-wrapper also scales to 10GigE. In fact, it is being used to
test stuff running at 40GigE. Most other tools for testing for
bandwidth and latency, start showing erroneous results above 20Mbit.

I too would like asymmetric networks to behave better, but these are
the best tools we got to fix what we have. Go forth, test, and deploy!

A plea: please stop debating about policy and just deploy s**t that works.

[1]  Quite a few bits of DSL firmware are a problem. The only truly
"perfect" DSL firmware I know of is in free.fr's revolution v6 router
- which was deployed august, 2012 - with a DRR + fq_codel based
implementation that works *really well* at line rate, whatever it is -
no software shaping required.

On Sun, Mar 1, 2015 at 3:40 AM, Aled Morris <aledm at qix.co.uk> wrote:
> On 1 March 2015 at 03:41, Barry Shein <bzs at world.std.com> wrote:
>
>> Previously all residential service (e.g., dial-up, ISDN) was
>> symmetrical.
>
>
> The rot set in with V.90 "56k" modems - they were asymmetric - only the
> downstream was 56k.  The only way to achieve this in the analogue realm was
> by digital synthesis at the head-end, i.e. the T1/E1 handoff to the ISP.
> The upstream from the subscriber didn't have a clean interface so was still
> using 33.6k.
>
> Sadly we don't have many "killer applications" for symmetric residential
> bandwidth, but that's likely because we don't have the infrastructure to
> incubate these applications.
>
> It's a chicken and egg situation - of course the average consumer today
> will say they "don't need" symmetric, but you could have asked them twenty
> years ago and they'd have said they didn't need the Internet at all.  Or
> smartphones.

I agree totally with this sentiment - if we had symmetric edge
networks, we would have come up with ways to use them.

offsite backup would be a lot more common, in particular.

> This all suits the telcos and cablecos very nicely - they are happy when
> their customers are passive consumers of paid content and services.  It
> gives them control.
>
> I don't think it's a conspiracy, but it suits the big players not to "fix"
> the "problem" since they don't perceive it as being one.
>
> Aled



-- 
Dave Täht
Let's make wifi fast, less jittery and reliable again!

https://plus.google.com/u/0/107942175615993706558/posts/TVX3o84jjmb


More information about the NANOG mailing list