Congestion control method, system, apparatus and device

Abstract

One embodiment of the present specification provides a congestion control method, system, device and equipment. The scheme comprises: obtaining a congestion control feedback message of a receiving end backhaul; the congestion control feedback message carries an arrival time of a data packet under a receiving end clock; calculating a mapped arrival time of the data packet under a sending end clock according to the arrival time and a receiving time of the congestion control feedback message under the sending end clock; calculating a one-way delay according to the mapped arrival time and a sending time of the data packet under the sending end clock; determining a congestion threshold based on the one-way delay; for a reference data packet successfully arriving at the receiving end, determining an in-flight data amount according to an amount of data sent by the sending end in a time interval formed by the sending time and the mapped arrival time of the reference data packet; and performing congestion control according to a comparison result of the in-flight data amount and the congestion threshold.

Description

Technical Field

[0001] This specification relates to the field of real-time communication technology, and particularly to congestion control methods. This specification also relates to congestion control systems, congestion control devices, and a computing device. Background Technology

[0002] Real-Time Communication (RTC) technology has been widely applied in various real-time interactive scenarios such as video conferencing, live streaming, distance education, and cloud gaming. These applications typically use UDP as the underlying transport protocol to reduce end-to-end transmission latency and avoid the latency uncertainties introduced by TCP retransmission mechanisms. Since UDP itself does not provide acknowledgment and retransmission mechanisms similar to TCP, congestion control tasks need to be implemented at the application or transport layer. Traditional congestion control algorithms usually estimate bandwidth and adjust the transmission rate based on signals such as packet loss or one-way delay changes. For example, the BBR (Bottleneck Bandwidth and Round-trip propagation time) algorithm, designed for TCP, achieves a balance between high throughput and low latency by measuring bottleneck bandwidth and round-trip propagation time, achieving good results in reliable transmission scenarios.

[0003] However, in UDP-based real-time communication scenarios, the transmission characteristics of data streams differ significantly from those of TCP. The sender cannot directly obtain reliable acknowledgments, making it difficult to meet the input conditions of traditional congestion control algorithms. How to ensure the sender obtains accurate network status information and performs effective congestion control based on this information in a UDP transmission environment that does not rely on the ACK mechanism has become a technical problem that needs further resolution in the field of real-time communication. Summary of the Invention

[0004] In view of this, one or more embodiments of this specification provide congestion control methods, systems, apparatuses, and devices to achieve effective congestion control in a UDP transmission environment that does not rely on the ACK mechanism.

[0005] According to a first aspect of one or more embodiments of this specification, a congestion control method is provided, comprising: Obtain the congestion control feedback message returned by the receiving end; the congestion control feedback message carries the arrival time of the data packet under the clock of the receiving end; Based on the arrival time and the reception time of the congestion control feedback message under the sending clock, calculate the arrival time of the data packet after mapping under the sending clock. Calculate the one-way delay based on the arrival time after mapping and the transmission time of the data packet under the clock of the sending end; Based on the unidirectional delay, a congestion threshold is determined; For a reference data packet that successfully arrives at the receiving end, the amount of data transmitted by the sending end within the time interval formed by the sending time and the mapped arrival time of the reference data packet is determined; Congestion control is performed based on the comparison between the amount of data in flight and the congestion threshold.

[0006] According to a second aspect of one or more embodiments of this specification, a congestion control system is provided, comprising: The sending end is used to execute the congestion control method described in one or more embodiments of this specification; The receiving end is used to generate and send a congestion control feedback message to the sending end; the congestion control feedback message carries the arrival time of the data packet under the clock of the receiving end.

[0007] According to a third aspect of one or more embodiments of this specification, a congestion control device is provided, comprising: The feedback message acquisition module is used to acquire the congestion control feedback message returned by the receiving end; the congestion control feedback message carries the arrival time of the data packet under the clock of the receiving end. The clock mapping module is used to calculate the arrival time of the data packet after mapping under the sending end clock, based on the arrival time and the reception time of the congestion control feedback message under the sending end clock. The delay calculation module is used to calculate the one-way delay based on the arrival time after mapping and the transmission time of the data packet under the clock of the sending end; A congestion threshold determination module is used to determine a congestion threshold based on the one-way delay; The in-flight data volume determination module is used to determine the in-flight data volume for a reference data packet that successfully arrives at the receiving end, based on the amount of data sent by the sending end within the time interval formed by the sending time and the mapped arrival time of the reference data packet. The congestion control module is used to perform congestion control based on the comparison result between the amount of in-flight data and the congestion threshold.

[0008] According to a fourth aspect of one or more embodiments of this specification, a computing device is provided, including a memory, a processor, and computer instructions stored in the memory and executable on the processor, wherein the processor, when executing the computer instructions, implements the steps of the congestion control method.

[0009] One embodiment of this specification can achieve at least the following beneficial effects: The sending end obtains the congestion control feedback message returned by the receiving end, uses the reception time of the message under the sending end's clock and the arrival time of the data packets carried in the message under the receiving end's clock to map the arrival time under the receiving end's clock domain, thereby obtaining the mapped arrival time and calculating the one-way delay of each data packet accordingly, and determining the congestion threshold based on the one-way delay; and divides the time interval by the transmission time and mapped arrival time of the successfully arrived reference data packet, and counts the amount of data sent by the sending end within the interval as the in-flight data volume; finally, compares the in-flight data volume with the congestion threshold, and performs congestion control according to the comparison result. Therefore, in a UDP transmission environment lacking TCP acknowledgment, the sender can map the arrival time under the receiver's clock to the local clock domain and calculate the one-way delay. The congestion threshold determined based on the one-way delay can reflect the current network pipeline's carrying capacity. By defining time intervals based on reference data packets to statistically analyze the amount of data sent, the ability to estimate the amount of data in flight is reconstructed without an acknowledgment mechanism. By comparing the amount of data in flight with the congestion threshold, the sender can anticipate congestion in advance and proactively adjust its sending behavior when the amount of data in flight approaches the pipeline capacity, rather than passively waiting for packet loss to occur before responding. The entire process forms a complete closed loop from delay awareness and load estimation to proactive control, enabling UDP-based real-time communication systems to effectively avoid network congestion while ensuring low latency, thereby improving transmission stability and bandwidth utilization. Attached Figure Description

[0010] To more clearly illustrate the technical solutions in one embodiment of this specification or in the prior art, the drawings used in the description of the embodiment or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments recorded in this specification. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0011] Figure 1 A schematic diagram of the overall framework of a congestion control method provided in one embodiment of this specification; Figure 2 A flowchart illustrating a congestion control method provided in one embodiment of this specification; Figure 3 This is a schematic diagram of a high packet loss robustness compensation architecture provided in one embodiment of this specification; Figure 4 A congestion control flowchart of a congestion control system provided in an embodiment of this specification in a practical application scenario; Figure 5 For one embodiment of this specification, corresponding to Figure 2A schematic diagram of the structure of a congestion control device; Figure 6 A structural block diagram of a computing device provided according to an embodiment of this specification is shown. Detailed Implementation

[0012] To enable those skilled in the art to better understand the technical solutions in this specification, the technical solutions in one embodiment of this specification will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of this specification, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments in this specification without creative effort should fall within the scope of protection of this specification.

[0013] This specification uses specific terms to describe embodiments thereof. Terms such as "an embodiment," "one embodiment," and / or "some embodiments" refer to a particular feature, structure, or characteristic associated with at least one embodiment of this specification. Therefore, it should be emphasized and noted that references to "an embodiment," "one embodiment," or "an alternative embodiment" in different locations throughout this specification do not necessarily refer to the same embodiment. Furthermore, those skilled in the art can combine and integrate the different embodiments or examples described herein, as well as the features of those different embodiments or examples, without contradiction.

[0014] The terminology used in one or more embodiments of this specification is for the purpose of describing particular embodiments only and is not intended to be limiting of the one or more embodiments of this specification. The singular forms “a,” “an,” “an,” “the,” and “the” as used in one or more embodiments of this specification and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used in one or more embodiments of this specification includes any or all possible combinations of one or more associated listed items.

[0015] The terms “comprising,” “including,” or any other variations thereof are intended to cover a non-exclusive inclusion, such that a process, method, product, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, product, or apparatus. Without further limitation, the presence of additional identical or equivalent elements in the process, method, product, or apparatus that includes said elements is not excluded.

[0016] Although the terms "first," "second," etc., may be used to describe various information in one or more embodiments of this specification, this information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, "first" may also be referred to as "second," and similarly, "second" may also be referred to as "first," without departing from the scope of one or more embodiments of this specification. Ordinal numbers such as "first," "second," etc., do not necessarily indicate order; often they are used to facilitate the distinction of objects. For example, "first server" and "second server" usually refer to two servers. To distinguish these two servers, they are described as "first server" and "second server." Of course, sometimes these two servers may be the same server.

[0017] Depending on the context, the word "if" as used here can be interpreted as "when," "when," or "in response to determination."

[0018] In this specification, unless explicitly stated otherwise, "receiving and sending data" does not necessarily mean direct receiving and sending; it can also mean indirect receiving and sending. For example, A receiving data sent by B can be understood as A directly receiving the data sent by B, or it can be understood as A indirectly receiving the data sent by B through other entities such as C. Similarly, B sending data to A can be understood as B sending the data directly to A, or it can be understood as B indirectly sending the data to A through other entities such as C. Here, C can be one entity, or it can be two or more entities.

[0019] In this specification, unless explicitly stated otherwise, the relationships between structures can be direct or indirect. For example, when describing "A is connected to B," unless it is explicitly stated that A and B are directly connected, it should be understood that A can be directly connected to B or indirectly connected to B. Similarly, when describing "A is on top of B," unless it is explicitly stated that A is directly above B (AB is adjacent and A is above B), it should be understood that A can be directly above B or indirectly above B (AB is separated by other elements, and A is above B). And so on.

[0020] The user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in one or more embodiments of this specification are all information and data authorized by the user or fully authorized by all parties. The collection, use and processing of related data shall comply with the relevant laws, regulations and standards of the relevant regions, and corresponding operation entry points shall be provided for users to choose to authorize or refuse.

[0021] The following explains the terms and concepts used in one or more embodiments of this specification.

[0022] Round-Trip Time (RTT) is an important metric for measuring network communication latency. It refers to the total time required for data to travel from the sender to the receiver, through the network, and back to the sender via an acknowledgment signal from the receiver.

[0023] Congestion control methods are technical means in computer science used to regulate network traffic and avoid or alleviate congestion. From the perspective of where congestion control methods are implemented, they can be divided into endpoint-based congestion control and link-based (router) congestion control. Link-based methods are executed in network devices (such as routers and switches), and their function is to detect the occurrence of network congestion and generate congestion feedback information. Endpoint-based methods are executed in hosts and network edge devices, and their function is to adjust the transmission rate based on feedback information. The key to congestion control algorithm design is how to generate feedback information and how to respond to feedback information.

[0024] Transmission Control Protocol (TCP) is a connection-oriented, reliable, byte-stream-based transport layer communication protocol defined by IETF RFC 793. TCP is designed to accommodate layered protocol hierarchies that support multiple network applications. In interconnected computer networks, pairs of application processes can rely on TCP to provide reliable communication services for transmitting byte streams. TCP supports bidirectional data streaming, but applications can also send data unidirectionally. Between hosts, TCP uses port numbers to identify application services and can multiplex data streams.

[0025] Acknowledgment Mechanism (ACK): TCP's acknowledgment mechanism is one of the core mechanisms that provides reliable, ordered, and non-duplicated transmission. The ACK mechanism allows the sender to determine which data has been correctly received and which needs to be retransmitted by having the receiver acknowledge successfully received data.

[0026] The TCP congestion control algorithm mainly consists of four parts: (1) Slow start. Whenever a TCP connection is established or a TCP connection times out and is retransmitted, the connection enters the slow start phase. After entering slow start, the TCP entity initializes the size of the congestion window (cwnd) to one packet, i.e., cwnd=1. After that, for each packet acknowledgment (ACK) received, the cwnd value is incremented by 1, i.e., the congestion window increases exponentially. When the cwnd value exceeds the slow start threshold (ssthresh) or a packet loss and retransmission occurs, the slow start phase ends. The former enters the congestion avoidance phase, and the latter re-enters the slow start phase. (2) Congestion avoidance. In the slow start phase, when the cwnd value exceeds the slow start threshold, the slow start process ends, and the TCP connection enters the congestion avoidance phase. In the congestion avoidance phase, the cwnd value is incremented by 1 only after each cwnd packet is fully acknowledged. In this phase, the cwnd value increases linearly. (3) Fast retransmission. Fast retransmission is an improvement over timeout retransmission. When the source receives three duplicate acknowledgments for the same packet, it can determine that the packet has been lost, and therefore immediately retransmits the lost packet without waiting for the retransmission timeout (RTO) to expire. This reduces unnecessary waiting time. (4) Fast recovery. Fast recovery is an improvement over the loss recovery mechanism. After fast retransmission, it directly enters the congestion avoidance phase without going through the slow start process. After each fast retransmission, ssthresh is set to cwnd / 2 and cwnd is set to ssthresh+3. After that, for each duplicate acknowledgment received, the cwnd value is incremented by 1 until the cumulative acknowledgments for the lost packet and several subsequent packets are received, at which point cwnd is set to ssthresh, and then the congestion avoidance phase begins.

[0027] BBR (Bottleneck Bandwidth and Round-trip Propagation Time) is a congestion control algorithm based on bandwidth and round-trip propagation time, originally used in the TCP protocol. BBR aims to improve network throughput by utilizing network resources more efficiently. Compared to traditional TCP congestion control algorithms, BBR places greater emphasis on the bottleneck bandwidth and round-trip propagation time of the actual network to more precisely control data transmission rates and avoid network congestion.

[0028] The BBR algorithm is implemented based on the following three core mechanisms: (1) Bandwidth probing: When a connection is established, BBR sends some special data packets to probe the network bandwidth. Specifically, BBR continuously increases the data packet sending rate until network congestion occurs, and then reduces the sending rate to avoid congestion. (2) Bottleneck bandwidth estimation: BBR estimates the bottleneck bandwidth on the network path by monitoring the time of data packet sending and receiving. Specifically, BBR calculates the bandwidth on the network path by measuring the difference between the sending interval and receiving time of two consecutive data packets on the network. (3) Congestion control: Once BBR estimates the bottleneck bandwidth on the network path, it calculates a congestion window size based on bandwidth and RTT to control the data packet sending rate. When network congestion occurs, BBR reduces the sending rate to avoid congestion, thereby ensuring network stability and reliability. In summary, the BBR algorithm achieves congestion control by continuously probing network bandwidth, estimating bottleneck bandwidth, and adjusting the congestion window size in real time, thereby optimizing network throughput and latency.

[0029] The BBR algorithm defines four states: the STARTUP phase for quickly probing the bottleneck bandwidth, the DRAIN phase for clearing the network queue to obtain propagation delay, the ProbeBW phase for periodically adjusting the gain to keep the amount of data in flight near the bandwidth-delay product, and the ProbeRTT phase for periodically updating the propagation delay estimate. Based on a model-driven control of the bandwidth-delay product, the BBR algorithm adjusts the transmission rate by estimating the bottleneck bandwidth and propagation delay to achieve a balance between high bandwidth utilization and low latency.

[0030] Network bottleneck bandwidth (BtlBw) refers to the maximum arrival rate that a network path can stably carry, determining the upper limit of the bandwidth available to the sender. In the native BBR method, the bottleneck bandwidth is estimated by calculating the delivery rate from the ACK stream and taking the maximum value. Specifically, the BBR bandwidth estimation method is as follows: each time an ACK is received, calculate DeliveryRate = number of bytes received / arrival time; then, calculate BtlBw = max(DeliveryRate).

[0031] Round-trip Propagation Time (RTprop) originates from the BBR algorithm. RTprop refers to the minimum delay required for a data packet to make one round trip between the sender and receiver under ideal conditions without queuing; that is, the minimum delay between two nodes. RTprop is the minimum RTT when the network is idle, reflecting the inherent physical characteristics of the network path. RTprop is a key state parameter used in congestion control algorithms, dynamically estimated through continuous network measurements. In the BBR algorithm, the minimum RTT is measured by periodically entering the ProbeRTT state to reduce the sending rate to a very low level.

[0032] The Bandwidth-Delay Product (BDP) is determined by multiplying the bottleneck bandwidth estimate (BtlBw) and the propagation delay estimate (RTprop). Physically, it represents the total amount of data the network can accommodate under ideal, queuing-free conditions, i.e., the amount of data when the network pipeline is fully loaded. During congestion control, the BDP serves as a reference target value for in-flight data volume, used to determine whether the current network load is approaching the network pipeline capacity.

[0033] Inflight data refers to the total amount of data sent in the network but not yet acknowledged by the receiver; that is, the total number of bytes of data packets sent by the sender that have not yet received an acknowledgment. This parameter reflects the current load level injected into the network. Ideally, congestion control aims to keep the inflight data amount close to the bandwidth-delay product to fully utilize the network pipeline capacity, while avoiding excessive inflight data amount exceeding the bandwidth-delay product, which could lead to network queuing.

[0034] The Congestion Window (cwnd) limits the amount of unacknowledged data. cwnd defines the maximum amount of unacknowledged data allowed to "fly" through the network. BBR uses cwnd to limit the amount of unacknowledged data (Inflight) in the network to prevent excessive packet accumulation (avoiding buffer bloat) and to prevent burst traffic from causing queue overload. BBR aims to keep Inflight close to BDP (Bandwidth-Delay Product), i.e., Inflight ≈ BtlBw × RTprop. cwnd updates are based on the currently estimated BDP and take into account queuing conditions in the network. For example, the calculation formula is: cwnd = 2 × BDP = 2 × (BtlBw × RTprop). By limiting cwnd, BBR attempts to control the total number of packets in the network, thereby controlling queuing latency.

[0035] Pacing rate is a parameter output by the congestion control algorithm used to control the rhythm of data packet transmission. It determines the time interval at which data packets are injected into the network from the sender.

[0036] User Datagram Protocol (UDP) is a transport layer protocol operating within the Open Systems Interconnection (OSI) model. It uses IP as its underlying protocol and provides applications with a minimal protocol mechanism to send messages to other programs. Its main characteristics are connectionless operation, no guaranteed reliable transmission, and message-oriented nature. RFC 768 is the UDP standard provided by the Internet Engineering Task Force (IETF). UDP congestion control relies on application layer implementation.

[0037] Real-time communication (RTC) refers to real-time interactive communication over a network. RTC includes the instant transmission of text, images, audio, video, and other multimedia types. This communication method allows participants to engage in one-way, two-way, or multi-party real-time interaction with virtually no latency. RTC has very high requirements for low latency and high stability. RTC is widely used in scenarios such as conferencing, live streaming, and online education. It is generally based on UDP transmission and lacks the TCP ACK mechanism, making it difficult for traditional congestion control algorithms to work effectively.

[0038] Web Real-Time Communications (WebRTC) is a technology used to enable real-time audio and video communication between browsers. In WebRTC, the network controller plays a crucial role, controlling the data transmission rate and encoder bitrate to adapt to network congestion and ensure the quality and stability of audio and video communication.

[0039] Transport-wide Congestion Control (RTC) is a bandwidth estimation algorithm in WebRTC based on receiver feedback. Its core process is as follows: the sender records the sequence number and transmission time of each RTP packet; the receiver constructs an RTCP feedback packet based on the actual arrival time of each RTP packet and sends it back to the sender; the sender can then parse the feedback packet to calculate the packet loss rate and round-trip time (RTT), thus providing a basis for congestion control. RTP packets (Real-time Transport Protocol) are transport protocol packets used to carry real-time media data such as audio and video, containing information such as sequence numbers and timestamps, facilitating the receiver's reconstruction of data order and timing. RTCP packets (Real-time Transport Control Protocol) are control protocol packets used in conjunction with RTP to transmit data transmission quality feedback (such as packet loss rate and latency jitter) and participant information. Transport-wide Congestion Control uses these types of packets to provide congestion information feedback.

[0040] GCC (Google Congestion Control) is the network controller in WebRTC. GCC utilizes sender-side bandwidth estimation to adjust the congestion window and change the encoder bitrate. The working principle of the GCC network controller is as follows: 1) Congestion Window Adjustment: In WebRTC, the congestion window controls the rate at which data is sent. The GCC network controller dynamically adjusts the size of the congestion window by monitoring network congestion to avoid data loss and increased latency caused by network congestion. 2) Sender-Side Bandwidth Estimation: The GCC network controller uses sender-side bandwidth estimation to determine the degree of network congestion. It calculates the network bandwidth by measuring the transmission time of sent data and the acknowledgment information from the receiver. Based on the bandwidth estimation results, GCC can determine whether network congestion exists and adjust the congestion window and encoder bitrate accordingly.

[0041] Existing congestion control algorithms for the UDP protocol are ineffective. For example, WebRTC's GCC algorithm relies on latency or packet loss signals for bandwidth estimation. In extremely weak network environments with high packet loss and high jitter, the causes of increased packet loss and latency become more complex, potentially stemming from network congestion or non-congestion factors such as wireless channel errors, path switching, and sudden interference. Because traditional algorithms like GCC struggle to accurately distinguish between these two causes, they are prone to bandwidth misjudgment, leading to problems such as stuttering or low bandwidth utilization.

[0042] The BBR algorithm is a congestion control algorithm designed for the TCP protocol. Its core objective is to maximize throughput and minimize transmission latency, making it suitable for reliable transmission of large amounts of data. However, this algorithm heavily relies on ACK feedback during operation to maintain the calculation of in-flight data volume and reception rate, which is precisely the main reason why it is difficult to directly apply to real-time communication (RTC).

[0043] In RTC scenarios, data transmission is based on the UDP protocol, characterized by strong burstiness, high latency requirements, and no reliance on retransmissions. This makes directly introducing the BBR algorithm into RTC unsuitable in several ways: the lack of ACK feedback makes it impossible to effectively observe the network status, and the sender cannot know the amount of data in flight or obtain accurate bandwidth information; the smooth transmission rate (pacing_rate) and congestion window (cwnd) output by BBR fluctuate wildly, easily causing frequent jumps in the coding bitrate, affecting the stability of audio and video quality; in environments with high packet loss rates (such as exceeding 20%), the bandwidth estimation mechanism of BBR will seriously fail, and the estimated value will deviate significantly from the actual available bandwidth; the ProbeRTT stage in BBR almost completely stops data transmission, which will directly cause obvious stuttering in real-time audio and video transmission; if the ProbeRTT stage is directly removed, it will destroy the multi-stream fairness mechanism that the native BBR relies on to achieve this stage, leading to an imbalance in bandwidth allocation during multi-stream contention.

[0044] Therefore, there is an urgent need for a BBR improvement scheme that adapts to the characteristics of RTC, so that it can work stably, efficiently and fairly under the UDP architecture.

[0045] To address common industry challenges in real-time communication scenarios, such as the lack of reliable acknowledgment mechanisms for UDP transmission, the susceptibility of bandwidth estimation failures under high packet loss conditions, and the difficulty in balancing low latency requirements with multi-stream fairness, this specification proposes an improved congestion control method for real-time audio and video communication in its embodiments. This method, while retaining the bandwidth detection capability of the BBR algorithm, incorporates several technical reconstructions tailored to the transmission characteristics of RTC scenarios.

[0046] First, a relative one-way delay mechanism is proposed to reconstruct network state awareness in an environment without acknowledgment feedback. By utilizing standard Transport-CC feedback messages and sending timestamps, the one-way transmission delay and in-flight data volume are accurately reconstructed, enabling the BBR algorithm to operate normally in a UDP-RTC environment without ACK.

[0047] Furthermore, the BBR control model is reconstructed, removing the congestion window limit and the ProbeRTT phase, and introducing dynamic congestion detection for in-flight data volume. When the network approaches a congested state, the encoder is notified in advance to reduce the bit rate, preventing data queue accumulation from the source, eliminating transmission interruptions, and ensuring a low-latency transmission experience.

[0048] Furthermore, a three-layer robust compensation architecture for high packet loss was constructed. By fitting transmission delay, random packet loss and congestion packet loss are distinguished, the detection rate is dynamically increased for uplink compensation, and lost feedback messages are recovered based on the short-time constant assumption, thus enabling the output of effective bandwidth estimates even in environments with up to 70% random packet loss.

[0049] Furthermore, a periodic bandwidth concession fairness mechanism is proposed. After each bandwidth probe cycle, high-bandwidth data streams proactively relinquish a portion of bandwidth resources proportionally, ensuring that multiple BBR streams can quickly converge to a fair allocation state, thus compensating for any potential fairness loss after the ProbeRTT phase is removed.

[0050] The technical solution based on this application has been applied in large-scale real-time communication products. Actual tests show that the stuttering rate is reduced by more than 40% in weak network environments, the image quality stability is significantly improved, and it also has good high-concurrency fair scheduling capabilities.

[0051] The technical solutions provided in the various embodiments of this specification are described in detail below with reference to the accompanying drawings.

[0052] Figure 1 This is a schematic diagram of the overall framework of a congestion control method provided in one embodiment of this specification.

[0053] The congestion control method, system, and related equipment provided in one embodiment of this specification can be widely applied to various real-time audio and video communication scenarios based on the UDP protocol, such as video conferencing, online live streaming, distance education, cloud gaming, video calls, and other real-time interactive applications requiring low latency and high stability transmission. By introducing a relative one-way latency mechanism and dynamic detection of data volume during flight, one embodiment of this specification can reconstruct network state awareness in an ACK-less environment, effectively avoiding network congestion while ensuring low latency, and maintaining stable bandwidth estimation and a smooth media transmission experience under weak network conditions with high packet loss and high jitter.

[0054] Figure 1 This document illustrates the overall workflow of the congestion control method in one embodiment, demonstrating the coordinated operation between the sending and receiving ends. For example... Figure 1 As shown, the sending end includes a media encoder, a congestion controller, and a smoothing transmitter. The congestion controller is a module used to dynamically adjust the transmission rate to avoid network congestion. The receiving end is responsible for recording the arrival time of data packets and generating feedback messages.

[0055] At the transmitting end, the media encoder dynamically adjusts the encoding rate based on the available bandwidth to generate the media data to be transmitted. The congestion controller includes several sub-modules, such as relative one-way delay assessment, smooth transmission rate control, packet loss compensation, and fairness guarantee. Specifically, the relative one-way delay assessment module calculates the one-way delay based on the TWCC feedback message returned from the receiving end and extracts the estimated propagation delay value; the smooth transmission rate control module smooths the bandwidth estimate to eliminate instantaneous jitter; the packet loss compensation module performs uplink compensation based on the packet loss type identification result; and the fairness guarantee module performs bandwidth concession after each bandwidth probe to ensure multi-stream fairness. The congestion controller determines the smooth transmission rate based on the above information and passes it to the smoothing transmitter. The smoothing transmitter controls the actual transmission rhythm of data packets according to this rate, injecting data into the network UDP link.

[0056] After receiving a data packet, the receiving end records the arrival time of each data packet under the receiving end's clock and periodically constructs a TWCC feedback message according to the Transport-CC protocol, sending the message back to the sending end. After receiving the feedback message, the sending end updates the relevant parameters in the congestion controller, forming a closed-loop control, and continuously adjusts the sending strategy to adapt to changes in network status.

[0057] The congestion control method provided in one embodiment of this specification can be deployed on a computing device. The computing device can be various electronic devices with computing and network communication capabilities, including but not limited to smartphones, tablets, personal computers, laptops, servers, cloud servers, smart TVs, and IoT devices. The sending and receiving ends can run on the same or different types of computing devices. Regarding deployment, the method provided in one embodiment of this specification can run independently on the client side (e.g., embedded in a real-time audio / video SDK), be centrally deployed on the server side (e.g., a cloud media server), or be implemented in a client-server collaborative manner. For example, the client performs bandwidth estimation and transmission rate adjustment, while the server performs encoding rate decisions and multi-stream scheduling. Regardless of the deployment method, it does not depart from the technical concept disclosed in this application.

[0058] In one embodiment of this specification, a congestion control method is provided. This application also relates to a congestion control system, a congestion control device, and a computing device, which will be described in detail in the following embodiments.

[0059] Figure 2 This is a flowchart illustrating a congestion control method provided in one embodiment of this specification.

[0060] From a programming perspective, the entity executing the process can be a program hosted on a server or terminal. It can be understood that this method can be executed by any device, equipment, platform, or cluster of devices with computing and processing capabilities.

[0061] like Figure 2 As shown, this process is applied to the data sending end and may specifically include the following steps: Step 202: Obtain the congestion control feedback message returned by the receiving end; the congestion control feedback message carries the arrival time of the data packet under the clock of the receiving end.

[0062] Figure 2 The congestion control method described is applied to the sending end of a UDP-based communication. The congestion control feedback message is a transport layer congestion control feedback message. This message is the Transport-wide Congestion Control (TWCC) feedback message defined in the WebRTC standard, and can be abbreviated as Transport-CC feedback message, TWCC feedback message, TWCC message, or TWCC feedback. This message carries the arrival time of the data packet under the receiver's clock.

[0063] The sending end receives the congestion control feedback messages returned by the receiving end. Specifically, the sending end receives the TWCC feedback messages from the receiving end via the UDP protocol and parses the arrival time information of each data packet under the receiving end's clock from the messages.

[0064] In some embodiments, the sending end uses the arrival time information carried in the TWCC feedback message, combined with the sending time and the time of receiving the TWCC feedback message recorded locally by the sending end, to establish a time reference for subsequent calculation of one-way delay.

[0065] Based on some embodiments of this specification, by acquiring TWCC feedback messages, the sending end can obtain the arrival time information of data packets at the receiving end in UDP transmission scenarios lacking a TCP ACK mechanism. This information provides the necessary data foundation for subsequent calculations of one-way delay, estimation of in-flight data volume, and congestion assessment, enabling UDP-based real-time communication systems to perceive network conditions.

[0066] Step 204: Calculate the arrival time of the data packet after mapping under the sending end clock, based on the arrival time and the reception time of the congestion control feedback message under the sending end clock.

[0067] In some embodiments, the sender performs step 204 based on the obtained congestion control feedback message: calculating the arrival time of the data packet after mapping under the sender's clock.

[0068] To facilitate understanding, this manual first explains the relevant clock concepts. The transmitting clock is the local clock used by the transmitting device to record time, and the receiving clock is the local clock used by the receiving device to record time. In real-time communication systems, the transmitting and receiving ends typically use independent local clocks, with an unknown fixed clock deviation between them, and the clock operating rates may have slight differences.

[0069] The specific implementation of step 204 includes: mapping the arrival time under the receiving clock to the sending clock domain based on the reception time of the congestion control feedback message under the sending clock and the arrival time information of the data packets carried in the message, thereby obtaining the mapped arrival time. In some embodiments, when the clocks at both ends are synchronized, the mapping degenerates into directly using the arrival time, in which case the mapped arrival time is equal to the arrival time under the receiving clock.

[0070] Through the above processing in step 204, the sending end can convert the arrival time under the receiving end clock to the time domain consistent with the local clock, thereby eliminating the impact of the clock deviation between the two ends on the one-way delay calculation.

[0071] In one or more embodiments of this specification, a specific method for calculating the arrival time after mapping is further provided.

[0072] In some embodiments, calculating the arrival time of the data packet after mapping under the sending end clock specifically includes: calculating an offset based on the reception time of the congestion control feedback message under the sending end clock and the arrival time of the last data packet in the congestion control feedback message under the receiving end clock; and calculating the arrival time of each data packet after mapping under the sending end clock based on the offset and the arrival time of each data packet in the congestion control feedback message under the receiving end clock.

[0073] Specifically, the sender first calculates the offset: Offset = Reception time of the congestion control feedback message under the sender's clock. The arrival time of the last data packet in the message at the receiving end's clock is calculated. Then, for each data packet in the message, its arrival time at the receiving end's clock is added to this offset to obtain the mapped arrival time of that data packet at the sending end's clock. The last data packet is chosen as the reference because its arrival time is closest to the time when the receiving end actually sent the feedback message, making the offset calculation more accurate.

[0074] For example, suppose the receiver receives the last data packet at 1236 milliseconds of its receiver clock, immediately generates a TWCC feedback message, and sends it back. The sender receives this message at 250 milliseconds of its sender clock. The sender calculates the offset as 250. 1236= 986, then for any data packet in the message, its mapped arrival time = the arrival time of that packet under the receiver's clock. 986. This calculation method requires no modification to the underlying protocol stack and can be completed solely by relying on standard TWCC feedback messages.

[0075] Based on some embodiments of this specification, the above mapping method enables the sender to convert the arrival time under the receiver's clock to a time domain consistent with the local clock in UDP transmission scenarios lacking a TCP ACK mechanism, providing an accurate time reference for subsequent one-way delay calculations. This mechanism does not rely on clock synchronization, allowing for unknown deviations between the independent clocks at both ends, enabling the BBR congestion control algorithm to obtain usable arrival time information in a UDP-RTC environment for the first time.

[0076] Step 206: Calculate the one-way delay based on the arrival time after mapping and the transmission time of the data packet under the clock of the sending end.

[0077] Based on the mapped arrival time, the sending end executes step 206: calculating the one-way delay according to the mapped arrival time and the transmission time of the data packet under the sending end's clock. In the embodiments of this specification, the one-way delay refers to the time elapsed from when the data packet is sent by the sending end to when it is received by the receiving end. Since the clocks at both ends are independent, the calculated one-way delay value contains an unknown fixed deviation, but its relative change can accurately reflect the change in network queuing delay. For ease of understanding, this application also refers to this value as the relative one-way delay (ROTT).

[0078] The specific formula for calculating one-way delay is: one_way_delay = map_arrival_time `send_time` is the local timestamp of the data packet leaving the sender (based on the sender's clock), and `map_arrival_time` is the arrival time in the sender's clock coordinate system after clock mapping alignment. This formula allows for the approximate calculation of the one-way transmission delay of each data packet in a UDP environment without ACK, based on the packet arrival time reported by the receiver, providing congestion control algorithms with delay observation capabilities similar to TCP ACK.

[0079] Furthermore, the sending end obtains the minimum one-way delay through a sliding window and uses this minimum value to estimate the propagation delay RTprop. Since the minimum one-way delay theoretically corresponds to the one-way propagation delay without queuing, and the uplink and downlink paths may be asymmetrical, in one implementation, RTprop ≈ 2 × min(one_way_delay). This estimated value is used as a baseline scaling factor for subsequent congestion threshold calculations.

[0080] Based on some embodiments of this specification, by calculating the one-way delay and utilizing its relative change, the transmitting end can accurately perceive the changing trend of network queuing delay without relying on clock synchronization, providing important input for congestion warning and proactive speed reduction.

[0081] In actual operation, due to slight differences in the operating rates of the clocks at both ends, the one-way delay will slowly change due to clock drift after a long period of operation. To eliminate this effect, in some embodiments, clock skew sensing technology is introduced at the transmitting end to perform a clock skew correction step to eliminate the operating deviation between the two clocks over a long period of operation.

[0082] In some embodiments, the congestion control method further includes: acquiring multiple one-way delay samples; fitting the changing trend of the multiple one-way delay samples over time to obtain a fitting result; and correcting the one-way delay by clock offset based on the fitting result.

[0083] In one specific implementation, the least squares method is used to perform linear fitting on the collected one-way delay samples to obtain the slope of the one-way delay changing with time. This slope reflects the difference in clock speeds between the transmitting and receiving ends. Correcting the subsequently calculated one-way delay based on this slope eliminates errors caused by clock drift.

[0084] It is understood that, in addition to the least squares method, those skilled in the art may also use other linear regression methods or higher-order fitting methods (such as polynomial fitting) to estimate the clock drift trend. As long as the trend of unidirectional delay over time can be fitted and corrected accordingly, it falls within the protection scope of this application.

[0085] Based on some embodiments of this specification, by fitting and correcting the trend of one-way delay, the transmitting end can eliminate the accumulated error caused by the difference in clock speeds at both ends, so that the one-way delay measurement value remains stable over a long period of time. This ensures the accuracy of key parameters such as congestion threshold and data volume during flight, and improves the reliability and stability of the congestion control algorithm during long-term operation.

[0086] Step 208: Determine the congestion threshold based on the unidirectional delay.

[0087] The congestion threshold is used to assess whether a network is approaching a congested state. Physically, the congestion threshold represents the maximum amount of data allowed in flight within the network; exceeding this limit may cause congestion. When the amount of data in flight exceeds the congestion threshold, it indicates that queuing is imminent, and the transmission rate may need to be reduced to avoid congestion.

[0088] In the embodiments of this specification, the congestion threshold refers to a value determined based on the Bandwidth-Delay Product (BDP), which is equal to the product of the propagation delay estimate and the bandwidth estimate. The congestion threshold can be the Bandwidth-Delay Product itself, or it can be the product of the Bandwidth-Delay Product and a preset coefficient.

[0089] In one or more embodiments of this specification, specific embodiments for determining the congestion threshold are further provided.

[0090] Specifically, determining the congestion threshold based on the one-way delay includes: determining a propagation delay estimate based on the minimum one-way delay within a sliding window; determining a bandwidth estimate based on the number of data packets successfully arriving at the receiving end within a statistical time window; and determining the congestion threshold based on the propagation delay estimate and the bandwidth estimate.

[0091] First, the propagation delay estimate is determined based on the minimum one-way delay within the sliding window. The sliding window is used for propagation delay estimation, and its window length is typically set relatively long (e.g., 10 seconds) to select the minimum one-way delay, thus eliminating the influence of queuing delays. The sliding window continuously records the minimum value, allowing the propagation delay estimate to be updated naturally. In practical applications, each entry in the sliding window corresponds to a data packet's information record, including fields such as sequence number, sending time, packet size, arrival time after mapping, calculated one-way delay, and packet loss flag. The sending end extracts all one-way delay values ​​from the sliding window and selects the minimum to determine the propagation delay estimate.

[0092] Secondly, the bandwidth estimate is determined based on the number of data packets that successfully arrive at the receiver within the statistical time window. The statistical time window is usually short (e.g., 200 milliseconds or 1 second) and is used to count the number of data packets that successfully arrive within the window to calculate the receiving rate.

[0093] Finally, the congestion threshold is determined based on the product of the propagation delay estimate and the bandwidth estimate. For example, in a certain operation, the minimum one-way delay within the sliding window is 48 milliseconds, the number of successfully arriving data packets within the statistical time window is 16, the data packet size is 1200 bytes, and the window length is 200 milliseconds. Then the receiving rate is 16 × 1200 / 200 = 96 bytes / millisecond, and the product of the propagation delay estimate and the bandwidth estimate is 48 × 96 = 4608 bytes. This product is the bandwidth-delay product, which can be used to determine the congestion threshold.

[0094] Based on some embodiments of this specification, the congestion threshold determined by the above method can reflect the capacity of the network pipeline, enabling the sending end to predict congestion in advance when the amount of data in flight approaches the threshold, thus avoiding increased latency caused by queue accumulation.

[0095] In the native BBR algorithm, the congestion threshold is the bandwidth-delay product (BDP = RTprop × BtlBw). When the in-flight data volume exceeds BDP, the network is considered to be about to become congested. In real-time communication scenarios, directly using BDP as the threshold may present problems: due to slight network fluctuations, the in-flight data volume may briefly exceed BDP, and immediately reducing the speed would cause unnecessary bandwidth waste and image quality fluctuations. Therefore, in some embodiments of this specification, a preset coefficient is introduced based on BDP to form a congestion threshold.

[0096] In some embodiments, a method for determining the congestion threshold is further provided. Determining the congestion threshold based on the propagation delay estimate and the bandwidth estimate specifically includes: calculating the product of the propagation delay estimate and the bandwidth estimate; and multiplying the product by a preset coefficient to obtain the congestion threshold.

[0097] The preset coefficient provides a buffer, allowing the data volume during flight to fluctuate reasonably around the bandwidth-delay product, preventing frequent bitrate adjustments due to momentary overshoots and thus maintaining stable image quality. For example, if the bandwidth-delay product is 4608 bytes and the preset coefficient is 1.1, the congestion threshold is 5068.8 bytes; if the preset coefficient is 2.0, the congestion threshold is 9216 bytes. In some embodiments, the preset coefficient includes a first coefficient and a second coefficient, where the first coefficient is smaller than the second coefficient, corresponding to the first and second congestion thresholds respectively, to implement tiered congestion response.

[0098] Based on some embodiments of this specification, by introducing a preset coefficient to adjust the congestion threshold, the sending end can flexibly control the response sensitivity according to the degree of network fluctuation, thereby avoiding false speed reduction while maintaining timely response to real congestion, and improving bandwidth utilization and image quality stability.

[0099] In some embodiments, a method for determining the bandwidth estimate is further provided. Determining the bandwidth estimate based on the number of data packets successfully arriving at the receiver within a statistical time window specifically includes: calculating the data packet reception rate based on the ratio of the number of data packets successfully arriving at the receiver to the statistical time window; and determining the bandwidth estimate based on the data packet reception rate.

[0100] The data packet reception rate directly reflects the network's actual transmission capacity within the current time window. For example, if the statistical time window is 200 milliseconds, and 16 data packets successfully arrive, each data packet being 1200 bytes, then the data packet reception rate is 16 × 1200 / 200 = 96 bytes / millisecond.

[0101] Based on some embodiments of this specification, by dividing the number of arrivals by the time window, the transmitter can obtain a real-time measurement of the receiving rate, providing a basic input for bandwidth estimation.

[0102] In some embodiments, the bandwidth estimate may be further smoothed. Specifically, determining the bandwidth estimate based on the data packet receiving rate includes: performing a smoothing filter on the data packet receiving rate to obtain the bandwidth estimate; the smoothing filter includes performing a weighted calculation based on the bandwidth estimate after the previous filtering and the currently measured data packet receiving rate.

[0103] The smoothing filter includes various implementation methods such as first-order filtering (EMA) and weighted moving average (WMA).

[0104] Optionally, the ratio can be subjected to first-order filtering to obtain a bandwidth estimate; in the first-order filtering, the current filtered bandwidth estimate is calculated by weighting the ratio of the previous filtered bandwidth estimate to the current measurement.

[0105] In one embodiment, the sending end counts the number of data packets successfully arriving at the receiving end every 200 milliseconds and calculates the current period's received rate measurement value R_measure (unit: bytes / millisecond). To avoid drastic changes in bandwidth estimation due to instantaneous network jitter, the sending end performs a first-order smoothing filter on the received rate measurement value to obtain a smoothed bandwidth estimate value B_smooth.

[0106] Specifically, an exponential moving average (EMA) method can be used: B_smooth(n) = α × B_smooth(n-1) + (1-α) × R_measure(n). Where: B_smooth(n) is the smoothed bandwidth estimate for the current period; B_smooth(n-1) is the smoothed bandwidth estimate for the previous period; R_measure(n) is the received rate measured in the current period; α is a smoothing factor, ranging from 0 to 1, and in this embodiment, α = 0.8.

[0107] For example, assuming the smoothed bandwidth estimate for the previous cycle is B_smooth(n-1) = 96 bytes / millisecond, and the measured reception rate for the current cycle is R_measure(n) = 90 bytes / millisecond, then the smoothed bandwidth estimate for the current cycle is: B_smooth(n) = 0.8 × 96 + 0.2 × 90 = 76.8 + 18 = 94.8 bytes / millisecond.

[0108] Through the above smoothing process, even if the current period measurement value is low due to packet loss or sudden jitter, the smoothed bandwidth estimate will not drop drastically, thereby avoiding frequent changes in the encoding bitrate and ensuring the stability of video quality.

[0109] It is understood that the smoothing factor α can be dynamically adjusted according to the network state: when the network is stable, α can take a larger value (e.g., 0.9) to make the bandwidth estimation smoother; when the network changes rapidly, α can take a smaller value (e.g., 0.6) to make the bandwidth estimation respond faster. Those skilled in the art can set the specific value of α according to actual needs, all of which fall within the protection scope of this application.

[0110] Based on some embodiments of this specification, by smoothing the receiving rate, the transmitting end can filter out measurement noise, obtain a stable bandwidth estimate, enable the encoder to obtain a relatively stable target bit rate, and thus ensure the smoothness of video quality.

[0111] In some embodiments, the input data for bandwidth estimation can be further corrected. Considering that bandwidth estimation based on receive rate may lead to a significant underestimation of the receive rate in high packet loss scenarios, thus affecting the accuracy of bandwidth detection, embodiments of this specification provide a downlink compensation mechanism. This mechanism assumes that the downlink packet loss rate remains relatively constant within a short time window (e.g., 1 second), and uses the density of received congestion control feedback messages to infer the lost feedback messages, thereby recovering the complete receive sequence for bandwidth calculation.

[0112] Specifically, the congestion control method further includes: acquiring message loss information; the message loss information reflecting the loss status of congestion control feedback messages; estimating the expected number of data packets corresponding to the lost congestion control feedback messages based on the data packet arrival density reported by the received congestion control feedback messages; and correcting the number of data packets arriving based on the message loss information and the expected number of data packets arriving.

[0113] Here, message loss information refers to parameters reflecting the message loss status of congestion control feedback, including but not limited to: the number of lost messages, the loss ratio, a list of lost message sequence numbers, and the loss rate, among others. In practical applications, both message loss information and packet arrival density can be applied to the aforementioned statistical time window.

[0114] In one implementation, the sending end maintains the reception status of feedback messages. When a feedback message is detected to be lost, the position of the lost message on the timeline is inferred by the density of received feedback messages (the number of messages received per unit time). Then, the arrival time of the data packet reported by the lost message is recovered by interpolation based on the content of the preceding and following messages.

[0115] For example, if 5 feedback messages should have been received within a 200-millisecond window, but only 3 were actually received, and each of the 3 received messages reported 3 data packets arriving, then the estimated 2 lost messages would also each report 3 data packets arriving, thus correcting the total number of arriving data packets within the window to 3×3 + 2×3 = 15. This corrected number of arriving data packets is used for bandwidth estimation, making the calculation results closer to the actual network condition.

[0116] Based on some embodiments of this specification, the sending end can compensate for the bandwidth estimation error caused by downlink feedback loss through the feedback message loss recovery mechanism, thereby improving the accuracy of bandwidth estimation; it can still maintain accurate bandwidth estimation in high packet loss environments, enhancing the robustness of the system and ensuring the effectiveness of congestion control.

[0117] In some embodiments, this specification provides a packet loss compensation scheme to address the issue that bandwidth estimation may become inaccurate due to reduced receiving rate in high packet loss environments. Considering that bandwidth estimation based on receiving rate may lead to a significant underestimation of the receiving rate in high packet loss scenarios, thereby affecting the accuracy of bandwidth probing, this scheme maintains the effectiveness of bandwidth probing by distinguishing packet loss types, identifying random packet loss, and correspondingly increasing the sending rate.

[0118] Specifically, the congestion control method further includes: determining packet loss information based on the congestion control feedback message; calculating a random packet loss rate based on the packet loss information; and increasing the data transmission rate during the bandwidth probing phase based on the random packet loss rate. That is, the sending end determines packet loss information based on the acquired congestion control feedback message, then calculates the random packet loss rate, and increases the data transmission rate during the bandwidth probing phase based on the random packet loss rate.

[0119] In practical applications, packet loss information includes data packet loss details, which can be obtained by parsing TWCC feedback messages. In one implementation, the random packet loss rate is estimated using a packet loss type identification method described later. When random packet loss is determined to exist in the current network, the sender employs an uplink compensation strategy: the target transmission rate is divided by (1 - random packet loss rate) to obtain the actual transmission rate, SendRate = TargetSendRate / (1 - L). For example, if the target transmission rate is 1 megabit per second and the random packet loss rate is 20%, the actual transmission rate is adjusted to 1.25 megabits per second. In this way, the sender actively increases the transmission rate in a random packet loss environment to offset the reduction in effective data volume caused by packet loss, enabling the receiver to obtain sufficient data for bandwidth estimation.

[0120] Based on some embodiments of this specification, by identifying random packet loss and dynamically increasing the transmission rate, the sending end can avoid the bandwidth estimation being consistently low due to random packet loss. Even under a high random packet loss rate, it can still maintain the ability to detect the actual available bandwidth, thereby ensuring the smoothness of real-time communication.

[0121] To further determine the random packet loss rate, some embodiments provide a specific method for identifying packet loss types. This method is based on the network caching characteristic of "queuing before congestion," meaning that congestion-induced packet loss is usually accompanied by increased queuing delays, while random packet loss does not exhibit this characteristic.

[0122] In some embodiments, calculating the random packet loss rate based on the packet loss information specifically includes: for a lost data packet, estimating the expected arrival time of the lost data packet based on the arrival times of adjacent data packets of the lost data packet; calculating the expected one-way delay of the lost data packet based on the expected arrival time; if the expected one-way delay is less than or equal to a delay threshold, then identifying the lost data packet as a random packet loss; and calculating the random packet loss rate based on the number of random packets lost in the current time period.

[0123] First, for a lost data packet, the sender uses the arrival times of its adjacent data packets (according to their sequence numbers) to estimate the expected arrival time of the lost data packet through linear interpolation. Specifically, assuming that the two successfully arrived data packets before and after the lost data packet are pkt_i and pkt_j, with sending times of ts_i and ts_j respectively, and mapping arrival times of tr_i and tr_j respectively, the expected arrival time of the lost data packet (sequence number k) can be calculated through linear interpolation: tr_k = tr_i + (tr_j - tr_i) × (ts_k - ts_i) / (ts_j - ts_i).

[0124] Then, after obtaining the expected arrival time, the expected one-way delay is calculated as tr_k - ts_k. If the expected one-way delay is less than or equal to the current delay threshold, the lost data packet is identified as random packet loss; otherwise, it is identified as congestion packet loss. For example, in a certain transmission segment, the minimum one-way delay of received data packets is 60 milliseconds, the maximum is 70 milliseconds, and the delay threshold is taken as the average of 65 milliseconds; if the expected one-way delay of a lost data packet obtained by interpolation is 62 milliseconds (less than 65 milliseconds), it is determined to be random packet loss; if it is 68 milliseconds (greater than 65 milliseconds), it is determined to be congestion packet loss. The sending end counts the number of randomly lost packets in the current time period to calculate the random packet loss rate.

[0125] Based on some embodiments of this specification, by analyzing the transmission delay change trend before and after the loss of data packets, it is possible to accurately distinguish between random packet loss and congestion packet loss, avoid misjudging random packet loss as congestion and incorrectly reducing bandwidth, and provide reliable input parameters for uplink compensation.

[0126] In some embodiments, a method for determining the latency threshold is further provided. The latency threshold is determined based on the one-way latency of data packets received within the current time period.

[0127] An exemplary calculation method is to obtain the minimum and maximum one-way delays of received data packets within the current time period, and take the average of the two as the delay threshold. This threshold reflects the current network queuing delay range, enabling packet loss type identification to adapt to changes in network conditions. For example, when the overall network queuing delay increases, the threshold is raised accordingly to avoid misjudging mild congestion as random packet loss; when the network is smooth, the threshold is lowered to more sensitively identify genuine random packet loss.

[0128] Based on some embodiments of this specification, by dynamically adjusting the latency threshold, packet loss type identification can adapt to different network environments, maintain the stability of bandwidth estimation while ensuring identification accuracy, and thus improve the adaptability of congestion control under various network conditions.

[0129] Figure 3 This is a schematic diagram of a high packet loss robustness compensation architecture provided in one embodiment of this specification.

[0130] In some embodiments, this specification provides a high packet loss robustness compensation architecture that establishes a three-layer joint compensation mechanism between the sender and receiver to address the impact of high random packet loss environments on bandwidth probing.

[0131] like Figure 3As shown, the sending end sends data packets to the receiving end, and the receiving end sends congestion control feedback messages back to the sending end. During transmission, data packet loss or feedback message loss may occur. To address different levels of packet loss, this architecture employs a three-layer mechanism of uplink compensation, packet loss type identification, and downlink compensation for coordinated processing.

[0132] In the downlink direction, when congestion control feedback messages sent back by the receiver are lost, the sender performs downlink compensation. This mechanism assumes that the downlink packet loss rate remains relatively constant within a short time window (e.g., 1 second). Using the packet arrival density reported by the received feedback messages, it infers the packet arrival information corresponding to the lost feedback messages, thereby recovering the complete received sequence for bandwidth calculation. In this way, even if some feedback messages are lost, the sender can still obtain relatively complete packet arrival time information, avoiding bandwidth underestimation due to feedback loss.

[0133] In the data packet transmission direction, when a data packet is lost during transmission, the sender first performs packet loss type identification. This mechanism is based on the network caching characteristic of "queuing before congestion," using linear interpolation of the transmission delays of adjacent data packets before and after the lost packet to estimate the expected arrival time of the lost packet. If the interpolated expected one-way delay is less than the current queue delay threshold, it is determined to be random packet loss; otherwise, it is determined to be congestion packet loss. By distinguishing packet loss types, the sender can accurately identify random packet loss caused by link quality problems, avoiding misjudging it as congestion and incorrectly reducing bandwidth.

[0134] After identifying random packet loss and estimating the random packet loss rate, the sender performs uplink compensation. This mechanism dynamically increases the transmission rate based on the estimated random packet loss rate L, specifically calculated as: SendRate = TargetSendRate / (1-L). For example, if the target transmission rate is 1 megabit per second and the random packet loss rate is 20%, the actual transmission rate is adjusted to 1.25 megabits per second. By actively increasing the transmission rate, the sender can offset the reduction in effective data volume caused by random packet loss, allowing the receiver to obtain sufficient data for bandwidth estimation, thus enabling the detection of the true usable bandwidth even in environments with up to 70% random packet loss.

[0135] Based on some embodiments of this specification, through a three-layer joint mechanism of downlink compensation, packet loss type identification, and uplink compensation, the system can maintain effective bandwidth detection capability in environments with high random packet loss. Downlink compensation recovers arrival information from lost feedback messages, ensuring the integrity of the input for bandwidth estimation; packet loss type identification accurately distinguishes between random packet loss and congestion packet loss, avoiding erroneous rate reduction; uplink compensation dynamically increases the transmission rate, offsetting the impact of random packet loss on the reception rate. The three-layer mechanism works together to enable the transmitter to obtain relatively accurate bandwidth estimates even under adverse network conditions, thereby ensuring smooth real-time communication and stable image quality.

[0136] Step 210: For a reference data packet that successfully arrives at the receiving end, determine the amount of data transmitted by the sending end within the time interval formed by the sending time of the reference data packet and the mapped arrival time.

[0137] In some embodiments, the sending end performs step 210 to determine the inflight data volume. The inflight data volume is used to assess the data load being transmitted in the network and is an important basis for congestion control.

[0138] In the embodiments described in this specification, the amount of in-flight data is obtained through estimation. Specifically, the sender selects a data packet that successfully arrives at the receiver as a reference data packet. The reference data packet must arrive successfully because only successfully arriving packets can obtain their mapped arrival time under the sender's clock through the aforementioned ROTT mechanism, thereby defining a time interval. A time interval is formed with the transmission time of the reference data packet as the starting point and the mapped arrival time of the reference data packet as the ending point. The total amount of data packets sent by the sender within this time interval is counted, and this amount of data is taken as the in-flight data amount corresponding to the reference data packet.

[0139] Each successfully arriving reference data packet can be used to calculate a corresponding in-flight data volume; the results may differ for different reference packets. In the embodiments of this specification, a sent data packet refers to a data packet already sent by the sender, regardless of whether the data packet ultimately arrives successfully at the receiver. In one implementation, the in-flight data volume is the total data volume of data packets sent within a time interval that subsequently arrive successfully (either within or outside the time interval), reflecting the effective data load transmitted in the network; in another implementation, the in-flight data volume is the total data volume of all data packets sent within a time interval, reflecting the sending intensity of the sender. Both methods can be used to compare with congestion thresholds to determine the network congestion status.

[0140] Based on some embodiments of this specification, by estimating the amount of data in flight in an ACK-free environment, the sending end can obtain the data load information being transmitted in the network, providing a quantitative basis for congestion judgment, and enabling congestion control to shift from passively responding to packet loss to actively predicting queuing.

[0141] In some embodiments, a method for determining the amount of data in flight is further provided. Determining the amount of data in flight based on the amount of data transmitted by the sending end within the time interval formed by the transmission time and the mapped arrival time of the reference data packet specifically includes: for multiple reference data packets that successfully arrive at the receiving end, determining the amount of data transmitted by the sending end within the time interval corresponding to each reference data packet; and calculating feature values ​​of the data amounts corresponding to the multiple reference data packets as the amount of data in flight.

[0142] The characteristic value can be the average, median, or other statistical measures. In practical engineering implementations, the in-flight data volume of multiple reference packets is usually averaged to obtain a smoothed periodic value for congestion assessment. For example, the sender selects multiple reference data packets that have successfully arrived within a recent period, calculates the in-flight data volume for each reference packet, and then averages these data volumes to obtain the final estimated in-flight data volume. In this way, outliers caused by instantaneous network fluctuations in individual reference packets are smoothed out, making congestion assessment more stable.

[0143] Based on some embodiments of this specification, by averaging the in-flight data volume corresponding to multiple reference packets, the sending end can obtain a smooth network load estimate, avoid congestion misjudgment due to abnormal fluctuations in a single packet, and improve the stability of congestion control.

[0144] In some embodiments, considering that including lost packets when calculating in-flight data volume would overestimate the actual network load and potentially lead to overly aggressive congestion control operations (such as rate reduction), lost packets, although occupying bandwidth, are not successfully processed by the receiving end and can be disregarded in the continuous network load. Therefore, in some embodiments, in-flight data volume can refer to the total amount of data being transmitted in the network that is expected to arrive successfully.

[0145] Specifically, determining the in-flight data volume based on the amount of data sent by the sending end within the time interval formed by the sending time and the mapped arrival time of the reference data packet includes: counting the total amount of data packets sent by the sending end within the time interval that eventually successfully arrive at the receiving end, and using this as the in-flight data volume corresponding to the reference data packet.

[0146] In practical applications, the time interval used for statistics is (ts, tr], which includes the data packet corresponding to the receiving time tr, but excludes the reference data packet itself corresponding to the sending time ts. Therefore, the data packets counted include those sent after ts, before tr, and those sent at time tr that eventually arrived successfully. Taking reference packet pkt10 as an example, its sending time ts = 85 milliseconds, and its receiving time after mapping tr = 103 milliseconds. Within the time interval (85, 103] milliseconds, the sender sent pkt11 (90 milliseconds), pkt12 (95 milliseconds), and pkt13 (100 milliseconds). All three data packets arrived successfully, so the amount of data in flight = 3 × 1200 = 3600 bytes. Only the data packets that eventually arrived successfully are counted in the statistics, because although lost data packets were transmitted in the network, they were not successfully processed by the receiving end and are not included in the continuous network load.

[0147] Based on some embodiments of this specification, by counting the total amount of successfully arrived data packets as the amount of data in flight, the sending end can more accurately reflect the data load of effective transmission in the network, avoid overestimation of load and excessive speed reduction due to the inclusion of lost packets, and make the congestion judgment closer to the actual network situation.

[0148] Step 212: Perform congestion control based on the comparison result between the amount of data in flight and the congestion threshold.

[0149] In this system, the amount of data in flight is used as input, and the congestion threshold is used as a comparison benchmark. The transmitter compares the two and decides whether to adjust the transmission rate or the coding rate based on the comparison result. Congestion control can encompass various transmission rate adjustment behaviors, including but not limited to reducing the transmission rate when the amount of data in flight exceeds the congestion threshold, maintaining the transmission rate when the amount of data in flight is normal, and increasing the transmission rate during the bandwidth probing phase to compensate for the impact of random packet loss. Congestion control can also include adjusting the coding rate.

[0150] Based on some embodiments of this specification, by comparing the amount of data in flight with a congestion threshold, the sender can dynamically adjust its sending behavior according to the network load status and proactively intervene when congestion is approaching, thus avoiding excessive accumulation of network queues.

[0151] In some embodiments, specific congestion control operations are further provided. The congestion control based on the comparison result of the in-flight data volume and the congestion threshold specifically includes: if the in-flight data volume is greater than or equal to the congestion threshold, performing at least one of the following operations: reducing the coding rate, or reducing the data packet transmission rate.

[0152] Adjusting the encoding bitrate and adjusting the transmission rate are two congestion control methods that can be executed independently or in combination. Adjusting the encoding bitrate involves sending control signals to the encoder to change the target output bitrate of the video or audio encoder. This operation affects the long-term rate of data generation, reducing network load at its source. Adjusting the transmission rate involves changing the parameters of the transmission scheduler, directly controlling the rate at which data packets are injected into the network from the transmission queue. This operation has a faster response and is suitable for handling transient congestion or smoothing traffic bursts. There is no necessary causal relationship between adjusting the encoding bitrate and adjusting the transmission rate; they can be used independently or in combination depending on the network conditions and system design. For example, when mild congestion is detected, only the encoding bitrate can be reduced to reduce data generation at the source; when a transient traffic burst is detected, only the transmission rate can be temporarily reduced to avoid frequent bitrate changes affecting user experience; when severe congestion is detected, both operations can be performed simultaneously to quickly alleviate congestion.

[0153] Based on some embodiments of this specification, by providing congestion control measures that can be executed independently or in combination, the sending end can flexibly select the response method according to the degree of congestion and network characteristics, ensuring low latency while avoiding overreaction that may cause unnecessary impact on user experience.

[0154] In some embodiments, unlike the native BBR which relies on the concurrency limit (cwnd) to limit the amount of unacknowledged data, some embodiments of this specification remove the cwnd limit. In real-time communication scenarios, data is generated in real time by the audio and video encoder and needs to be transmitted continuously and smoothly. If a cwnd limit exists, when the cwnd is exhausted, the sender must wait for confirmation from the receiver before continuing to send. This waiting can lead to transmission interruptions, resulting in audio and video stuttering. By removing the cwnd limit, some embodiments of this specification use a smooth transmission rate to control the transmission rhythm, avoiding transmission interruptions caused by cwnd exhaustion. This allows data packets to be continuously and smoothly injected into the network from the sender, adapting to the continuous transmission requirements of real-time communication.

[0155] Specifically, some embodiments of this specification further provide a tiered congestion response mechanism. The congestion thresholds include a first congestion threshold and a second congestion threshold, where the first congestion threshold is less than the second congestion threshold. The congestion control based on the comparison between the in-flight data volume and the congestion thresholds specifically includes: When the amount of data in flight is greater than or equal to the first congestion threshold, a first congestion response operation is executed. Further, the first congestion response operation may include sending a bit rate reduction signal to the encoder. This first congestion response operation belongs to the Inflight dynamic congestion detection mechanism: the transmitter calculates the current amount of data in flight in real time. When the amount of data in flight exceeds α times the bandwidth-delay product (α is 1.1), it determines that the network is about to enter a congested state and proactively sends an early bit rate reduction signal to the encoder, reducing data generation from the source and avoiding queue congestion. Through this mechanism, congestion control changes from traditional "transmission control" to "encoding coordination control," adjusting the data volume from the source to adapt to the continuous transmission requirements of real-time communication.

[0156] When the amount of data in flight is greater than or equal to the second congestion threshold and the duration exceeding the second congestion threshold reaches a preset duration, a second congestion response operation is executed. Further, the second congestion response operation may include reducing the data packet transmission rate. The purpose of the second congestion response is to urgently alleviate severe congestion. In one embodiment, the second congestion response specifically includes: re-determining the bandwidth estimate based on the latest calculated data packet reception rate, and rapidly reducing the transmission rate by using 0.75 times the estimated value as the upper limit of the transmission rate.

[0157] In one implementation, the first congestion threshold is set to 1.1 times the bandwidth-delay product, and the second congestion threshold is set to 2.0 times the bandwidth-delay product. When the amount of data in flight exceeds 1.1 times the bandwidth-delay product, the network is determined to be near congestion, and the transmitter actively notifies the encoder to appropriately reduce the bit rate to avoid queue accumulation. When the amount of data in flight exceeds 2.0 times the bandwidth-delay product and this state lasts for more than 500 milliseconds, the network is determined to be severely congested. The transmitter recalculates the bandwidth estimate based on the latest calculated packet reception rate and uses 0.75 times this estimate as the upper limit of the transmission rate to quickly alleviate severe congestion. This hierarchical design allows the transmitter to control the flow at the source by adjusting the encoder during mild congestion and to ensure system stability by rapidly reducing the transmission rate during severe congestion.

[0158] Based on some embodiments of this specification, by setting multi-level congestion thresholds and corresponding differentiated response operations, the sending end can distinguish between mild congestion and severe congestion, and take targeted control measures to avoid overreacting to instantaneous fluctuations and to reduce speed in time during continuous severe congestion, thereby balancing image quality stability and congestion mitigation efficiency.

[0159] While one or more embodiments of this specification provide method steps as described in the embodiments or flowcharts, it is understood that the order of steps listed in the embodiments or flowcharts is merely one possible execution order among many steps and does not represent the only possible execution order. The order of some steps may be adjusted according to actual needs, or some steps may be omitted. When the claims involve method steps, changes in the order of such steps, or parallel execution between steps, are also within the scope of protection of the claims.

[0160] Figure 2 In the congestion control method, the sending end obtains the congestion control feedback message returned by the receiving end. On the one hand, it uses the reception time of the message under the sending end's clock and the arrival time of the data packets carried in the message under the receiving end's clock to map the arrival time under the receiving end's clock domain, thereby calculating the one-way delay of each data packet and determining the congestion threshold based on the one-way delay. On the other hand, it divides the time interval by the transmission time and the mapped arrival time of the successfully arrived reference packet, and counts the amount of data sent by the sending end within this interval as the in-flight data volume. Finally, it compares the in-flight data volume with the congestion threshold and performs congestion control based on the comparison result.

[0161] Because real-time communication systems rely on UDP for transmission and lack the acknowledgment mechanism found in TCP, the sending end cannot directly obtain information such as data packet acknowledgment time, in-flight data volume, and reception rate. To address this issue, this specification proposes a relative one-way delay mechanism: the receiving end transmits the arrival time of data packets via Transport-CC feedback messages; the sending end uses the arrival time of the last data packet in the feedback message as a mapping benchmark to calculate the one-way transmission delay; the propagation delay is estimated based on the minimum one-way delay within a sliding window, and the in-flight data volume is dynamically estimated by combining records of sent but unreceived data packets. This mechanism requires no modification to the underlying UDP protocol stack and relies solely on standard Transport-CC feedback messages to provide network state input equivalent to the TCP acknowledgment mechanism for congestion control in a pure UDP environment.

[0162] Through the synergistic effect of the above features, a closed loop is formed from latency awareness and load estimation to proactive control, enabling UDP-based real-time communication systems to achieve congestion control capabilities comparable to TCP in an environment without acknowledgment mechanisms, thereby effectively avoiding network congestion while ensuring low latency.

[0163] based on Figure 2 In addition to the method described herein, this specification also provides some improved implementations of the method, which are described below.

[0164] In some embodiments, to accommodate the continuous transmission requirements of real-time communication, the probing mechanism in the native BBR congestion control algorithm has been adjusted. The native algorithm incorporates a mechanism that periodically enters the ProbeRTT phase, which significantly reduces the transmission rate (e.g., minimizing the congestion window) for a period to empty the network queue, thereby measuring the actual propagation delay. In real-time communication scenarios, data is generated in real-time by the audio / video encoder and needs to be transmitted continuously and smoothly. Transmission interruptions caused by the ProbeRTT phase can lead to audio / video stuttering. Therefore, some embodiments in this specification remove the ProbeRTT phase to avoid transmission interruptions caused by deliberate pauses.

[0165] To accurately estimate propagation delay even after the ProbeRTT phase is cancelled, some embodiments in this specification employ implicit probing. During the non-bandwidth probing phase, the sender transmits data using only a preset percentage (e.g., 80%) of the current bandwidth estimate. Since the transmission rate does not reach the network bottleneck, queuing delays in the network are naturally low, and the measured one-way delay is closer to the true one-way propagation delay. The sender continuously records the minimum one-way delay using a sliding window, thus naturally updating the propagation delay estimate during normal transmission without needing to specifically stop transmission for probing. This approach balances low latency with link characteristic awareness.

[0166] In some embodiments, a bandwidth concession mechanism is provided. Specifically, the congestion control method further includes: after each update of the bandwidth estimate, sending data at a preset percentage (e.g., 80%) of the updated bandwidth estimate as the upper limit of the transmission rate.

[0167] This bandwidth concession mechanism plays a role in regulating fairness in multi-stream contention scenarios. When there is only one data stream in the network, this mechanism allows the sender to retain bandwidth redundancy during the non-probing phase, which is beneficial for implicit measurement of propagation delay. When multiple data streams coexist, each stream, after completing bandwidth probing and updating its bandwidth estimate, actively limits its own transmission rate to a preset proportion of the estimated bandwidth, thereby reserving bandwidth space for other data streams. Newly added streams can use this reserved bandwidth to probe available capacity and also perform bandwidth concession after their own probing cycle ends. Through multiple probe-concede iterations, the streams can gradually converge to a fair bandwidth allocation.

[0168] The aforementioned bandwidth transfer mechanism and Figure 2 The congestion control process works in tandem. Figure 2The congestion control process dynamically adjusts the transmission rate in real time based on the comparison between the amount of data in flight and the congestion threshold. When the amount of data in flight exceeds the congestion threshold, it actively reduces the transmission rate or encoding rate. The aforementioned bandwidth concession mechanism applies an upper limit constraint after each bandwidth estimate update to ensure that the actual transmission rate used by the sender does not exceed this upper limit. For example, assuming the current bandwidth estimate is 1000 kilobits per second and the preset ratio is 0.8, the upper limit of the transmission rate is 800 kilobits per second. Even Figure 2 In the congestion control process, the sender is allowed to transmit at 1000 kilobits per second based on network conditions, but the actual transmission rate will not exceed 800 kilobits per second. When the bandwidth estimate is updated to 1200 kilobits per second, the transmission rate limit is updated to 960 kilobits per second. Through this periodic "update-rate limiting" operation, the sender maintains a rapid response to external congestion while actively reserving bandwidth space for other data streams, promoting fair convergence of multiple streams.

[0169] Based on some embodiments in this specification, by eliminating the ProbeRTT phase and employing implicit detection of propagation delay, audio and video interruptions caused by active transmission halting are avoided, ensuring the continuity and low latency of real-time communication. Simultaneously, by using a preset proportion as the upper limit of the transmission rate after updating the bandwidth estimate, active bandwidth concession is achieved in multi-stream scenarios, enabling each data stream to fairly share network resources. This bandwidth concession mechanism, in conjunction with real-time congestion response, maintains stable measurement in single-stream scenarios and promotes fair allocation in multi-stream scenarios, thereby comprehensively improving the transmission quality and stability of the real-time communication system under different network environments.

[0170] The various technical features in the above embodiments can be combined arbitrarily, as long as there is no conflict or contradiction between the combinations of features. However, due to space limitations, they have not been described one by one. Therefore, the arbitrary combination of various technical features in the above embodiments is also within the scope of this specification.

[0171] One or more embodiments of this specification further provide a congestion control system, including: The sending end is used to execute the congestion control method described in any of the foregoing embodiments; The receiving end is used to generate and send a congestion control feedback message to the sending end; the congestion control feedback message carries the arrival time of the data packet under the clock of the receiving end.

[0172] The system forms a closed-loop control through congestion control feedback messages. The sending end is responsible for logic such as bandwidth estimation, packet loss compensation, and transmission rate adjustment, and sends media data to the receiving end. After receiving the media data, the receiving end sends network status information back to the sending end through Transport-CC (Transport-wide Congestion Control) feedback messages. This feedback message contains the arrival time of each data packet under the receiving end's clock. The sending end uses this information, combined with its locally recorded transmission time and feedback message reception time, to calculate one-way delay, estimate the amount of data in flight, determine the congestion threshold, and dynamically adjust its transmission strategy based on the comparison results.

[0173] The sending and receiving ends work together to complete a congestion control closed loop. The sending end continuously executes the congestion control method described in the previous embodiments, while the receiving end periodically sends back feedback messages, enabling the sending end to perceive changes in network status in real time. For example, when the receiving end detects the arrival of a data packet, it records the arrival time in a TWCC feedback message and sends it back to the sending end. After parsing the message, the sending end updates the one-way delay information in the sliding window, re-estimates the amount of data in flight, and compares it with the congestion threshold. If the amount of data in flight exceeds the congestion threshold, it reduces the transmission rate or notifies the encoder to reduce the bit rate; if the amount of data in flight is lower than the congestion threshold, it maintains or appropriately increases the transmission rate. Through this continuous feedback and control loop, the sending end can dynamically adjust its transmission behavior according to the actual network status.

[0174] Based on some embodiments of this specification, through the coordinated operation of congestion control methods executed by the sending end and feedback messages returned by the receiving end, the system constructs a complete network state awareness and response closed loop in a UDP transmission environment. The sending end can obtain the arrival time of data packets at the receiving end in real time, thereby estimating one-way latency and in-flight data volume, and achieving proactive congestion control by comparing this data with congestion thresholds. The feedback mechanism at the receiving end compensates for the lack of an acknowledgment mechanism in UDP, enabling the sending end to obtain accurate network state information without relying on TCP-style ACKs, thus achieving stable, low-latency data transmission in real-time communication scenarios.

[0175] Figure 4 This is a congestion control flowchart of a congestion control system provided in an embodiment of this specification in a practical application scenario.

[0176] In some embodiments, this specification provides a real-time communication congestion control system based on relative unidirectional time delay. The system includes a transmitter and a receiver, and forms a closed-loop control through TWCC feedback messages.

[0177] like Figure 4As shown, the sending end can be divided into two links: the upper-layer sending link and the lower-layer feedback processing link. The two links work together to complete the congestion control decision.

[0178] After receiving media data from the sender, the receiver generates a TWCC feedback message and sends it back to the sender via the information feedback path. The TWCC feedback message carries the arrival time information of the data packets under the receiver's clock, providing the sender with basic data for network status awareness.

[0179] In the lower-layer feedback processing link at the sending end, the ROTT data processing module receives TWCC feedback messages, parses information such as the arrival time and loss status of each data packet, calculates the relative one-way delay of all data packets, and cleans and aggregates the data to provide a basis for upper-layer bandwidth judgment. The bandwidth assessment module estimates the current network bandwidth in real time based on ROTT data, packet loss rate, jitter, and other indicators, outputting the estimated bandwidth as the raw input for subsequent bandwidth calculations. The packet loss analysis module analyzes the packet loss information in the feedback in detail, including packet loss location, packet loss ratio, and whether it is sudden or random packet loss, determining whether the packet loss is mainly caused by congestion or link quality issues (random packet loss), providing a basis for compensation and coding strategies. The packet loss compensation module takes compensation measures based on the packet loss analysis results, assesses how much transmission bandwidth can cover the impact of the current random packet loss, and feeds back the results of the compensation strategy to the upper-layer transmission link, forming a closed loop in the system.

[0180] In the upper-layer transmission link at the sending end, the bandwidth smoothing module smooths the bandwidth information obtained from the current analysis, eliminating instantaneous jitter and making subsequent control more stable. In scenarios with multiple sessions or multimedia streams coexisting, the fairness guarantee module uses a reserved bandwidth transfer mechanism based on the smoothed bandwidth information to ensure fairness between different streams. The bandwidth output module outputs the finally calculated available bandwidth result as input parameters for encoding and determining the packet transmission rate. The encoding, forward error correction (FEC), and automatic repeat request (ARQ) modules dynamically adjust the encoding rate based on the available bandwidth, determine redundancy and retransmission behavior in conjunction with FEC and ARQ strategies, and actually execute data packaging, encoding, and transmission to send the media data to the receiving end.

[0181] The data flow within the system is as follows: In the upper-layer transmission link, data flows along the path of "bandwidth smoothing → fairness guarantee → bandwidth output → encoding / FEC / ARQ," ultimately reaching the receiver. In the feedback direction, data enters the lower-layer feedback processing link from the receiver via TWCC feedback messages, undergoing processing along the path of "ROTT data processing → bandwidth assessment → packet loss analysis → packet loss compensation." The results of the compensation strategy are then fed back to the bandwidth smoothing module in the upper-layer transmission link, achieving continuous iterative optimization. Through this bidirectional data flow, the sender can obtain complete network state awareness in a UDP transmission environment and proactively adjust its transmission behavior based on the comparison between the in-flight data volume and the congestion threshold.

[0182] Based on some embodiments of this specification, the system implements a complete control flow from network status awareness, bandwidth estimation, packet loss analysis to transmission strategy adjustment. The upper-layer transmission link is responsible for bandwidth smoothing, fairness assurance, and data transmission, while the lower-layer feedback processing link is responsible for data analysis, bandwidth assessment, and packet loss compensation. This enables the system to achieve congestion control capabilities comparable to TCP in a UDP transmission environment, thereby realizing low-latency, high-stability real-time communication transmission.

[0183] Based on the same idea, an embodiment of this specification also provides an apparatus corresponding to the above method.

[0184] Figure 5 For one embodiment of this specification, corresponding to Figure 2 A schematic diagram of the structure of a congestion control device.

[0185] like Figure 5 As shown, the device may include: The feedback message acquisition module 502 is used to acquire the congestion control feedback message returned by the receiving end; the congestion control feedback message carries the arrival time of the data packet under the clock of the receiving end. The clock mapping module 504 is used to calculate the arrival time of the data packet after mapping under the sending end clock, based on the arrival time and the reception time of the congestion control feedback message under the sending end clock. The delay calculation module 506 is used to calculate the one-way delay based on the arrival time after mapping and the transmission time of the data packet under the clock of the sending end. The congestion threshold determination module 508 is used to determine the congestion threshold based on the one-way delay; The in-flight data volume determination module 510 is used to determine the in-flight data volume for a reference data packet that has successfully arrived at the receiving end, based on the amount of data sent by the sending end within the time interval formed by the sending time of the reference data packet and the mapped arrival time. The congestion control module 512 is used to perform congestion control based on the comparison result between the amount of in-flight data and the congestion threshold.

[0186] based on Figure 5 The present specification also provides some specific implementations of the method in one embodiment, which are described below.

[0187] Optionally, calculating the arrival time of the data packet after mapping under the sending end clock specifically includes: The offset is calculated based on the reception time of the congestion control feedback message under the clock of the sending end and the arrival time of the last data packet in the congestion control feedback message under the clock of the receiving end. Based on the offset and the arrival time of each data packet in the congestion control feedback message under the clock of the receiving end, calculate the arrival time of each data packet after mapping under the clock of the sending end.

[0188] Optionally, the congestion control device is further configured to: Collect multiple unidirectional delay samples; The fitting results are obtained by fitting the changing trends of the multiple unidirectional time delay samples over time. The unidirectional delay is corrected by clock offset based on the fitting results.

[0189] Optionally, determining the congestion threshold based on the one-way delay specifically includes: Based on the minimum value of the one-way delay within the sliding window, the estimated propagation delay value is determined; The bandwidth estimate is determined based on the number of data packets that successfully arrive at the receiving end within the statistical time window. Based on the propagation delay estimate and the bandwidth estimate, the congestion threshold is determined.

[0190] Optionally, determining the congestion threshold based on the propagation delay estimate and the bandwidth estimate specifically includes: Calculate the product of the propagation delay estimate and the bandwidth estimate; The congestion threshold is obtained by multiplying the product by a preset coefficient.

[0191] Optionally, determining the bandwidth estimate based on the number of data packets successfully arriving at the receiving end within the statistical time window specifically includes: The data packet reception rate is calculated based on the ratio of the number of data packets successfully arriving at the receiving end to the statistical time window. Based on the data packet reception rate, a bandwidth estimate is determined.

[0192] Optionally, determining the bandwidth estimate based on the data packet reception rate specifically includes: The data packet receiving rate is subjected to a smoothing filter to obtain a bandwidth estimate; the smoothing filter includes a weighted calculation based on the bandwidth estimate after the previous filtering and the currently measured data packet receiving rate.

[0193] Optionally, the congestion control device is further configured to: Obtain message loss information; the message loss information reflects the loss status of congestion control feedback messages; Based on the packet arrival density reported by the received congestion control feedback messages, estimate the expected number of packets corresponding to the lost congestion control feedback messages. The number of data packets arriving is adjusted based on the message loss information and the expected number of data packets arriving.

[0194] Optionally, the congestion control device is further configured to: Based on the congestion control feedback message, packet loss information is determined; Calculate the random packet loss rate based on the packet loss information; Based on the aforementioned random packet loss rate, the data transmission rate is increased during the bandwidth probing phase.

[0195] Optionally, calculating the random packet loss rate based on the packet loss information specifically includes: For a lost data packet, the expected arrival time of the lost data packet is estimated based on the arrival times of its adjacent data packets; Calculate the expected one-way delay of the lost data packet based on the expected arrival time; If the expected one-way delay is less than or equal to the delay threshold, the lost data packet is identified as random packet loss. Calculate the random packet loss rate based on the number of random packets lost in the current time period.

[0196] Optionally, the delay threshold is determined based on the one-way delay of the data packets received within the current time period.

[0197] Optionally, determining the in-flight data volume based on the amount of data transmitted by the sender within the time interval formed by the transmission time and the mapped arrival time of the reference data packet specifically includes: For multiple reference data packets that successfully arrive at the receiving end, the amount of data sent by the sending end within the time interval corresponding to each reference data packet is determined. Calculate the characteristic value of the data volume corresponding to the plurality of reference data packets, and use it as the in-flight data volume.

[0198] Optionally, determining the in-flight data volume based on the amount of data transmitted by the sender within the time interval formed by the transmission time and the mapped arrival time of the reference data packet specifically includes: The total amount of data packets sent by the sending end and successfully delivered to the receiving end within the time interval is counted and used as the in-flight data amount corresponding to the reference data packet.

[0199] Optionally, the congestion control based on the comparison between the in-flight data volume and the congestion threshold specifically includes: If the amount of in-flight data is greater than or equal to the congestion threshold, perform at least one of the following operations: Reduce the encoding bitrate, or reduce the data packet sending rate.

[0200] Optionally, the congestion threshold includes a first congestion threshold and a second congestion threshold, wherein the first congestion threshold is less than the second congestion threshold; The congestion control based on the comparison between the in-flight data volume and the congestion threshold specifically includes: When the amount of in-flight data is greater than or equal to the first congestion threshold, a first congestion response operation is performed; the first congestion response operation includes sending a bit rate reduction signal to the encoder; When the amount of data in flight is greater than or equal to the second congestion threshold and the duration of exceeding the second congestion threshold reaches a preset duration, a second congestion response operation is executed; the second congestion response operation includes reducing the data packet transmission rate.

[0201] Optionally, the congestion control device is further configured to: After each update of the bandwidth estimate, data is sent at a predetermined percentage of the updated bandwidth estimate as the upper limit of the transmission rate.

[0202] It is understood that the modules mentioned above refer to computer programs or program segments used to perform one or more specific functions. Furthermore, the distinction between these modules does not imply that the actual program code must also be separate.

[0203] For ease of description, the above devices are described by dividing them into various modules or units based on their functions. Of course, when implementing one or more of these specifications, the functions of each module or unit can be implemented in one or more software and / or hardware components, or a module that performs the same function can be implemented by a combination of multiple sub-modules or sub-units. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division; in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0204] The above is a schematic scheme of a congestion control device according to this embodiment. It should be noted that the technical solution of this congestion control device and the technical solution of the congestion control method described above belong to the same concept. For details not described in detail in the technical solution of the congestion control device, please refer to the description of the technical solution of the congestion control method described above.

[0205] Based on the same idea, an embodiment of this specification also provides a device corresponding to the above method.

[0206] Figure 6 A structural block diagram of a computing device provided according to an embodiment of this specification is shown.

[0207] The computing device 600 includes: Memory 610 and processor 620; The memory 610 is used to store computer programs / instructions, and the processor 620 is used to execute the computer programs / instructions, which, when executed by the processor 620, implement the steps of the congestion control method.

[0208] Specifically, the components of the computing device 600 include, but are not limited to, a memory 610 and a processor 620. The processor 620 is connected to the memory 610 via a bus 630, and the database 650 is used to store data.

[0209] The computing device 600 also includes an access device 640, which enables the computing device 600 to communicate via one or more networks 660. Examples of these networks include Public Switched Telephone Network (PSTN), Local Area Network (LAN), Wide Area Network (WAN), Personal Area Network (PAN), or combinations of communication networks such as the Internet. The access device 640 may include one or more of any type of wired or wireless network interface (e.g., a network interface card (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) wireless interface, a Wi-MAX (Worldwide Interoperability for Microwave Access) interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, a Near Field Communication (NFC) interface, and so on.

[0210] In one embodiment of this specification, the above-described components of the computing device 600 and Figure 6 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 6 The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this application. Those skilled in the art can add or replace other components as needed.

[0211] The computing device 600 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or personal computers (PCs). The computing device 600 can also be a mobile or stationary server.

[0212] The processor 620 implements the congestion control method when executing the computer instructions.

[0213] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the congestion control method described above belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the congestion control method described above.

[0214] An embodiment of this specification also provides a computer-readable storage medium storing computer instructions that, when executed by a processor, implement the steps of the congestion control method as described above.

[0215] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium and the technical solution of the congestion control method described above belong to the same concept. For details not described in detail in the technical solution of the storage medium, please refer to the description of the technical solution of the congestion control method described above.

[0216] An embodiment of this specification also provides a computer program product, including a computer program / instructions that, when executed by a processor, implement the steps of the congestion control method described above.

[0217] The above is an illustrative scheme of a computer program product according to this embodiment. It should be noted that the technical solution of this computer program product and the technical solution of the congestion control method described above belong to the same concept. For details not described in detail in the technical solution of the computer program product, please refer to the description of the technical solution of the congestion control method described above.

[0218] The various embodiments in this specification are described in a progressive manner, and the same or similar parts between the embodiments can be referred to mutually. Each embodiment focuses on describing the differences from other embodiments. In particular, for the apparatus and device embodiments, since they are basically similar to the method embodiments, the description is relatively simple, and the relevant parts can be referred to the description of the method embodiments. The apparatus, device and method provided in one embodiment of this specification correspond to each other, and therefore the apparatus and device also have similar beneficial technical effects as the corresponding method. Since the beneficial technical effects of the method have been described in detail above, the beneficial technical effects of the corresponding apparatus and device will not be repeated here.

[0219] The foregoing has described specific embodiments of this specification. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired result. Furthermore, the processes depicted in the drawings do not necessarily require a specific or sequential order to achieve the desired result. In some embodiments, multitasking and parallel processing are possible or may be advantageous.

[0220] In the 1990s, improvements to a technology could be clearly distinguished as either hardware improvements (e.g., improvements to the circuit structure of diodes, transistors, switches, etc.) or software improvements (improvements to methodology). However, with technological advancements, many methodological improvements today can be considered direct improvements to hardware circuit structures. Designers almost always obtain the corresponding hardware circuit structure by programming the improved methodology into the hardware circuit. Therefore, it cannot be said that a methodological improvement cannot be implemented using hardware physical modules. For example, a Programmable Logic Device (PLD) (such as a Field Programmable Gate Array (FPGA)) is such an integrated circuit whose logic function is determined by the user programming the device. Designers can program a digital system themselves to "integrate" it onto a PLD, without needing chip manufacturers to design and manufacture dedicated integrated circuit chips. Furthermore, nowadays, instead of manually manufacturing integrated circuit chips, this programming is mostly implemented using "logic compiler" software. Similar to the software compiler used in program development, the original code before compilation must also be written in a specific programming language, called a Hardware Description Language (HDL). There are many HDLs, such as ABEL (Advanced Boolean Expression Language), AHDL (Altera Hardware Description Language), Confluence, CUPL (Cornell University Programming Language), HDCal, JHDL (Java Hardware Description Language), Lava, Lola, MyHDL, PALASM, and RHDL (Ruby Hardware Description Language). Currently, the most commonly used are VHDL (Very-High-Speed ​​Integrated Circuit Hardware Description Language) and Verilog. Those skilled in the art should also understand that by simply performing some logic programming on the method flow using one of these hardware description languages ​​and programming it into an integrated circuit, the hardware circuit implementing the logical method flow can be easily obtained.

[0221] The controller can be implemented in any suitable manner. For example, it can take the form of a microprocessor or processor and a computer-readable medium storing computer-readable program code (e.g., software or firmware) executable by the (micro)processor, logic gates, switches, application-specific integrated circuits (ASICs), programmable logic controllers, and embedded microcontrollers. Examples of controllers include, but are not limited to, the following microcontrollers: ARC 625D, Atmel AT91SAM, Microchip PIC18F26K20, and Silicon Labs C8051F320. A memory controller can also be implemented as part of the control logic of the memory. Those skilled in the art will also recognize that, in addition to implementing the controller in purely computer-readable program code form, the same functionality can be achieved by logically programming the method steps to make the controller take the form of logic gates, switches, application-specific integrated circuits, programmable logic controllers, and embedded microcontrollers. Therefore, such a controller can be considered a hardware component, and the means included therein for implementing various functions can also be considered as structures within the hardware component. Alternatively, the means for implementing various functions can be considered as both software modules implementing the method and structures within the hardware component.

[0222] The systems, devices, modules, or units described in the above embodiments can be implemented by computer chips or entities, or by products with certain functions. A typical implementation device is a computer. Specifically, a computer can be, for example, a personal computer, laptop computer, cellular phone, camera phone, smartphone, personal digital assistant, media player, navigation device, email device, game console, tablet computer, wearable device, or any combination of these devices.

[0223] For ease of description, the above devices are described separately by function as various units. Of course, in implementing this application, the functions of each unit can be implemented in one or more software and / or hardware.

[0224] Those skilled in the art will understand that one or more embodiments of this specification can be provided as a method, system, or computer program product. Therefore, an embodiment of this specification may take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, an embodiment of this specification may take the form of a computer program product implemented on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0225] This invention is described with reference to flowchart illustrations and / or block diagrams of a method, apparatus (system), and computer program product according to one embodiment of this specification. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, produce a machine for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0226] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0227] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0228] In a typical configuration, a computing device includes one or more processors (CPU), input / output interfaces, network interfaces, and memory.

[0229] Memory may include non-persistent storage in computer-readable media, such as random access memory (RAM) and / or non-volatile memory, such as read-only memory (ROM) or flash RAM. Memory is an example of computer-readable media.

[0230] Computer-readable media includes both permanent and non-permanent, removable and non-removable media that can store information using any method or technology. Information can be computer-readable instructions, data structures, modules of programs, or other data. Examples of computer storage media include, but are not limited to, phase-change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technologies, CD-ROM, digital character versatile optical disc (DVD) or other optical storage, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other non-transferable medium that can be used to store information accessible by a computing device. As defined herein, computer-readable media does not include transient computer-readable media, such as modulated data signals and carrier waves.

[0231] This application can be described in the general context of computer-executable instructions, such as program modules, that are executed by a computer. Generally, program modules include routines, programs, objects, components, data structures, etc., that perform a specific task or implement a specific abstract data type. This application can also be practiced in distributed computing environments where tasks are performed by remote processing devices connected via a communication network. In distributed computing environments, program modules can reside in local and remote computer storage media, including storage devices.

[0232] The above description is merely an embodiment of this application and is not intended to limit the scope of this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the scope of the claims of this application.

Claims

1. A congestion control method, comprising: Obtain the congestion control feedback message returned by the receiving end; The congestion control feedback message carries the arrival time of the data packet under the clock of the receiving end; Based on the arrival time and the reception time of the congestion control feedback message under the sending clock, calculate the arrival time of the data packet after mapping under the sending clock. Calculate the one-way delay based on the arrival time after mapping and the transmission time of the data packet under the clock of the sending end; Based on the unidirectional delay, a congestion threshold is determined; For a reference data packet that successfully arrives at the receiving end, the amount of data transmitted by the sending end within the time interval formed by the sending time and the mapped arrival time of the reference data packet is determined; Congestion control is performed based on the comparison between the amount of data in flight and the congestion threshold.

2. The method as described in claim 1, wherein calculating the arrival time of the data packet after mapping under the clock of the sending end specifically includes: The offset is calculated based on the reception time of the congestion control feedback message under the clock of the sending end and the arrival time of the last data packet in the congestion control feedback message under the clock of the receiving end. Based on the offset and the arrival time of each data packet in the congestion control feedback message under the clock of the receiving end, calculate the arrival time of each data packet after mapping under the clock of the sending end.

3. The method of claim 1, further comprising: Collect multiple unidirectional delay samples; The variation trend of the multiple unidirectional time delay samples over time is fitted to obtain the fitting result; The unidirectional delay is corrected by clock offset based on the fitting results.

4. The method as described in claim 1, wherein determining the congestion threshold based on the one-way delay specifically includes: Based on the minimum value of the one-way delay within the sliding window, the estimated propagation delay value is determined; The bandwidth estimate is determined based on the number of data packets that successfully arrive at the receiving end within the statistical time window. Based on the propagation delay estimate and the bandwidth estimate, the congestion threshold is determined.

5. The method of claim 4, wherein determining the congestion threshold based on the propagation delay estimate and the bandwidth estimate specifically includes: Calculate the product of the propagation delay estimate and the bandwidth estimate; The congestion threshold is obtained by multiplying the product by a preset coefficient.

6. The method as described in claim 4, wherein determining the bandwidth estimate based on the number of data packets successfully arriving at the receiving end within a statistical time window specifically includes: The data packet reception rate is calculated based on the ratio of the number of data packets successfully arriving at the receiving end to the statistical time window. Based on the data packet reception rate, a bandwidth estimate is determined.

7. The method of claim 6, wherein determining the bandwidth estimate based on the data packet receiving rate specifically includes: The data packet receiving rate is subjected to a smoothing filter to obtain a bandwidth estimate; the smoothing filter includes a weighted calculation based on the bandwidth estimate after the previous filtering and the currently measured data packet receiving rate.

8. The method of claim 4, further comprising: Obtain message loss information; the message loss information reflects the loss status of congestion control feedback messages; Based on the packet arrival density reported by the received congestion control feedback messages, estimate the expected number of packets corresponding to the lost congestion control feedback messages. The number of data packets arriving is adjusted based on the message loss information and the expected number of data packets arriving.

9. The method of claim 1, further comprising: Based on the congestion control feedback message, packet loss information is determined; Calculate the random packet loss rate based on the packet loss information; Based on the aforementioned random packet loss rate, the data transmission rate is increased during the bandwidth probing phase.

10. The method as described in claim 9, wherein calculating the random packet loss rate based on the packet loss information specifically includes: For a lost data packet, the expected arrival time of the lost data packet is estimated based on the arrival times of its adjacent data packets; Calculate the expected one-way delay of the lost data packet based on the expected arrival time; If the expected one-way delay is less than or equal to the delay threshold, the lost data packet is identified as random packet loss. Calculate the random packet loss rate based on the number of random packets lost in the current time period.

11. The method of claim 10, wherein the delay threshold is determined based on the one-way delay of the data packets received within the current time period.

12. The method of claim 1, wherein determining the amount of data in flight based on the amount of data transmitted by the transmitting end within the time interval formed by the transmission time and the mapped arrival time of the reference data packet specifically includes: For multiple reference data packets that successfully arrive at the receiving end, the amount of data sent by the sending end within the time interval corresponding to each reference data packet is determined. Calculate the characteristic value of the data volume corresponding to the plurality of reference data packets, and use it as the in-flight data volume.

13. The method of claim 1, wherein determining the amount of data in flight based on the amount of data transmitted by the transmitting end within the time interval formed by the transmission time and the mapped arrival time of the reference data packet specifically includes: The total amount of data packets sent by the sending end and successfully delivered to the receiving end within the time interval is counted and used as the in-flight data amount corresponding to the reference data packet.

14. The method of claim 1, wherein performing congestion control based on the comparison result of the in-flight data volume and the congestion threshold specifically includes: If the amount of in-flight data is greater than or equal to the congestion threshold, perform at least one of the following operations: Reduce the encoding bitrate, or reduce the data packet sending rate.

15. The method of claim 1, wherein the congestion threshold includes a first congestion threshold and a second congestion threshold, wherein the first congestion threshold is less than the second congestion threshold; The congestion control based on the comparison between the in-flight data volume and the congestion threshold specifically includes: When the amount of in-flight data is greater than or equal to the first congestion threshold, a first congestion response operation is executed; The first congestion response operation includes sending a bit rate reduction signal to the encoder; When the amount of data in flight is greater than or equal to the second congestion threshold and the duration of exceeding the second congestion threshold reaches a preset duration, a second congestion response operation is executed; the second congestion response operation includes reducing the data packet transmission rate.

16. The method of claim 1, further comprising: After each update of the bandwidth estimate, data is sent at a predetermined percentage of the updated bandwidth estimate as the upper limit of the transmission rate.

17. A congestion control system, comprising: A sending end, configured to perform the method according to any one of claims 1 to 16; The receiving end is used to generate and send congestion control feedback messages to the sending end; The congestion control feedback message carries the arrival time of the data packet under the clock of the receiving end.

18. A congestion control device, comprising: The feedback message acquisition module is used to acquire the congestion control feedback messages sent back by the receiving end. The congestion control feedback message carries the arrival time of the data packet under the clock of the receiving end; The clock mapping module is used to calculate the arrival time of the data packet after mapping under the sending end clock, based on the arrival time and the reception time of the congestion control feedback message under the sending end clock. The delay calculation module is used to calculate the one-way delay based on the arrival time after mapping and the transmission time of the data packet under the clock of the sending end; A congestion threshold determination module is used to determine a congestion threshold based on the one-way delay; The in-flight data volume determination module is used to determine the in-flight data volume for a reference data packet that successfully arrives at the receiving end, based on the amount of data sent by the sending end within the time interval formed by the sending time and the mapped arrival time of the reference data packet. The congestion control module is used to perform congestion control based on the comparison result between the amount of in-flight data and the congestion threshold.

19. A computing device, comprising: Memory and processor; The memory is used to store computer programs / instructions, and the processor is used to execute the computer programs / instructions, which, when executed by the processor, implement the steps of the method according to any one of claims 1 to 16.

Images