A low-latency QUIC protocol transmission method and system

Abstract

The present invention belongs to the field of wireless communication technologies, and particularly relates to a low-latency QUIC protocol transmission method and system. In the transmission method of the present invention, an active forward error correction coding mechanism based on packet loss rate estimation is adopted, and the coding mechanism is called stream coding; during the transmission process, all lost packets rely on stream coding for recovery; the sender adaptively adjusts the target code rate of the stream coding based on the estimation of the link packet loss rate and automatically selects whether to send repair packets based on the target code rate; when packet loss occurs during the transmission process, the receiver uses the subsequently received repair packets to complete data recovery; Westwood+ is adopted as the congestion control algorithm of QUIC in the transmission method, reducing the end-to-end ordered delivery latency in the long-latency link and improving the throughput of the link.

Description

Technical Field

[0001] The present invention belongs to the technical field of wireless communication, and particularly relates to a low-latency QUIC protocol transmission method and system. Background Art

[0002] In recent years, with the explosive growth of throughput and user access in traditional terrestrial networks, a pure terrestrial network can no longer meet the user's demand for high-data-rate and reliable network access at any time and any place, especially in areas where terrestrial cellular networks are difficult to cover, such as the ocean and mountains. The Space-Air-Ground-Sea Integrated Network (SAGSIN) is the development direction of the next-generation wireless communication system. The SAGSIN network is based on the terrestrial network, supplemented and extended by the space-based network and the air-based network, and provides an infrastructure for efficient communication within a wide-area space including the ocean, sky, and deep earth.

[0003] The design of the transport layer is one of the keys to determining the end-to-end application experience of SAGSIN. However, the currently widely used Transmission Control Protocol (TCP) faces challenges on the long-distance lossy links of the SAGSIN network. On the one hand, TCP regards network packet loss as congestion, and occasional random packet loss in the wireless link may lead to unnecessary CWND reduction, reducing network utilization; on the other hand, for long-delay links, the packet recovery mechanism based on request retransmission will significantly reduce the end-to-end packet delivery delay of the connection, bringing the head-of-line blocking problem, thereby causing the effective throughput delivered by the transport layer to the application to fluctuate violently. In scenarios such as streaming media and interactive applications, it will seriously damage the user experience.

[0004] Although TCP has also produced many variants such as Cubic, Hybla, and BBR to solve these problems, due to the problem of protocol rigidity, the deployment of TCP variants is difficult and it is difficult to popularize. The UDP-based design does not have these problems, and a typical one is the Quick UDP Internet Connections (QUIC) based on UDP. QUIC was proposed by Google and the specification was finalized in May 2021. Since it can run in user space, QUIC is easier to deploy and expand than TCP. Compared with traditional TCP, on the one hand, QUIC omits the three-way handshake of TCP, reducing the network establishment time, and on the other hand, it also supports stream multiplexing, which can prevent the head-of-line blocking problem when downloading different objects from a single server. Finally, since QUIC encrypts almost all data and headers, the middleware cannot interfere with the protocol expansion.

[0005] However, since QUIC still adopts a congestion control and packet loss recovery mechanism similar to TCP, the problems faced by TCP in long-distance lossy links also exist in QUIC. To address these issues, applying FEC in QUIC can be a good solution. One of the key goals of QUIC defined by the IETF QUIC Working Group is to provide FEC support. People such as Garrido and Michel added an FEC mechanism to the QUIC protocol. However, since it still relies on a packet recovery mechanism based on request retransmission to ensure the reliability of the protocol, its performance in the SAGSIN network is not ideal. Summary of the Invention

[0006] The purpose of the present invention is to provide a QUIC protocol transmission method and system with high link bandwidth utilization and low end-to-end ordered delivery delay.

[0007] To achieve the above invention purposes, the technical solutions adopted by the present invention are specifically as follows:

[0008] A low-latency QUIC protocol transmission method, characterized in that an active forward error correction coding mechanism based on packet loss rate estimation is adopted in the transmission method, and this coding mechanism is called stream coding; all lost packets during the transmission process rely on stream coding for recovery; the sender adaptively adjusts the target code rate of stream coding based on the estimation of the link packet loss rate and automatically selects whether to send repair packets based on the target code rate; when packet loss occurs during the transmission process, the receiver uses the subsequently received repair packets to complete data recovery; the Westwood+ is adopted as the congestion control algorithm for QUIC in the transmission method.

[0009] . Preferably, the transmission method of the present invention specifically includes the following steps:

[0010] Step S1, initialize the QUIC connection, and the sender and receiver respectively initialize the stream coding parameters;

[0011] Step S2, transfer the data to be sent in byte form to the sender;

[0012] Step S3, the sender determines whether there is remaining space in the congestion window and the flow control window. If there is no remaining space in the congestion window or the flow control window, repeat Step S3;

[0013] Step S4: When there is remaining space in the congestion window and the flow control window, the QUIC sender generates data packets and encrypts them to obtain QUIC packets; the encrypted QUIC packets are input into the SCEncoder module and different operations are performed according to their packet types; the QUIC packet types include source packets and unprotected packets, where source packets are packets protected by stream coding and can be repaired when they are lost, and unprotected packets cannot be recovered when they are lost; for source packets, the SCEncoder module treats them as a byte stream and adds an SCheader at the beginning and then passes them to the UDP send queue; for unprotected packets, the SCEncoder module directly passes them to the UDP send queue;

[0014] Step S5: The sender selects whether to send repair packets based on the target code rate of the current stream coding;

[0015] Step S6: All received QUIC packets at the receiver are input into the SCDecoder module; the SCDecoder module removes the SCheader of the received QUIC packets and delivers them to the QUIC session; if a QUIC packet is lost, the decoder in the SCDecoder module is activated and data recovery is performed using the received repair packets; all arrived QUIC packets are delivered to the upper layer following the default settings of QUIC, and an ACK packet is fed back to the sender;

[0016] Step S7: The sender processes the ACK packet, calculates the round-trip time RTT, the number of acknowledged packets, and the link packet loss rate; uses the Westwood+ congestion control algorithm to update the link congestion window according to the number of acknowledged packets and the round-trip time RTT and perform congestion control; the SCEncoder module adjusts the target code rate of the stream coding according to the link packet loss rate;

[0017] Step S8: Repeat steps S4 - S7 until the data transmission ends.

[0018] Preferably, in step S1, the sender stream coding parameters include the requested file size, the number of source packets to be sent, the Galois field size, the transmission packet size, the frequency of sending repair packets, and the random coding coefficient seed; the receiver stream coding parameters include the Galois field size, the transmission packet size, the frequency of sending repair packets, and the random coding coefficient seed. If the requested file size and the number of source packets to be sent are 0, it indicates that the packets arrive successively and have no determined size.

[0019] Preferably, the present invention also proposes a low-latency QUIC protocol transmission system, characterized in that the system includes a sender, a receiver, a stream coding transmission unit, a congestion control unit, and a loss detection unit; where:

[0020] The sending end is used to send packets; the types of packets include: source packets, unprotected packets, and repair packets; source packets are packets protected by stream coding and can be repaired when they are lost in the link; unprotected packets cannot be recovered if they are lost in the link; repair packets are repair packets generated by the encoder in the stream coding transmission unit to recover lost protected packets;

[0021] The receiving end is used to receive packets and ensure that the packets are transmitted to the upper layer completely and orderly. At the same time, the receiving end also sends ACK packets to the sending end to indicate the packet reception situation; ACK packets are composed of a group of ACKranges, and each ACKrange represents an ordered packet sequence number received;

[0022] The stream coding transmission unit includes an SCEncoder module and an SCDecoder module. The SCEncoder module provides the encoding function of stream coding transmission and includes an encoder and an adaptive FEC code rate module; the SCDecoder module provides the decoding function of stream coding transmission and includes a decoder and a source packet storage module; the stream coding transmission unit adopts a packet-level proactive forward error correction code based on the packet loss rate and adaptively sends repair packets by estimating the link packet loss rate;

[0023] The congestion control unit adopts the Westwood+ congestion control algorithm, estimates the bandwidth of the current transmission link through the feedback information of the receiving end, and calculates the congestion window based on this;

[0024] The loss detection unit estimates the link packet loss rate by using the ACK packets fed back by the receiving end.

[0025] Compared with the prior art, the beneficial effects of the present invention are as follows:

[0026] 1) In the present invention, stream coding is used to provide loss recovery ability. When a packet is lost, the SCDecoder at the receiving end is activated, and the SCDecoder uses the received repair packets to recover the data, reducing the end-to-end ordered delivery delay in the long-delay link;

[0027] 2) In the present invention, Westwood+ is adopted as the congestion control algorithm. By processing the feedback information of the receiving end, the current bandwidth, round-trip delay, and packet loss rate of the link are estimated, and the coding code rate can be dynamically adjusted, solving the problem that the congestion window frequently drops due to random packet loss and improving the effective throughput of the link. Description of the Drawings

[0028] To more clearly illustrate the technical solutions of the embodiments of the present invention, the present invention will be described in detail below in conjunction with the drawings and detailed embodiments. Obviously, the drawings in the following description are only some embodiments of the present invention. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings. Among them:

[0029] Figure 1 is the method principle framework diagram of the embodiment provided by the present invention;

[0030] Figure 2 is the comparison diagram of the throughput and delay of the method of the present invention, QUIC, and rQUIC under different random losses in the satellite network in the embodiment provided by the present invention. Detailed Embodiments

[0031] In order to make the objectives, technical solutions, and advantages of the present invention clearer, the present invention will be further described in detail below in conjunction with the drawings and embodiments. Of course, the specific embodiments described here are only used to explain the present invention and are not used to limit the present invention.

[0032] As Figure 1 shown, the present invention provides a low-latency QUIC protocol transmission method, which is characterized in that the transmission method adopts an active forward error correction (FEC) coding mechanism based on packet loss rate estimation, and this coding mechanism is called stream coding; all lost packets during transmission rely on stream coding for recovery; the sender adaptively adjusts the target code rate of the FEC stream coding based on the estimated link packet loss rate and automatically selects whether to send repair packets based on the target code rate; when packet loss occurs during transmission, the receiver uses the subsequently received repair packets to complete data recovery; the Westwood+ is adopted as the congestion control algorithm of QUIC in the transmission method.

[0033] The transmission method of the present invention specifically includes the following steps:

[0034] Step S1, initialize the QUIC connection, and the sender and receiver respectively initialize the stream coding parameters.

[0035] Step S2, transfer the data to be sent in the form of bytes to the sender.

[0036] Step S3, the sender determines whether there is remaining space in the congestion window and the flow control window. If there is no remaining space in the congestion window or the flow control window, repeat Step S3.

[0037] Step S4: When there is remaining space in the congestion window and the flow control window, the QUIC sender generates data packets and encrypts them to obtain QUIC packets; the encrypted QUIC packets are input into the SCEncoder module and different operations are performed according to their packet types; the QUIC packet types include source packets and unprotected packets, where source packets are packets protected by stream coding and can be repaired when lost, and unprotected packets cannot be recovered when lost; for source packets, the SCEncoder module treats them as a byte stream and adds an SCheader at the beginning and then passes them to the UDP send queue; for unprotected packets, the SCEncoder module directly passes them to the UDP send queue.

[0038] Step S5: The sender selects whether to send repair packets based on the target code rate of the current stream coding.

[0039] Step S6: Input all the received QUIC packets at the receiver into the SCDecoder module; the SCDecoder module removes the SCheader of the received QUIC packets and delivers them to the QUIC session; if a QUIC packet is lost, the decoder in the SCDecoder module is activated and data recovery is performed using the received repair packets; after the QUIC session receives a packet, it feeds back an ACK packet to the sender.

[0040] Step S7: The sender processes the ACK packets, calculates the round-trip time RTT, the number of acknowledged packets, and the link packet loss rate; uses the Westwood+ congestion control algorithm to update the link congestion window based on the number of acknowledged packets and the round-trip time RTT and performs congestion control; the SCEncoder module adjusts the target code rate of the stream coding according to the link packet loss rate.

[0041] Step S8: Repeat steps S4 - S7 until the data transmission ends.

[0042] In step S1, the sender stream coding parameters include the requested file size, the number of source packets to be sent, the Galois field size, the transmission packet size, the frequency of sending repair packets, and the random coding coefficient seed; the receiver stream coding parameters include the Galois field size, the transmission packet size, the frequency of sending repair packets, and the random coding coefficient seed. If the requested file size and the number of source packets to be sent are 0, it indicates that the packets arrive sequentially and have no determined size.

[0043] In step S5, the repair packet is a linear combination of the previously sent protected packets; let i seq represent the number of the most recently sent uncoded source packet, initialize i seq = -1, and whenever a source packet is sent, i seq is incremented by 1; the repair packet is expressed as:

[0044]

[0045] where c k is the repair group numbered k; g k,i is the stream coding coefficient randomly extracted from the finite field , where k is the number of the repair group; w s corresponds to the number of the earliest source packet in the current transmission queue. Initialize w s = 0. According to the feedback from the receiver, remove the source packets that have been confirmed to be received from the queue. At this time, w s is updated. Let w e = i seq . [w s , w e is called the coding window of the current repair group.

[0046] In step S6, the repair process is as follows: Let i ord represent the number of the latest orderly transmitted packet. Initialize i ord = -1. The initial state of the decoder in the SCDecoder module is the orderly state. If the next packet received by the decoder is neither nor a repair group with the characteristic of w e = i ord , it means that the orderly transmission is interrupted, where represents the QUIC packet encoded as i ord +1. Then the decoder enters the disorderly state. At this time, the decoder will buffer the received QUIC packets and try to decode. The buffered packets are disorderly source packets or repair groups, that is, their numbers are greater than i ord +1 or where w e > i ord +1. Let be the maximum number of the upper bound of the coding window among the buffered repair groups, and is called the current decoding window of the decoder. As the buffered packets increase, the window will expand, that is, grows. The decoder uses Gaussian elimination to decode, that is, dynamically constructs a system of linear equations AS = B and performs forward elimination online, where the rows of A and B are the coding coefficients and coding information symbols of the buffered packets respectively, and the disorderly source packets are regarded as special repair groups with only one non-zero element 1 in the coding coefficients. When the decoding is successful, all the decoded source packets in the decoding window are transmitted to the upper-layer application, and the decoder resumes to the orderly state, and the orderly transmission restarts with . When the decoder is activated, the subsequent arriving packets will still be forwarded to the upper layer as before.

[0047] In step S7, the Westwood+ congestion control algorithm divides the entire transmission process into sampling periods. Whenever the ACK interval reaches this period, it calculates the estimated current link bandwidth. The calculation formula is as follows:

[0048]

[0049] where b k is the estimated bandwidth of the k-th sampling period, and t k -t k-1 represents the k-th sampling period, and d k is the amount of data acknowledged within the k-th sampling period. A low-pass filter is used to average the sampled measurement values, and the specific method is as follows:

[0050]

[0051]

[0052] where b ns_est_k is the intermediate traversal of the k-th sampling period, representing the bandwidth value after one smoothing, and b ns_est_k-1 represents the intermediate traversal of the (k-1)-th sampling period, is the smoothed estimated bandwidth of the k-th sampling period, is the smoothed estimated bandwidth of the (k-1)-th sampling period;

[0053] When packet loss occurs, Westwood+ sets the congestion window and the slow start threshold to the product of the current smoothed estimated bandwidth and the minimum RTT, that is:

[0054]

[0055]

[0056] where CWND is the congestion window, ssthresh is the slow start threshold, and RTT Min represents the product of the minimum RTT;

[0057] After that, Westwood+ enters the slow start state. The SCEncoder adjusts the target coding rate of the stream according to the link packet loss rate. The packet loss rate is the quotient of the number of lost packets sent and the number of acknowledged packets. The formula is as follows:

[0058]

[0059] where is the packet loss rate, t n is the time when the n-th ACK arrives at the sender, is the sequence number of the largest source packet acknowledged at time t n ​ is the number of packet sequence numbers skipped at time t n The total number of source packets sent at time t That is, the total number of source packets sent at time t n The total number of packets determined by QUIC to be lost at time t. A smoothing filter is used to smooth the packet loss rate, and the formula is as follows: is at time t n The total number of packets determined by QUIC to be lost at time t. A smoothing filter is used to smooth the packet loss rate, and the formula is as follows:

[0060]

[0061] where represents the smoothed packet loss rate at time t n The smoothed packet loss rate at time t, represents the smoothed packet loss rate at time t n-1 The smoothed packet loss rate at time t, α represents the filter coefficient, and in this embodiment, α = 0.9.

[0062] Whether to send a repair packet is determined by the current link packet loss rate. If the current repair insertion frequency is lower than then a repair packet will be sent, that is:

[0063]

[0064] where and are the numbers of source packets and repair packets sent by the sender at the current time t c respectively, and is the smoothed packet loss rate at the current time t c δ ∈ (0, 1).

[0065] A low-latency QUIC protocol transmission system proposed in the present invention includes a sender, a receiver, a stream coding transmission unit, a congestion control unit, and a loss detection unit; among them:

[0066] The sender is used to send packets; the types of packets include: protected packets, unprotected packets, and repair packets; if an unprotected packet is lost in the link, it cannot be recovered; the repair packet is a repair packet generated by the encoder of the stream coding transmission unit for recovering lost protected packets;

[0067] The receiver is used to receive packets and ensure that the packets are transmitted to the upper layer completely and orderly. At the same time, the receiver also sends ACK packets to the sender to indicate the packet reception situation; the ACK packet consists of a group of ACK ranges, and each ACK range represents a segment of received ordered packet sequence numbers;

[0068] The streaming coding transmission unit includes an SCEncoder module and an SCDecoder module. The SCEncoder module provides the encoding function for streaming coding transmission, including an encoder and an adaptive FEC code rate module; the SCDecoder module provides the decoding function for streaming coding transmission, including a decoder and a source packet saving module; the streaming coding transmission unit adopts a packet-level proactive forward error correction code based on the packet loss rate and adaptively sends repair packets by estimating the link packet loss rate.

[0069] The congestion control unit adopts the Westwood+ congestion control algorithm, estimates the bandwidth of the current transmission link through the feedback information of the receiver, and calculates the congestion window based on this.

[0070] The loss detection unit estimates the link packet loss rate by using the ACK packets fed back by the receiver.

[0071] In this embodiment, tests were carried out in Mininet, and the method of the present invention was compared with schemes such as QUIC and rQUIC in the satellite network. The results are as Figure 2 shown, where SC represents the method of the present invention. For each protocol type, 2500 and 25000 packets were transmitted respectively in a point-to-point manner, and the size of each packet was 1400 bytes to simulate the situations when transmitting small files and large files. The results show that the method of the present invention can achieve lower latency in the case of a lossy link and higher throughput compared with the traditional QUIC and rQUIC protocols.

[0072] It should be noted that the description of the system in the embodiment of the present invention is similar to the description of the above method embodiment and has similar beneficial effects as the method embodiment, so it will not be elaborated here.

[0073] Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art can still modify the technical solutions described in the foregoing embodiments, or perform equivalent replacements for some of the technical features. Any modifications, equivalent replacements, improvements, etc. made within the spirit and principle of the present invention shall be included within the protection scope of the present invention.

Claims

1. A low-latency QUIC protocol transmission method, characterized in that, The transmission method adopts an active forward error correction coding mechanism based on packet loss rate estimation, and this coding mechanism is called stream coding; During the transmission process, all lost packets rely on the stream coding for recovery; the sender adaptively adjusts the target code rate of the stream coding based on the estimation of the link packet loss rate and automatically selects whether to send repair packets based on the target code rate; When packet loss occurs during the transmission process, the receiver uses the subsequently received repair packets to complete data recovery; the Westwood+ is adopted as the congestion control algorithm for QUIC in the transmission method; The transmission method specifically includes the following steps: Step S1, initialize the QUIC connection, and the sender and receiver respectively initialize the stream coding parameters; Step S2, transfer the data to be sent in the form of bytes to the sender; Step S3, the sender determines whether there is remaining space in the congestion window and the flow control window. If there is no remaining space in the congestion window or the flow control window, repeat Step S3; Step S4, when there is remaining space in the congestion window and the flow control window, the QUIC sender generates data packets and encrypts them to obtain QUIC packets; the encrypted QUIC packets are input into the SCEncoder module and different operations are performed according to their packet types; the QUIC packet types include source packets and unprotected packets, where the source packets are the packets protected by the stream coding and can be repaired when they are lost, and the unprotected packets cannot be recovered when they are lost; For source packets, the SCEncoder module treats them as a byte stream and adds an SCheader at the beginning and then transfers them to the UDP send queue; for unprotected packets, the SCEncoder module directly transfers them to the UDP send queue; Step S5, the sender selects whether to send repair packets based on the target code rate of the current stream coding; Step S6, input all the received QUIC packets at the receiver into the SCDecoder module; the SCDecoder module removes the SCheader of the received QUIC packets and delivers them to the QUIC session; If a QUIC packet is lost, activate the decoder in the SCDecoder module and use the received repair packets to perform data recovery; all the arrived QUIC packets are delivered to the upper layer according to the default settings of QUIC, and an ACK packet is fed back to the sender; Step S7, the sender processes the ACK packet, calculates the round-trip time RTT, the number of acknowledged packets, and the link packet loss rate; Use the Westwood+ congestion control algorithm to update the link congestion window and perform congestion control according to the number of acknowledged packets and the round-trip time RTT; the SCEncoder module adjusts the target code rate of the stream coding according to the link packet loss rate; Step S8, repeat Steps S4 - S7 until the data transmission ends.

2. The low-latency QUIC protocol transmission method according to claim 1, characterized in that In step S1, the sender stream coding parameters include the requested file size, the number of source packets to be sent, the Galois field size, the transmission packet size, the frequency of sending repair packets, and the random coding coefficient seed; the receiver stream coding parameters include the Galois field size, the transmission packet size, the frequency of sending repair packets, and the random coding coefficient seed; if the requested file size and the number of source packets to be sent are 0, it indicates that the packets arrive successively and have no determined size.

3. A low-latency QUIC protocol transmission system, characterized in that, The system includes a sender, a receiver, a stream coding transmission unit, a congestion control unit, and a loss detection unit; where: The sender is used to send packets; the types of packets include: source packets, unprotected packets, and repair packets; the source packets are packets protected by stream coding and can be repaired when lost in the link; the unprotected packets cannot be recovered if lost in the link; the repair packets are repair packets generated by the encoder in the stream coding transmission unit to recover the lost protected packets; The receiver is used to receive packets and ensure that the packets are transmitted to the upper layer completely and orderly. At the same time, the receiver also sends ACK packets to the sender to indicate the packet reception situation; the ACK packets consist of a group of ACK ranges, and each ACK range represents an ordered packet sequence number received; The stream coding transmission unit includes an SCEncoder module and an SCDecoder module. The SCEncoder module provides the encoding function of stream coding transmission, including an encoder and an adaptive FEC code rate module; the SCDecoder module provides the decoding function of stream coding transmission, including a decoder and a source packet saving module; the stream coding transmission unit adopts a packet-level proactive forward error correction code based on the packet loss rate and adaptively sends repair packets by estimating the link packet loss rate; The congestion control unit adopts the Westwood+ congestion control algorithm, estimates the bandwidth of the current transmission link through the feedback information of the receiver, and calculates the congestion window based on this; The loss detection unit estimates the link packet loss rate by using the ACK packets fed back by the receiver.

Images