Ability Requirements for Stability Guarantees in Per-packet Load Balancing Networks
draft-liu-opsawg-stbl-req-per-packet-00

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,
              <https://www.rfc-editor.org/info/rfc2119>.

   [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,
              <https://www.rfc-editor.org/info/rfc4560>.

   [RFC5880]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD)", RFC 5880, DOI 10.17487/RFC5880, June 2010,
              <https://www.rfc-editor.org/info/rfc5880>.

   [RFC5881]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881,
              DOI 10.17487/RFC5881, June 2010,
              <https://www.rfc-editor.org/info/rfc5881>.

   [RFC5883]  Katz, D. and D. Ward, "Bidirectional Forwarding Detection
              (BFD) for Multihop Paths", RFC 5883, DOI 10.17487/RFC5883,
              June 2010, <https://www.rfc-editor.org/info/rfc5883>.

   [RFC6374]  Frost, D. and S. Bryant, "Packet Loss and Delay
              Measurement for MPLS Networks", RFC 6374,
              DOI 10.17487/RFC6374, September 2011,
              <https://www.rfc-editor.org/info/rfc6374>.

   [RFC7799]  Morton, A., "Active and Passive Metrics and Methods (with
              Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799,
              May 2016, <https://www.rfc-editor.org/info/rfc7799>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [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, <https://www.rfc-editor.org/info/rfc8321>.

   [RFC9341]  Fioccola, G., Ed., Cociglio, M., Mirsky, G., Mizrahi, T.,
              and T. Zhou, "Alternate-Marking Method", RFC 9341,
              DOI 10.17487/RFC9341, December 2022,
              <https://www.rfc-editor.org/info/rfc9341>.

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,
              <https://www.rfc-editor.org/info/rfc9342>.

   [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,
              <https://www.rfc-editor.org/info/rfc9343>.

Author's Address

   Kefe Liu
   China Mobile
   China
   Email: liukefei@chinamobile.com

Liu                      Expires 7 January 2027                 [Page 6]