Patent Application
20160323062
Networked applications rely on transport layer protocols to deliver data across the network. Different types of applications place different requirements on the transport layer. Delay is an issue that presents a challenge in the context of network communications.
End to end delay has several components. Some of these delay components are introduced by elements of a sender, such as a send buffer and congestion control elements. Other delay components are introduced by elements of a receiver such as a receive buffer. Still other delays are introduced by network path elements such as network path buffers and by physical propagation along network links. More particularly, end to end delay can include: 1) Queueing delay in a send buffer, which is the time that data stays in a send buffer until sending starts. This delay occurs when the rate of sending data is lower than the data rate. A large send buffer introduces large queueing delay. 2) Sending delay, which is the time that it takes for data to be sent. This delay can be influenced by the operation of congestion control elements at the sender, which under some conditions acts to reduce the sending rate in order to relieve congestion. 3) Propagation delay, which is the time it takes for a packet to get across the network path under no congestion (including delay due to the finite speed of light in transmission media). 4) Queueing delay in network buffers. This delay occurs when the offered traffic exceeds the network capacity. 5) Retransmission delay, which is the time that it takes for lost packets to be recovered. 6) Head-of-line (HOL) blocking delay, which is introduced by the requirement of in-order delivery and is the time that new data is blocked by old data.
The delay components are determined by two modules in transport protocols. The first is congestion control, which regulates the rate at which data is sent into the network. Congestion control affects the queueing delay in the send buffer, the sending delay, and queueing delay in the network. The second is error control, which provides reliability. Error control affects the retransmission delay and head-of-line blocking delay.
User Datagram Protocol (UDP) and Transmission Control Protocol (TCP) are standard transport protocols in wide use in the Internet. UDP does not provide congestion control. Data is sent immediately. TCP is the most widely used transport protocol. It provides congestion control that responds to the change of available bandwidth. TCP also provides reliability (recovery of lost packets).
Both User Datagram Protocol and Transmission Control Protocol have limitations with respect to delivery of interactive real time media. Since UDP does not reduce the sending rate to respond to congestion, it may have higher packet losses and introduce high queueing delay in network buffers. High packet losses will degrade video quality. However, TCP is also not well suited for interactive real-time media. TCP aggressively reduces its sending rate in response to even a single instance of congestion, which increases the sending delay and causes video jitter. TCP uses a loss-based congestion control procedure that operates by filling the queues on a path until loss occurs, thus maximizing delay. The reliability of TCP forces every type of data to be received even if some data is less important or too late to be useful. TCP uses a fixed-sized send buffer that prevents applications from quickly reacting to reduced available bandwidth. Using a small send buffer can limit the delay, but this hurts throughput.
Interactive real-time multimedia applications require low delay and a smooth sending rate. Such applications require an intermediate level of reliability that may be called “partial reliability.” What is needed is a transport protocol that supports the requirements of real-time interactive media, including lower delay in the network, lower delay in the send buffer, a smoother sending rate, and partial reliability.
Embodiments of the present invention provide an application-level transport protocol to support the requirements of real-time interactive media. In a preferred embodiment, techniques are provided for congestion control, dynamic management of send buffers, message dropping, and error control.
The preferred congestion control technique is delay-based, in contrast to the loss-based congestion control of TCP. The delay-based technique provides a smoother sending rate and lower queueing delay in network buffers.
Queueing delay in the send buffer is controlled by calculating the current send buffer queueing delay at the time a new message is requested to be sent and comparing the current queueing delay to the threshold. If the delay exceeds the threshold, the new message is not placed in the send buffer.
Message dropping procedures are provided to ensure that messages that are “too old” are dropped and thus do not contribute to queueing delays. Special procedures are provided for video to reduce the occurrence of “artifacts” when a video frame is dropped by sending an “out of band” request to a video encoder to send a new video key frame.
The preferred error control technique utilizes only gap-based loss detection in the receiver, in contrast to TCP and UDP which perform both gap-based loss detection at the receiver as well as timer-based detection at the sender. This approach is well-matched to the regular data generation and high packet rates characteristic of real-time media applications, conditions under which it is found that gap-based detection tends to perform particularly well. It also avoids problems with timer-based approaches that can be caused by inaccurate Round Trip Time (RTT) estimates.
Embodiments of the present invention provide a transport protocol for interactive real-time media.
User device 103 includes central processing unit (CPU) 120, memory 122 and storage 121. User device 103 also includes an input and output (I/O) subsystem (not separately shown in the drawing) (including e.g., a display or a touch enabled display, keyboard, d-pad, a trackball, touchpad, joystick, microphone, and/or other user interface devices and associated controller circuitry and/or software). User device 103 may include any type of electronic device capable of providing media content. Some examples include desktop computers and portable electronic devices such as mobile phones, smartphones, multi-media players, e-readers, tablet/touchpad, notebook, or laptop PCs, smart televisions, smart watches, head mounted displays, and other communication devices.
Server computer 101 includes central processing unit CPU 110, storage 111 and memory 112 (and may include an I/O subsystem not separately shown). Server computer 101 may be any computing device capable of hosting computer product 131 for communicating with one or more client computers such as, for example, user device 103, over a network such as, for example, network 102 (e.g., the Internet). Server computer 101 communicates with one or more client computers via the Internet and may employ protocols such as the Internet protocol suite (TCP/IP), Hypertext Transfer Protocol (HTTP) or HTTPS, instant-messaging protocols, or other protocols.
Memory 112 and 122 may include any known computer memory device. Storage 111 and 121 may include any known computer storage device.
Although not illustrated, memory 112 and 122 and/or storage 111 and 121 may also include any data storage equipment accessible by the server computer 101 and user device 103, respectively, such as any memory that is removable or portable, (e.g., flash memory or external hard disk drives), or any data storage hosted by a third party (e.g., cloud storage), and is not limited thereto.
User device(s) 103 and server computer(s) 101 access and communicate via the network 102. Network 102 includes a wired or wireless connection, including a Wide Area Networks (WANs) and cellular networks or any other type of computer network used for communication between devices.
In the illustrated embodiment, computer program product 131 in fact represents computer program products or computer program product portions configured for execution on, respectively, server 101 and user device 103. A portion of computer program product 131 that is loaded into memory 122 configures device 103 to create and send ACK and NACK packets in response to data packets received from sever 101, the ACK, NACK, and data packets being in conformance with the inventive protocol requirements further described herein. A portion of computer program product 131 that is loaded into memory 112 configures server 101 to utilize information received in ACK and NACK data packets for efficiently controlling the queuing and sending of data packets in conformance with the inventive protocol requirements further described herein.
A preferred embodiment of the present invention provides a UDP-based application level transport protocol for interactive real-time media. As shown in
In other embodiments, the interactive real-time media transport protocol can be implemented as a monolithic layer 3 transport protocol. In such embodiments, the interactive real-time media transport protocol provides basic transport layer services (such as those provided conventionally by UDP) in addition to specialized services tailored to the needs of interactive real-time media. Advantages of such embodiments can include greater efficiency and reduced processing time.
Also shown in
In some embodiments, sender 300 can be associated with an entity that sends real-time media information, such as video and audio streams. For example, sender 300 can be associated with a server computer, such as server computer 101 as depicted in
In some embodiments, receiver 301 can be associated with an entity that receives real-time media information, such as video and audio streams. For example, receiver 301 can be associated with user device(s) 103, as depicted in
In some embodiments, server computer 101 may comprise both one or more instances of sender 300 and one or more instances of receiver 301. In some embodiments, client device 103 may comprise both one or more instances of sender 300 and one or more instances of receiver 301.
A preferred embodiment of the inventive interactive real-time media transport protocol can be used to send control information from client device 103 to server computer 101 and also to deliver streaming audio and/or video from server computer 101 to client device 103.
The structure of data packets 410, ACK packets 420, and NACK packets 430 is shown in detail in
A data packet 410 conveys data (not shown) to or from an application. For example, data packet 410 can convey one “chunk” of data, where a “chunk” is part of a message. A message is the minimal data unit that can be handled by an application. It is received either as a whole or not at all. A message can be, for example, a video frame or an audio frame. A message is split into chunks and each chunk is sent over one UDP data packet. All data packets belonging to the same message have the same message sequence number. The congestion control protocol cares only about packet loss, which is used to calculate the allowed sending rate.
Each of data packets 410, ACK packets 420, and NACK packets 430 includes conventional IP header 401 and conventional UDP header 402, as well as additional header information that will now be described.
Packet sequence 411 is the sequence number of data packet 410. Packet sequence number 411 is incremented once per data packet, and is used for loss detection in the congestion control protocol (described below).
Chunk sequence 412 is the sequence number of a chunk. It is incremented by one per chunk. Chunk sequence 412 is used for re-assembly of messages and loss recovery.
Message sequence 413 is the sequence number of the message to which this chunk belongs.
Drop message sequence 414 is used, in the message drop feature, to notify the receiver that messages prior to this sequence should be dropped.
Each retransmitted data packet carries a NACK sequence 415 that corresponds to the sequence number of the associated NACK request. NACK sequence 415 is used for loss detection and recovery of retransmitted data packets.
RTT 416 is an estimate of round-trip time. RTT 416 is used to determine congestion intervals in the congestion control protocol.
Timestamp 417 records the time when this packet was sent. Timestamp 417 is used for the calculation of queueing delay in the congestion control protocol.
TTL 418 is the remaining time that this message should be kept in the receive buffer. It is used by the message dropping feature.
ACK packets 420 are sent from the receiver to the sender, and in embodiments of the present invention are used to provide feedback as part of the congestion control protocol.
Echo sequence 421 is the largest sequence number of data packets received, and is used to calculate round-trip time (RTT) in the congestion control protocol.
Cumulative ACK 422 is a chunk sequence number, and indicates that all chunks prior to this chunk sequence number have been received.
Congestion event rate 423 is calculated by the receiver, and is used in the calculation of the allowed sending rate in the congestion control protocol.
Receive rate 424 is measured by the receiver, and is used in the calculation of the allowed sending rate in the congestion control protocol.
NACK packets 430 are sent by the receiver to request retransmission of lost chunks. A NACK packet can carry one or more NACK requests. Each NACK request has a sequence number and corresponds to one lost chunk.
NACK sequence 431 is the smallest sequence number of the NACK requests in this NACK packet. This sequence number can help detect duplicate NACK requests and losses of retransmitted data packets.
Loss blocks, such as loss block 432, specify a range of a contiguous sequence numbers of chunks.
The use of data packets, ACK packets, and NACK packets in performing various methods comprising embodiments of the present invention will be described in detail below.
As suggested above, embodiments of the interactive real-time media transport protocol of the present invention comprise several methods which are designed to work together and which together serve to reduce end-to-end delay to the low levels required by real-time interactive media.
Specifically, methods are disclosed for congestion control, control of send buffer queueing delay, message dropping in the receiver, and error control. Each of these methods will now be described in turn, with reference to the corresponding drawings.
It should be noted that, while the methods are designed to work together to satisfy the delay requirements of real-time interactive media, in some embodiments the methods can be used individually, or in various combinations, or in combination with other protocols or methods.
Congestion Control.
In
The use of a weighted average filter in calculating the weighted-average congestion event rate makes the measured congestion event rate change smoothly, which contributes to a smoother sending rate.
At the sender, the echoed sequence number is then used for the calculation of RTT. At the sender, RTT samples are received at step 510 and, at step 511, a “smoothed” RTT is calculated. At step 512 the “smoothed” RTT and the congestion event rate are used by a TCP throughput equation to calculate the allowed sending rate, which is output at step 513. Also, the current receive rate is monitored. Preferably, the allowed sending rate is limited to no more than twice the receive rate. At step 515 outgoing packets are scheduled and sent based on the allowed sending rate.
In a preferred embodiment, the TCP throughput equation is one specified in RFC 5348 Section 3.1. This equation is:
Where:
In a preferred embodiment, the congestion control method is substantially in conformance with dflow, as described in Internet-Draft draft-ohanlon-rmcat-dflow-02.
Dynamic Send Buffer.
At step 610 the application generates a message (for example, a video encoder generates a video frame). At step 620 the application requests to send the message. At step 630 the queueing delay in the send buffer is calculated. From the application point of view, this is the time that the new message would need to wait until all pending data are sent. This delay time is equal to pending data size divided by the current sending rate (as set by the congestion control method described above). Pending data includes pending packets not yet sent, and pending retransmissions from NACK requests.
At step 640 the calculated queueing delay is compared to a pre-set threshold. If the delay does not exceed the threshold, at step 650 the new message is queued into the send buffer. If the calculated queueing delay exceeds the threshold, the new message is not appended into the send buffer, and the application has to try again, returning to step 620. In a variation, the application can be explicitly notified of the need to try again
Message Dropping.
Two mechanisms are used for the receiver to detect messages that are not received within a specified time limit. The first mechanism is a message drop sequence field in each data packet that notifies the receiver to drop all messages prior to that sequence. See also the data packet field layout in
For interactive real-time media applications, time limits for video frames in particular can be specified. For delta frames, the time limit may be frame-rate based. In this alternative, the frame has a time limit of A*1000/frames per second where A is a constant parameter. Alternatively, the limit may be based on a frame interval. Here, the time limit for the i-th frame is B*(t(i)−T(I−1), where t(i) is the time that the i-th frame is sent and B is a constant parameter. For key frames (intra frames) a higher limit should be specified. For video frames, frame drop can introduce a video artifact, which will last until the next key frame is received. When the time between key frames is large, this can cause a bad user experience. To correct this, a notification can be sent out-of-band to the encoder to request a key frame and thus stop the video artifact.
In general, notifications regarding dropped messages can be sent to an application out-of-band by using, for example, a TCP connection.
Next, the message dropping method will be described in more detail with reference to
At step 911 of
Next, an example of message dropping will be described in detail with reference to the sequence diagram of
At step 1031 sender 1030 sends message 1 comprising one chunk to receiver 1140, which forwards the message to application 1050.
At step 1032 sender 1030 sends a first chunk of message 2 to receiver 1040 where it is held in the receive buffer.
At step 1033 sender 1030 sends a second chunk of message 2, but this chunk is lost.
At step 1034 sender 1030 sends a first chunk of message 3. This data packet includes a message drop field with a value of 1, indicating that any packets of any message with an earlier message drop field being held in the receive buffer should be dropped.
Meanwhile, at step 1035 the second chunk of message 3 is successfully sent and received, and message 3 is forwarded to the application.
At step 1036 a first chunk of message 4 is successfully sent and received. This data packet includes a message drop field with a value of 2, indicating that message 2 should not be held in the receive buffer and should be dropped. The TTL timer for message 4 is started and will expire after 100 ms.
At step 1037 a second chunk of message 4 is sent but it is lost. Message 4 had a TTL field value of 100 time units. When this time expires, message 4 is dropped from the receive buffer and a notification is sent to the application.
At step 1038 message 5 comprising one chunk is successfully sent and received. Message 5 is held awaiting message 4 and is not immediately available to the application. The TTL timer for message 4 expires since the message is still not received. Message 4 is then dropped and a notification is sent to the application. Message 5 is then available to the application.
At step 1039 a chunk of message 6 is sent and received. This message has message drop set to the value 4, but there is nothing with an earlier message sequence number in the buffer, so there is nothing to drop.
Error Control.
The error control method (loss recovery protocol) is based on gap-based loss detection at the receiver. See
At step 1110 a data packet is received. At step 1113 a test is performed to see if the NACK sequence number of the received data packet is larger than the largest NACK sequence number previously received. If not, control passes to the lower box where loss detection of chunks (data packets) is performed. At step 1117 a test is performed to see if the chunk sequence number of this packet has a gap with the largest chunk sequence number previously received. If yes, some chunks sent for the first time have been lost. At step 1118 new NACK requests corresponding to the lost chunks are appended into the loss list (list of pending NACK requests).
At step 1120 the new NACK requests are sent to the sender in a NACK packet unless at step 1119 it is detected that one or more NACK requests correspond to chunks that are part of an expired message. Such NACK requests are removed. Thus, in effect, the message dropping procedure (see above) places a limit on the efforts of the loss recovery protocol to recover lost data.
Returning to step 1113, if the received data packet does have a NACK sequence number larger than the largest NACK sequence number previously received, this indicates that some chunks have been retransmitted since the last data packet was received.
At step 1114 it is determined, based on any gap in NACK sequence numbers, whether any retransmitted chunks have been lost. If so, at step 1115 new NACK requests are appended into the loss list. At step 1115 all NACK requests prior to and including this NACK sequence number are removed from the loss list. Control then passes to box 1117 where the test for lost chunks is performed as before.
Error control will now be discussed in further detail with reference to the sequence diagram of
In particular, loss detection at the receiver is demonstrated. Step 1262 is an example of the loss detection of chunks sent for the first time. Steps 1266 and 1269 illustrate loss detection of retransmitted chunks.
At steps 1210-1215 data packets having chunk sequence numbers 1, 2, 3, 4, 5, and 6 are sent. Of these, data packets 1, 2, and 6 are successfully received, but packets 3, 4, and 5 are lost. At step 1262, the receiver detects the break in chunk sequence numbers, and at step 1263 sends toward the sender a NACK packet with a NACK sequence of 1 and loss block of [3,5].
At step 1216 the sender receives the NACK packet. At steps 1217-1219 the sender resends data packets 3, 4, and 5. Resent packet 3 carries the NACK sequence number 1. The NACK sequence number is incremented for each resent packet, so that resent data packets 4 and 5 carry, respectively, NACK sequence numbers 2 and 3. Resent data packet 4 is lost, and this is detected by the receiver at step 1266 from the break in NACK sequence numbers. A new NACK with sequence number 4 and loss block [4,4] is then generated and sent to the sender.
At step 1221 data packet 4 is resent but is again lost. The loss is detected in the receiver at step 1269, which at step 1270 sends a NACK with NACK sequence 5 and loss block 4,4, which is received at sender 1200 at step 1224.
At steps 1222 and 1223 data packets 7 and 8 are successfully sent, with the NACK sequence number remaining at 4.
At step 1225 data packet 4 is again re-sent, now with NACK sequence number 5. This time data packet 4 is successfully received.
At step 1226, a data packet 9 is successfully sent, with NACK sequence remaining at 5.
As discussed above, the “loss list” is a list of pending NACK requests. Each NACK request has a unique NACK sequence number and the sequence number of a lost chunk. NACK requests are “appended” into the loss list whenever new packet loss is detected. Operation of the loss list may be understood with regard to the example of
In
The pending NACK request(s) is (are) removed (acknowledged) from the loss list when 1) the chunks that they request are successfully received or 2) the retransmitted chunks are lost again. In this case, new NACK request(s) is (are) appended.
For example, at step 1264, the retransmitted chunk 3 that responds to NACK request 1 is received, which acknowledges the receiver that NACK request 1 has been successfully responded to and can be removed from loss list. At step 1266, NACK request 3 is also successfully responded to while NACK request 2 fails since retransmitted chunk 4 is lost. Both NACK request 2 and 3 are removed from loss list. A new NACK request (4, 4) for chunk 4 is appended to loss list.
Packet Recovery.
Packet loss can be recovered in two ways: Automatic Repeat Request (ARQ) or Application Layer Forward Erasure Control (AL-FEC). The ARQ scheme needs at least one Round Trip Time (RTT) to recover from a loss. This is an issue if the RTT exceeds the maximum acceptable delay of a real-time stream. AL-FEC codes prevent retransmission delays by proactively adding redundancy packets to the original data.
A certain number of missing packets can be recovered at the receiver side without using feedback-based retransmission. In block FEC codes, a source block of k source symbols is encoded as an FEC block of n output symbols that are transmitted to a receiver so that the original k source symbols can be recovered even if some of the output symbols are not received. In the class of FEC codes called systematic codes, the original k source symbols are included unaltered in the set of n output symbols. The set of n output symbols thus may consist of k source symbols and n-k repair symbols. An advantage of a systematic code is that, if all source symbols are received, there is no need to wait for or process the repair symbols.
Application Layer Forward Erasure Control differs from Forward Error Control at the physical layer in that the latter is concerned with correcting bit errors on transmission links. AL-FEC by contrast is concerned with loss or erasure of entire packets, as may occur, for example, due to buffer overflow at the routers of a busy or congested network.
A single FEC block may protect several video frames. This may be an acceptable strategy for an application that does not have strict latency requirements. A large block size can also provide better protection against bursty loss (loss of several consecutive packets). Some embodiments of the present invention employ a hybrid strategy, in which a relatively small FEC block protects primarily against random errors (loss of a single packet), while burst errors are recovered using an ARQ scheme. For an application that has strict quality requirements but not so strict latency requirements (for example playing a recorded video over a network) the tradeoffs may favor large block size.
However, with live streaming, unlike recorded video, a frame is not available until it is generated. Consequently, the next video frame is not available until a certain amount of time has passed. If a block spans more than one video frame, the recovery delay will depend on the frame interval. A large frame interval will introduce a high recovery delay. For example, say a video frame has some missing packets, which are protected by a FEC block that spans the next 2 video frames. For frame interval 50 ms, it will take 100 ms for the next 2 frames to be generated, and then the repair packets can be created for recovery.
In order to decouple the frame interval and recovery delay, according to some embodiments of the present invention, the protection range is limited to one video frame. That is, in such embodiments, each FEC block protects exactly one video frame. Thus, the repair packets for a video frame can be generated and sent immediately after the video frame is sent. So long as the number of output symbols received is enough to recover packet loss, the receiver can recover the video frame without waiting for an additional frame or frames. This reduces the component of transport delay attributable to recovery from packet loss, which helps reduce overall transport delay. Achieving a low end to end transport delay is important for many applications, such as real-time interactive media.
Limiting the span of protection to a single video frame can, in some embodiments, be accomplished at the application layer, since the application knows the boundaries of the video frame. In some embodiments, the application inputs the video frame as a single source block to the FEC encoding process, thus ensuring that the FEC block is limited to one video frame.
In some embodiments, the FEC block is of fixed size. In other embodiments, the FEC block is of variable size. An advantage of a variable size FEC block is the ability to adjust to varying network conditions. For example, the block size could be increased when the average length of loss bursts increases. An advantage of a fixed block size is that it avoids the need to re-initialize the FEC code, with attendant delay and computation overhead.
Source symbol S16 is protected by FEC block 1304, as shown in
At step 1701 the process starts.
At step 1703, video is received from a video capture device or other source. For example, in some embodiments, analog RGB video signals may be received from a video camera. In other applications, video may be received in a digital format.
At step 1705, a video frame is encoded, for example utilizing an H.264 video codec.
At step 1707, a source block is constructed from an encoded video frame. The source block is the unit to which the FEC encoding will be applied. In general it consists of one or more source symbols. A source symbol may consist of multiple bytes of information, representing a portion of the encoded video frame. In an embodiment, all the source symbols in a single source block are the same size, except possibly the last source symbol in the block.
At step 1709, the source block is sent to the FEC Scheme (FEC encoder/decoder).
At step 1711 the FEC Scheme generates repair symbols based on the source symbols. In some embodiments, the FEC code is a systematic code (see above), such that the input source symbols, along with the repair symbols, form the set of output symbols of the encoding process.
At step 1713, source and repair packets are constructed based on the source and repair symbols.
At step 1715 the source and repair packets are sent across the network. The process then returns to step 1705 and another video frame is encoded.
At step 1803, source and repair packets for one video frame are received at the receiver.
At step 1805, if missing sequence numbers are detected at the receiver, control is passed to step 1807.
At step 1807 the FEC Scheme (FEC encoder/decoder) reconstructs missing symbols using the repair packet or packets.
At step 1809, the video frame is decoded. For example, if the video was encoded by an H.264 codec at the transmitter, H.264 decoding is performed at this step.
At step 1811, the video information corresponding to the decoded video frame is sent to a display device, for example, to a user device having a display. The process then returns to step 1803, and source and repair packets for another video frame are received.
In one aspect, an embodiment provides for low-delay transmission of packets across a network from a transmitter to a receiver, comprising, at one or more computers coupled to the network, transmitting a data packet; at the transmitter, receiving an ACK packet conveying a congestion event rate and an echoed sequence number; at the transmitter, calculating a smoothed round-trip time based on the echoed sequence number; at the transmitter, utilizing a TCP throughput equation to calculate an allowed sending rate, based on a congestion event rate and smoothed round-trip time; at the transmitter, calculating a current queueing delay of a send buffer; at the transmitter, queueing into the send buffer a message requested to be sent by an application only if the current queueing delay does not exceed a threshold; at the transmitter, inserting a time limit value in a data packet, the time limit value signaling to the receiver a limit on how long the associated message should stay in the receive buffer before being removed; at the transmitter, inserting a message drop sequence number in a data packet, the message drop sequence number signaling to the receiver to drop all messages with an earlier sequence number; and at the transmitter, receiving a NACK packet indicating a range of sequence numbers of lost packets, and retransmitting the lost packets. Also disclosed is a computer program product stored on a non-transitory computer-readable medium that, when read and executed by one or more computers, performs the above-disclosed method. Also disclosed is a transmitter for transmitting packets across a network to a receiver with low delay, and for receiving an ACK packet conveying a congestion event rate and an echoed sequence number; calculating a smoothed round-trip time based on the echoed sequence number; utilizing a TCP throughput equation to calculate an allowed sending rate, based on a congestion event rate and smoothed round-trip time; calculating a current queueing delay in a send buffer, and queueing into the send buffer a message requested to be sent by an application only if the current queueing delay does not exceed a threshold; and receiving a NACK packet indicating a range of sequence numbers of lost packets, and retransmitting the lost packets.
In another aspect a method is disclosed for low delay reception of packets across a network from a transmitter to a receiver, comprising, at one or more computers coupled to the network: receiving a data packet; at the receiver, detecting packet losses indicative of congestion by detecting sequence number breaks; at the receiver, detecting high queueing delay indicative of congestion based on a timestamp value in a received data packet; at the receiver, calculating a congestion event rate and sending to the transmitter an ACK packet conveying the congestion event rate and an echoed sequence number, as input to the calculation of allowed sending rate; at the receiver, determining, based on a time limit value in each received data packet, the maximum allowable time for a message to stay in the receive buffer, and removing any messages that exceed the maximum allowable time; at the receiver, receiving a data packet having a message drop sequence number, and dropping all messages prior to a message associated with the data packet; and at the receiver, identifying lost packets via sequence number gaps, and, when losses are detected, sending a NACK packet to the transmitter to request the transmitter to retransmit the lost packets. Also disclosed is a computer program product stored on a non-transitory computer-readable medium that, when read and executed by one or more computers, performs the above-disclosed method. Also disclosed is a transmitter for transmitting packets across a network to a receiver with low delay, the transmitter comprising: a congestion control module configured to receive an ACK packet conveying a congestion event rate and an echoed sequence number, calculate a smoothed round-trip time based on the echoed sequence number, and utilize a TCP throughput equation to calculate an allowed sending rate based on the congestion event rate and the smoothed round-trip time; a send buffer; a queue control module configured to calculate a current queueing delay in the send buffer and to queue into the send buffer a message requested to be sent by an application only if the current queueing delay does not exceed a threshold; and an error control module configured to receive a NACK packet indicating a range of sequence numbers of lost packets, wherein the transport layer is configured to direct the transmitter to retransmit the lost packets. Also disclosed is receiver for receiving packets from a transmitter across a network with low delay, the receiver comprising: a congestion control module configured to detect congestion by detecting packet losses or high queueing delay, and to send to the transmitter an ACK packet conveying a congestion rate event and an echoed sequence number; a message dropping module configured to determine, based on a time limit value in each data packet, the maximum allowable time for a message to stay in a receive buffer, and removing any messages that exceed the allowable time, the message dropping module further configured to receive a data packet having a message drop sequence number, and to drop all messages with an earlier message sequence number from the receive buffer; and an error control module configured to identify lost packets via sequence number gaps, and, when losses are detected, send a NACK packet to the transmitter to request the transmitter to retransmit the lost packets.
Although a few exemplary embodiments have been described above, one skilled in the art will understand that many modifications and variations are possible without departing from the spirit and scope of the present invention. Accordingly, all such modifications and variations are intended to be included within the scope of the claimed invention.
This application is a continuation-in-part of U.S. application Ser. No. 14/702,353, filed on May 1, 2015, which is hereby incorporated by reference in its entirety.
| Number | Date | Country | |
|---|---|---|---|
| Parent | 14702353 | May 2015 | US |
| Child | 14925622 | US |
