Controlling Bufferbloat With Queue Delay 134
CowboyRobot writes "We all can see that the Internet is getting slower. According to researchers, the cause is persistently full buffers, and the problem is only made worse by the increasing availability of cheap memory, which is then immediately filled with buffered data. The metaphor is grocery store checkout lines: a cramped system where one individual task can block many other tasks waiting in line. But you can avoid the worst problems by having someone actively managing the checkout queues, and this is the solution for bufferbloat as well: AQM (Active Queue Management). However, AQM (and the metaphor) break down in the modern age when Queues are long and implementation is not quite so straightforward. Kathleen Nichols at Pollere and Van Jacobson at Parc have a new solution that they call CoDel (Controlled Delay), which has several features that distinguish it from other AQM systems. 'A modern AQM is just one piece of the solution to bufferbloat. Concatenated queues are common in packet communications with the bottleneck queue often invisible to users and many network engineers. A full solution has to include raising awareness so that the relevant vendors are both empowered and given incentive to market devices with buffer management.'"
s/slower/laggier/ (Score:5, Insightful)
The Internet is not getting slower. It is becoming laggier. Comeon people, learn the difference.
Re:s/slower/laggier/ (Score:5, Insightful)
And smaller buffers will help. Larger buffers do almost nothing to increase throughput, but they can increase latency. Having buffers isn't a problem. Having buffers that are too large is a problem.
Summary so awful, it just hurts. (Score:4, Insightful)
Can we? It looks like it has been getting faster to me....
According to researchers, the cause is persistently full buffers,
What researchers? What buffers? Server buffers? Router buffers? Local browser buffers? Your statements are so vague as to be useless.
and the problem is only made worse by the increasing availability of cheap memory, which is then immediately filled with buffered data.
Buffering is a way of speeding servers up immensely. Memory is orders of magnitude faster than disk, and piling RAM on and creating huge caches can only help performance. I call bullshit on your entire claim. This summary is so awful, I don't even want to read whatever article you linked to.
Paper is ambiguous about what gets dropped (Score:4, Insightful)
It's not clear from the paper whether packet dropping is per-flow, in some fair sense, or per link. There's a brief mention of fairness, but it isn't explored. It sounds like the new approach has no built-in fair queuing.
Without fair queuing, whoever sends the most gets the most data through. Windows (especially) starts up TCP connections by sending as many packets as it can at connection opening. There used to be a convention in TCP called "slow start", where new connections started up sending only two packets, increasing if the round trip time turned out to be good. That was too pessimistic. But Windows now starts out by blasting out 25 or so packets at once. This hogs the available bandwidth through everything with FIFO queues.
If the routers at choke points (where bandwidth out is much less than bandwidth in, like the entry to a DSL line) do fair queuing by flow, the problem gets dealt with there, as the excessive sending fights with itself, trailing packets on the biggest flows are sent last, and everything works out OK.
"Bufferbloat" is only a problem when a small flow gets stuck behind a big one. A flow getting stuck behind the preceding packets of the same flow is fine; you want those packets delivered. Packet reordering is better than packet dropping, although more computationally expensive. Most CIsco routers offer it on slower links. Currently, this means links below 2Mb/s [cisco.com], which is very slow by modern standards. That's why we still have kludgy solutions like RED. This new thing is a better kludge, though.
My internets fine (Score:4, Insightful)