Ability Requirements for Stability Guarantees in Per-packet Load Balancing Networks

Introduction The rapid development of AI services has led to the continuous expansion of the network scale, causing the network to become a performance bottleneck. To optimise network performance, many per-packet load balancing mechanisms have been proposed. However, per-packet load balancing poses significant challenges to the guarantee of network stability. Firstly, packet path tracking becomes more difficult. In flow-based networks, packets with the same five-tuple traverse the same network path. When an anomaly occurs (e.g., packet loss or abnormally high latency), the faulty network path can be tracked by replaying the anomalous 5-tuple, which helps to further locate the failed network device. However, in per-packet load balancing networks, packets are randomly sprayed across parallel paths, making 5-tuple-based path tracking impossible. Secondly, per-packet load balancing networks require faster fault notification and convergence. Since packets in a single flow are sprayed across parallel paths, network failures have a more severe impact on packet spraying networks than on per-flow networks. Therefore, per-packet load balancing networks require real-time fault notification mechanisms to enable rapid network recovery and minimize the impact of failures on service performance. In addition, packet spraying networks require explicit loss notification. In traditional per-flow networks, packets from a single flow traverse the same network path and will not be out-of-order. Therefore, when the destination device receives an out-of-order packet, it can clearly identify the loss event. However, in per-packet load balancing networks, packet spraying inevitably causes out-of-order packet arrival. This makes it difficult for the receiver to detect packet loss based on the packet order. As a result, when packet loss occurs, the receiver must wait for a timeout before triggering a retransmission, which significantly degrades network performance. Per-packet networks require a more explicit loss notification mechanism to improve retransmission efficiency. This draft analyzes the ability requirements for stability guarantees in per-packet load balancing networks.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Requirement Analysis

In-band Anomaly Detection and Location Firstly, packet loss has a severe impact on the throughput of AI services and is also the most obvious indicator of network failures. Therefore, it is essential to precisely locate packet loss in real time. In flow-based networks, packets with identical 5-tuples follow the same path. When probes or service packets are dropped, operators can replay the lost packets with path-tracking tools (e.g., Traceroute) to identify the abnormal network path and further locate the faulty network device. However, in per-packet networks, packets with the same 5-tuple may be randomly sprayed along parallel paths, making replay-based path tracking mechanisms ineffective. Per-packet load balancing networks require the ability to detect and locate anomalies in-band without replaying packets for path tracking. In addition to loss detection and location, in-band performance measurement is also important. AI services are highly sensitive to network bottlenecks and their performance can degrade severely when hot spots occur. In flow-based networks, these bottlenecks can be located by tracking the paths of packets with high latency. However, since the packet replay mechanism is ineffective in per-packet load balancing networks, in-band performance measurements, such as per-hop latency and buffer measurements, are required to accurately identify and locate network performance bottlenecks in real time.

Fast Fault Notification and Convergence In per-packet load balancing networks, packets in a flow are randomly sprayed across different paths. As a result, the number of flows on each switch and link in packet spraying networks increases significantly compared to flow-based networks. When a link or switch fails, a greater number of flows are affected. Therefore, per-packet load balancing networks require faster failure detection and notification mechanisms to achieve rapid network convergence, thereby minimising the impact of network failures on service performance. Furthermore, for host-based stateful spraying schemes (e.g., MRC and UEC), fast fault notification to source hosts can avoid spraying packets to faulty switches or links when failures occur, thereby further improving the efficiency of fault recovery.

Explicit Packet Loss Signals In flow-based networks, packets within a flow traverse the same network path, ensuring they reach the destination NIC in order. When an out-of-order packet arrives at the destination NIC, it can detect the loss event and notify the source NIC for retransmission. In contrast, random spraying makes out-of-order arrival inevitable, and destination switches and NICs in per-packet load balancing networks typically have the ability to handle out-of-order packets. However, this reduces the efficiency of loss packet retransmission, as the destination device cannot identify whether out-of-order arrival is caused by packet loss. When a loss event occurs, the destination NIC must wait for a timeout before sending a retransmission signal, which results in degraded network performance. Therefore, in per-packet load balancing networks, an explicit loss notification is required when a packet is dropped to inform the destination device for efficient retransmission. Furthermore, if the source NIC can be notified directly, retransmission efficiency can be further improved.

IANA Considerations There are no IANA consideration introduced by this draft.

Security Considerations There are no security issues introduced by this draft.