Ethernet links can move frames faster than a receiving device can process or forward them. When that mismatch lasts long enough, receive buffers fill and frames may be dropped.

IEEE 802.3x flow control provides a link-level response for full-duplex Ethernet. A device can send a MAC Control PAUSE frame that asks its directly connected peer to stop transmitting ordinary data frames for a specified interval. The pause is temporary, local to that link, and different from congestion control performed by higher-layer protocols.

A PAUSE frame carries a timer

A PAUSE frame is a MAC Control frame. Its control opcode identifies the pause operation, and its pause-time field contains a 16-bit value measured in units of 512 bit times.

The receiving peer uses that value to defer normal frame transmission. A value of zero cancels an active pause, allowing transmission to resume without waiting for the previous timer to expire.

The real duration represented by one pause unit depends on link speed because the unit is defined in bit times. At 1 Gbit/s, 512 bit times equal 512 nanoseconds. At 10 Gbit/s, the same unit equals 51.2 nanoseconds.

A sender can issue another PAUSE frame before the timer expires if pressure remains. This lets flow control extend the quiet period without assigning an unlimited duration in a single frame.

PAUSE is not an end-to-end network signal. A switch that sends a PAUSE frame asks the device on the other end of that Ethernet link to reduce transmission. Routers and remote hosts elsewhere in the path do not receive that request as a general congestion notification.

This scope matters in switched networks. Suppose a server sends traffic into a switch faster than a congested output port can drain it. If the relevant switch buffer reaches a threshold, the switch may pause the server-facing link. The server then stops sending ordinary frames on that link for the requested period.

The immediate buffer pressure can fall, but the original bottleneck may still exist. Link-level flow control can move waiting time toward the sender rather than remove the capacity mismatch.

Classic 802.3x PAUSE affects the transmitting direction broadly. It does not identify one TCP connection, one VLAN, or one application flow that should stop while all others continue.

That broad effect can create head-of-line blocking. A peer may have traffic for several destinations, yet a pause request can hold all ordinary transmission on the affected link even when only one downstream destination is congested.

This behavior is especially important on busy switch uplinks and server interfaces carrying many independent flows. Avoiding a frame drop for one congested path can add latency to traffic that had available capacity elsewhere.

For general-purpose networks, packet loss plus end-to-end congestion control can therefore be preferable to propagating link pauses through a large topology.

Pause propagation can spread congestion

A congested switch can pause an upstream neighbor. That neighbor may then accumulate frames in its own buffers. If those buffers also cross a flow-control threshold, another upstream link may be paused.

This chain is often called congestion spreading. The physical bottleneck remains in one part of the network, but its backpressure can affect devices and traffic farther away.

Large buffers do not eliminate this effect. They can delay frame loss, but sustained offered load above available output capacity still creates a queue that must eventually be drained, limited, or dropped.

A stable design therefore treats PAUSE as one possible buffer-management mechanism, not as extra bandwidth.

Priority Flow Control narrows the pause scope

Data-center Ethernet can use Priority Flow Control, defined in IEEE 802.1Q, to apply pause behavior to selected traffic priorities rather than stopping the entire link.

PFC is useful in environments where particular traffic classes are designed to operate with very low loss. A receiver can signal pause state separately for enabled priorities, allowing other priorities to continue transmitting.

That finer scope does not make congestion disappear. Poor queue design, excessive use of lossless classes, or cyclic dependencies can still create severe blocking. PFC deployments need compatible queue mapping, buffer thresholds, and traffic engineering across participating devices.

Classic PAUSE and PFC therefore solve related but different problems. Classic PAUSE controls the link as a whole, while PFC adds per-priority control.

Negotiation determines whether flow control is active

Ethernet devices can advertise pause capabilities during auto-negotiation. The advertised combinations allow link partners to resolve whether pause handling is symmetric or asymmetric.

Symmetric operation means both sides can participate in sending and honoring pause requests. Asymmetric combinations support cases where pause behavior is desired primarily in one direction.

Interface settings shown by an operating system or switch can be confusing because transmit and receive flow-control labels describe different actions. Receive flow control usually refers to honoring PAUSE frames received from the peer. Transmit flow control refers to generating PAUSE frames toward the peer when local receive pressure reaches configured thresholds.

Both link partners and the negotiated result matter. Enabling a setting on one side does not guarantee the final link behavior matches that setting in isolation.

PAUSE frames are not TCP flow control

Several mechanisms can slow traffic, but they operate at different layers and scopes.

TCP receive-window flow control prevents a TCP sender from overrunning the receiving TCP endpoint’s advertised buffer capacity. TCP congestion control adjusts sending behavior in response to network conditions. Ethernet PAUSE acts between directly connected Ethernet interfaces and can affect traffic from many protocols at once.

A PAUSE frame also does not tell an application that a downstream service is overloaded. From the application’s perspective, the immediate effect may simply appear as added transmission delay.

Keeping these mechanisms separate is useful during troubleshooting. A link with active pause events can show little packet loss while still suffering latency from queue buildup and repeated transmission stops.

Counters can reveal sustained backpressure

Managed switches and server NICs often expose counters for transmitted and received pause frames. Rising counters show that link-level flow control is being exercised, but the count alone does not identify the root bottleneck.

A few pause events during short bursts can be harmless. Continuous or rapidly increasing counts can point to persistent queue pressure, an oversubscribed downstream link, a slow receiver, or thresholds that are too aggressive.

Useful investigation pairs pause counters with interface utilization, queue occupancy or drop counters, traffic-class statistics, and the topology around the affected port.

The direction matters as well. A port transmitting many PAUSE frames is asking its peer to stop. A port receiving many is being asked to stop by its peer.

Flow control trades drops for waiting time

Ethernet PAUSE can protect a receiving buffer during temporary bursts by stopping transmission on the adjacent full-duplex link. That can reduce frame loss when the pause interval gives the receiver enough time to drain queued data.

The tradeoff is delay and a wider blocking scope. Classic PAUSE can hold unrelated traffic, and repeated backpressure can spread congestion upstream. PFC reduces the scope to selected priorities but adds configuration and operational constraints of its own.

The practical question is not simply whether a link supports flow control. The important behavior is where queues form, which traffic gets stopped, how long the stop persists, and whether the network benefits more from temporary backpressure or from allowing controlled loss.

Networking Ethernet Flow Control Switching