Vendors on flow control

Hewlett-Packard says...

Flow Control was originally invented to prevent packet drops by switches that were running at less than media-speed. At that time the method of control was usually back-pressure. This was not a standardized method, but was effective in preventing any data loss. It also could substantially lower overall throughput through the segments being flow controlled. And core switches and routers did not use it.

Now there is a standardized means of flow control in IEEE 802.3x. It doesn't change the debate, however, as to whether it should be implemented in a core switch. It is actually more detrimental to flow control in the core than helpful. Flow control in the core can cause congestion in sections of the network that otherwise would not be congested. So how do you decide which segments to hold off when one of the segments gets congested? Even a network manager familiar with the traffic patterns of his/her network would, in many cases, be hard pressed to answer this question due to the dynamic nature of network traffic. And if particular links are constantly in a congested state, there is most likely a problem with the current implementation of the network.

The best way to handle any potential congestion in the backbone can much better be answered through CoS/QoS controls that many core switches, such as the HP ProCurve Routing Switch 9304M, have implemented. Prioritizing packets through multiple queues (the 9304M has 4 queues) provides far more sophisticated traffic control (such as targeting specific application packet types) than an all-or-nothing, or even a throttled form of flow control. CoS/QoS can provide policy-based traffic shaping and guarantee that the proper traffic gets through in cases of temporarily limited bandwidth. This sophistication is becoming more important as different emphasis is placed on differing types of traffic.

The one area where flow control can add value is in an edge switch, such as the HP ProCurve Switch 4000M. At this point in the network, the singular clients can be held off without potentially affecting large areas of the network. Flow control can be useful, for example, if the uplink is being swamped by individual clients. Even here, though, CoS/QoS will become more important over time. The 4000M supports tagging and can convert IP/TOS priorities to 802.1Q priorities and can set these parameters for multiple switches at a time through TopTools, our network management application that ships with each managed product. HP will continue to develop these capabilities over time, making 802.3x largely irrelevant in the future.

  

Cisco says...

The IEEE 802.3x Task Force defined Ethernet flow control, aka "Pause Frames", in 1997 as an optional clause of the specification for full duplex Ethernet. The IEEE 802.3 Ethernet standard does not require implementation of Ethernet flow control to be completely standards compliant.

The problem Ethernet flow control is intended to solve is input buffer congestion on oversubscribed full duplex links which cannot handle wire-rate input. The Cisco products tested, the Catalyst 2948G and Catalyst 8510 are both non-blocking, shared-memory devices, and therefore would never issue Pause frames since:

(1) They can sustain wirespeed throughput on all ports, so none of the links can become oversubscribed from input traffic, which is the problem Ethernet flow control is intended to solve.

(2) There are no "input buffers" to become congested. The test used tries to force a port to send Pause frames by putting it into a head-of-line blocking configuration. By definition, there is no "head-of-line blocking" in these products. This is one of the fundamental advantages of shared memory architectures.

Ethernet flow control is not intended to solve the problem of steady-state overloaded networks or links. Unfortunately, perhaps the only feasible way any network-based test can "force" a device under test to issue a Pause frame is to put it into exactly this situation. The port being tested is usually put it into a "head-of-line blocking" situation to simulate congestion. Typically this is achieved by oversubscribing a separate output port to which the port under test needs to send traffic. It can be argued that what the test primarily demonstrates is that the device under test is subject to head-of-line blocking. This test doesn't apply to non-blocking shared memory devices which are, by definition, not subject to head-of-line blocking.

If an output port is oversubscribed, having separate input ports issue Pause frames, and potentially cause blocking on other network devices by backward propagation of Pause frames, is not an appropriate long-term solution. For this reason, it can be argued that Pause Frames should not be used in a network core where they could potentially cause the delay of traffic unrelated to the oversubscription of a link. The right solution is to redesign the network with additional capacity, reduce the load, or provide appropriate end-to-end Quality of Service to ensure critical traffic can get through.

Ethernet flow control is also not intended to provide end-to-end flow control. End-to-end mechanisms, typically at the Transport Layer are intended to address such issues. The most common example is TCP Windows, which provide end-to-end flow control between source and destination for individual L3/L4 flows.

An example of where Ethernet flow control might be used appropriately is at the edge of a network where Gigabit Ethernet attached servers are operating at less than wirespeed, and the link only needs to be paused for a short time, typically measured in microseconds. The use of Pause frames to manage this situation may be appropriate under such circumstances.

Unfortunately, Ethernet flow control is commonly misunderstood. It is not intended to address lack of network capacity, or end-to-end network issues. Properly used, Ethernet flow control can be a useful tool to address short term overloads on a single link.

 

Foundry says...

The interoperability test highlighted both aspects of flow control mechanics; responding to (throttling) and transmitting flow control frames. Only a few test ports were actually used in this portion of the test. All Foundry Networks products are 802.3x compliant and implement flow control but will only generate flow control messages when total system resources rather than an individual buffer for a given port are almost depleted. This protects the rest of the device (and the network) from a problem that could be caused by a single port. Due to the BigIron's switched shared memory architecture, consuming the system resources requires more test equipment than was actually available for this particular phase of the Interoperability Test. Had there been enough traffic generation ports to consume the system resources, the BigIron would have generated flow control messages.