Inflight Packet Adjustment
Figure 6-12 depicts the ACK_CC header structure and fields. When NSCC is enabled in the UET node, the PDS must use the pds.type ACK_CC in the prologue header, which serves as the common header structure for all PDS messages. Within the actual PDS ACK_CC header, the pds.cc_type must be set to CC_NSCC. The pds.ack_cc_state field describes the values and states for service_time, rc (restore congestion CWND), rcv_cwnd_pend, and received_bytes. The source specifically utilizes the received_bytes parameter to calculate the updated state for inflight packets.
The CCC computes the reduction in the inflight state by subtracting the rcvd_bytes value received in previous ACK_CC messages from the rcvd_bytes value carried within the latest ACK_CC message. As illustrated in Figure 6-12, the inflight state is decreased by 4,096 bytes, which is the delta between 16,384 and 12,288 bytes.
Recap: In order to transport data to network, the Inflight bytes must be less than CWND size.
Figure 6-12: NSCC: Inflight Bytes adjustment.
CWND Adjustment
A single, shared Congestion Window (CWND) regulates the total volume of bytes across all PDCs that are permitted for transmission to the backend network. The transport rate and network performance are continuously monitored and serve as the baseline information for dynamic CWND adjustments. The primary objective of these adjustments is to maintain minimal queue depth to eliminate queuing delay while ensuring the backend network is not overloaded, thereby guaranteeing lossless, line-rate packet transport.
Figure 6-13 illustrates the ACK_CC message structure, specifically the pds.flags field, which indicates whether a switch in the backend network has experienced congestion in an outgoing interface queue. The m-flag is set when the packet being acknowledged carries ECN-CE bits within the ToS field of the IP header.
In addition to the ECN state, the CWND adjustment algorithm compares the measured Queuing Delay against the Target Delay. As a recap from the Inflight section, the Queuing Delay is calculated as follows:
Queuing Delay = Ack_arrival_time - pkt_tx_state – service_time
The pkt_tx_state is recorded by the PDS and passed to the CCC, which derives the queuing delay by subtracting both the transmission timestamp and the service_time from the ACK arrival time.
The service_time is measured at the target by calculating the delta between the packet reception time (rx_time) and the response transmission time (tx_time). This value is encoded into the service_time parameter within the pds.ack_cc_state field. It represents the total processing overhead for the Packet Delivery and Semantic Sublayers to handle the RMA operation, including header extraction, memory addressing, data writing, SES response generation, and ACK_CC construction. By isolating this processing time, the source can accurately determine the true delay caused strictly by the network fabric.
Proportional and Fast Increase Logic
When the m-flag is clear (indicating no ECN-CE bits are detected) and the calculated Queuing Delay is less than the Target Delay, the network utilization is considered below its optimum. In this state, the CWND size increment is directly related to the magnitude of the difference between the measured queuing delay and the target delay.
A large difference between these two values indicates that network utilization is low and the path can handle a significantly higher volume of flows. The NSCC algorithm responds by increasing the CWND at a rate proportional to this gap, allowing more room for inflight packets. As the measured delay approaches the target delay and the difference narrows, the rate of increase automatically slows down to stabilize the flow.
In scenarios where the network remains significantly underloaded for a duration, such as when competing flows terminate, the system can escalate to a fast_increase. This mode employs exponential growth to quickly converge on the newly available bandwidth, remaining active until the system detects the first signs of incipient congestion.
Fair increase Logic
The fair_increase action is initiated when the system detects that a congestion event is subsiding. This state occurs when ECN signals indicate that the network queue has drained below the configured threshold, even if a previous packet experienced congestion. This mechanism is primarily designed to prevent the transmission rate from "undershooting" the actual network capacity during the recovery phase.
In this mode, the NSCC algorithm performs an additive increase rather than a proportional one. By adding a constant, fixed amount to the CWND, the system promotes fairness among competing flows. Because every flow receiving the same signal increases its CWND by the identical fixed value, flows with smaller windows experience a larger relative growth rate compared to those with larger windows. This ensures that all active flows eventually converge toward an equitable share of the available bandwidth.
Multiplicative Decrease Logic
The multiplicative_decrease action is triggered when the measured Queuing Delay exceeds the Target Delay and ECN feedback indicates that the network queue is not effectively decreasing. In this state, the average delay serves as a direct metric for the volume of excess data currently enqueued beyond the desired threshold.
The NSCC algorithm reacts by reducing the CWND proportionally to this measured queuing excess. By directly tying the window reduction to the specific magnitude of the buffer overflow, the system can rapidly shed load to alleviate congestion. When all competing flows execute this coordinated reduction, the objective is to clear the bottleneck and return the queue to its target occupancy level within approximately one Round-Trip Time (RTT).
Figure 6-13: NSCC: CWND Adjustment.
NSCC Summary
The Network-Signaled Congestion Control (NSCC) framework is designed to solve the fundamental challenge of high-performance networking: maximizing throughput while maintaining near-zero latency. This objective is achieved by managing a continuous balance between Inflight Load and the CWND Budget.
The system continuously adjusts transmission rates to ensure optimal network utilization. By proactively responding to fabric signals, NSCC maintains line-rate performance and prevents bufferbloat (a jam before buffer overflow), ensuring that packets spend as little time as possible waiting in switch queues. The core gatekeeper rule of the transport layer is defined by the relationship between two variables. Inflight bytes represent the real-time volume of data currently transiting the network, while the Congestion Window (CWND) represents the total data budget the network can safely handle. The source calculates the current Inflight state by tracking cumulative received_bytes from ACK_CC messages, and new data is only injected into the fabric when the Inflight count is lower than the CWND.
The sender dynamically scales the CWND budget using a sophisticated state machine based on the m-flag (ECN-CE) and measured Queuing Delay. It utilizes Proportional or Fast Increase to fill available bandwidth when the network is underutilized, ensuring the pipe remains full. As congestion clears, the Fair Increase mechanism ensures multiple flows converge to an equitable share of the pipe. Conversely, the Multiplicative Decrease action aggressively slashes the window when buffers overflow to protect the fabric from packet loss.
No comments:
Post a Comment