Automatic Bandwidth Delay Product Discovery

Probably the most important unsolved technical problem with TCP over high-performance networks today is automatically determining the bandwidth-delay-product (BDP), which is used to specify the simplified maximum TCP window size for each TCP session. The correct BDP is extremely important for maximum utilization of high-performance networking without undue memory consumption, particularly over very long-distance high-performance networks.

The simplified BDP is calculated by multiplying the round-trip-time (RTT) by the maximum bandwidth of the least-capable hop of all of the router hops between two hosts using the TCP protocol. The RRT is easily obtained with the "ping" protocol, which utilizes an ICMP echo request message, which is a special IP message that is echoed back to the sending host by the receiving. Simply measuring the time it takes to get the echoed message back provides the RTT.

Right now, however, there is no way quick and easy method to automatically obtain the least-bandwidth number between an arbitrary pair of TCP hosts, so all users who expect to obtain high-performance networking results are required to manually compute this value, which essentially implies that such users must have an intimate knowledge of the complete network topology between their own host and any host with which they wish to communicate. Furthermore, every application that is to make use of this information requires special coding and special user-interface parameters. This is a ludicrous situation akin to having to be an expert automobile mechanic to be able to drive an automobile (which was actually the case at the dawn of the automobile age). As long as it requires network-engineer training for any user that must deal with BDP-discovery, we too will remain only at the dawn of the high-performance networking era.

The method proposed herein for automatic BDP discovery and caching is to use a simple mechanism modeled after the ICMP Echo Request and Echo Reply protocol to discover the bandwidth of the least-capable hop between a given source and destination host pair. This new mechanism could be a new type of ICMP Request/Reply pair, or it could be a simple enhancement to the existing Echo Request/Reply, but using a new IP option class/number combination. The main difference between the new mechanism and the existing ICMP Request/Reply pair is that the router would have to process two new fields in the message.

This new mechanism would actually be different from the ICMP Echo protocol in only a couple of ways, and would work as follows:

1. Two new fields would be defined for the Request and Reply message types:
   1. A Next-Hop-Least-Bandwidth-Request Field, and
   2. A Next-Hop-Least-Bandwidth-Reply Field
2. BDP Request and Reply would work like Echo Request and Reply does now except each router along the path would intercept the BDP messages and perform the following before forwarding the message to the next hop:
   1. If the message is a Request, then the router would compare the value of the Next-Hop-Least-Bandwidth-Request field with the router’s best knowledge of the next hop’s maximum possible bandwidth, and if this next hop bandwidth is less than the field’s value, then the new value would be overwritten in the field, otherwise the field’s existing value is unchanged. Essentially, the router should always compare the maximum possible bandwidth of the next hop with the current Next-Hop-Least-Bandwidth-Request value. The goal is to return the maximum possible bandwidth of the least-capable link in the path so that the maximum TCP window will never be too small to consume all possible bandwidth, should such bandwidth ever be available. If a router isn't exactly sure of a link's maximum possible bandwidth, it should therefore use the largest bandwidth it thinks a link may be capable of. Note that this procedure is not a bandwidth allocation scheme and a router should never use a value smaller than the maximum bandwidth that a link is capable of.
   2. If the message is a Reply, then the router would compare the value of the Next-Hop-Least-Bandwidth-Reply field with the router’s best knowledge of the next hop’s maximum possible bandwidth, and if this next hop bandwidth is less than the field’s value, then the new value would be overwritten in the field, otherwise the field's existing value is unchanged. Essentially, the router should always compare the maximum possible bandwidth of the next hop with the current Next-Hop-Least-Bandwidth-Reply value. The goal is to return the maximum possible bandwidth of the least-capable link in the path so that the maximum TCP window will never be too small to consume all possible bandwidth, should such bandwidth ever be available. If a router isn't exactly sure of a link's maximum possible bandwidth, it should therefore use the largest bandwidth it thinks a link may be capable of. Note that this procedure is not a bandwidth allocation scheme and a router should never use a value smaller than the maximum bandwidth that a link is capable of.
3. The source host would fill in the initial Next-Hop-Least-Bandwidth-Request value, while the destination host would fill in the initial Next-Hop-Least-Bandwidth-Reply value. The destination host is also responsible for converting the received Request message into the outgoing Reply message, preserving all information received in the Request message, just as it would for a normal Echo Request message. The destination host could also extract the value of the Next-Hop-Least-Bandwidth-Request Field.

Note that when the BDP Reply arrives at the source host, it would provide the RRT plus the least-bandwidth information for both the forwarding and return paths between the source host and the destination host, which is all the information necessary to calculate the pair of simplified BDPs. This information would be cached in a new kernel table indexed by destination host IP addresses, and individually cached entries would timeout after some suitable interval to force fresh information to be obtained.

Development of this BDP protocol initially requires the cooperation of at least one router vendor, though a crude prototype could be demonstrated with traceroute and SNMP-derived information.