It's easy to make the mistake of assuming your application bandwidth is directly related to your WAN bandwidth. Most applications rely on TCP as an underlying transport mechanism, which is constrained by a window buffer. Most modern systems have a 65Kbyte window, which means only 65Kbytes of data can be in transit across the WAN before receiving an acknowledgment from the recipient host.
If your WAN latency is 100 millisecond, you could only have 65Kbytes of data in flight before the next acknowledgment. Another way to put this would be to say that you would only be able to achieve 81,250 bits/second!
Even if you have a DS3!!
To calculate your estimated WAN throughput on a per connection basis, use the following calculation:
TCP Throughput = WINDOW SIZE (bytes) / Latency (seconds)
Divide that by 8 to get your estimated throughput in bits per second. If your TCP throughput is higher than your WAN pipe, the TCP flow will be constrained by bandwidth. Of course, contention on the shared WAN and LAN will also affect these types of calculations. Various other factors can also affect this estimate.
Conversely the Bandwidth Delay Product is used to calculate the optimal TCP receive window size on a given network with a given latency value. This can be useful if you have to transfer large files across a large WAN, where the WAN latency is quite high. Of course, your OS and application needs to be receptive to TCP tuning. Not all applications can benefit from this type of tuning. Applications with a high number of request-response messages is considered to be chatty. The benefits of a large TCP buffer is marginal at best on chatty applications.
The formula for BDP:
BDP = (Bandwidth x Delay)
