PFC Working Principles: Which Statements Are False?

PFC starts at the receiver buffer, not at a full-buffer condition. When a packet of a given priority arrives at the receive end, it enters a per-priority ingress buffer. PFC monitors that buffer against an XOFF watermark. Once usage crosses that watermark, the receiver sends a PFC pause frame for that priority to the transmitter. The transmitter pauses only that priority, while other priorities continue. This is the step where option A fails: waiting until the buffer is full is too late and is not the PFC trigger.

The pause is released at a lower watermark. While the sender is paused, the receiver continues draining the buffer. When usage falls to the lower XON/resume watermark, the receiver sends the control frame that ends the pause. It does not need to wait until the buffer is completely cleared. That makes option B false: “only after the buffer is cleared” describes a drain-to-empty condition, not the actual PFC resume trigger. Option D describes the resume side correctly: after backpressure is active, the receiver sends the stop-pause/control frame once the buffer decreases to the configured extent.

Option C is the accurate XOFF description. It says the receive end sends PFC packets when received traffic exceeds a certain buffer threshold, requesting the transmit end to reduce its sending rate. That matches the watermark-driven PFC pause trigger, so C is true. In exam wording, PFC pause is often summarized as asking the sender to reduce or stop sending traffic of that priority; the key detail is that the request is threshold-based, not full-buffer-based.

Verdict: The false statements are A and B. A wrongly places the pause trigger at a full buffer, and B wrongly delays resume until the buffer is completely cleared. C and D align with the threshold-based XOFF and XON behavior of PFC.