OPSAWG K. Liu Internet-Draft China Mobile Intended status: Informational 6 July 2026 Expires: 7 January 2027 Ability Requirements for Stability Guarantees in Per-packet Load Balancing Networks draft-liu-opsawg-stbl-req-per-packet-00 Abstract Many per-packet load balancing mechanisms have been proposed to optimize the performance of AI networks. However, per-packet load balancing poses significant challenges to network stability assurance. This draft analyzes these challenges, as well as the ability requirements for stability guarantees in per-packet load balancing networks. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 7 January 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. Liu Expires 7 January 2027 [Page 1] Internet-Draft Abbreviated Title July 2026 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 2. Requirement Analysis . . . . . . . . . . . . . . . . . . . . 3 2.1. In-band Anomaly Detection and Location . . . . . . . . . 3 2.2. Fast Fault Notification and Convergence . . . . . . . . . 4 2.3. Explicit Packet Loss Signals . . . . . . . . . . . . . . 4 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 4. Security Considerations . . . . . . . . . . . . . . . . . . . 4 5. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 5.1. Normative References . . . . . . . . . . . . . . . . . . 4 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 6 1. 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. Liu Expires 7 January 2027 [Page 2] Internet-Draft Abbreviated Title July 2026 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. 1.1. 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. 2. Requirement Analysis 2.1. 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 Liu Expires 7 January 2027 [Page 3] Internet-Draft Abbreviated Title July 2026 and locate network performance bottlenecks in real time. 2.2. 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. 2.3. 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. 3. IANA Considerations There are no IANA consideration introduced by this draft. 4. Security Considerations There are no security issues introduced by this draft. 5. References 5.1. Normative References Liu Expires 7 January 2027 [Page 4] Internet-Draft Abbreviated Title July 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4560] Quittek, J., Ed. and K. White, Ed., "Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations", RFC 4560, DOI 10.17487/RFC4560, June 2006, . [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010, . [RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI 10.17487/RFC5881, June 2010, . [RFC5883] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883, June 2010, . [RFC6374] Frost, D. and S. Bryant, "Packet Loss and Delay Measurement for MPLS Networks", RFC 6374, DOI 10.17487/RFC6374, September 2011, . [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, May 2016, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8321] Fioccola, G., Ed., Capello, A., Cociglio, M., Castaldelli, L., Chen, M., Zheng, L., Mirsky, G., and T. Mizrahi, "Alternate-Marking Method for Passive and Hybrid Performance Monitoring", RFC 8321, DOI 10.17487/RFC8321, January 2018, . [RFC9341] Fioccola, G., Ed., Cociglio, M., Mirsky, G., Mizrahi, T., and T. Zhou, "Alternate-Marking Method", RFC 9341, DOI 10.17487/RFC9341, December 2022, . Liu Expires 7 January 2027 [Page 5] Internet-Draft Abbreviated Title July 2026 [RFC9342] Fioccola, G., Ed., Cociglio, M., Sapio, A., Sisto, R., and T. Zhou, "Clustered Alternate-Marking Method", RFC 9342, DOI 10.17487/RFC9342, December 2022, . [RFC9343] Fioccola, G., Zhou, T., Cociglio, M., Qin, F., and R. Pang, "IPv6 Application of the Alternate-Marking Method", RFC 9343, DOI 10.17487/RFC9343, December 2022, . Author's Address Kefe Liu China Mobile China Email: liukefei@chinamobile.com Liu Expires 7 January 2027 [Page 6]