Flow control feedback

Flow control is a mechanism created to manage the flow of data between two full-duplex Ethernet devices. Through flow control, a device that is oversubscribed - either macroscopically from a system resource perspective or microscopically on a port-by-port basis - sends a pause message to its link partner to temporarily reduce the amount of data it's transmitting. Otherwise, buffer overflow occurs, data is lost and retransmission is required.

When we conceived these interoperability tests, we thought flow control would be a pretty straightforward test. After all, there's a standard for how a switch should act: IEEE's 802.3x standard for flow control over Fast Ethernet and Gigabit Ethernet. But the IEEE standard only requires a device to respond to pause frames and doesn't require it to initiate pause frames. We set out to determine which devices send, receive and respond to pause messages after we deliberately oversubscribed a single port.

Well, vendors had a lot to say about that, particularly since not all their devices are capable of receiving, sending and/or responding to pause messages. Devices that support Symmetric Flow Control can transmit and receive pause frames. Devices that support Asymmetric Flow Control can only transmit or receive pause frames.

Nonetheless, we continued as planned, but promised vendors the opportunity to air their views on flow control. Most were quick to point out that they adhere to the specification because they respond to the pause frames. True, though in our tests we found those responses varied.

To begin with, most vendors have different thresholds for initiating such messages. Cabletron and Foundry Networks initiate pause messages when their boxes are under heavy utilization and system resources become scant because we oversubscribed only one port and didn't attempt to saturate the entire switch, Cabletron and Foundry never initiated pause messages in our tests. Both say their boxes would initiate pause frames under greater load.

Hewlett-Packard points out that quality of service is a better way to handle potential congestion, and Cabletron and Nortel note that QoS features can't operate properly if a switch sends pause frames.

Cisco's edge devices don't initiate flow control messages to remove the possibility of an edge switch slowing the core network. Cisco and Nortel also point out that pause messages could potentially cause head-of-line blocking.

The pros and cons of flow control implementations depend on how a device is deployed in an enterprise and the type of network traffic (data, voice or video) being carried among its link partners.

Kilmartin and Hamilton are engineer/analysts at The Tolly Group. They oversaw the Ethernet switch interoperability testing in New Jersey and, with Tolly Director of Engineering John Curtis, developed the interoperability testing methodology. Kilmartin and Hamilton can be reached at gkilmartin @tolly.com and shamilton @tolly.com.

See what the vendors have to say

Switch vendors pass interoperability tests
The main article on switch interoperability. Network World, 9/13/99.

SwitchMetric results
Latest data from our cost/performance testing of LAN switches.

Feedback
Tell us your thoughts on this article or the issues it raises.