QUIC Working Group Z. Du Internet-Draft China Mobile Intended status: Informational 23 December 2025 Expires: 26 June 2026 Delayed Transmission and Store-and-forward in QUIC draft-du-quic-store-and-forward-00 Abstract This document describes two mechanisms in QUIC. The first is the delayed transmission, in which the sender would negotiate a proper time to send traffic to the receiver. The second is the store-and- forward, in which the sender would send the traffic to another place that supports temporary data store and data upload instead of the sender. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 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 26 June 2026. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. Du Expires 26 June 2026 [Page 1] Internet-Draft Store-and-forward in QUIC December 2025 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. Procedure of Delayed Transmission . . . . . . . . . . . . . . 3 3. Procedure of Store-and-forward . . . . . . . . . . . . . . . 3 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . 4 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 4 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 4 7.1. Normative References . . . . . . . . . . . . . . . . . . 4 7.2. Informative References . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction In today's Internet, some software update work can be scheduled on the evening so that normal work will not be disturbed. However, it is downstream traffic that from the cloud to the client. In future, an agentic Internet would appear, where more upstream traffic would emerge. The agentic APP would trigger more upstream traffic that needs to be uploaded to the cloud. For the communication between the Agents, some use cases and requirements for AI Agent protocols are introduced in [I-D.rosenberg-ai-protocols]. The AI Agents are considered to be more intelligent than normal devices. If the upload speed is slow due to limited available bandwidth, they should support delaying the upload job and restarting it in a proper time. Also, if the network can provide a temporary data store service, the AI Agents can choose to upload the data to a temporary place, which works as a proxy for the upload job. For example, an MEC node can provide this store-and-forward service. The client can upload the data to an MEC, and then the MEC uploads the data to the cloud in a proper time. This document suggests making some extension to QUIC [RFC9000] to support the delayed transmission and the store-and-forward. The client and the server should all support the extension to enable the time-shifted upload. Du Expires 26 June 2026 [Page 2] Internet-Draft Store-and-forward in QUIC December 2025 2. Procedure of Delayed Transmission The performance of upload work is mainly related the load of the nodes and links along the path between the client and the server. It may include the user network, the operator network, and the cloud network. If anyone of the networks becomes congested, the upload performance would be influenced. In this case, the client can negotiate with the server about the execution time of the upload task. An example procedure is introduced as follows, in which a client needs to upload some data to the server. 1. The client decides to delay the transmission due to the poor performance when executing the upload task. It wants to restart the task after a while. 2. The client sends a packet including the task information, for example, the total size of the data, the expected complete time of the task, etc., to the server. Meanwhile, the packet also includes information to show the intent to trigger the delayed transmission mechanism. 3. After receiving the packet, the server may respond another packet including a suggested restart time. 4. The client receives the response packet from the server, and acts accordingly. When the restart time comes, the client restarts the task and uploads the data. We need to extend some new frames in QUIC to carry the information in the step 2 and the step 3. 3. Procedure of Store-and-forward In this case, the client can negotiate with the server in the cloud about the proxy of the upload task. An example procedure is introduced as follows, in which a client needs to upload some data to the server by using a proxy. 1. The client connects the server in the cloud, and starts the upload task. Due to the poor performance, The client decides to find a proxy for the task. 2. The client sends a packet including the task information, for example, the total size of the data, the expected complete time of the task, etc., to the server in the cloud. Meanwhile, the Du Expires 26 June 2026 [Page 3] Internet-Draft Store-and-forward in QUIC December 2025 packet also includes information to show the intent to trigger the store-and-forward mechanism, and optionally the address of the store-and-forward server. 3. The server in the cloud receives the packet, and responds another packet including information about the store-and-forward server, for example, the address of the store-and-forward server, which means the server in the cloud agrees with triggering the store- and-forward mechanism. 4. The client receives the response packet from the server in the cloud. Accordingly, the client connects the store-and-forward server, and uploads the data. The client can send a packet including the task information to the store-and-forward server. Meanwhile, the packet also includes information about the server in the cloud. 5. The store-and-forward server uploads the data to the server in the cloud. Similarly, we need to extend some new frames in QUIC to carry the information in the procedure. Besides, the server in the cloud can issue a token to the client in the response packet of the step 3. The token can be provided to the store-and-forward server in the step 4, and be provided to the server in the cloud in the step 5 to make a verification. 4. IANA Considerations TBD. 5. Security Considerations TBD. 6. Acknowledgements TBD. 7. References 7.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, . Du Expires 26 June 2026 [Page 4] Internet-Draft Store-and-forward in QUIC December 2025 [RFC9000] Iyengar, J., Ed. and M. Thomson, Ed., "QUIC: A UDP-Based Multiplexed and Secure Transport", RFC 9000, DOI 10.17487/RFC9000, May 2021, . 7.2. Informative References [I-D.rosenberg-ai-protocols] Rosenberg, J. and C. F. Jennings, "Framework, Use Cases and Requirements for AI Agent Protocols", Work in Progress, Internet-Draft, draft-rosenberg-ai-protocols-00, 5 May 2025, . Author's Address Zongpeng Du China Mobile No.32 XuanWuMen West Street Beijing 100053 China Email: duzongpeng@foxmail.com Du Expires 26 June 2026 [Page 5]