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

[Jim Gettys <[e-mail]>]

On 08/03/2011 03:52 PM, Carlos M. Martinez wrote:
> Maybe we need to solve the pesky quality-of-service-on-the-internet
> thing once and for all :-)
>
> Seriously, giving the fact that we are inventing this PCP thing for
> remote-controlling port forwarding, maybe we could do something similar
> for traffic class queues on WAN links, so the hotel (or other similarly
> under provisioned network) can set up its traffic queues on the remote
> side of the WAN link.
>
> The ISP could assign a "pipe" of, say, 5 mbps to Delta Hotel, and a
> (hopefully clueful) sys/net admin could set some traffic queues for
> video/browsing/email/bit torrent (yes, there are people who do torrents
> on hotels, i've seen it with Wireshark) within the 5 mbps pipe.
>
> Can we set the BoF date ?? :)
>
> cheers!
>
> Carlos

Note that QOS, useful as it is, just moves what category of service
suffers.  The ultimate solution that our networks don't fall off of
cliffs under load is timely notification of congestion (e.g. packet loss
or ECN), and AQM to do so.  Lying to TCP's servo system gets us into a
world of hurt.  You thought there was TCP congestion avoidance?  Well,
there was once (and I hope will be again...).

Having said that, QOS is very, very useful at preventing out and out
failures and to enforce policies; right now, lots of what we're calling
"ants", those worker packets of DNS, DHCP, RA, etc, are getting lost in
the current mess, with the resulting complete failures of applications. 
So I don't see solving bufferbloat as a AQM versus QOS question at all:
both are useful (though if I have to only pick one, I'd pick working AQM)...
                    - Jim
>
> On 8/3/11 4:45 PM, Jim Gettys wrote:
>> On 08/03/2011 12:43 PM, Dave CROCKER wrote:
>>> On 8/1/2011 3:01 PM, Ole Jacobsen wrote:
>>>> "Expectations" are indeed important.
>>>>
>>>> Equally important is "common sense and common courtesy" which implies
>>>> a number of do's and don'ts on the hotel network. I am not going to
>>>> attempt to create that list here, but I can well imagine some things
>>>> that I should NOT be doing while on the hotel network, in
>>>> consideration of my fellow IETFers. (Large downloads, live video...)
>>> Ole,
>>>
>>> At various times, such examples have been cited, effectively placing
>>> the responsibility for poor hotel network performance onto IETF guests
>>> at the hotel.
>>>
>>> Is this merely a matter of being thorough in listing theoretical
>>> possibilities?  Or do we have any hard data to support the theory that
>>> IETF guests are, in fact, abusing the hotel networks?
>>>
>>> Is it equally plausible that problem hotels merely do not have
>>> adequate resources for reasonable use by an Internet-centric block of
>>> guests?
>>>
>>> What should the site qualifying teams do to assess a hotel's network
>>> capabilities?  I know what some of that is already being done but it's
>>> worth making sure that this issue is sufficiently covered by the site
>>> qualifying teams.
>>>
>>> d/
>>>
>> Hotel networks tend to be under provisioned in the first place; that
>> just makes network problems (such as bufferbloat, which only is an issue
>> when saturation occurs) worse.  In my wanderings over the last year,
>> I've had very bad experiences at most other hotels at peak hours, even
>> those not occupied by computer geeks, but by typical "users".  I think
>> there is a lot of video streaming  that has changed the workload
>> considerably.  The retirement of Windows XP is increasing the fraction
>> of connections that will saturate any link even with a single TCP
>> connection; so an increasing fraction of many other activies such as
>> backup or large file copy will induce saturation.
>>
>> We may be polite to each other, but try explaining this to the unwashed
>> masses, who want to watch tonight's episode of "House" or other show as
>> they do at home.  People aren't just reading email any more.
>>
>> We can test for whether the hotel's network and back haul network has
>> problems using existing tools (e.g. netalyzr, the mlabs tools, or even
>> iperf/netperf + ping) in advance.  I suspect that most of the major
>> hotels the IETF uses are less likely than most to use broadband
>> connections for their backhaul as commonly found in smaller
>> hotels/motels recently connected to the Internet. Resolving problems in
>> advance may be more of a problem. On a couple occasions, I've tried to
>> track down clue full people to talk to them, but as an individual patron
>> of the hotel, had no traction in doing so, and the hotel networks seemed
>> to be remotely managed by others. And once checked out, I had no
>> incentive to continue trying.
>>
>> Wireless at a conference hotel is probably completely infeasible in the
>> short term: the first wireless networks I've seen working well under
>> load are those set up at NANOG and IETF, where both commercial grade
>> AP's and really clue full configuration have managed to succeed.  That's
>> not even been carefully written down anywhere, though the principles of
>> it is covered very quickly in Anton Kapela's lightning talk at NANOG 38. 
>>
>> As soon as your wireless bandwidth is below that of the backhaul, your
>> problems with bufferbloat will be in your host OS and the hotel's
>> wireless gear; while we have some test bits for controlling buffering
>> for Linux (the debloat-testing tree), I have no clue as to when you
>> might see anything Mac or Windows; in the short term, you really want
>> the bottleneck some place other than your wireless hop.  Which hop is
>> the bottleneck link easily varies depending on the ratio of the hotel's
>> back haul is available to you and how much wireless bandwidth you can get.
>>
>> In the short term, I'd focus on seeing if the wired hotel network is
>> provisioned properly under load, it's ISP runs with suitable AQM. At
>> least then, if you plug into the wired ethernet, it should behave
>> properly and degrade reasonably under load rather than falling off a cliff.
>>                                                     - Jim
>>
>>
>>
>>
>> _______________________________________________
>> 81attendees mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/81attendees