Re: [81attendees] sucky Delta hotel network (and bufferbloat)

[Jim Gettys <[e-mail]>]

Hotels are probably the best (worst) place to see bufferbloat (and many
other problems) in all their glory, particularly when a pile of IETF
folks arrive.  Fred Baker has been studying this slow motion disaster
for many years; he has some very entertaining plots and data
demonstrating various diseases he's found including bufferbloat.  Might
make a good transport plenary session sometime.

Wireless drivers in the operating systems have lots of issues, such as
trying to retransmit packets until the cows come home in the face of
errors, compounding problems; not all of what you see in sick wireless
networks is bufferbloat; lots of other diseases abound.  If you want to
see (and maybe help fix) such an example, look at:
https://www.bufferbloat.net/issues/216 where we are fighting such a
problem in the Linux stack, specifically the Ath9k driver.

In the hotel case, you have many places to suffer from bufferbloat,
depending on the bottleneck link:

    1) in your host operating systems you'll get bufferbloat, if the
transfer rate you are getting via wireless is below that of the
broadband link, common due to both running through multiple walls and
the sharing of the link with others.  A common ring buffer size in
drivers is 200-300 *packets* on modern hardware.

    2) In many hotels, these access points are home routers rather than
enterprise grade access points, so you get into all the trouble in those
I've noted in my talk and blog.

    3) then you get into the bloat in the back haul from the hotels. 
Many/most hotels are now (under) provisioned over broadband connections,
so that hop, anytime there are a lot of users, saturates and stays
saturated during busy hours, particularly if IETF is in town, so you get
latency and bad packet loss there.  Similar pheonomena occur in venues
like libraries.

    4) particular ISP's who specialised in connecting hotels to the
Internet appear to have been (to be) particularly clueless and do not
run any form of AQM on their networks, even though parts of those
networks are often saturated.  Those ISP's seem to have been merged into
bigger ISP's, but the same clueless operators seem still in charge of
the remains of those networks. I've seen bad problems 5 hops into such
networks.  This is classic http://www.faqs.org/rfcs/rfc2309.html mistake
of the 1990's. I won't name any names, but you can figure out who on
your own easily enough.

If you run Windows, pingplotter is probably the best tool to observe
problems; on Linux, mtr can be useful.  I've done my own work mostly
with vanilla ping and scp (to saturate the path).

And anywhere I go, I *always* run netalyzr first, as it warns me of all
sorts of illness (and tries to test for bufferbloat too).
I recommend everyone do so.  See: http://netalyzr.icsi.berkeley.edu/

So hotels and conferences are particularly fruitful places to see
Internet illnesses of all sorts.  The one exception to the conference
problems I've seen is NANOG/IETF, where cluefull people have done useful
classification and AQM setup and where there is lots of traffic via
enterprise access points that aren't over buffered, so that even RED93
algorithms can succeed at controlling the queues.  Would that someone
would write up that configuration and publish it as a BCP: it would at
least help other conferences and enterprises to do much better, while we
sort out the home router mess which needs other AQM algorithms, as yet
untested.
                        - Jim