End-network collaborative congestion control method, and network device and computer program product

Abstract

Provided in the embodiments of the present disclosure are an end-network collaborative congestion control method, and a network device and a computer program product. The method comprises: a second device receiving a task transmission request from a first device; the second device determining quota authorization information on the basis of the task transmission request; and the second device sending the quota authorization information to the first device, such that the first device performs traffic transmission on the basis of the quota authorization information.

Description

End-to-end network collaborative congestion control methods, network equipment, and computer program products

[0001] Cross-reference of related applications

[0002] This application is based on and claims priority to Chinese patent application CN202510227566.6, filed on February 27, 2025, entitled “Congestion Control Method, Network Device and Computer Program Product for End-to-End Collaboration”, the entire contents of which are incorporated herein by reference. Technical Field

[0003] This disclosure relates to the field of communications, and more specifically, to a congestion control method, network device, and computer program product for end-to-end network collaboration. Background Technology

[0004] Traditional congestion control mechanisms based on end-side network status detection and speed adjustment cannot guarantee high-performance wide area network (WAN) transmission of large-capacity data. The main reason is that WANs cannot provide stable and predictable transmission capabilities. Due to factors such as changes in network routing, link changes, and other traffic randomly joining / leaving shared links, the bottleneck links of the network path are constantly changing. Traditional congestion control algorithms adjust speed based on the detected bottleneck link status. Furthermore, due to the slow feedback over long distances in WANs and the inaccuracy of feedback information, the detected available bandwidth and other information cannot keep up with the actual changes, resulting in packet loss or ineffective utilization of link bandwidth. Ultimately, this leads to excessively long convergence times, exceeding the completion time requirements. Summary of the Invention

[0005] This disclosure provides a congestion control method, network device, and computer program product for end-to-end network collaboration.

[0006] According to one embodiment of this disclosure, a congestion control method for end-to-end network collaboration is provided, comprising: a second device receiving a task transmission request from a first device; the second device determining quota authorization information based on the task transmission request; and the second device sending the quota authorization information to the first device, so that the first device performs traffic transmission based on the quota authorization information.

[0007] According to another embodiment of this disclosure, a congestion control method for end-to-end network collaboration is provided, comprising: a first device sending a task transmission request to a second device; the first device receiving quota authorization information from the second device, wherein the quota authorization information is determined by the second device based on the task transmission request; and the first device performing traffic transmission based on the quota authorization information.

[0008] According to yet another embodiment of this disclosure, a network device is also provided, the network device including a receiver, a transmitter, and a processor, the network device being configured to perform the steps of any of the above method embodiments via at least one of the receiver, the transmitter, and the processor.

[0009] According to yet another embodiment of this disclosure, a computer-readable storage medium is also provided, wherein a computer program is stored therein, wherein the computer program is configured to perform the steps in any of the above method embodiments when executed.

[0010] According to yet another embodiment of this disclosure, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to run the computer program to perform the steps in any of the above method embodiments.

[0011] According to yet another embodiment of this disclosure, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps in any of the above method embodiments. Attached Figure Description

[0012] Figure 1 is a flowchart of a congestion control method for end-to-end network collaboration according to an embodiment of this disclosure;

[0013] Figure 2 is another flowchart of the congestion control method of end-to-end network coordination according to an embodiment of the present disclosure;

[0014] Figure 3 is a structural block diagram of a network device according to an embodiment of the present disclosure;

[0015] Figure 4 is a schematic diagram of rate negotiation between the end-side host and the network side;

[0016] Figure 5 is a schematic diagram of quota-based resource scheduling on the network side;

[0017] Figure 6 is a schematic diagram of fast feedback for traffic control at the ingress / gateway node;

[0018] Figure 7 is a flowchart illustrating the congestion control method of end-to-end network collaboration according to an embodiment of this disclosure.

[0019] Figure 8 is a flowchart of the end-to-end network cooperative congestion control mechanism based on network quota authorization according to an embodiment of this disclosure;

[0020] Figure 9 is a schematic diagram of the principle of extending the task transmission request message;

[0021] Figure 10 is a schematic diagram illustrating the principle of expanding quota authorization information;

[0022] Figure 11 is a schematic diagram of the fields of a Time frame TLV;

[0023] Figure 12 is a schematic diagram of the transmission of large amounts of data over a wide area network. Detailed Implementation

[0024] The embodiments of this disclosure will be described in detail below with reference to the accompanying drawings and examples.

[0025] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of the embodiments of this disclosure are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0026] In related technologies, with the development of new technologies such as Artificial Intelligence (AI) and High Performance Computing (HPC), the demand for large-scale data transmission and processing has increased dramatically. This data needs to be transmitted at high performance via wide area networks (WANs). Typical applications include HPC scientific research, industrial internet data research, cloud storage and backup, and AI distributed training. The main demand of these services stems from the time-sensitive transmission of large volumes of data, such as completion time requirements at the second or minute level. Simultaneously, there is collaborative transmission of multiple concurrent services, requiring long-distance WAN connections between sites or data centers. It is necessary to meet the ever-increasing demand for high-speed data transmission, ensure data integrity, provide stable and efficient WAN transmission services, and ultimately achieve the goal of high-performance WAN transmission. To support wide area network (WAN) data transmission, high-performance wide area networks (HP-WAN) are designed for high-speed, low-latency, and ultra-high-capacity applications, compared to ordinary WANs. They impose higher performance requirements: ultra-high effective throughput becomes the primary goal for time-limited transmission of large amounts of data; ultra-low packet loss rate and low latency, providing an extremely low packet loss rate of 0.001% and microsecond-level queuing latency, are necessary conditions for complex wide area networks (WANs); ultra-high bandwidth utilization and fairness require fair sharing of link bandwidth resources, ensuring effective throughput and improving data migration efficiency while improving bandwidth utilization.

[0027] Existing WAN transport layer protocols, such as Transmission Control Protocol (TCP), Quick UDP Internet Connections (QUIC), and Remote Direct Memory Access (RDMA), typically employ traditional congestion control algorithms. These algorithms, implemented on the host (sender and receiver), adjust the transmission rate by detecting network bottleneck link status and other information. For example, the commonly used TCP transport layer congestion control algorithm is Cubic, which adjusts the transmission window based on packet loss signals. However, this algorithm suffers from slow convergence; when new traffic flows enter the network, the convergence time can reach 200 seconds. Another type of congestion control algorithm is BBR and its improved versions, BBRv2 and BBRv2+. These algorithms actively probe the bandwidth and round-trip time of network bottleneck links to adjust the transmission window, attempting to solve the buffer bloat problem in long, bloated networks. However, the BBR algorithm also requires 30 to 100 seconds to converge. Therefore, congestion control mechanisms based on end-side network status detection and rate adjustment cannot guarantee high-performance WAN transmission.

[0028] High-performance wide area networks (WANs) require solutions to various problems, including congestion control, flow control, resource scheduling, and bandwidth and rate coordination. These issues have become key factors affecting the performance of existing technologies. From the endpoint perspective, traditional endpoint-based congestion control mechanisms, implemented on the host, suffer from reduced throughput and network resource utilization due to long feedback loops and inaccurate network capabilities. When data loss or congestion occurs, the endpoint may not be able to adjust the transmission rate in a timely manner based on slow feedback from the network. Furthermore, the endpoint lacks precise perception of network transmission capacity, resulting in low speed adjustment efficiency, a sawtooth effect, and long convergence times. From the network perspective, WANs passively execute greedy transmission without predictable resource scheduling, leading to bursts of traffic and bottleneck link congestion, resulting in low bandwidth utilization. Additionally, uneven distribution of network resources among flows with different transmission link delays leads to unfair transmission between multiple services at different distances.

[0029] Therefore, traditional congestion control mechanisms relying solely on passive end-side detection cannot meet the demands of high-capacity, time-limited transmission. A more proactive, network-coordinated approach to ensure high performance should be considered to improve overall HP-WAN transmission performance. This would enhance the WAN's traffic scheduling capabilities, proactively avoid sudden network congestion, and, when congestion occurs, actively collaborate with hosts to efficiently and quickly adjust rates. Currently, the standard lacks a mechanism for achieving high-performance, high-capacity data transmission over WANs.

[0030] This embodiment provides a congestion control method for end-to-end network collaboration. Figure 1 is a flowchart of the congestion control method for end-to-end network collaboration according to an embodiment of this disclosure. As shown in Figure 1, the process includes the following steps:

[0031] In step S102, the second device receives a task transmission request from the first device.

[0032] In one exemplary embodiment, the first device includes an end-side host; the second device includes at least one of the following: a proxy device; a network-side ingress node; a network-side gateway node; a network-side controller; and a network-side centralized scheduler.

[0033] In this embodiment of the disclosure, the end-side host can be a source host or a destination host.

[0034] In one exemplary embodiment, the task transmission request includes at least one of the following: task identifier; task start time; task completion time; data transmission volume; traffic type; and quality of service (QoS) level.

[0035] In one exemplary embodiment, the second device and the first device interact with each other via control signaling or extended protocols.

[0036] In the embodiments disclosed herein, the methods of information interaction through control signaling or extended protocols are merely illustrative examples and are not intended to impose specific limitations.

[0037] In step S104, the second device determines the quota authorization information based on the task transmission request.

[0038] In one exemplary embodiment, the second device acquires network resource information; the second device determines the quota for each task based on the network resource information and the task transmission request, and performs quota-based resource scheduling.

[0039] In this embodiment of the disclosure, the quota guarantee strategy of the network side (i.e., the second device) needs to be selected based on network resources. The network side needs to collect network resource information and select a resource guarantee strategy according to task requirements.

[0040] In one exemplary embodiment, quota-based resource scheduling includes: a second device allocating fixed resources to different tasks based on available resources within a certain time period to control traffic transmission, and allocating time-sliced ​​resources to each task, wherein available resources include bandwidth, queues, and buffers.

[0041] In this embodiment of the disclosure, the aforementioned certain time period refers to the quota time corresponding to the quota authorization information of the second device.

[0042] In one exemplary embodiment, the quota authorization information includes at least one of the following: the task quota; the negotiated transmission rate; the task identifier; and time-slicing information.

[0043] In one exemplary embodiment, the task quota includes: a certain amount of transmission bits guaranteed by network resources within a certain period of time, and the quota is converted into a negotiated transmission rate for traffic forwarding.

[0044] In this disclosure, the quota for a task can be converted into a negotiated transmission rate for traffic forwarding, but is not limited to this conversion method.

[0045] In one exemplary embodiment, the second device negotiates the transmission rate corresponding to the task transmission with the first device based on the task transmission request.

[0046] In one exemplary embodiment, the second device negotiates an optimal rate with the first device based on a task transmission request to determine an optimal traffic transmission rate; or, the second device negotiates a minimum rate with the first device based on a task transmission request to determine a minimum traffic transmission rate; or, the second device negotiates a maximum rate with the first device based on a task transmission request to determine a maximum traffic transmission rate.

[0047] In this embodiment, the network side (i.e., the second device) provides a resource scheduling mechanism for large-capacity data to obtain QoS guarantees and achieve optimal rate transmission. The end-side host (i.e., the first device) can transmit at the negotiated optimal rate or optimal rate range. Alternatively, the network side provides a minimum resource reservation guarantee for large-capacity data to achieve minimum rate transmission, and the end-side host can transmit at a rate not less than the negotiated rate. Alternatively, the network side provides an upper limit for resource reservation for large-capacity data to achieve maximum rate transmission, and the end-side host can transmit at a rate not greater than the negotiated rate.

[0048] In one exemplary embodiment, the second device classifies traffic according to the task transmission request, and aggregates or splits the traffic to be transmitted according to the traffic classification result to obtain the final traffic classification result; the second device determines the quota authorization information according to the final traffic classification result.

[0049] In one exemplary embodiment, the second device determines the quota of network resources corresponding to the task transmission based on the task transmission request and according to the network cooperation guarantee policy.

[0050] In one exemplary embodiment, the network coordination guarantee strategy includes at least one of the following: lossless guarantee strategy; lossy commitment guarantee strategy; minimum bandwidth guarantee strategy.

[0051] In this embodiment, for the lossless guarantee strategy, when quota management reserves bandwidth queues and buffers and adopts ingress admission, it can guarantee no network congestion, no packet loss, and a guaranteed latency. This can be achieved through methods such as explicit paths and deterministic queues. For the lossy guarantee strategy, when quota management reserves bandwidth resources, packet loss may occur in the network, requiring network-side flow control to ensure a certain level of guaranteed packet loss. This can be achieved through methods such as bandwidth slicing. Flow control mechanisms are implemented between intermediate network nodes according to the allocated quotas. When the quota is exceeded, the flow control mechanism is activated to guarantee a guaranteed packet loss level. For the minimum bandwidth guarantee strategy, quota management reserves a minimum bandwidth resource. This bandwidth value needs to be calculated using a mathematical model, and a guarantee deadline is set. Remaining bandwidth can be preempted.

[0052] In one exemplary embodiment, the second device reserves an explicit path and / or bandwidth queue for the first device based on a lossless guarantee strategy; or, the second device reserves a bandwidth slice and / or guarantees a packet loss rate for the first device based on a lossy guarantee strategy; or, the second device reserves a minimum bandwidth resource for the first device based on a minimum bandwidth guarantee strategy.

[0053] In step S106, the second device sends quota authorization information to the first device so that the first device can transmit traffic based on the quota authorization information.

[0054] In one exemplary embodiment, when the first device performs traffic transmission based on quota authorization information, the second device performs access control and traffic control based on the quota authorization information.

[0055] In one exemplary embodiment, if the traffic sent by the first device exceeds the quota limit indicated in the quota authorization information, the second device buffers the portion of the traffic exceeding the quota limit and sends feedback information to the first device within the quota time corresponding to the quota authorization information, instructing the first device to suspend or adjust the traffic transmission.

[0056] In this embodiment, when the data sent by the source host (i.e., the first device) exceeds the quota, the network ingress or gateway node of the second device caches the data and prohibits its transmission into the network. Within the quota period, it provides rapid feedback via protocol, enabling or disabling traffic. When a part of the system, such as the destination host, exceeds its traffic limit, network congestion or excessive traffic occurs. The network side (i.e., the second device) performs quota-based flow control. When the quota is exceeded, flow control is activated, thereby notifying the source host to suspend sending traffic and alleviate the degree of congestion.

[0057] In one exemplary embodiment, when the second device receives a new task transmission request from the first device, the second device adjusts the existing quota authorization information based on the new task transmission request and the current network resource status.

[0058] This embodiment also provides a congestion control method based on end-to-end network collaboration. Figure 2 is a flowchart of another congestion control method based on end-to-end network collaboration according to an embodiment of this disclosure. As shown in Figure 2, the process includes the following steps:

[0059] In step S202, the first device sends a task transmission request to the second device.

[0060] In step S204, the first device receives quota authorization information from the second device, wherein the quota authorization information is determined by the second device based on the task transmission request.

[0061] Step S206: The first device transmits traffic based on the quota authorization information.

[0062] This disclosure provides a congestion control method for end-to-end network collaboration, comprising: a second device receiving a task transmission request from a first device; the second device determining quota authorization information based on the task transmission request; and the second device sending the quota authorization information to the first device, so that the first device performs traffic transmission based on the quota authorization information. This disclosure solves the problem of poor high-performance, time-limited transmission of large-capacity data in wide area networks (WANs) in related technologies, achieving the goal of ensuring high-performance transmission of large-capacity data over WANs.

[0063] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solutions of the embodiments of this disclosure, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the embodiments of this disclosure.

[0064] This embodiment also provides a congestion control device for end-to-end network coordination, which is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0065] In this embodiment of the disclosure, the aforementioned end-to-end network collaborative congestion control device may include different modules, and the naming and functional division of these modules may be selected in different ways according to the actual situation, without specific limitations.

[0066] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0067] This disclosure also provides a network device. FIG3 is a structural block diagram of the network device according to an embodiment of this disclosure. As shown in FIG3, the network device 300 includes a receiver 301, a transmitter 302 and a processor 303. The network device 300 is used to execute the steps of the above-described model access method embodiment through at least one of the receiver 301, transmitter 302 and processor 303.

[0068] This disclosure also provides a computer-readable storage medium storing a computer program configured to perform the steps in any of the above method embodiments when executed.

[0069] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0070] This disclosure also provides an electronic device including a memory and a processor, the memory storing a computer program and the processor being configured to run the computer program to perform the steps in any of the above method embodiments.

[0071] In one exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.

[0072] This disclosure also provides a computer program product, including a computer program that, when executed by a processor, implements the steps in any of the above method embodiments.

[0073] In one exemplary embodiment, the computer program product described above includes a non-volatile computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps of the methods described in various embodiments of this application.

[0074] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0075] Obviously, those skilled in the art should understand that the modules or steps of the embodiments of this disclosure described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented herein, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the embodiments of this disclosure are not limited to any particular combination of hardware and software.

[0076] To enable those skilled in the art to better understand the technical solutions of the embodiments disclosed herein, the following description is provided in conjunction with different embodiments.

[0077] Example 1

[0078] In this embodiment of the disclosure, the first device may be an end-side host, and the second device may be one of a proxy device, a network-side entry node, a network-side gateway node, a network-side controller, and a network-side centralized scheduler.

[0079] This embodiment provides an end-to-end network collaborative congestion control method. The network negotiates transmission rates with end-side hosts based on task-oriented application requirements, and prevents congestion by dynamically allocating and authorizing transmission traffic quotas to end-side hosts. Simultaneously, it implements quota-based resource scheduling, admission control, and flow control to meet the optimal completion time objective. This method focuses on an end-to-end network collaborative mechanism based on proactive network-side congestion avoidance, which differs significantly from traditional end-side rate-adjustment-based congestion control techniques. It can greatly reduce the convergence time of traditional congestion control algorithms, achieving high-throughput, time-limited transmission of large-capacity data over wide area networks while ensuring resource utilization and fairness.

[0080] First, the endpoint host sends a transmission request based on a predictable task to the network-side ingress node, network-side gateway node, or network-side controller to negotiate quotas and rates, including but not limited to task identifier; task start time; task completion time; data transmission volume; traffic type; and Quality of Service (QoS) level.

[0081] Sudden surges in data transmission over a wide area network (WAN) can lead to momentary congestion, packet loss, and queuing delays. Because the congestion control mechanism lacks quantitative awareness of network bandwidth resources at the endpoint, rate adjustment becomes uneven, convergence is slow, and throughput decreases. Therefore, this application proposes that in wide-area high-throughput transmission scenarios, the endpoint host can negotiate the transmission rate with the network based on the task-oriented transmission needs of high-capacity data transmission. According to the coordination mechanism between the endpoint host and the network, there are three strategies for rate negotiation as follows:

[0082] ① Optimal rate or optimal rate range negotiation: The network side provides a resource scheduling mechanism for large-capacity data to obtain QoS guarantee and achieve optimal rate transmission. The terminal host can transmit according to the negotiated optimal rate or optimal rate range.

[0083] ② Minimum Rate Negotiation: The network side provides minimum resource reservation guarantee for large-capacity data to achieve minimum rate transmission, and the terminal host can transmit at a rate not less than the negotiated rate.

[0084] ③ Maximum rate negotiation: The network side provides an upper limit for resource reservation for large-capacity data to achieve maximum rate transmission, and the terminal host can transmit at a rate not greater than the negotiated rate.

[0085] Because the tasks are predictable, the endpoint host needs to provide predictable task traffic information, i.e., the endpoint host sends a task transmission request to the network side. The task transmission request includes, but is not limited to, task identifier; task start time; task completion time; data transmission volume; traffic type; QoS level, etc. The network side needs to provide task awareness and resource scheduling to ensure the transmission needs and resource guarantees of all tasks. Figure 4 is a schematic diagram of rate negotiation between the endpoint host and the network side. As shown in Figure 4, the source host and the ingress or gateway node or controller of the network side send task transmission requests through control signaling or protocol, carrying the traffic pattern. The parameters in the task transmission request may carry task identifier ID, task start time, task completion time, data volume, traffic type, QoS level, etc.

[0086] Secondly, after the network-side ingress node / gateway node / controller receives the task transmission request, the network performs quota resource scheduling according to the task transmission request, dynamically allocates and authorizes the guaranteed quota for the task, and returns the quota authorization information to the end-side host.

[0087] This disclosure proposes that the network needs to grant quotas based on task transmission requests and available resources, and implement quota-based resource scheduling, sending the negotiated quotas and rate authorizations to the end-side host. Furthermore, after receiving a task transmission request, the network ingress or gateway node can first classify the traffic according to the task requirements, and then aggregate or split the traffic based on the classification. It can also provide quota authorization and scheduling based on traffic classification. As shown in Figure 4, after receiving a task transmission request via signaling or protocol, the network ingress or gateway node allocates a quota for the task based on the traffic parameters and network resources of the task transmission request, including resource guarantee policies and negotiated rates, and returns the quota authorization information to the end-side host. When the network receives a new concurrent task transmission request, it can adjust the authorization (i.e., quota authorization information) according to the completion time requirements and available resources.

[0088] The quota proposed in this disclosure can be defined as the amount of transmitted bits guaranteed by network resources within a certain period of time, which can be converted into a negotiated rate for traffic forwarding. Available resources based on the quota include bandwidth, queues, buffers, etc., within a certain period. The network can control traffic by allocating fixed resources to different tasks and allocating time-based resources to each task to ensure reasonable resource utilization, preventing resource preemption by the same task in network control and ensuring fair resource sharing among different tasks. This allocation ensures that even under high load conditions, each task can obtain a certain level of resource guarantee, thereby avoiding congestion caused by resource contention.

[0089] This disclosure proposes that the network side can allocate and authorize quotas according to task requirements, and implement resource scheduling based on these quotas to proactively avoid congestion and ensure efficient forwarding based on quotas and their rates. The network quota guarantee strategy needs to be selected based on network resources. The network side needs to collect network resource information and select a resource guarantee strategy according to task requirements. The quota-based resource management and guarantee strategy proposed in this disclosure has three methods as follows:

[0090] ① Network side provides lossless protection: When quota management reserves bandwidth queues and buffers and adopts entry admission, it can ensure that the network is free from congestion, packet loss, and has a guaranteed latency. For example, explicit paths and deterministic queues are used for resource protection.

[0091] ② The network side provides a certain level of guaranteed (lossy) packet loss: When quota management reserves bandwidth resources, packet loss may occur in the network. Network-side flow control is required to ensure a certain level of guaranteed packet loss. For example, bandwidth guarantee can be achieved through methods such as slicing. Flow control mechanisms are implemented between intermediate network nodes according to the allocated quotas. When the quota is exceeded, the flow control mechanism needs to be activated to guarantee a level of guaranteed packet loss.

[0092] ③ The network side provides a minimum bandwidth guarantee: the quota management reserves a minimum bandwidth resource, which needs to be calculated through a mathematical model to guarantee the deadline, and the remaining bandwidth can be preempted.

[0093] Figure 5 is a schematic diagram of quota-based resource scheduling on the network side. As shown in Figure 5, the network-side controller or centralized scheduler needs to implement quota-based resource planning and allocation. The network-side controller or centralized scheduler needs to allocate quotas based on time-limited transmission requests from multiple endpoints, the available resources of bottleneck links, and the available capacity of destination hosts, and then feed back the allocation to the ingress or gateway node.

[0094] In this embodiment of the disclosure, after the end-side host sends traffic according to the negotiated quota or rate, the network side performs quota-based admission and traffic control, etc. When the quota is exceeded, the ingress or gateway node provides rapid feedback within the quota time.

[0095] After receiving a message, the endpoint host can send traffic at the negotiated rate corresponding to the network's authorized quota. The endpoint host's congestion control algorithm can send traffic based on either the network-authorized quota or the negotiated rate. When the endpoint host sends a new task transmission request to the network, the network can adjust the authorized quota of existing tasks based on the new request and available resources. The adjusted quota must guarantee the task completion time.

[0096] Figure 6 illustrates the rapid feedback mechanism of ingress / gateway node flow control. As shown in Figure 6, after the source host sends traffic according to the negotiated quota or rate, the network ingress or gateway node performs admission and flow control based on the negotiated quota. When the data sent by the source host exceeds the quota, the network ingress or gateway node buffers the data, prohibiting it from entering the network for transmission. Within the quota period, it provides rapid feedback via protocol, enabling or disabling traffic. When a part of the system, such as the destination host, exceeds its traffic limit, network congestion or excessive traffic occurs. The network then implements quota-based flow control. When the quota is exceeded, flow control is activated, thereby notifying the source host to suspend traffic transmission and alleviate congestion.

[0097] Example 2

[0098] This embodiment provides a congestion control method based on end-to-end network collaboration. It achieves high-performance transmission of large-capacity data over a wide area network by proposing that the network side negotiates quotas and rates with the end-side hosts based on task-oriented application requirements (i.e., task transmission requests). Congestion is prevented by dynamically authorizing traffic quotas to the end-side hosts, thereby implementing quota-based resource scheduling, admission control, and flow control to meet the optimal completion time objective. Figure 7 is a flowchart illustrating the end-to-end network collaboration congestion control method of this embodiment. The specific steps are shown in Figure 7.

[0099] In step S702, the terminal host sends a quota and rate negotiation request based on a predictable task transmission request to the network-side ingress node, gateway node, or controller. This request includes, but is not limited to, information such as task identifier, task start time, task completion time, data transmission volume, traffic type, and QoS level.

[0100] In step S704, after the network-side ingress node, gateway node, or controller receives the task transmission request, the network side performs quota-based resource scheduling according to the task transmission request, dynamically allocates and authorizes a guaranteed quota for the task, and returns the result to the end-side host.

[0101] In step S706, after the end-side host sends traffic according to the negotiated quota or rate, the network side performs quota-based admission and traffic control. When the quota is exceeded, the network-side ingress node or gateway node provides rapid feedback within the quota time.

[0102] Figure 8 is a flowchart of the end-to-end collaborative congestion control mechanism based on network quota authorization according to an embodiment of this disclosure. As shown in Figure 8, the solid line part of the process belongs to the Web and Internet Transport (WIT) domain technology in the Internet Engineering Task Force (IETF) standard, the dashed line part of the process belongs to the IETF network layer routing (RTG) domain technology, and the dotted line part of the process represents the service traffic sent by the end side. The source host and the ingress / gateway node (exgress / gateway node and destination host) can interact using signaling or protocols. Within the network (ingress / gateway node, intermediate nodes, egress / gateway node), quota-based resource scheduling and interaction with the controller can adopt extended protocols such as traffic engineering techniques, and quota-based flow control can adopt Priority Flow Control (PFC) and its extended protocols.

[0103] This disclosure proposes that the source host and the network-side ingress or gateway node or controller can be extended through new signaling or existing signaling, including but not limited to existing signaling methods such as Resource Reservation Protocol (RSVP), Link Layer Discovery Protocol (LLDP), Border Gateway Protocol (BGP), Path Computation Element Communication Protocol (PCEP), etc.

[0104] This disclosure proposes that the source host and the network-side entry or gateway node or controller can also be extended through new protocols or existing protocols, including but not limited to existing protocols such as TCP, User Data Protocol (UDP), QUIC, etc.

[0105] This disclosure provides extended task transmission request messages and authorization messages (i.e., quota authorization information). Figure 9 is a schematic diagram of the principle of extending the task transmission request message. As shown in Figure 9, the fields of the extended Traffic Pattern Object in the task transmission request message include: Task ID; Task Start Time; Task Completion Time; Data Volume; QoS level / Traffic Type, etc.

[0106] This disclosure also provides an extension of the Quota Object in the Acknowledgement message, i.e., the quota authorization information. Figure 10 is a schematic diagram of the principle of extending the quota authorization information. As shown in Figure 10, the fields of the Quota Object include: Task ID; Rate; Quota Policy; Time frame TLV, etc.

[0107] Figure 11 is a schematic diagram of the fields of a Time frame TLV. As shown in Figure 11, the fields include: Start Time and End Time.

[0108] Example 3

[0109] FIG. 12 is a schematic diagram of large-capacity data transmission through a wide area network. As shown in FIG. 12, source hosts 1 / 2 / 3 send data to a destination host through the wide area network. Source host 1 sends 1TB of data, which is required to start at time T0 and be completed within 60s; source host 2 sends 2TB of data, which is required to start at T0+30s and be completed within 100s; source host 3 sends 3TB of data, which is required to start at T0+45s and be completed within 120s. The wide area network receives data through an ingress gateway and sends the data to the destination host through an egress gateway. The bandwidth of the network bottleneck link is 100G. The specific steps are as follows:

[0110] ① Source host 1 sends a 1TB data request 1 to a gateway node, the request carries information such as start time T0 and completion time 60s; source host 2 sends a 2TB data request 2 to the gateway node, the request carries information such as start time T0+30s and completion time 100s; source host 3 sends a 3TB data request 3 to the gateway node, the request carries information such as start time T0+45s and completion time 120s.

[0111] ② The gateway node applies for quota allocation from the controller according to the received concurrent request information. Based on the available bandwidth of 100G, the controller authorizes a quota for each request, which includes: 100G (T0->T0+30), 50G (T0+30->T0+45), 33G (T0+45-><T0+60), and returns the authorized quota to end-side host 1; 50G (T0+30->T0+45), 33G (T0+45-><T0+100s), and returns the authorized quota to end-side host 2; 33G (T0+45-><T0+120s), and returns the authorized quota to end-side host 3.

[0112] Embodiment 4

[0113] As shown in FIG. 12, source hosts 1 / 2 / 3 send data to a destination host through a wide area network, and source host 1 sends 1TB of data, which is required to start at time T0 and be completed within 60s. Through quota authorization-based resource scheduling, the network actively avoids congestion, reserves bandwidth, and provides guaranteed packet loss and delay. The specific steps are as follows:

[0114] ① A controller of the network needs to collect network resource information, and perform quota planning and the like based on information such as network resources, including bandwidth, queues, buffers and the like.

[0115] ② The gateway node applies for quota allocation from the controller according to the received concurrent request information, and the controller allocates a quota for each request and reserves resources.

[0116] ③ When the network needs to provide lossless guarantee, the controller needs to calculate an explicit path according to the data volume, completion time and other parameters of the task request, reserve bandwidth resources, and adopt deterministic queues and other methods to ensure no congestion, no packet loss and commitable delay in the network, and allocate 100G bandwidth and 60s delay to the task of source host 1, with the queue being Cycle Specified Queuing and Forwarding (CSQF) queue.

[0117] ④ When the network provides a certain commit (lossy) guarantee, the controller needs to calculate an explicit path according to the data volume, completion time and other parameters of the task request, reserve bandwidth, and guarantee a certain packet loss rate, and allocate 100G slice bandwidth to the task of source host 1.

[0118] Embodiment 5

[0119] As shown in Figure 12, source hosts 1 / 2 / 3 send data to the destination host through the wide area network. Source host 1 sends 1TB of data, requiring to start at time T0 and complete within 60s; source host 2 sends 2TB of data, requiring to start at time T0 and complete within 100s, and the bandwidth of the network bottleneck link is 100G. Source host 3 sends a request to transmit 3TB of data at time T0, requiring to start at T0+45s and complete within 120s. The specific steps are as follows:

[0120] ① Source host 1 sends data request 1 of 1TB to the gateway node, which carries information such as start time T0 and completion time 60s; source host 2 sends data request 2 of 2TB to the gateway node, which carries information such as start time T0 and completion time 100s.

[0121] ② The gateway node applies for quota allocation from the controller according to the received concurrent request information. Based on the available bandwidth of 100G, the controller authorizes quotas for each request, including: 50G (from T0 to T0+60s), and returns the authorized quota to source host 1; 50G (from T0 to T0+60s) and 100G (from T0+60s to T0+100s), and returns the authorized quota to source host 2.

[0122] ③ Source host 3 sends data request 3 of 3TB to the gateway node, which carries information such as start time T0+45s and completion time 120s.

[0123] ④ The gateway node applies for quota allocation from the controller according to the received request message. Based on the available bandwidth of 100G, the controller grants a quota to the source host 3, which includes: 20G (T0+45s->T0+100s), and returns the granted quota to the end-side host 3; adjusts the granted quota of the source host 2 to 30G (T0+45s->T0+100s), 100G (T0+60s-><T0+120s), and returns the granted quota to the end-side host 2.

[0124] ⑤ When the egress gateway node receives the notification of capacity exceeding limit from the destination end side, the gateway node enables caching, and starts the intra-network flow control mechanism when the quota transmission exceeds the limit, notifies the ingress gateway along the path through intermediate nodes, and the ingress gateway node sends a fast feedback to the end-side host 3 to shut down the traffic.

[0125] The above description is only the preferred embodiments of the embodiments of the present disclosure, and is not intended to limit the embodiments of the present disclosure. For those skilled in the art, various modifications and changes can be made to the embodiments of the present disclosure. Any modification, equivalent replacement, improvement, etc. made within the principles of the embodiments of the present disclosure shall be included in the protection scope of the embodiments of the present disclosure.

Claims

1. A congestion control method involving end-to-end network coordination, comprising: The second device receives a task transmission request from the first device; The second device determines the quota authorization information based on the task transmission request; The second device sends quota authorization information to the first device, so that the first device can perform traffic transmission based on the quota authorization information.

2. The method according to claim 1, wherein, The first device includes an end-side host; The second device includes at least one of the following: a proxy device; a network-side entry node; a network-side gateway node; a network-side controller; and a network-side centralized scheduler.

3. The method according to claim 1, wherein, The task transmission request includes at least one of the following: Task identifier; task start time; task completion time; data transmission volume; traffic type; Quality of Service (QoS) level.

4. The method according to claim 1, wherein, The second device determines quota authorization information based on the task transmission request, including: The second device acquires network resource information; The second device allocates a quota for each task based on the network resource information and the task transmission request, and performs quota-based resource scheduling.

5. The method according to claim 4, wherein, The quota-based resource scheduling includes: The second device allocates fixed resources to different tasks based on available resources within a certain time period to control traffic transmission, and allocates time-sliced ​​resources to each task, wherein the available resources include bandwidth, queues, and buffers.

6. The method according to claim 1, wherein, The quota authorization information includes at least one of the following: Task quota; negotiated transmission rate; task identifier; time fragmentation information.

7. The method according to claim 6, wherein, The quota for the task includes: Within a certain period of time, the amount of transmission bits guaranteed by network resources is converted into the negotiated transmission rate for traffic forwarding.

8. The method according to claim 1, wherein, The second device determines quota authorization information based on the task transmission request, including: The second device negotiates the transmission rate corresponding to the task transmission with the first device based on the task transmission request.

9. The method according to claim 8, wherein, The second device performs rate negotiation with the first device based on the task transmission request, including: The second device negotiates the optimal rate with the first device based on the task transmission request to determine the optimal traffic transmission rate; Alternatively, the second device may negotiate a minimum rate with the first device based on the task transmission request to determine the minimum traffic transmission rate; Alternatively, the second device may negotiate the maximum rate with the first device based on the task transmission request to determine the maximum traffic transmission rate.

10. The method according to claim 1, wherein, The second device determines quota authorization information based on the task transmission request, including: The second device classifies traffic according to the task transmission request, and aggregates or splits the traffic to be transmitted according to the traffic classification result to obtain the final traffic classification result; The second device determines the quota authorization information based on the final traffic classification result.

11. The method according to claim 1, wherein, The second device determines quota authorization information based on the task transmission request, including: Based on the task transmission request, the second device determines the network resource quota corresponding to the task transmission according to the network cooperation guarantee strategy.

12. The method according to claim 11, wherein, The network coordination protection strategy includes at least one of the following: Lossless guarantee strategy; lossy guarantee strategy; minimum bandwidth guarantee strategy.

13. The method according to claim 12, wherein, The second device determines the network resource quota corresponding to the task transmission according to the network coordination guarantee strategy, including: The second device reserves an explicit path and / or bandwidth queue for the first device based on the lossless protection strategy; Alternatively, the second device may reserve bandwidth slices and / or commit to a packet loss rate for the first device based on the lossy commitment guarantee strategy. Alternatively, the second device may reserve minimum bandwidth resources for the first device based on the minimum bandwidth guarantee strategy.

14. The method according to claim 1, wherein, Also includes: When the first device transmits traffic based on the quota authorization information, the second device performs access control and traffic control based on the quota authorization information.

15. The method according to claim 1, wherein, Also includes: If the traffic sent by the first device exceeds the quota limit indicated in the quota authorization information, the second device buffers the portion of the traffic exceeding the quota limit and sends feedback information to the first device within the quota time corresponding to the quota authorization information, instructing the first device to pause or adjust the traffic transmission.

16. The method according to claim 1, wherein, Also includes: When the second device receives a new task transmission request from the first device, the second device adjusts the existing quota authorization information based on the new task transmission request and the current network resource status.

17. The method according to claim 1, wherein, The second device interacts with the first device through control signaling or extended protocols.

18. A congestion control method involving end-to-end network coordination, comprising: The first device sends a task transmission request to the second device; The first device receives quota authorization information from the second device, wherein the quota authorization information is determined by the second device based on the task transmission request; The first device transmits traffic based on the quota authorization information.

19. A network device comprising a receiver, a transmitter, and a processor, the network device being configured to perform the steps of the method of any one of claims 1 to 18 via at least one of the receiver, the transmitter, and the processor.

20. A computer-readable storage medium storing a computer program, wherein, When the computer program is executed by a processor, it implements the steps of the method described in any one of claims 1 to 15.

21. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor, when executing the computer program, performs the steps of the method according to any one of claims 1 to 18.

22. A computer program product comprising a computer program that, when executed by a processor, implements the steps of the method described in any one of claims 1 to 18.

Images