Congestion Control Context
Ultra Ethernet Transport (UET) uses a vendor-neutral, sender-specific congestion window–based congestion control mechanism together with flow-based, adjustable entropy-value (EV) load balancing to manage incast, outcast, local, link, and network congestion events. Congestion control in UET is implemented through coordinated sender-side and receiver-side functions to enforce end-to-end congestion control behavior.
On the sender side, UET relies on the Network-Signaled Congestion Control (NSCC) algorithm. Its main purpose is to regulate how quickly packets are transmitted by a Packet Delivery Context (PDC). The sender adapts its transmission window based on round-trip time (RTT) measurements and Explicit Congestion Notification (ECN) Congestion Experienced (CE) feedback conveyed through acknowledgments from the receiver.
On the receiver side, Receiver Credit-based Congestion Control (RCCC) limits incast pressure by issuing credits to senders. These credits define how much data a sender is permitted to transmit toward the receiver. The receiver also observes ECN-CE markings in incoming packets to detect path congestion. When congestion is detected, the receiver can instruct the sender to change the entropy value, allowing traffic to be steered away from congested paths.
Both sender-side and receiver-side mechanisms ultimately control congestion by limiting the amount of in-flight data, meaning data that has been sent but not yet acknowledged. In UET, this coordination is handled through a Congestion Control Context (CCC). The CCC maintains the congestion control state and determines the effective transmission window, thereby bounding the number of outstanding packets in the network. A single CCC may be associated with one or more PDCs communicating between the same Fabric Endpoint (FEP) within the same traffic class.
Initializing Congestion Control Context (CCC)
When the PDS Manager receives an RMA operation request from the SES layer, it first checks whether a suitable Packet Delivery Context (PDC) already exists for the JobID, destination FEP, traffic class, and delivery mode caried within the request. If no matching PDC is found, the manager allocates a new one.
For the first PDC to a particular destination, a Congestion Control Context (CCC) is required to manage end-to-end congestion for that flow. The PDS Manager requests the CCC from the CCC Manager in the Congestion Management Sublayer (CMS). The CCC Manager creates the CCC, which initially enters the IDLE state, containing only the basic structure without active configuration.
Next, the CCC is initialized with the required congestion control parameters, such as the initial congestion window (CWND). Once these parameters are in place, the CCC transitions from IDLE to ACTIVE. In the ACTIVE state, the CCC holds all configuration information and is associated with the PDC, but data transport has not yet started.
When the CCC is fully configured and ready for operation, it transitions to the READY state. This transition signals that the CCC can now enforce congestion control policies and monitor traffic. At this point, the PDC is allowed to begin sending data, and the CCC will track and regulate the flow according to the congestion control algorithms.
The CCC serves as the central control structure for congestion management, hosting sender-side (NSCC) or receiver-side (RCCC) algorithms. A CCC is unidirectional and is instantiated independently on both the sender and receiver, where it is locally associated with the corresponding PDC. Once in the READY state, it maintains the state required for regulating data flow, ensuring that NSCC and RCCC can effectively enforce congestion windows, credits, and path usage to avoid network congestion and maintain efficient data transport.
Note: In this model, the PDS Manager acts as the control-plane authority responsible for context management and coordination, while the Packet Delivery Context (PDC) performs data-plane execution under the control of the Congestion Control Context (CCC). Once the CCC is operational and the PDC is authorized for data transport, RMA data transfers proceed directly over the PDC without further involvement from the PDS Manager.
Figure 6-6: Congestion Context: Initialization.
