IPPM Working Group X. He Internet-Draft China Telecom Intended status: Informational X. Min Expires: 7 December 2026 ZTE Corp. 5 June 2026 Requirements and Problem Statement for Monitoring Packet Loss Caused by Network Congestion draft-he-ippm-congestion-loss-monitoring-problem-00 Abstract Emerging services including enhanced Mobile Broadband (eMBB) and Ultra-Reliable Low Latency Communication (uRLLC), as well as Artificial Intelligence (AI)training and inference have imposed stringent requirements of "high throughput, low latency, and minimal packet loss" on IP bearer network performance. Network congestion can lead to performance degradation and increase uncertainty in service delivery, so real-time congestion monitoring is necessary. This document discuss the requirements of real-time monitoring of packet loss caused by congestion, present the problems and challenges faced by existing measurement techniques in monitoring congestion- induced packet loss. 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 December 2026. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. He & Min Expires 7 December 2026 [Page 1] Internet-Draft Requirements and Problem Statement for M June 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 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Requirements for Real-time Monitoring of Packet Loss Caused by Congestion . . . . . . . . . . . . . . . . . . . . . . . 4 4. Problem Statement for Monitoring Packet Loss Caused by Congestion . . . . . . . . . . . . . . . . . . . . . . . 7 5. Challenges for Real-time Monitoring of Packet Loss Caused by Congestion . . . . . . . . . . . . . . . . . . . . . . . 9 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 1. Introduction With the large-scale deployment of 5G networks, emerging services including enhanced Mobile Broadband (eMBB) and Ultra-Reliable Low Latency Communication (uRLLC) , demanding significantly reduced latency, minimized jitter, and near-zero packet loss rates [_GPP_TS_22.261]. At the same time, the technical development of Big Data and Artificial Intelligence (AI) calls for intelligent computing network infrastructure whose goal is to construct a lossless network characterized by "high throughput, low latency, and zero packet loss" [Adithya_Gangidi24][Kun_Qian24]. However, the inherent statistical multiplexing nature of TCP/IP-based IP networks results in bursty traffic patterns, making network congestion an inevitable occurrence. Such congestion phenomena degrade network performance and introduce the uncertainty in service delivery, e.g., loss leads to packet retransmission, increasing delay leads to decreasing throughput. For a long time, numerous studies have been concentrated on congestion control mechanisms and related algorithms [RFC9293][RFC9743] to improve network performance. He & Min Expires 7 December 2026 [Page 2] Internet-Draft Requirements and Problem Statement for M June 2026 Network congestion is roughly divided into two classes: long-lived congestion and short-lived congestion. A long lived congestion is generally caused by persistent traffic growth, e.g., congestion duration ranging from hours to days, which is easy to be observed through Network Management System/Element Management System (NMS/ EMS). However, a short-lived congestion is almost caused by traffic bursts, among which microburst is one of the major contributors. Microburst is a phenomenon where a device port receives a considerable amount of burst data in a very short time (i.e., typically hundreds of microseconds to tens of milliseconds), resulting in an instantaneous burst rate much higher than the average rate, even exceeding the port bandwidth [Microburst][Shuhei_Yoshida21]. A microburst is prone to packet loss but difficult to detect in time. Many investigations prove that microburst is the main culprit affecting latency-sensitive and packet loss-sensitive services. When a microburst occurs, the queuing time increases rapidly, and in severe case, packet loss may even occur, which are intolerable for applications like Virtual reality (VR). In order to reduce uncertain service delivery caused by network congestion, it is essential to monitor congestion-induced packet loss in real time so that network operators can quickly locate the congested nodes and links, and then make path optimization for the affected traffic flows to avoid congestion; and evaluate network congestion level so as to provide the guidance for network planning, capacity expansion and optimization. This document discusses the requirements of real-time monitoring of packet loss caused by congestion, presents the problems and challenges faced by existing monitoring and measurement techniques in real-time monitoring of congestion-induced packet loss. 2. Terminology Abbreviations used in this document: AI: Artificial Intelligence AltMark: Alternate-Marking DEX: Direct Exporting IOAM: In situ Operation, Administration, and Maintenance MPLS: Multi-Protocol Label Switching OAM: Operation, Administration, and Maintenance He & Min Expires 7 December 2026 [Page 3] Internet-Draft Requirements and Problem Statement for M June 2026 SRv6: Segment Routing over IPv6 VPN: Virtual Private Network 3. Requirements for Real-time Monitoring of Packet Loss Caused by Congestion Real-time monitoring of packet loss caused by congestion is valuable to network operators in many aspects, including quickly pinpointing the congestion location, making rapid path adjustment for loss- sensitive traffic flows once congestion loss is detected. More importantly, we can determine the nature of congestion based on real- time congestion loss statistics. That is, if the number of lost packets is persistently increasing for a longer time (e.g., hours level), a long-lived congestion event may occur; or, if packet loss happens in a very short time (e.g., milliseconds to seconds), a short-lived congestion event may occur. Moreover, we can obtain the characteristics of microbursts from real-time congestion loss statistics, such as the frequency and duration of microburst occurrence. On the other hand, measurement accuracy of congestion- induced loss is significant in evaluating congestion level, which provides the guidance for subsequent network expansion and optimization, as well as a reliable verification of user Service Level Objective (SLO) for packet loss. He & Min Expires 7 December 2026 [Page 4] Internet-Draft Requirements and Problem Statement for M June 2026 Generally speaking, for long-lived congestion events, if these monitored congestion events are local, for example, congestion occurs only in a very small part of nodes or links in the network, load balancing (e.g., by partitioning partial traffic into links with low utilization) is the most effective approach to eliminate congestion. But for short-lived congestion events, especially for microbursts, which typically occur randomly and globally, expanding the whole network capacity may be necessary to reduce congestion events if they occur frequently. At present, network operators usually regard network utilization as the only indicator of network expansion, and they collect minute-level link utilization data based on SNMP. This kind of average traffic statistical data skips many real-time short- lived congestion events observed actually as shown in Figure 1, which are exactly critical causes leading to bad quality of experience (QoE) for latency-sensitive and loss-sensitive services. So the frequency and duration time of short-lived congestion occurrence are also important concerns for capacity expansion. It is essential to determine proper frequency and duration time parameters for short- lived congestion occurrences. We can take both link utilization and short-lived congestion events into consideration in launching capacity expansion plan. Specifically, when the monitored average link utilization meets need of capacity expansion, say 50%, but the frequency and duration time parameters detected for short-lived congestion occurrence are far below the preset thresholds, we can wait some time; otherwise, we should take action immediately. Top: 5-minute sampling cycle utilization (%) 95% | 50% |--------------------------------------- 0% | ---------------- time (t)----------------> Bottom: millisecond sampling cycle (reveals microbursts) utilization (%) 95% | ^ ^ ^ 50% | | | | 0% | | | | [microburst] [microburst] [microburst] ---------------- time (t)----------------> Figure 1: Utilization Comparison between Different Sampling Cycle He & Min Expires 7 December 2026 [Page 5] Internet-Draft Requirements and Problem Statement for M June 2026 Another requirement is the real-time localization of congestion occurrence. It can help operators make rapid troubleshooting, improving the efficiency of fault diagnosis and root cause analysis. In addition, to analyze the cause of congestion, it is necessary to parse what traffic flows are contained in discarded packets and identify what traffic flows lead to the congestion such that we can take action to those culprits causing congestion. From the perspective of adaptability of packet loss monitoring and measurement methods, today's networks need to provide different transport modes for different services, accordingly, a kind of packet loss monitoring method is also required to adapt to various transport modes. For instance, L2/3 VPN is widely used by enterprise, and Multi-Protocol Label Switching (MPLS) technique has been deployed by network operators to deliver MPLS VPN services. With the evolution of the network and the emergence of new services, more transport protocols will emerge to adapt to the delivery of new services. An ideal packet loss monitoring scheme should be protocol-independent, that is, it is applicable to all current and future transport protocols, including native IPv4/6, SR-MPLS [RFC8402][RFC8660], SRv6 [RFC8986], Virtual eXtensible Local Area Network (VXLAN)[RFC7348] and General Routing Encapsulation (GRE)[RFC8086], etc., such that the data plane (e.g., forwarding chip) does not need to be upgraded and packet header encapsulation not to be modified to adapt to existing monitoring and measurement methods. Another praised feature for loss monitoring scheme is to make less or even no interference to network so that network load is less affected and hence the packet loss monitoring results can reflect the actual congestion state. In addition, for large-scale operator networks, typically tens of thousands of user flows need to be measured simultaneously, and the scalability is also vital factor in weighing a good monitoring method, that is, the number of concurrent measurements should be less limited by network resources (e.g., computing, storage or bandwidth). In summary, an ideal packet loss monitoring solution should include five aspects: * Real-time: The monitoring system is required to collect and analyze congestion-induced packet loss in real time to quickly pinpoint the congestion location and identify the cause of congestion. He & Min Expires 7 December 2026 [Page 6] Internet-Draft Requirements and Problem Statement for M June 2026 * Accuracy: The monitoring system is required to provide the accurate measurement results for packet loss caused by congestion so that the operators can accurately assess the status and trend of the network congestion and make appropriate decisions. * Protocol-independent: The monitoring system is required to be independent of network transport protocols so that the data plane does not need to be upgraded and packet header encapsulation does not need to be modified. * Little or even no interference to network: The monitoring system is required to have less or even no interference to network in order to reduce the impact on network traffic forwarding behavior. * Scalability: The monitoring system is required to have the capability to accommodate tens of thousands of measurement sessions simultaneously so that the number of concurrent measurements should be less limited by network resources. 4. Problem Statement for Monitoring Packet Loss Caused by Congestion Packet loss measurement is an important means of evaluating network performance and user quality of service (QoS). According to [RFC7799], measurement method can be classified as active, passive and hybrid method. Existing active measurement methods include IP Ping [RFC2151], A One- way Active Measurement Protocol (OWAMP) [RFC4656], A Two-Way Active Measurement Protocol (TWAMP) [RFC5357],the Simple Two-way Active Measurement Protocol (STAMP) [RFC8762],which have been widely adopted by network operators. An active measurement method can obtain one- way or two-way packet loss by means of the external probes or the built-in measurement module of device , but it can only indirectly measure the monitored traffic by sending probe packets to simulate real traffic, thus making some deviations with the actual loss results. Also, in some serious circumstances (e.g., sending excessive testing traffic), it may interfere with network traffic forwarding behavior. He & Min Expires 7 December 2026 [Page 7] Internet-Draft Requirements and Problem Statement for M June 2026 Compared to active methods, passive methods only rely on the presence of the measured traffic flows at one or more observation points. It does not generate additional traffic disturbing the network. For example, monitoring packet loss between two nodes traversed by the designated traffic flow can be conducted by configuring packet counters on sending node and receiving node respectively. More current studies have concentrated on sampled traffic data provided by NetFlow [RFC3954][Yuliang_Li16] [Hua_Hu23], where the accuracy of loss detection result depends on traffic sampling scheme, and the real-time performance depends on the collection interval. The emerging on-path detection techniques, including Alternate- Marking method (AltMark) [RFC9341], In Situ Operations, Administration, and Maintenance (IOAM) [RFC9197] and In-Band Network Telemetry (INT) [INT_Spec], have aroused great interests from both industry and academia. These types of measurement and monitoring techniques are classified as hybrid methods. The greatest advantage of AltMark method lies in its high efficiency and credence, as it can directly measure the real traffic with a single-marking bit. But there exist some deficiencies. First, two counters need to be employed for each measured flow in every measurement point, and much more counters will be consumed when concurrent measured flows and measurement points are large. For example, in hop by-hop mode, considering m monitored flows that traverse n nodes along the path, then n*m*2 packet counters are needed. Second, it is required to define different packet header encapsulations to adapt to different transport protocols for different data plane, and the forwarding chip for the data plane also needs to be upgraded accordingly. For instance, the encapsulation for MPLS performance measurement with AltMark is defined in [RFC9714], Extension Header Option for IPv6 network defined in [RFC9343] to encode Alternate-Marking information in both the Hop-by-Hop Options Header and Destination Options Header, and application of the Alternate-Marking Method to the Segment Routing Header defined in [RFC9947]. IOAM and INT methods can directly monitor Operations, Administration, and Maintenance (OAM) information by embedding the monitoring instructions and carrying the OAM data of the forwarding path into the monitored packet. However, these methods add some additional telemetry data which may claim much bandwidth, even causing path Maximum Transmission Unit (MTU) issue. Similarly to AltMark method, they are also protocol dependent, and need to define different packet header encapsulations for different transport protocols as defined in [RFC9486] for IPv6,[I.D.ietf-mpls-mna-ioam] for MPLS. As a result, this increases the complexity of forwarding chips. In addition, a significant deficiency is that both IOAM and INT lack the ability to detect packet loss [Lizhuang_Tan21], so another IOAM option type called the Direct Export (DEX) [RFC9326], i.e., postcard-based IOAM, He & Min Expires 7 December 2026 [Page 8] Internet-Draft Requirements and Problem Statement for M June 2026 is proposed, which is used as a trigger for IOAM data to be directly exported without being pushed into data packets. However, an IOAM encapsulating node that supports the DEX Option-Type must support the capability to select a subset of the forwarded traffic. If an IOAM encapsulating node incorporates the DEX Option-Type into all the traffic it forwards, it may lead to an excessive amount of exported data, which may overload the network and the receiving entity. Theoretically, if an IOAM encapsulating node incorporates the DEX Option-Type into all monitored packets of traffic it forwards, the precision of loss result can be ensured. While too small subset of traffic or too low traffic sampling is implemented, loss results may lack fidelity, since the transmitting packet interval may be longer than the duration of instantaneous congestion such as microburst. In order to augment IOAM capabilities in performance measurement such as packet loss, delay and jitter, the two IETF drafts that integrate the Alternate-Marking method into IOAM as defined in [I.D.he-ippm-ioam- dex-extensions-incorporating-am] and [I.D.he-ippm-ioam-extensions- incorporating-am] are proposed. 5. Challenges for Real-time Monitoring of Packet Loss Caused by Congestion Loss events may occur due to various situations, including link quality degradation, CRC error, illegal packets, malformed frames, mismatched access control list (ACL), mismatched forwarding information base (FIB), etc. Loss caused by congestion is only one of many loss events. The above-mentioned monitoring and measurement methods have not been specially designed to monitor packet loss caused by congestion. These methods will face challenges when they are employed for monitoring congestion-induced packet loss, especially in the short-lived congestion caused by frequent microburst whose duration is typically hundreds of microseconds to tens of milliseconds. The reasons are as follows: * First, existing monitoring and measurement methods have no ability to distinguish congestion-induced packet loss from all loss events, and the above-mentioned measurement methods can only obtain loss results from all loss events. He & Min Expires 7 December 2026 [Page 9] Internet-Draft Requirements and Problem Statement for M June 2026 * Second, it is difficult for them to capture a loss event if this loss event is only caused by instantaneous congestion such as microburst. Take active methods into consideration, in order to capture a microburst, the probe packets sent must be at milliseconds or even microseconds interval, which will generate the excessive testing traffic, inundating the forwarding plane. For example, when a microburst with the duration of 1ms occurs, causing considerable dropped packets, such a microburst may not be detected if the probe packet interval is greater than 1ms. resultantly, the discarded packets will be not counted. * Third, it is also difficult for existing monitoring and measurement methods to accurately measure the number of all discarded packets caused by congestion. When a congestion loss event occurs, which generates considerable amount of packet loss, AltMark method can only obtain the accurate number of discarded packets of the monitored user flow encountering congestion, and the discarded packets by the other unmonitored traffic flows encountering the same congestion will not be collected, therefore, the total number of discarded packets caused by congestion is unknown. * Fourth, existing monitoring and measurement methods have no capability to analyze what traffic flows are contained in discarded packets and identify what traffic flows lead to the congestion, because those discarded packets are not saved by network devices. * Fifth, existing monitoring and measurement methods have difficulty in distinguishing long-lived congestion from short-lived congestion, let alone detecting the frequency and duration time of microburst occurrences. Although active methods and on-path methods such as AltMark can measure the number of discarded packets in every fixed measurement period (typically tens of seconds), they cannot detect in a measurement period how often microburst occurs and how long it lasts. * Finally, the ability to accurately localize packet loss caused by congestion in real time (e.g., from which device ID, port ID and queue ID a loss event happens) will help network operator quickly pinpoint congested nodes and make rapid troubleshooting. Existing monitoring techniques are also insufficient.Through sending probe packets, the traditional active measurement methods can only get packet loss results from ingress node to egress node, but cannot accurately indicate which node in the forwarding path discarded packets. As for hybrid measurement methods such as AltMark, the practical deployment for loss measurement adopts the end-to-end option mode, where only ingress node and egress node send packet He & Min Expires 7 December 2026 [Page 10] Internet-Draft Requirements and Problem Statement for M June 2026 counter values to the monitoring system for analysis, and intermediate nodes do not process the measured packets to mitigate the network and receiving entity. In case of packet loss detected, the hop-by-hop option mode is switched to localize packet loss. Still, it is difficult to pinpoint the instantaneously congested node (e.g., caused by a microburst). The reason lies in that when the hop-by-hop option mode is adopted after packet loss was detected, the congestion caused by microburst might have eliminated. 6. IANA Considerations This document has no IANA actions. 7. Security Considerations The congestion-induced loss monitoring system introduces additional traffic to the network. During network congestion, the monitoring system itself must not exacerbate the situation. Mechanisms such as rate limiting and traffic prioritization for congestion-related monitoring data should be considered. Also, some appropriate defense measures against Distributed Denial of Service (DDoS) attack are necessary to protect the data plane and control plane. This document does not specify security mechanisms, but highlights that any solution must consider trusted boundary regarding telemetry data subscriptions, telemetry data reporting, and protection of potentially sensitive operational data. These aspects are expected to be addressed by solution proposals based on deployment requirements and threat models. 8. References 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC8126] Cotton, M., Leiba, B., and T. Narten, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 8126, DOI 10.17487/RFC8126, June 2017, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . He & Min Expires 7 December 2026 [Page 11] Internet-Draft Requirements and Problem Statement for M June 2026 8.2. Informative References [Adithya_Gangidi24] Gangidi, A., Miao, R., and S. Zheng, "RDMA over Ethernet for Distributed AI Training at Meta Scale", In ACM SIGCOMM 2024 Conference , 2024, . [Hua_Hu23] Hu, H., Liu, Y., and S. Ni, "LossDetection: Real-time Packet Loss Monitoring System for Sampled Traffic Data", IEEE Transactions on Network and Service Management March, 2023, . [I-D.he-ippm-ioam-dex-extensions-incorporating-am] hexiaoming, X., Brockners, F., Song, H., Fioccola, G., and A. Wang, "IOAM Direct Exporting (DEX) Option Extensions for Incorporating the Alternate-Marking Method", Work in Progress, Internet-Draft, draft-he-ippm-ioam-dex- extensions-incorporating-am-04, 27 February 2026, . [I-D.he-ippm-ioam-extensions-incorporating-am] hexiaoming, X., Min, X., Brockners, F., Fioccola, G., and C. Xie, "IOAM Trace Option Extensions for Incorporating the Alternate-Marking Method", Work in Progress, Internet- Draft, draft-he-ippm-ioam-extensions-incorporating-am-06, 27 February 2026, . [I-D.ietf-mpls-mna-ioam] Gandhi, R., Mirsky, G., Li, T., Song, H., and B. Wen, "Supporting In Situ Operations, Administration and Maintenance Using MPLS Network Actions", Work in Progress, Internet-Draft, draft-ietf-mpls-mna-ioam-05, 19 May 2026, . [INT_Spec] The P4.org Applications Working Group, "In-Band Network Telemetry (INT) Data plane Specification V2.1", 2020, . [Kun_Qian24] Qian, K., Xi, Q., and J. Cao, "Alibaba HPN: A Data Center Network for Large Language Model Training", In ACM SIGCOMM 2024 Conference , 2024, . He & Min Expires 7 December 2026 [Page 12] Internet-Draft Requirements and Problem Statement for M June 2026 [Lizhuang_Tan21] Tan, L., Su, W., and W. Zhang, "A Packet Loss Monitoring System for In-Band Network Telemetry: Detection, Localization, Diagnosis and Recovery", IEEE Transactions on Network and Service Management December, 2021, . [Microburst] Huawei Technologies Co., Ltd, "What is a Microburst? How to Detect a Microburst,(Nov. 2020)", 2020, . [RFC2151] Kessler, G. and S. Shepard, "A Primer On Internet and TCP/ IP Tools and Utilities", FYI 30, RFC 2151, DOI 10.17487/RFC2151, June 1997, . [RFC3954] Claise, B., Ed., "Cisco Systems NetFlow Services Export Version 9", RFC 3954, DOI 10.17487/RFC3954, October 2004, . [RFC4656] Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, . [RFC5357] Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, DOI 10.17487/RFC5357, October 2008, . [RFC7348] Mahalingam, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., and C. Wright, "Virtual eXtensible Local Area Network (VXLAN): A Framework for Overlaying Virtualized Layer 2 Networks over Layer 3 Networks", RFC 7348, DOI 10.17487/RFC7348, August 2014, . [RFC7799] Morton, A., "Active and Passive Metrics and Methods (with Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, May 2016, . [RFC8086] Yong, L., Ed., Crabbe, E., Xu, X., and T. Herbert, "GRE- in-UDP Encapsulation", RFC 8086, DOI 10.17487/RFC8086, March 2017, . He & Min Expires 7 December 2026 [Page 13] Internet-Draft Requirements and Problem Statement for M June 2026 [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, July 2018, . [RFC8660] Bashandy, A., Ed., Filsfils, C., Ed., Previdi, S., Decraene, B., Litkowski, S., and R. Shakir, "Segment Routing with the MPLS Data Plane", RFC 8660, DOI 10.17487/RFC8660, December 2019, . [RFC8762] Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple Two-Way Active Measurement Protocol", RFC 8762, DOI 10.17487/RFC8762, March 2020, . [RFC8986] Filsfils, C., Ed., Camarillo, P., Ed., Leddy, J., Voyer, D., Matsushima, S., and Z. Li, "Segment Routing over IPv6 (SRv6) Network Programming", RFC 8986, DOI 10.17487/RFC8986, February 2021, . [RFC9197] Brockners, F., Ed., Bhandari, S., Ed., and T. Mizrahi, Ed., "Data Fields for In Situ Operations, Administration, and Maintenance (IOAM)", RFC 9197, DOI 10.17487/RFC9197, May 2022, . [RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)", STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022, . [RFC9326] Song, H., Gafni, B., Brockners, F., Bhandari, S., and T. Mizrahi, "In Situ Operations, Administration, and Maintenance (IOAM) Direct Exporting", RFC 9326, DOI 10.17487/RFC9326, November 2022, . [RFC9341] Fioccola, G., Ed., Cociglio, M., Mirsky, G., Mizrahi, T., and T. Zhou, "Alternate-Marking Method", RFC 9341, DOI 10.17487/RFC9341, 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, . He & Min Expires 7 December 2026 [Page 14] Internet-Draft Requirements and Problem Statement for M June 2026 [RFC9486] Bhandari, S., Ed. and F. Brockners, Ed., "IPv6 Options for In Situ Operations, Administration, and Maintenance (IOAM)", RFC 9486, DOI 10.17487/RFC9486, September 2023, . [RFC9714] Cheng, W., Ed., Min, X., Ed., Zhou, T., Dai, J., and Y. Peleg, "Encapsulation for MPLS Performance Measurement with the Alternate-Marking Method", RFC 9714, DOI 10.17487/RFC9714, February 2025, . [RFC9743] Duke, M., Ed. and G. Fairhurst, Ed., "Specifying New Congestion Control Algorithms", BCP 133, RFC 9743, DOI 10.17487/RFC9743, March 2025, . [RFC9947] Fioccola, G., Zhou, T., Mishra, G., Wang, X., Zhang, G., and M. Cociglio, "Application of the Alternate-Marking Method to the Segment Routing Header", RFC 9947, DOI 10.17487/RFC9947, March 2026, . [Shuhei_Yoshida21] Yoshida, S., Ukon, Y., and S. Ohteru, "FPGA-based network microburst analysis system with efficient packet capturing", Journal of Optical Communications and Networking October, 2021, . [Yuliang_Li16] Li, Y., Miao, R., and C. Kim, "LossRadar: Fast Detection of Lost Packets in Data Center Networks", Proceedings of the 12th International on Conference on emerging Networking Experiments and Technologies 2016, . [_GPP_TS_22.261] 3GPP, "Service requirements for the 5G system; Stage 1 (Release 18)", 2024, . Authors' Addresses Xiaoming He China Telecom Email: hexm4@chinatelecom.cn He & Min Expires 7 December 2026 [Page 15] Internet-Draft Requirements and Problem Statement for M June 2026 Xiao Min ZTE Corp. Email: xiao.min2@zte.com.cn He & Min Expires 7 December 2026 [Page 16]