.svg)
After a couple of weeks covering Cisco Live, it’s time to follow up on my post about Data Centre Quantized Congestion Notification (DCQCN). You may recall that DCQCN is made up of ECN (Explicit Congestion Notification) which I discussed in DNA 26-05 and PFC (Priority Flow Control), which I will focus on today.
PFC has been around for a while and was traditionally used at Layer 2 to prevent network congestion. PFC used the COS field for classification but as RoCEv2 operates at Layer 3, the DCQCN implementation has been adapted to use the DSCP field instead, with RoCEv2 packets marked for PFC and added to a lossless queue. The buffers on these lossless queues have two levels, xOFF and xON. When the queue buffer goes above the xOFF level, a PFC frame with an xOFF (Pause Frame) is sent to the next hop device indicating that no more packets should be sent.
The next hop device will now likely have a build-up on its own queues and will in turn send a pause frame to the next upstream device. In this way, PFC Pause Frames propagate through the network to the transmitting host, which stops transmission. The queues on each of the devices will eventually drain and drop below the xON level, and pause frames will no longer be sent. The transmitting devices will either receive a PFC xON or the PFC Pause Timer will expire to allow transmission to begin again. See the diagram below for an illustration of this process.
There are a few other noteworthy points on PFC. Firstly, a faulty device or host can trigger a PFC storm by flooding needless PFC Pause Frames onto the network and preventing transmission. This scenario can be mitigated by using the PFC Watchdog feature which is available on most vendor platforms. Secondly, PFC is considered the failsafe to ECN – ECN will handle short periods of congestion, such as micro-bursts with PFC only kicking in when significant or continuous congestion occurs.
