Sizing router buffers

Abstract

All Internet routers contain buffers to hold packets during times of congestion. Today, the size of the buffers is determined by the dynamics of TCP's congestion control algorithm. In particular, the goal is to make sure that when a link is congested, it is busy 100% of the time; which is equivalent to making sure its buffer never goes empty. A widely used rule-of-thumb states that each link needs a buffer of size B = RT T × C, where RT T is the average round-trip time of a flow passing across the link, and C is the data rate of the link. For example, a 10Gb/s router linecard needs approximately 250ms × 10Gb/s = 2.5Gbits of buffers; and the amount of buffering grows linearly with the line-rate. Such large buffers are challenging for router manufacturers, who must use large, slow, off-chip DRAMs. And queueing delays can be long, have high variance, and may destabilize the congestion control algorithms. In this paper we argue that the rule-of-thumb (B = RT T × C) is now outdated and incorrect for backbone routers. This is because of the large number of flows (TCP connections) multiplexed together on a single backbone link. Using theory, simulation and experiments on a network of real routers, we show that a link with n flows requires no more than B = (RT T × C)/ √ n, for long-lived or short-lived TCP flows. The consequences on router design are enormous: A 2.5Gb/s link carrying 10,000 flows could reduce its buffers by 99% with negligible difference in throughput; and a 10Gb/s link carrying 50,000 flows requires only 10Mbits of buffering, which can easily be implemented using fast, on-chip SRAM.

A non-invasive method for link upgrade planning using coarse-grained measurements

“…Remark: We note that in environments with many traffic sources and a reasonable degree of traffic multiplexing (such as occurs in network core routers), small buffer sizes do not have a detrimental effect on router throughput (see, e.g., [2]). …”

Emulating AQM from end hosts

“…As a result, it is not necessary to respond with a 50% window reduction in case of early response. In [1], the authors suggest that router buffers are commonly set to the BandwidthDelay Product of the link since the TCP flow reduces its window by 50%. If TCP flows were to use a factor f reduction during loss, then the relationship between the buffer size B and the window reduction factor f can be re-written as…”

“…We attempt to make our evaluation realistic by simulating a wide range of network parameters. We first present the results for a single bottleneck topology with bottleneck link bandwidth in the range of [1 Mbps, 1 Gbps], RTT in the range of [10 ms, 1 s], the number of long-term background flows in the range of [1,1000] and the number of web sessions in the range of [10,1000] …”

“…August 27-31, 2007, Kyoto, Japan. per RTT to probe for available bandwidth 1 . When congestion is perceived, the congestion window is decreased by half to relieve the congestion.…”

Phrase based browsing for simulation traces of network protocols

“…NS2 is well known and used extensively in the networking research community. The simulator is frequently used to build traffic models, as in the paper by Lang, Branch, and Armitage (2004), or to test new network protocols, as in (Appenzeller, Keslassy, and McKeown 2004) and (Zapotoczky and Wolter 2008).…”