SCONE Z. Ruan, Ed. Internet-Draft M. Han, Ed. Intended status: Standards Track Y. Liu Expires: 24 April 2025 X. Gao China Unicom X. Geng H. Shi Huawei 21 October 2024 Use Cases and Requirements for SCONE in Massive Data Transmission draft-ruan-scone-use-cases-and-requirements-00 Abstract This document outlines a use case for Standard Communication with Network Elements (SCONE) in the context of massive data transmission (MDT). From the described use case, it derives a set of signaling requirements for the communication between applications and network elements. 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 24 April 2025. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. 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 Ruan, et al. Expires 24 April 2025 [Page 1] Internet-Draft Use Cases and Requirements for SCONE in October 2024 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. Use-case: Massive Data Transmission . . . . . . . . . . . . . 2 3. Requirements of Signaling . . . . . . . . . . . . . . . . . . 3 4. Security Considerations . . . . . . . . . . . . . . . . . . . 3 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 6. Informative References . . . . . . . . . . . . . . . . . . . 4 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction In scenarios involving massive data transmission, network elements must communicate with applications to exchange crucial information, such as network path throughput and availability. By leveraging this information, applications can schedule data transmissions during optimal time periods—such as when network congestion is low or user activity is reduced—thereby enhancing data transfer efficiency and minimizing the impact on network performance. With knowledge of network availability, applications can also offer more accurate estimates for upload or download times, improving user experience by enabling better planning. This document focuses on the requirements for collaboration between applications and network elements in such scenarios. 2. Use-case: Massive Data Transmission Emerging industries like artificial intelligence (AI), intelligent computing, and supercomputing generate vast amounts of data daily, which must be quickly transmitted over the operator's network. The scenario described in [I-D.liu-rtgwg-mdt-in-high-bdp] provides an in- depth analysis of massive data transmission needs. Given the volume of data involved, the demand for network bandwidth is substantial. For example, an AI training model may require the transmission of 10 TB of data to a computing center within a few hours, with transmission speeds ranging from 10 Gbps to 30 Gbps. Operator networks, which typically offer link bandwidth between 50 Gbps and 100 Gbps, see a single MDT task consuming up to 10%–30% of the link's capacity. When multiple tasks are transmitted concurrently, the instantaneous load on the network can be significant. However, several strategies for collaboration between applications and networks, such as those discussed in [I-D.kwbdgrr-tsvwg-net-collab-rqmts] Ruan, et al. Expires 24 April 2025 [Page 2] Internet-Draft Use Cases and Requirements for SCONE in October 2024 [I-D.zhang-rtgwg-collaboration-app-net], offer potential solutions to this challenge. In MDT scenarios, two primary components must work together: the application side and the network side. Their roles are as follows: Application side: The MDT tasks may originate from either operators or third-party file transfer systems. The application side provides the network side with data transmission requirements, including the data volume, source and destination addresses, and expected completion times. Based on the network's feedback, the application formulates an appropriate data transfer strategy. Network side: Network devices, which may be closest to the application or specialized gateway devices, monitor the network's real-time status. They perform path calculations, reserve necessary resources, and communicate the results back to the application side, helping guide the data transmission strategy. One of the key characteristics of operator networks is the "tidal effect," where network load is high during peak hours and low during off-peak times. To avoid overloading the network when multiple MDT tasks are transmitted simultaneously, operators aim to schedule these tasks during off-peak hours when higher bandwidth can be made available. Additionally, they may distribute different MDT tasks across various time slots and network paths to ensure more efficient network utilization. 3. Requirements of Signaling The exchange of information between the application and network sides requires new signaling mechanisms. While this document does not specify the exact signaling format, it outlines the essential information that needs to be conveyed: a) Available time slots: Information about when the network can accommodate MDT tasks, guiding the application's scheduling. b)Path information: Details about available network paths, including throughput recommendations, latency, packet loss rate, maximum transmission unit (MTU), and other relevant metrics. c) Path identifier: A mechanism to assign a unique identifier to each transmission path, allowing the application to direct traffic appropriately. The network device uses this identifier to steer traffic to the designated path. 4. Security Considerations TBD Ruan, et al. Expires 24 April 2025 [Page 3] Internet-Draft Use Cases and Requirements for SCONE in October 2024 5. IANA Considerations TBD 6. Informative References [I-D.liu-rtgwg-mdt-in-high-bdp] Ying, "Use Cases and Requirements of Massive Data Transmission(MDT) in High Bandwidth-delay Product (BDP) Network", Work in Progress, Internet-Draft, draft-liu- rtgwg-mdt-in-high-bdp-01, 5 July 2024, . [I-D.kwbdgrr-tsvwg-net-collab-rqmts] Kaippallimalil, J., Wing, D., Gundavelli, S., Rajagopalan, S., Dawkins, S., and M. Boucadair, "Requirements for Host- to-Network Collaboration Signaling", Work in Progress, Internet-Draft, draft-kwbdgrr-tsvwg-net-collab-rqmts-04, 14 October 2024, . [I-D.zhang-rtgwg-collaboration-app-net] Zhang, N., Zhang, S., Yi, X., Geng, X., and H. Shi, "Deep Collaboration between Application and Network", Work in Progress, Internet-Draft, draft-zhang-rtgwg-collaboration- app-net-01, 17 October 2024, . Authors' Addresses Zheng Ruan (editor) China Unicom Beijing China Email: ruanz6@chinaunicom.cn Mengyao Han (editor) China Unicom Beijing China Email: hanmy12@chinaunicom.cn Ruan, et al. Expires 24 April 2025 [Page 4] Internet-Draft Use Cases and Requirements for SCONE in October 2024 Ying Liu China Unicom Beijing China Email: liuy619@chinaunicom.cn Xing Gao China Unicom Beijing China Email: gaox60@chinaunicom.cn Xuesong Geng Huawei Beijing China Email: gengxuesong@huawei.com Hang Shi Huawei Beijing China Email: shihang9@huawei.com Ruan, et al. Expires 24 April 2025 [Page 5]