Delayed Transmission and Store-and-forward in QUIC
draft-du-quic-store-and-forward-00

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

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

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, <https://datatracker.ietf.org/doc/html/draft-
              rosenberg-ai-protocols-00>.

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]