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,
<https://datatracker.ietf.org/doc/html/draft-liu-rtgwg-
mdt-in-high-bdp-01>.
[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, <https://datatracker.ietf.org/doc/html/
draft-kwbdgrr-tsvwg-net-collab-rqmts-04>.
[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,
<https://datatracker.ietf.org/doc/html/draft-zhang-rtgwg-
collaboration-app-net-01>.
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]