Bandwidth and QoS: Let's have a "peak"
|
|
|||
|
|
Sign up to receive this and other networking newsletters in your inbox.
Listen carefully to all the talk about delivering QoS in high-speed LAN environments and you may notice one aspect that is usually avoided: Peak Bandwidth. It's not a term that many vendors are touting, and it isn't even standardized - although perhaps it should be.
Unlike many QoS implementations that specify a guaranteed minimum bandwidth for a given connection, Peak Bandwidth specifies a maximum bandwidth, regardless of how few stations are on the network. Therefore, it can deliver two benefits: First, it can reduce congestion by throttling traffic on the backbone before it gets to slower departmental LANs. Second, it can help ensure that more powerful workstations with voluminous file transfers don't subdue mission-critical, low-bandwidth interactive applications.
ATM provides a good example of how Peak Bandwidth works: An ATM connection is configured for a Peak Cell Rate (PCR) that defines the maximum data rate for a given virtual circuit; this rate is usually lower than the physical link speed. Now consider an OC-3 connection operating at 155M bit/sec with a data rate of 149.76M bit/sec. A given virtual circuit within that physical link may be limited to a PCR that provides, say, only 30M bit/sec. In LAN-based systems, Peak Bandwidth might establish a maximum rate of only 15M bit/sec within an available 100M bit/sec Fast Ethernet LAN.
To put things in perspective, recall that frame-based "QoS" solutions traditionally presume that all connections on the net should be able to burst to the maximum LAN speed whenever allowed. This would seem to be the most efficient use of network resources. Unfortunately, simply specifying only minimum bandwidth can actually contribute to congestion. Powerful applications can occupy large quantities of bandwidth on the backbone that simply won't fit on lower speed departmental LANs. Traffic moving from the backbone to workgroups may encounter congestion. Controlling the bandwidth on faster LANs can help prevent congestion before it can occur.
Another problem with allowing applications to burst to line speed at will is that it means allocating bandwidth on a first-come, first-served basis. In practice, this often results in low-priority, high-performance "background" batch applications consuming considerably more bandwidth than they need. This, in turn, can potentially snuff out high-priority traffic from less powerful workstations. Moreover, bandwidth reservation schemes that provide for only minimum bandwidth eventually favor more aggressive applications and protocol stacks that take whatever is available, regardless of the overriding business objectives.
Considering the important benefits of Peak Bandwidth, such functionality should be on the short list of product features as customers deploy higher speed campus LANs such as Gigabit Ethernet.
RELATED LINKS
The quality-of-service quandary: Network World, 4/13/98.
Switch users in for QoS cost surprise: Network World, 3/23/98.
Why you need a QoS scheme: Network World, 3/16/98.
