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.'"
Re:s/slower/laggier/ (Score:5, Informative)
Yup, and another error in TFS is:
According to researchers, the cause is persistently full buffers.
should be "a cause".
Lame, misleading summaries is par for the course around here, though. But look on the bright side--it helps keep us on our toes, sorting sense from nonsense, and helps us spot the real idiots in the crowd. :)
At least this one had a link to a fairly reliable source. It wasn't just blog-spam to promote some idiot's misinterpretation of the facts. Might have been nice to also provide a link to bufferbloat.net [bufferbloat.net] or Wikipedia on bufferbloat [wikipedia.org], as well, for background information, but what can you do?
Re:Summary so awful, it just hurts. (Score:5, Informative)
It is definitely a terrible summary, but the ACM article it links to is actually quite interesting. (You do know what the ACM is, don't you?) And bufferbloat has nothing to do with discs, so your objection is completely off base. It certainly would have helped if the summary had given you any idea what bufferbloat is, of course, so I understand your confusion. But it's a real thing. The problem is that the design of TCP/IP includes built-in error correction and speed adjustments. Large buffers hide bottlenecks, making TCP/IP overcorrect wildly back and forth, resulting in bursty, laggy transmission.
Re:Where's the incentive? (Score:5, Informative)
Today, there is no incentive for an ISP to consider spending money on this. For their private customers, they sell QoS, which guarantees their customers a better queuing method. Extremely profitable. For consumers, it makes sense to simply continue investing in infrastructure.
You appear to be confused about the issue. This is not about capacity and oversubscription. This is about a pathology of queueing.
The packets leaving a router, once it has figured out where they go, are stored in a buffer, waiting their turn on the appropriate output interface. While there are a lot of details about the selection of which packet leaves when, you can ignore it and still understand this particular issue: Just assume they all wait in a single first-in-first-out queue and leave in the order they were processed.
If the buffer is full when a new packet is routed, there's nothing to do but drop it (or perhaps some other packet previously queued - but something has to go). If there are more packets to go than bandwidth to carry them, they can't all go.
TCP (the main protocol carrying high-volume data such as file transfers) attempts to fully utilize the bandwidth of the most congested hop on its path and divide it evenly among all the flows passing through it. It does this by speeding up until packets drop, then slowing down and ramping up again - and doing it in a way that is systematic so all the TCP links end up with a fair share. (Packet drop was the only congestion signal available when TCP was defined.)
So the result is that the traffic going out router interfaces tends to increase until packets occasionally drop. This keeps the pipes fully utilized. But if buffer overflow is the only way packets are dropped, it also keeps the buffers full.
A full buffer means a long line, and a long delay between the time a packet is routed and the time it leaves the router. Adding more memory to the output buffer just INCREASES the delay. So it HURTS rather than helping.
The current approach to fixing this is Van Jacobson's previous work: RED (Random Early Drop/Discard). In addition to dropping packets when the buffer gets full, an very occasional randomly-chosen packet is dropped when the queue is getting long. The queue depth is averaged - using a rule related to typical round-trip times - and the random dropping increases with the depth. The result is that the TCP sessions are signalled early enough that they back off in time to keep the queue short while still keeping the output pipe full.The random selection of packets to drop means TCP sessions are signalled in proportion to their bandwidth and all back off equally, preserving fairness. The individual flows don't have any more packets drop on the average - they just get signalled a little sooner. Running the buffers nearly empty rather than nearly full cuts round-trip time and leaves the bulk of the buffers available to forward - rather than drop - sudden bursts of traffic.
ISPs have a VERY LARGE incentive to do this. Nearly-full queues increase turnaround time of interactive sessions, creating the impression of slowness, and dropping bursty traffic creates the impression of flakeyness. This is very visible to customers and doing it poorly leaves the ISP at a serious competitive disadvantage to a competitor that does it well.
So ISPs require the manufacturers of their equipment to have this feature. Believe me, I know about this: Much of the last 1 1/2 years at my latest job involved implementing a hardware coprocessor to perform the Van Jacobson RED processing in a packet processor chip, to free the sea of RISC cores from doing this work in firmware and save their instructions for other work on the packets.
Re:And why... (Score:2, Informative)
What matters is not (if we put privacy aside) that 10 domains are requested, but that there are 10 (mostly) different routes to 10 different servers. If a single of these routes or servers are slow, the website loaded will load slow as well.