]> ZTE Corporation

xiong.quan@zte.com.cn

ZTE Corporation

zhu.xiangyang@zte.com.cn

teas This document proposes RSVP extensions for rate-based resource quota to enable dynamic resource reservation, achieving effective rate control in multi-flow data transmission.

Introduction The increasing number of job-based applications (e.g., AI/HPC, video conferencing, cloud gaming) demand for high-throughput, low-latency communications over WANs. To ensure efficient transmission of these services in the network and avoid congestion, the network can establish tunnels and reserve resources based on the requirements, guaranteeing high-throughput transmission within the job's completion time. A job decomposed into multiple tasks for parallel transmission results in the concurrent transmission of multiple flows. Traditional congestion control mechanisms implemented on hosts lack rate controls, resulting in unbounded rate adjustments. The static resource allocation methods can provide QoS guarantee to imigrate the congestion for the job. But in multi-flow communications, network bandwidth is shared among multiple flows, leading to suboptimal performance, including slow-flow (tailing) and throughput degradation as follows. *Slow-flow tailing: when one flow experiences congestion, it can delay others. *Throughput inefficiency: static bandwidth allocation for multi-flows may over/under-utilize resources. *Lack of synchronization: multi-flows may arrive with different delays, disrupting the synchronization of group communication. The network should provide efficient resource reservation mechanisms at nodes along the path. This is not bandwidth allocation but rather quota reservation, which can be used for admission control. Quota is expressed as a vector of resource quantities (bandwidth, buffer, queue, etc.) for a given time frame. The network can make dynamic resource reservation for different time frames defined by quota. The network nodes can reserve resource quota based on rate control for each flow. For example, it could reserve the minimum bandwidth quota to guarantee the minimum rate of multiple flows and schedule dynamic resources to achieve the maximum rate. This document proposes RSVP extensions for rate-based resource quota to enable dynamic resource reservation, achieving effective rate control in multi-flow data transmission.

Conventions Used in This Document

Abbreviations and Terminology This document uses the following terminology: Resource Quota: A vector of resource quantities (bandwidth, buffer, queue, etc.) for a given time frame.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

RSVP Signalling for Rate-based Resource Quota Reservation The network needs to perform the admission control based on available capacity after receiving the flow transmission request. The request will be accepted when the rate-based resource quota reservation succeeds; otherwise, it will be rejected. When the network reserves the resource quota based on the minimum rate of the flow and scheduled the resource based on the maximum rate, the traffic can be transmitted within the controlled range of rates to guarantee the completion time and the throughput among multiple flows. The network performs dynamic resource reservation for different time frames defined by quota as follows.

• The ingress node sends Path message to request the resource quota while carrying the Quota Object (Section 4.1.1) to indicate the required resource (e.g., bandwidth, buffer, queue) within a time frame. The resource quota can be computed based on the minimum rate of the flow.
• The transit node receiving a Path message needs to check the resources allocated for the service and transfer it to the next node. When the remaining resources are not enough for the requested quota, it needs to reply with a PathErr message.
• The egress node receiving the Path message needs to check the output resources and return a Resv message carrying the Quota Object (Section 4.1.1) and RateControl Object (Section 4.1.2) to indicate the maximum rate of the flow.
• The network nodes receiving the Resv message need to reserve the resource quota within a time frame, but not allocate it while the traffic in the network is still sharing the resources. For example, the nodes need to subtract the resource quota within the time frames and the subtraction result will be viewed as the resource constraints for admission control.
• The egress node may send a Notify message carrying RateControl Object to update the maximum rate of the flow.
• When the data transmission is completed, the resource quota will be released with PathTear and ResvTear messages.

|------------------------->| |<-------------------------|<-------------------------| |Resv message |Resv message | |(reserve rate-based quota)|(reserve rate-based quota)| | | | |Notify message | | |(update dynamic resource and rate) | |<----------------------------------------------------| | | | |PathTear message |PathTear message | |(request resource quota) |(request resource quota) | |------------------------->|------------------------->| |<-------------------------|<-------------------------| |ResvTear message |ResvTear message | |(release rate-based quota)|(release rate-based quota)| | | | | | | V V V Figure 1 RSVP Signaling for Rate-based Resource Quota Reservation ]]>

RSVP Extensions

Objects Extensions

RateControl Object This document proposes the RateControl Object to carry the rate information which is acknowledged by the egress node. The format of the RateControl Object is shown in Figure 2. Min-Rate: 32bits, indicates the minimum rate for the flow. Max-Rate: 32bits, indicates the maximum rate for the flow.

Quota Object This document proposes the Quota Object to carry the resource quota information. The format of the Quota Object is shown in Figure 3. Quota Type: 16 bits, indicates the type of resource quota, including the bandwidth, buffer, queue, CPU size, etc. Time Unit Type: 16 bits, indicates the type of time unit, including second, microsecond, millisecond, and minute. Start Time: 32 bits, indicates the start time of the time frame. End Time: 32 bits, indicates the end time of the time frame. optional TLVs: variable length and multiple TLVs can be carried to indicate the resource quota. Bandwidth: 32 bits, indicates the bandwidth quota which is reserved for the flow. Timeslot/Cycle: 32 bits, indicates the time-based quota which is reserved for the flow. Queue ID: 32 bits, indicates the queue quota which is reserved for the flow. Buffer: 32 bits, indicates the buffer quota which is reserved for the flow. CPU Size: 32 bits, indicates the CPU quota which is reserved for the flow.

Security Considerations The security considerations specified in and apply to this document. In addition, and provide useful guidance on RSVP security mechanisms. The network nodes need to perform quota-based resource computation and reservation based on authentication (e.g., and ) and authorization (e.g.,).

IANA Considerations TBA.

Informative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This memo resolves a duplication in the assignment of RSVP Message Types, by changing the Message Types assigned by RFC 2747 to Challenge and Integrity Response messages. [STANDARDS-TRACK] This document describes the format and use of RSVP's INTEGRITY object to provide hop-by-hop integrity and authentication of RSVP messages. [STANDARDS-TRACK] The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. This specification replaces and obsoletes the OAuth 1.0 protocol described in RFC 5849. [STANDARDS-TRACK] This memo describes version 1 of RSVP, a resource reservation setup protocol designed for an integrated services Internet. RSVP provides receiver-initiated setup of resource reservations for multicast or unicast data flows, with good scaling and robustness properties. [STANDARDS-TRACK] RFC 3175 defines aggregate Resource ReSerVation Protocol (RSVP) reservations allowing resources to be reserved in a Diffserv network for a given Per Hop Behavior (PHB), or given set of PHBs, from a given source to a given destination. RFC 3175 also defines how end-to-end RSVP reservations can be aggregated onto such aggregate reservations when transiting through a Diffserv cloud. There are situations where multiple such aggregate reservations are needed for the same source IP address, destination IP address, and PHB (or set of PHBs). However, this is not supported by the aggregate reservations defined in RFC 3175. In order to support this, the present document defines a more flexible type of aggregate RSVP reservations, referred to as generic aggregate reservation. Multiple such generic aggregate reservations can be established for a given PHB (or set of PHBs) from a given source IP address to a given destination IP address. The generic aggregate reservations may be used to aggregate end-to-end RSVP reservations. This document also defines the procedures for such aggregation. The generic aggregate reservations may also be used end-to-end directly by end-systems attached to a Diffserv network. [STANDARDS-TRACK] This document summarizes the security properties of RSVP. The goal of this analysis is to benefit from previous work done on RSVP and to capture knowledge about past activities. This memo provides information for the Internet community. The Resource reSerVation Protocol (RSVP) allows hop-by-hop integrity protection of RSVP neighbors. This requires messages to be cryptographically protected using a shared secret between participating nodes. This document compares group keying for RSVP with per-neighbor or per-interface keying, and discusses the associated key provisioning methods as well as applicability and limitations of these approaches. This document also discusses applicability of encrypting RSVP messages. This document is not an Internet Standards Track specification; it is published for informational purposes.