You can have an overall congested network. I've seen this on occasion.

But it is very easy (and even more common) for you (or people in your house) to do it to you, than to have the overall ISP network congested. This is something a simple file copy can/does do to you, in practice.

Some ISP's run AQM properly (e.g. RED) in the cores of their networks; some do not. On the ones that do not, you'll see problems at peak hours. Similarly on corporate networks.

Heh. The worst problems (as far as I've seen) we have are in the edge.

In our hosts and home routers (most of which are Linux boxes).

The problem occurs anytime you are next to a bottleneck, and the "municipal and/or corporate resistance" have now built out the core of the internet to the point that the problem is most severe at the very edge, including your laptop/handheld device.

*EVERYONE* has made the same set of mistakes. I have done so too at times....

Yes, and since the BDP is not knowable usually (neither the bandwidth or delay are predictable these days in many/most circumstances), we have to be smart (need AQM).

The problem is *we don't know* what will happen.

The network is operating in a regime it wasn't intended to... And we lack the instrumentation we need to understand how the internet is operating.

The buffers are now so large that we've defeated the basic congestion avoidance algorithms (slow start and congestion avoidance). Technically, TCP congestion avoidance is operating, but the time gets so long that TCP thinks the path changed, and probes more aggressively for a new operating point, as explained in the article.We are flying in a piece of the flight envelope that has not been tested. That was a big surprise, when we dug into the traces.

That should make us nervous.

We've also had one credible report of a significant network that collapsed and was very difficult to restart. We don't know exactly what all happened (and hopefully never will; we just are frustrated we don't have packet traces).

Re: 1. I've always thought that the congestion window to the same end-point should be shared: but that's not the way TCP implementations work, and wishing they worked that way won't make the problem go away. And, as I've shown, bufferbloat is not a TCP phenomena in any case.

Re: 2. HTTP is a lousy protocol in and of itself, and having to do it on top of TCP makes it yet harder. It is the fact that HTTP is so ugly that makes so much else difficult. And I disagree with your claim that high latency links won't use the bandwidth; in fact, lots of sessions is just making things harder. You can read our HTTP/1.1 Sigcomm performance paper.

I'll be writing more on this topic this week.

And we need to replace HTTP, and something other than TCP would be highly desirable. Personally, I'm much more fond of CCNx than any IP based transport.

Thank you for the kind words.

It helps for the several months of lonely work setting the stage for this for it to have succeeded this way.

Your Linux (and Mac and Windows) laptops also suffer from bufferbloat.

As does your home router and 802.11 network.

As do some ISP's.

Don't think the problem is just in your broadband. It's all over.

You asked, I just provided:

http://gettys.wordpress.com/what-is-bufferbloat-anyway/

Good question.

Bufferbloat is the cause of much of the poor performance and human pain using today’s internet. It can be the cause of a form of congestion collapse of networks, though with slightly different symptoms than that of the 1986 NSFnet collapse. There have been arguments over the best terminology for the phenomena. Since that discussion reached no consensus on terminology, I invented a term that might best convey the sense of the problem. For the English language purists out there, formally, you are correct that “buffer bloat” or “buffer-bloat” would be more appropriate.

I’ll take a stab at a formal definition:

Bufferbloat is existence of excessively large (bloated) buffers into systems, particularly network communication systems.

Systems suffering from bufferbloat will have bad latency under load under some or all circumstances, depending on if and where the bottleneck in the communication’s path exists. Bufferbloat encourages congestion of networks; bufferbloat destroys congestion avoidance in transport protocols such as HTTP, TCP, Bittorrent, etc. Without active queue management, these bloated buffers will fill, and stay full.

More subtlety, poor latency, besides being painful to users, can cause complete failure of applications and/or networks, and extremely aggravated people suffering with them.

Bufferbloat is seldom detected during the design and implementations of systems as engineers are methodical people, seldom if ever test latency under load systematically, and today’s memory is so cheap buffers are often added without thought of the consequences, where it can be hidden in many different parts of network systems.

You see manifestations of bufferbloat today in your operating systems, your home network, your broadband connections, possibly your ISP’s and corporate networks, at busy conference wireless networks, and on 3G networks.

Bufferbloat is a mistake we’ve all made together.

We’re all Bozos on This Bus.

A very long time ago, in a galaxy far, far away (MIT, mid 1970's, when I was an undergraduate and a member of MIT"s Planetary Astronomy Laboratory of that era), I remember having conversations with Mike Gaffey about asteroid mining. I see a reference to Technology Review on asteroid mining from Mike in 1977, so I think this got all published; I don't have any TR's of that era around to refresh my memory.

I remember one interesting scheme, where you might take a m-type metallic asteroid (which is mostly iron, nickel, and other useful metals) to earth orbit, by any of a number of propulsion schemes (solar sail, ion engine, or the like). It would probably take a number of years to move it from the asteroid belt to earth orbit. Then foam the asteroid (use solar mirrors to make it molten, and inject gas), and shape it into a lifting body. Then you would fly it into the earth's atmosphere, and land it in the ocean outside any port you would care to deliver it to. The point of foaming it was to reduce its density so that it would reenter the earth's atmosphere without much heating and ablation (we don't want to dump lots of metal into the earth's upper atmosphere), and float when you landed it.

Then you take a tug boat and pull it to a dock, and you have however many kilotons of metal you like. And without the huge energy cost of mining and environmental problems on earth.

As I remember, all the physics work (without having to invent fundamental new technologies), and there are lots of metallic asteroids. Now we just have to figure out how to actually do it. And it is way, way easier to deal with getting to and from the asteroids than the moon or any planet.
                                                                        - Jim

And Chuck is building hardware which is often, or even usually, running Linux right now.

Track down the research project that's doing big programmable multiprocessors at Berkeley/Stanford/MS research and others.

The x86 instruction set is too baroque to fit in a sane number of gates, so in fact most of the software on that hardware is free and open source software.

I'm tickled pink.

His contributions are inspiring; in fact playing with an Alto so many years ago was the first time I got to mess with a graphics display and mouse, if only on an occasional basis for a few hours.

And I had a chance to work with Chuck a bit: he's great people, and has continued to do first class stuff ever since.
 

I live about 22 miles outside of Cambridge, where I have often worked. So that is 44 miles/day@ $.5 per mile (U.S. government reimbursement). Your actual costs will vary; but the government rate isn't far from reality. Parking is about $20/day in Cambridge; sometimes more, sometimes less depending on the lot.

$5500 - Mileage
$5000 - Parking

Round numbers for automobile commute: $10,500

Note that there are hidden costs of road maintenance, etc.

Additionally, it is my time; on the commuter rail, at least I get (at least) an hour of my time back.

$2400/year - Commuter rail ticket (also covers unlimited subway use)
$1500/year - Mileage to train station.

Commuter rail commute is therefore about $3900, before any tax breaks (or lower auto insurance rate, due to less mileage and lower theft rates).

Savings for me (excluding tax break and insurance break) was about $6-7K/year.

And the following data:
http://w3schools.com/browsers/browsers_os.asp
is very different (4x higher).

And I can argue both sides of these numbers: people learning web technologies may be more or less likely to be Linux users, statistically.

So right now, we're seeing data that is based on marketing: the web site with the best marketing department has the most widespread results (and who knows who pays their marketing budget, to be paranoid?).

Only Google and similar organizations know "for sure", and even then *they* don't due to embedded uses of Linux, POS systems, and the developing world where traffic statistics will be undercounted.

At best, you can use these data sources for *trends*, and not absolute numbers.