Saturday, May 28, 2011

Why use the bandwidth delay product (BDP) and not just bandwidth or delay in protocol design

In this discussion, I am trying to reason why we use the BDP for optimal transport protocol design, and not just use either bandwidth, or delay. I think this is best explained with a couple of examples.

You would say that I could possibly decide the performance of a link purely based on bandwidth? Right? In some cases it does work out. For example, if a link has high throughput, then I know that it has high capacity and I can decide the congestion windows so that a large number of packets remain un-acknowledged and vice-versa.  So this worked fine over here.

Now consider a satellite link. In this case my bandwidth is low. However, if you use this information for scheduling and leaving very few open packets, the high delay on the link will result in very poor performance. Imagine waiting for every packet to be acknowledged before transmission of the next. Hence, in this case too, it makes sense to have a large number of packets. Thus we want to send more unacknowledged packets on the link, when either the bandwidth is high, or the delay is high, thus in this case, the bandwidth delay product (BDP) is an excellent indicator. It is also observed that for most links, this product remains constant, giving a good idea of the general link characteristics irrespective of instantaneous performance.

These characteristics make the BDP an important metric in setting parameters like the congestion window (CW) in TCP. The higher the BDP, the larger should be the CW. If this is not the case, it will lead to a suboptimal use of the link.

Please feel free to post comments and discuss this topic as desired.


Post a Comment