Delayed Transmission and Store-and-forward in QUIC

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 . 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 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.‌

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. 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. 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. After receiving the packet, the server may respond another packet including a suggested restart time. 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.

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. 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. 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 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. 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. 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. 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.

TBD.