|
Bufferbloat is a phenomenon in packet-switched networks, in which excess buffering of packets causes high latency and packet delay variation (also known as jitter), as well as reducing the overall network throughput. When a router device is configured to use excessively large buffers, even very high-speed networks can become practically unusable for many interactive applications like voice calls, chat, and even web surfing. The bufferbloat phenomenon was initially described as far back as in 1985,〔(【引用サイトリンク】 On Packet Switches With Infinite Storage )〕 and gradually became more recognized as an issue. It gained more widespread attention starting in 2009. Overly large buffers have been placed in some models of equipment by their manufacturers. In such equipment, bufferbloat occurs when a network link becomes congested, causing packets to become queued in buffers for too long. In a first-in first-out queuing system, overly large buffers result in longer queues and higher latency, but do not improve network throughput and may even reduce goodput to zero in extreme cases. == Buffering == Bufferbloat as an issue is caused mainly by router and switch manufacturers making incorrect assumptions and buffering packets for too long in cases where they should be dropped, in an attempt to keep a congested link as busy as possible. The rule of thumb for the network equipment manufacturers was to provide buffers large enough to accommodate 250 ms (or more) worth of traffic passing through a device. For example, that way, a router's 1 Gbit/s Ethernet interface requires a huge 32 MB buffer. Such sizing of the buffers can lead to TCP's congestion-avoidance algorithms breaking, causing problems such as high and variable latency, and choking network bottlenecks for all other flows as the buffer becomes full of the packets of one TCP stream and other packets are then dropped. The buffers then take some time to drain, before the TCP connection ramps back up to speed and then floods the buffers again. A bloated buffer has an effect only when this buffer is actually used. In other words, oversized buffers have a damaging effect only when the link they buffer for becomes a bottleneck. When the current bottleneck on the route from or to another host is not contended, it is easy to check whether it is bloated or not using the ping utility provided by most operating systems. First, the other host should be pinged continuously; then, a several-seconds-long download from it should be started and stopped a few times. By design, the TCP congestion avoidance algorithm rapidly fills up the bottleneck on the route. If downloading (and uploading, respectively) correlates with a direct and important increase of the round trip time reported by ping, then it proves that the buffer of the current bottleneck in the download (and upload, respectively) direction is bloated. Since the increase of the round trip time is caused by the buffer on the bottleneck, the maximum increase gives a rough estimation of its size in milliseconds. In the previous example, using an advanced traceroute tool instead of the simple pinging (for example, MTR) will not only demonstrate the existence of a bloated buffer on the bottleneck, but will also pinpoint its location in the network. Traceroute achieves this by displaying the route (path) and measuring transit delays of packets across the network. The history of the route is recorded as round-trip times of the packets received from each successive host (remote node) in the route (path). 抄文引用元・出典: フリー百科事典『 ウィキペディア（Wikipedia）』 ■ウィキペディアで「bufferbloat」の詳細全文を読む スポンサード リンク
|