diff --git a/doc/qos/dscp-remapping-images/Bounced-back-traffic-flow-PFC.png b/doc/qos/dscp-remapping-images/Bounced-back-traffic-flow-PFC.png new file mode 100644 index 0000000000..d34702a688 Binary files /dev/null and b/doc/qos/dscp-remapping-images/Bounced-back-traffic-flow-PFC.png differ diff --git a/doc/qos/dscp-remapping-images/Bounced-back-traffic-flow.png b/doc/qos/dscp-remapping-images/Bounced-back-traffic-flow.png index 44f806d5f9..4b9aa16718 100644 Binary files a/doc/qos/dscp-remapping-images/Bounced-back-traffic-flow.png and b/doc/qos/dscp-remapping-images/Bounced-back-traffic-flow.png differ diff --git a/doc/qos/tunnel_dscp_remapping.md b/doc/qos/tunnel_dscp_remapping.md index 4b7499103e..1617383eb9 100644 --- a/doc/qos/tunnel_dscp_remapping.md +++ b/doc/qos/tunnel_dscp_remapping.md @@ -40,9 +40,16 @@ This document covers high level design of DSCP and TC remapping for tunnel traff In Dual-ToR scenario, PFC deadlock can happen if two servers are congested at same time and start sending PFC pause frames to both upper ToR and lower ToR. It is because the south bound traffic from T1 to standby ToR is bounced back to T1 via the same queue. Even when the block condition is resolved, the pause condition among T1 and both ToRs can stay forever and no traffic will go through. To avoid this scenario, the bounced-back traffic from standby ToR to T1 will be remapped into another queue. For example, the traffic flow is as below if we are going to remap traffic in queue 3 to queue 2. +

Figure 1. Bounced back traffic flow

+ +When congestion happens on server, the traffic flow of PFC pause frames is as below diagram. + +

+Figure 2. Bounced back traffic flow with PFC pause +

The current QoS map architecture allows for port-based selection of each QoS map. However, we are not able to override the port-based QoS map for tunnel traffic. This design proposes a method to remapping DSCP and TC for tunnel traffic.