Bandwidth is getting less expensive all the time. Networks are delivering more data in a given amount of time.
Bandwidth is not infinite, however. Applications fight over bandwidth, and if the wrong application wins -- and a voracious, time-sensitive and key convergence app loses-- the overall level of service suffers.
As the name implies, traffic management software attempts to referee these conflicts. Late last month, Propel Software released Personal Bandwidth Management (PBM) software. The goal is to simplify the way in which users monitor and control the applications running on their devices. InformationWeek says that PBM shows which applications are running, their upstream and downstream data rate at any point in time, and the cumulative amount of bandwidth being used. The software enables users to give a higher priority to a chosen application and to reallocate bandwidth based on the current traffic mix.
This TMCnet post gives a thumbnail example of how an organization can implement bandwidth management. In the example, a company's financial department is assigned 20 percent of the overall bandwidth. Forty percent may be reserved for e-mail (SMTP) traffic, 30 percent for Internet (HTTP) traffic, and 30 percent to miscellaneous protocols. Setting limits makes it impossible for one application to dominate the network. The example goes a step further: Suppose, for instance, that SMTP is using only 25 percent to 40 percent of the bandwidth it is allotted, while HTTP is running full throttle. A bandwidth management system would enable the user to direct HTTP to momentarily burst into the unused portion of the SMTP traffic.
Bandwidth management is an issue at all stops on the network or, more accurately, the network of networks that take signals from one place to another. This is as big a concern in the core of the Internet and in carrier and service provider networks as it is on the enterprise local-area network (LAN).
In the legacy telephone world, there is a concept called contention. Simply, no network will work if everybody who has a phone decides to use it at the same time. This level of robustness simply isn't cost-effective because it would be used so rarely. The industry, over its century of history, has become very good at figuring out the lowest amount of bandwidth to have in place to keep things moving in a vast majority of cases. But if the unforeseen occurs -- an earthquake on Mother's Day, for instance -- any network will buckle.
Contention also is an issue in IP-based convergence. This Quality Real-Time Traffic post does a good job of discussing some of financial factors play into this. There also are IP network-specific issues to consider. For instance, e-mail and other TCP-based protocols are flexible. If the network slows down, the protocol compensates. The extra second or so it takes to send the data will never be noticed. This, the writer says, is called "graceful degradation." In real-time voice streams, however, the use of a different protocol -- User Datagram Protocol -- and the demanding nature of the content delivery demands more draconian.
The writer of this blog post makes a compelling case that bandwidth management will fall short in an era in which the needs are growing so rapidly. He also points out that throwing bandwidth at problems doesn't always work, since some applications have trouble navigating networks even if they have enough capacity.
The answer -- or at least part of the answer -- is bandwidth governance. This, simply, is making sure that apps are bandwidth efficient. This should be a part of the design process, and ways should be found to retrofit applications that already are deployed.