Hi Xiao Min, Thank you for submitting the draft. Below are some quick comments after I read it.
PFC aims to achieve lossless ethernet within DCN, so I guess the propagated back pressure pause packet is also intended for lossless WAN. But the WAN has much longer path span and the latency could be tens to hundreds of milliseconds. The buffer headroom required could be primitively large. PFC is applied for a whole priority queue on a link which could include many IP flows from many paths. Sending pause packets for each of them could have a large overhead and bandwidth impact. PFC has many negative side effects such of HoL blocking, PFC propagation, potential deadlock. That's why it's only used as the last resort when e2e congestion control can't make it. Extending it to WAN could only exacerbate the situation. The pause could paralyze the entire WAN. Therefore, I think the mechanism should be meticulously evaluated and tested before considering the standardization. Cheers, Haoyu From: [email protected] <[email protected]> Sent: Friday, February 27, 2026 12:19 AM To: [email protected] Subject: [rtgwg] Congestion Notification for Pause Dear all, A new document draft-xiao-rtgwg-congestion-notification-for-pause-01 has been submitted. Link as below. https://datatracker.ietf.org/doc/html/draft-xiao-rtgwg-congestion-notification-for-pause-01 This draft defines the IP Pause message which is analogous to Ethernet PFC frame. Except for the different layers, the IP Pause message is distinct from the PFC frame in that, the IP Pause messages are all sent from one node (the egress PE) while the PFC frames may be sent by multiple nodes along the path with stepwise backpressure. Looking forward to your review and comments. Cheers, Xiao Min
_______________________________________________ rtgwg mailing list -- [email protected] To unsubscribe send an email to [email protected]
