Research recently conducted by Webtorials indicates that well over half of all IT organizations intend to increase their WAN bandwidth over the next year. That is not necessarily a bad thing. It is only a bad thing if companies are throwing bandwidth at a problem. In this context, "throwing bandwidth at a problem" refers to situations in which the IT organization does not understand the source of a performance problem and adds bandwidth in the hope that the problem will go away. Regrettably, hope is usually not an effective strategy.
Research recently conducted by Webtorials indicates that well over half of the 192 respondents surveyed intend to increase their WAN bandwidth over the next year. That is not necessarily a bad thing. It is only a bad thing if companies are throwing bandwidth at a problem. In this context, "throwing bandwidth at a problem" refers to situations in which the IT organization does not understand the source of a performance problem and adds bandwidth in the hope that the problem will go away. Regrettably, hope is usually not an effective strategy.
To put this in context, there are many situations in which adding bandwidth does nothing to improve the performance of an application. For example, consider a company that has a T-1 circuit from Boston to San Francisco that is experiencing 70 milliseconds of one-way delay. Further assume that the company is sending 128 octet packets, and that due to the TCP window size, it sends four packets at a time before it has to wait for an acknowledgement. This translates into the company sending 4,096 bits before it has to stop and wait.
In this case, the company is only getting 56K bit/sec of throughput on its T-1 circuit. If the company increases the circuit to T-3 speed, the throughput increases to 58K bit/sec.
Future newsletters will discuss why the throughput increased by 2K bit/sec, the primary sources of delay that limit the throughput, and will make suggestions for what can be done to improve the performance of this WAN.