Generally, flow-control is a mechanics allowing the receiving party of a connection to control the rate of the sending party. You may see many different implementations of flow-control technologies at different levels of OSI model (e.g. XON/XOFF for RS232, TCP sliding window, B2B credits for Fibre Channel, FECN/BECN for Frame-Relay, ICMP source-quench message, etc). Flow-Control allows for explicit feedback loop and theoretically implementing loss-less networks that avoid congestion.

For the original Ethernet technology on half-duplex connections there was no possibility of implementing explicit flow control, since only one side could send frames at time. However, you may still remember the Cisco's so-called "back-pressure" feature on some of the older switches, e.g. Cisco Catalyst 1924. The idea was that switch may send barrage of dummy frames on a half-duplex link, effectively preventing the attached station from transmitting information at given moments of time.

Things changed with full-duplex point-to-point connections. The idea of IEEE 802.3X flow-control was to allow a station on a point-to-point link sending a special "PAUSE" frame (destined to a reserved multicast MAC address 01:80:C2:00:00:01). This frame would signal the other end of the connection to pause transmission for a certain amount of time, which was is specified in the frame. (Note that the PAUSE frame uses MAC LLC encapsulation). The attached device could be a host station or another switch - it does not matter. Upon receiving the PAUSE frame, the sender should stop the traffic flow and either buffer the packets or drop them. The paused switch may in turn propagate the PAUSE frame further upstream toward the sending node, and thus congestion notification will propagate end-to-end.

There were two main problems with the 802.3x flow-control. Firstly, there were interoperability problems with different vendors implementing the PAUSE functionality. Secondly, the PAUSE frame mechanics was too simple to implement granular policies, for example based on per-VLAN or per-class basis. This being said, mixing PAUSE functionality with per-class services was impossible - it would stop sending of all traffic, regardless of QoS marking. This is why it's typically advised to turn off 802.3X flow control whether you enable MLS QoS on a Cisco switch be it 3550 or 3560. By default flowcontrol is disabled and you can only enable a Cisco switch to receive PAUSE frames, but not to send them.

Use the following commands to set up and verify your current flow-control settings:

SW1:

interface GigabitEthernet0/1

 flowcontrol receive on
giga1-sw-ats64#show interfaces gigabitEthernet 0/1 flowcontrol

Port       Send FlowControl  Receive FlowControl  RxPause TxPause

           admin    oper     admin    oper

---------  -------- -------- -------- --------    ------- -------

Gi0/1      Unsupp.  Unsupp.  on       on          0       0

Even though the simple 802.3X flow-control idea did not work out well, the evolving body of DCB (data-center bridging) standards uses similar, yet more granular mechanism to implement lossless Ethernet transmissions. Lossless Ethernet is important for storage transportation protocols such as FCoE and is one of the cornerstones of the evolving data-center Ethernet standard.