| Internet-Draft | Framework for HP-WAN | March 2025 |
| Xiong, et al. | Expires 4 September 2025 | [Page] |
This document defines a framework to enable the host-network collaboration for high-speed data transmission in High Performance Wide Area Network (HP-WAN). It particularly facilitates the functionalities of the edge nodes/gateway nodes/proxy to transform transport protocols and collaborate with the host to perform QoS negotiation, such as flow control, admission control and traffic scheduling.¶
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 4 September 2025.¶
Copyright (c) 2025 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 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.¶
Data-intensive applications always demand high-speed data transmission over WANs such as scientific research, academia, education as disccussed in [I-D.kcrh-hpwan-state-of-art] and other applications in public networks as per [I-D.yx-hpwan-uc-requirements-public-operator]. The specific requirements of HP-WANs applications mainly focus on the massive data transmission over long-distance WANs within a completion time. It is crucial to achieve high throughput while ensuring the efficient use of capacity as per [I-D.xiong-hpwan-problem-statement]. The performance will be impacted by the issues related to existing transport protocols and congestion control mechanisms such as poor convergence speed, long feedback loop and unscheduled traffic. And it is also worthwile to consider the adaptation of functionality to suit the requirements of different transport protocols when multiple services coexist.¶
Multiple data transfer requests should be scheduled in terms of available capacity and the requested completion time in terms of transmission performance. From the routing aspect, the optimal path and resources for the high-speed flows should be scheduled to travel through the network with the negotiated QoS. From transport aspect, it ensures the reliable delivery of data with traffic scheduling and flow control to effectively handle the flow of data during transmission, reducing congestion and ensuring timely delivery of data packets. The host should consider to signal and collaborate with the network to negotiate QoS requirements of differentiated traffic (especially when the traffic is encrypted) and optimize the overall efficiency of data transfer.¶
This document defines a framework for a protocol or signaling to enable the host-and-network collaboration for high-speed data transmission in High Performance Wide Area Network (HP-WAN). It particularly facilitates the functionalities of the edge nodes/gateway nodes/proxy to transform transport protocols and collaborate with the host to perform QoS negotiation, such as flow control, admission control and traffic s cheduling.¶
This document uses the terms defined in [I-D.kcrh-hpwan-state-of-art] and [I-D.xiong-hpwan-problem-statement]:¶
The framework is formulated to enable the host-network collaboration upon more active network involvement. The client and server could adjust the rate efficiently and rapidly with the negotiated QoS-based congestion control algorithms in a fine-grained way. The network could enhance the capability to regulate the traffic and schedule the resources which could provide predictable network behaviour and avoid incast network congestion preemptively.¶
The following diagram illustrates the functionalities between Client/Server and Edge/Gateway/Proxy including:¶
*Host-network collaboration signalling or protocol¶
*Active network-collaborated scheduling¶
*Negotiated QoS-based congestion control algorithms¶
+--------------------------+
| |
+--------+ | | +--------+
| | +--------+--------+ +--------+--------+ | |
| Client <------> Edge/Gateway/Proxy| WAN |Edge/Gateway/Proxy <-------> Server |
| | +--------+--------+ +--------+--------+ | |
+--------+ *collaboration | | *collaboration+--------+
signalling/protocols | | signalling/protocols
| |
+--------------------------+
\_________/ \______________________________/
*Negotiated QoS-based *Active network-collaborated scheduling
congestion control
algorithms
¶
The following diagram illustrates the workflows among client, server and network nodes (e.g. Edge/Gateway/Proxy nodes and transit nodes). The request of scheduled traffic will be signaling from client to Edge/Gateway/Proxy to negotiate QoS. The acknowledgement will be signaling back from Edge/Gateway/Proxy to the client, including the response of negotiated rate for the client to send traffic and the fast and accurate quantitative feedback when Edge/Gateway/Proxy performs admission control and flow control.¶
The functions are described in the sections below including transport-related technologies such as flow control, QoS negotiation, congestion control, admission control and traffic scheduling and routing-related technologies like traffic engineering and resource scheduling.¶
+--------+ +-------------------+ +-------------------+ +--------+
| Client | |Edge/Gateway/Proxy | |Edge/Gateway/Proxy | | Server |
+----+---+ +--------+----------+ +--------+----------+ +----+---+
| | | |
| Requests(traffic pattern) |*Adapts transport protocols| |
|------------------------------->|*Negotiated QoS-based | |
| | traffic scheduling | |
| Acknowledgement(Negotiated QoS)|*Negotiated QoS-based | |
|<-------------------------------|traffic engineering | |
| |<#########################>| |
| | | |
| Traffic(Negotiated-rate) |Traffic(Negotiated-rate) | Traffic(Negotiated-rate)|
|------------------------------->|##########################>|------------------------>|
| Traffic(Over-rate) | | |
|------------------------------->|*Admission control | |
| Fast Feedback(on/off) | | |
|<-------------------------------| | Exceeding Threshold |
| |*Flow Control |<------------------------|
| Fast Feedback(on/off) |<#########################>| |
|<-------------------------------| | |
V V V V
¶
The transport protocol proxy adapts the different transport protocols from the diversified hosts. It also could perform the aggregation of mouse flows or the fragmentation of an elephant flow if needed.¶
The client communicates the traffic patterns of high-speed flows to the network to negotiate QoS. The network node (Edge/Gateway/Proxy) performs QoS-based traffic scheduling such as traffic classification based on the traffic type. If the traffic needs acceleration, it should upgrade the priority of QoS. And if the traffic needs a guaranteed QoS, it should provide guaranteed bandwidth for this flow.¶
The network node (Edge/Gateway/Proxy) should perform admission and traffic control based on negotiated QoS and rate. When the data sent by the client exceeds the negotiated rate, the Edge/Gateway/Proxy should provide fast and accurate quantitative feedback to control the traffic on or off.¶
The specific elements along the path should provide active and precise flow control to mitigate network congestion to provide negotiated QoS for a flow. Flow control refers to a method for ensuring the data is transmitted efficiently and reliably and controlling the rate of data transmission to prevent the fast sender from overwhelming the slow receiver and prevent packet loss in congested situations. For example, the receiver node could signal the sender node to control the traffic on or off to guarantee the negotiated QoS.¶
The client should perform the improvement of congestion control algorithms based on the negotiated-rate from the network. The negotiated-rate can be viewed as an initial congestion signal to assist the client to select a suitable sending rate with the network resource scheduling acknowledgement.¶
And it also needs to turn off/on or adjust the rate reasonably and rapidly when receiving the fast feedback from the node nearing the client.¶
The signaling from client will assist the network operator's traffic management and corresponding resource planning and scheduling. The network should provide resource scheduling and traffic scheduling at node nearing clients such as Edge/Gateway/Proxy. The Edge/Gateway/Proxy can get information (topology, link bandwidth, queue and buffer) from a centralized controller which can also exchange information with clients and servers. The client and network can also negotiating QoS based on the quota of each job. Quota is expressed as a vector of resource quantities (bandwidth,buffer,queue, etc.) at a given priority, for a timeframe. The network can make dynamic bandwidth reservation upon different timeframes defined by quota.¶
TBA.¶