|Automatic Bandwidth Delay Product Discovery||
FAQ | News | Partnerships | Home
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:
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.
Last Modified: 12/31/69 07:00PM
This material is based in whole or in part on work supported by the
National Science Foundation under Grant No. 0083285. Any opinions,
findings and conclusions or recommendations expressed in this
material are those of the author(s) and do not necessarily reflect
the views of the National Science Foundation (NSF).|