Drop Congestion Notification (DCN)

Benefits of Drop Congestion Notification (DCN)

• DCN reduces end-to-end latency by enabling faster retransmissions through packet trimming, thereby decreasing the time needed for data recovery during congestion.

• DCN improves flow completion times by avoiding full packet drops, maintaining consistent data transfer rates, and enhancing overall network performance.

• By prioritizing DCN packets in high-priority queues, it ensures critical data is transmitted even under heavy network load.

• DCN offers seamless integration with existing congestion management technologies such as ECN and PFC, providing flexibility and compatibility across various networking environments.

• DCN simplifies network management by reducing the complexity of state machine operations at end hosts, which helps maintain optimal throughput and system efficiency.

Overview

DCN introduces a novel approach to congestion management by trimming packet payloads instead of dropping packets entirely during network congestion. This method significantly reduces end-to-end latency as it allows packet headers to be sent immediately through a dedicated high-priority queue, facilitating rapid retransmission requests. By employing DCN, you streamline flow completion times and maintain consistent data transfer rates, crucial for ensuring optimal network performance even under heavy congestion conditions. The feature is designed to work seamlessly alongside existing congestion management tools such as ECN and PFC, offering enhanced compatibility and flexibility across various networking environments.

Figure 1 explains the network level view of DCN.

The network-level implementation of DCN involves two key elements: End Hosts and Transit Switches. The following outlines the sequence of events in the DCN process.

1. The sender end host creates DCN-capable packets by adding a DCN shim header to the original data packet. This converts the packet into a DCN-enabled packet. Additionally, the sender host assigns a specific L4 destination port number that corresponds to the DCN. The size of the DCN shim header must be at least 8 bytes.

2. The DCN data packets reach a transit switch—in this case, a QFX5240. If the packet encounters congestion on the egress queue and the buffer becomes exhausted, it will be tail dropped.

3. With DCN enabled on the transit switch, the transit switch truncates the dropped packet to the size of a single cell, marks it as a DCN drop packet, and places it in a high-priority queue with dedicated bandwidth toward the original destination. This trimmed version of the packet retains all the necessary headers (L2, L3, L4, DCN) and part of the payload. As the packet is reduced in size and classified into a high-priority queue, there is a higher likelihood that it will successfully egress from the transit switch. On the QFX5240, each trimmed packet must be 206 bytes or smaller.

4. If DCN is enabled on subsequent transit switches, they can classify the DCN drop packets into high-priority queues, ensuring that these packets have precedence over regular data packets.

5. The trimmed DCN drop packets are received by the receiver end host. It is the responsibility of the end host to extract the necessary data from these trimmed packets and use it for the end-to-end control loop. A user-defined algorithm running on the end host manages the processing of the DCN drop notification packets.

6. The receiver end host identifies the exact dropped packet using the DCN drop notification and generates a retransmission request specifically for the missing packet, which is then sent to the sender host.

7. The sender end host, upon receiving the DCN feedback, immediately re-transmits the exact packet and adjusts the flow rate.

DCN's packet management system segregates packets into distinct types

• DCN data packets – DCN capable packets that can be trimmed when there is congestion

• DCN data dropped packets – DCN packets that have been trimmed and sent high priority to their destination.

• DCN control packets

This differentiation allows for more precise control over network traffic during congestion, ensuring critical data is prioritized for transmission. The dedicated high-priority queuing mechanism further enhances the likelihood of successful packet egress, even when the network is under significant load. DCN's interoperability with ECN and PFC ensures that it can coexist with other devices, treating DCN-unaware packets as regular data packets, thereby maintaining a cohesive network environment. However, DCN is restricted to UDP traffic and does not support Layer 2 or non-unicast traffic, which are important considerations when planning network architecture.

The DCN header utilizes the most significant two bits, known as Congestion Notification (CC) bits, to identify DCN packets across the network. These bits are crucial for signaling congestion and managing packet flow efficiently. Understanding the DCN header allows network engineers to precisely identify and handle congestion notification packets, ensuring they receive the necessary prioritization. While DCN can coexist with ECN and PFC without conflict, it is important to note its limitations, such as support restricted to UDP traffic and exclusion from Layer 4 protocols other than UDP. Additionally, DCN does not carry routing plane information, which may influence its application in specific network configurations. These header details should be considered when implementing DCN to ensure optimal network performance and compatibility.

Note:

Packet trimming is most effective when it is applied to large data packets (e.g. 4KB), because it reduces the data rate significantly. Conversely, trimming packets just fractionally larger than single cell size (206 bytes) provides little data reduction, and can even be detrimental if a large fraction of bandwidth is used by trimmed packets.