Bandwidth * Delay Product

Question

I'm trying to calculate the bandwidth delay product between various hosts, and reading this wiki article, I am confused.

From the acticle;

Residential ADSL2+: 20 Mbit/s (from DSLAM to residential modem), 50 ms RTT

B×D = 20×106 b/s × 50×10-3 s = 106 b, or 1 Mb, or 125 kB.

One of the connections I am testing from, to a test host, is an ADSL2+ connection. It has a downstream sync rate of "11006 kbps", I am guestimating that 10000Kbps is a reasonable theoretical maximum throughput. When "ping'ing" the test host from the ADSL2+ line I get an RTT of 29ms. The test host is connect to the "Internet" with a 100Mbps Ethernet connection.

Now, here's the confusing part; Performing a speed test against the server (it is running a copy of speedtest.net's mini speed test app) I get 9.23Mbps for the downstream. According to that Wiki article, 10000000bps * 0.029s = 290000bps (290 Kbps), which is much less than my 9.23Mbps.

Have I missed something obvious, or is the article wrong?

Answer 1

I'm trying to calculate the bandwidth delay product between various hosts... Have I missed something obvious, or is the article wrong?

You're only missing the units; when you multiply bps by seconds, you get bits as the units:

10Mbps * .029s = 2900000.0 bits (362500 bytes)

The point of the article is that it highlights what your (scaled) TCP window needs to be in order to avoid delays due to a "long fat network". Quoting RFC 1072:

Recent work on TCP performance has shown that TCP can work well over a variety of Internet paths, ranging from 800 Mbit/sec I/O channels to 300 bit/sec dial-up modems [Jacobson88]. However, there is still a fundamental TCP performance bottleneck for one transmission regime: paths with high bandwidth and long round-trip delays. The significant parameter is the product of bandwidth (bits per second) and round-trip delay (RTT in seconds); this product is the number of bits it takes to "fill the pipe", i.e., the amount of unacknowledged data that TCP must handle in order to keep the pipeline full. TCP performance problems arise when this product is large, e.g., significantly exceeds 10**5 bits. We will refer to an Internet path operating in this region as a "long, fat pipe", and a network containing this path as an "LFN" (pronounced "elephan(t)").

In this particular case, TCP needs to give you a scaled window size that is roughly 362KB. Modern TCP implementations (those that properly implement RFC 1323) do not suffer from issues related to LFNs.