Improved Congestion Response

Abstract

In an example of the present invention, during content delivery, the round-trip time of each delivered data packet is measured, and the congestion window used for delivery is adjusted accordingly. The congestion window is set to a relatively large value when the round-trip time is relatively short, and is set to a relatively small value when the round-trip time is relatively long.

Description

Technical Field

[0001] The present invention relates to methods and apparatus for managing congestion response during content delivery over a network. Background Art

[0002] The Transmission Control Protocol (TCP) is a transport protocol used when delivering data over a distributed computer network such as the Internet.

[0003] TCP is designed to achieve reliable data transfer over a network, with the aim of not adversely affecting the network throughput competing for TCP traffic flows. According to the TCP protocol, lost packets during transmission are retransmitted in an attempt to achieve reliable delivery. Additionally, the TCP protocol implements a congestion response or congestion avoidance scheme. As part of this scheme, assuming that packet loss is caused by congestion on the network, after detecting packet loss, the transmission rate of packets from the sender to the receiver over the network is reduced.

[0004] The transmission rate of packets to the network can be controlled by a parameter called the congestion window (which can be represented as CWND in this document). The congestion window can indicate the maximum allowed number of packets that have been transmitted into the network but not yet acknowledged by the receiver at any given time. A TCP sender (e.g., a media content server) can maintain a congestion window for each receiver (e.g., a content client) connection or flow. After detecting packet loss on a given connection, the TCP sender typically takes prompt measures to significantly reduce the size of the congestion window, thereby causing a substantial reduction in the transmission rate of that connection. The TCP NewReno implementation does this through a process called additive increase multiplicative decrease.

[0005] For example, when such a TCP flow passes through a router to transfer a large file, the transmission rate increases until the router queue fills up, at which point packets will be lost. In some router implementations known as tail drop, packets are not lost until the queue is completely full. In other implementations (such as random early drop), the probability of packet loss increases monotonically with buffer filling. However, generally, the probability of packet loss due to buffer filling increases with buffer filling.

[0006] Thus, as the router buffer fills up, packet loss occurs, causing TCP to slow down the transmission rate by reducing the congestion window size. Then, TCP gradually increases the congestion window size as it receives acknowledgments until the router queue fills up again and packet loss occurs.

[0007] Figure 4This is a typical example showing the results of such behavior over time on the TCP congestion window size (CWND), buffer fill, and round-trip time (RTT) for the following scenario: a single TCP New Reno flow through a router with a queue size of 100 packets, and packets from sources other than the source queued in the router with a packet size of 1500 bytes, a bottleneck throughput rate of 10 Mbit / s, and an RTT of 10 ms. The CWND is shown by the solid line plot 400 (and measured in packets), the buffer fill is shown by the dashed line plot 402 (and measured in packets), and the RTT is shown by the dotted-dashed line plot 404 (and measured in ms). It can be seen that each of these plots is zigzag.

[0008] The size of the congestion window increases steadily, and the buffer fill and round-trip time are not very linear because the congestion window increases by one packet per round-trip time, but the round-trip time increases with the congestion window and buffer fill, thus increasing the interval between increments.

[0009] Popular implementations of TCP congestion control (such as TCP New Reno and TCP CUBIC) control the data flow in response to packet loss and thus cannot guarantee the delivery of a specified amount of data within a specified time interval.

[0010] The applicant's international application WO2014 / 155031 describes TCP congestion control, in which the TCP congestion window is controlled during the delivery of data segments to ensure the delivery of data segments within a specified time interval, and in which packet loss is monitored during delivery, and in which the packet loss measured during the delivery of one or more previous segments is used to calculate the constraint on the congestion window to be used for the delivery of the next data segment.

[0011] For example, for a content streaming application, the specified time interval can be set to a relatively short time, in which content needs to be delivered within a certain time to prevent playback pauses. Conversely, for a file download, if the user does not urgently need the file, the specified time interval can be set to a relatively long time. Summary of the Invention

[0012] According to one aspect of the present disclosure, there is provided a method for delivering content from a server to a client over a network, the content including a plurality of time segments having an associated time available for delivery, and each time segment including a plurality of data packets, the method including the steps of:

[0013] a) delivering a first portion of a segment from the server to the client;

[0014] b) Measure a plurality of round-trip times associated with delivering at least the first portion;

[0015] c) Determine a current round-trip time, a center round-trip time, a low round-trip time, and a high round-trip time based on the plurality of round-trip times;

[0016] d) Calculate a required congestion window size for delivering the remaining data in the segment within the time available for delivering the remaining data in the segment, wherein the required congestion window size depends on the center round-trip time;

[0017] e) Calculate a modified congestion window size, wherein the modified congestion window size falls within a range set around the required congestion window size, and wherein the modified congestion window size is relatively large when the current round-trip time is close to the low round-trip time, and wherein the modified congestion window size is relatively small when the current round-trip time is close to the high round-trip time;

[0018] f) Use the modified congestion window size to deliver further data from the remaining portion of the segment from the server to the client;

[0019] g) Measure a plurality of round-trip times associated with delivering further data from the remaining portion of the segment; and

[0020] h) Repeat steps c) to f) at least using the plurality of round-trip times from step g).

[0021] The current round-trip time may be the round-trip time associated with delivering the most recent packet.

[0022] The time available for delivering the data in the remaining portion of the segment may be the time available for delivering the segment minus the time elapsed since the start of data delivery for the segment.

[0023] The modified congestion window size may fall between a minimum congestion window size and a maximum congestion window size, the minimum congestion window size and the maximum congestion window size being set as percentage offsets from the required congestion window size.

[0024] The low round-trip time may be the shortest measured round-trip time, and the high round-trip time may be the longest measured round-trip time.

[0025] The modified congestion window size CWND modified may be given by:

[0026]

[0027] where CWNDmin is the minimum congestion window size, CWND max is the maximum congestion window size, RTT high is the high round-trip time, RTT low is the low round-trip time, and RTT current is the current round-trip time.

[0028] According to a second aspect of the present disclosure, there is provided a server for delivering content to a client over a network, the content including a plurality of time segments having associated times available for delivery, and each time segment including a plurality of data packets, the server being operable to:

[0029] a) deliver a first portion of the segment from the server to the client;

[0030] b) measure a plurality of round-trip times associated with delivering at least the first portion;

[0031] c) determine a current round-trip time, a central round-trip time, a low round-trip time, and a high round-trip time based on the plurality of round-trip times;

[0032] d) calculate a required congestion window size for delivering the remaining data in the segment within the time available for delivering the remaining data in the segment, wherein the required congestion window size depends on the central round-trip time;

[0033] e) calculate a modified congestion window size, wherein the modified congestion window size falls within a range set around the required congestion window size, and wherein the modified congestion window size is relatively large when the current round-trip time is close to the low round-trip time, and wherein the modified congestion window size is relatively small when the current round-trip time is close to the high round-trip time;

[0034] f) use the modified congestion window size to deliver further data from the remaining portion of the segment from the server to the client;

[0035] g) measure a plurality of round-trip times associated with delivering the further data from the remaining portion of the segment; and

[0036] h) repeat steps c) to f) at least using the plurality of round-trip times from step g). BRIEF DESCRIPTION OF THE DRAWINGS

[0037] For a better understanding of the present invention, reference is now made, by way of example only, to the following drawings, in which:

[0038] Figure 1 shows an example of a communication network;

[0039] Figure 2 shows an example of a data server that forms part of a network in Figure 1 ;

[0040] Figure 3 is a flowchart summarizing the steps of a method for content delivery over a network according to an example of the present invention;

[0041] Figure 4 is a graph showing the variation of the congestion window size, buffer fill, and round-trip time of an example TCP New Reno flow over time;

[0042] Figure 5 is a graph showing the variation of the congestion window size, buffer fill, and round-trip time of an example TCP New Reno flow competing with a TCP flow having a fixed congestion window size over time; and

[0043] Figure 6 is a graph showing the variation of the congestion window size, buffer fill, and round-trip time of an example TCP New Reno flow competing with a TCP flow using a modified congestion window control over time. DETAILED DESCRIPTION

[0044] The present invention will now be described with reference to specific examples. However, the present invention is not limited to such examples.

[0045] Examples of the present invention present a method for delivering content from a server to a client over a network. The content can be media content (such as a video sequence) or can be some other form of content (such as file transfer). The content includes a plurality of time segments. For media content, each segment can include data of up to a short duration when played (e.g., data equivalent to 2 to 15 seconds of play). The number of data packets for each segment of media content depends on the duration of the time segment, the encoded bit rate, and the size of each data packet, and can vary from dozens of data packets to thousands of data packets. For example, in the case where the time segment has a duration of 10 seconds, the encoded bit rate is 1 MBit / s, and the data packet size is 1500 bytes, each media content segment of 10 seconds duration will include 833 data packets (10×1000000 / (1500×8)).

[0046] In examples of the present invention, during content delivery, the round-trip time of each delivered data packet is measured, and the congestion window used for delivery is adjusted accordingly. The congestion window is set to a relatively large value when the round-trip time is relatively short, and is set to a relatively small value when the round-trip time is relatively long.

[0047] Now, exemplary embodiments of the present disclosure will be described. In the following examples, media content is delivered over a network according to HTTP adaptive bitrate streaming, where HTTP uses TCP together with a modified TCP congestion response. However, examples of the present invention can equally be applied to other content rather than media content, such as file delivery for operating system updates, games, and applications. Typical examples of media content include movies, news, and TV shows.

[0048] Figure 1 An example of a communication system 100 is shown. The system includes a data server 104, and a plurality of client devices or receivers 108, 110, and 112 separated by a communication network 106. The network 106 can be a wireless network, a wired network, or a combination of a wired network and a wireless network. The network 106 can be a distributed computing network such as the Internet (or can form part of a distributed computing network such as the Internet).

[0049] The data server 104 is shown communicatively coupled to a data source 102. The data source 102 provides data to the data server 104. As described above, in this example, the data is media content including a video stream and / or an audio stream, but can be some other form of data. Thus, the data source 102 is a content generator configured to encode a video stream to generate an encoded video stream. For example, the video stream can be encoded according to the ITU-T H.264 standard, but other standards can also be used. If the media content further includes audio content, the audio content is encoded to generate an encoded audio stream. An example of a standard for encoding an audio stream is MPEG-4 HE AAC, but other standards can alternatively be used. The data source 102 can also be configured to segment the media content into a plurality of discrete time segments, which, as described above, typically have a duration between 2 seconds and 15 seconds. This content stream can be segmented before or after encoding.

[0050] The data server 104 is configured to receive media content from the data source 102 and can store the received content. As shown above, the media content received from the data source 102 can be encoded and segmented. The data server can transmit or deliver the media content via the network 106 to one or more of the clients 108, 110, and 112. The data server 104 can be a video streaming server and can deliver video (and / or audio) content to clients upon request. Thus, the client devices 108, 110, and 112 can be adapted to request media content from the server 104. For example, the client device can be a suitably configured set-top box, PC, laptop, smartphone, tablet, smart TV, etc.

[0051] Figure 2 An example of the data server 104 is shown in more detail.

[0052] The server 104 includes: an input interface 202; a data storage unit 204, and an output interface 210. The server 104 also includes a scheduling unit 214, a congestion window unit 212, and a delivery monitoring unit 218 that are coupled to the output interface 210. The server 104 may be configured to receive encoded content segments from a data source 102 at the input interface 202 and store the received encoded segments as data files 206 in the data storage unit 204.

[0053] Each content segment is sent from the server 104 via the output interface 210 as a plurality of data packets. That is, each content data segment is formed by a plurality of data packets. The number of data packets that make up a content segment may vary and depends on many factors as previously described. The data server 104 may also receive acknowledgment packets from one or more content clients to which the server has sent the data packets via the output interface 210. The communication system may be arranged to cause the content server to receive acknowledgment packets for each data packet successfully delivered to a client over the network.

[0054] Referring to Figure 1 , consider an example of a first flow from the data server 104 to the client 108 and a second flow from the data server 104 to the client 110 over the network 106, where the two flows contend for bandwidth on at least a portion of the network 106. Referring to the TCP flow described previously ( Figure 4 illustrating the behavior of this TCP flow), it has been found that if there is a second flow contending with such a TCP flow, then the second flow can achieve better performance by sending at a higher rate when the buffer is less full and at a lower rate when the buffer is more full. A conventional TCP flow cannot do this because the transmission rate of a conventional TCP flow is controlled based on the congestion window size of that TCP flow, and the congestion window size is in turn controlled by packet loss events. However, a flow using an alternative modified congestion response can delay the response of the flow to packet loss events, and thus the transmission rate of the flow can be controlled regardless of the packet loss rate. Examples of the present invention propose such a modified congestion response.

[0055] When using the network configuration where the two flows described above contend for bandwidth on at least a portion of the network 106, it was found in simulations that the throughput of a TCP New Reno flow is approximately the same as the throughput of a TCP flow with a fixed congestion window size of 47 data packets. This size of the fixed congestion window size can be found by iterating over different values until the throughput achieved by each of the two flows is approximately the same.

[0056] Figure 5 Shows the round-trip time (RTT) 504, buffer fill 502, TCP New Reno congestion window size (TCP CWND) 500, and fixed congestion window size of 47 packets 506 for the case where a single TCP New Reno flow contends with a single TCP flow with a fixed congestion window size of 47 packets through this network configuration.

[0057] In a simulation of a nearly 20-minute transmission ( Figure 5 showing a 30-second segment of this 20-minute transmission), the TCP NewReno flow experiences 1204 packet losses per million packets sent. However, the TCP flow with a fixed congestion window size experiences 852 packet losses per million packets sent, which is significantly less than the packet losses of the TCP New Reno flow.

[0058] For the TCP flow with a fixed congestion window size, the lower level of packet losses observed can be explained as follows. The average congestion window sizes of the two contending flows are approximately the same. As the buffer fills, the congestion window of the TCP New Reno flow increases, and the time point at which the buffer overflows is greater than the fixed congestion window size of the other flow. Although either one or both flows may experience losses, the TCP New Reno flow has more "in-flight" packets, which makes the TCP New Reno flow more likely to experience packet losses among the two flows.

[0059] Therefore, a TCP flow with a fixed congestion window size can achieve the same throughput as the contending TCP New Reno flow while experiencing lower packet losses. This is generally beneficial to the network because fewer data packets need to be retransmitted and fewer resources are wasted. However, performance can be further improved by allowing the congestion window size to vary according to some variation in the measured round-trip time, as described in the example of the present invention using a modified congestion window.

[0060] A conventional TCP flow such as TCP New Reno will gradually increase its congestion window size without experiencing packet losses and then substantially reduce packet losses. As the congestion window size increases towards the direction of packet losses, the growing congestion window size is likely to cause the network buffer to fill up and the round-trip time to increase.

[0061] By measuring the round-trip time and setting a modified congestion window size that is larger when the round-trip time is short and smaller when the round-trip time is long, a flow can take advantage of the situation when the network buffer is relatively empty. That is, when the round-trip time is low, by setting a larger congestion window size, the transmission rate can be effectively increased. As the network buffer fills up and the round-trip time increases, a smaller congestion window is used, thereby reducing the transmission rate.

[0062] Controlling the congestion window size in this way results in a smaller decrease in network buffer filling after a packet loss event compared to when all flows are regular TCP flows. This is because the modified TCP flow, based on the observed reduced round-trip time, increases its transmission rate as soon as it infers a decrease in network buffer filling. The resulting higher than normal average network buffer filling leads to an increase in the average round-trip time, which in turn leads to an increase in the time between buffer overflow events, which means a low average packet loss rate among all contending flows. And by having a smaller congestion window size at the time of overflow, the modified TCP flow is less likely to suffer packet losses compared to other contending flows.

[0063] Figure 6 Shows the round-trip time (RTT) 604, buffer filling 602, TCP New Reno congestion window size (TCP CWND) 600, and the congestion window size 606 of a contending flow using a modified congestion window control (RTT Aware CWND) for a 30-second portion of a nearly 20-minute transmission through the same network configuration as Figure 4 where the contending flow is adjusting its congestion window size based on the measured round-trip time.

[0064] The parameters of the simulation were again set using an iterative process so that the TCP New Reno flow and the contending TCP flow using the modified congestion window achieved approximately the same throughput. The TCP New Reno flow suffered 1141 packet losses per million packets sent, while the TCP flow using the modified congestion window suffered 735 packet losses per million packets transmitted.

[0065] Thus, instead of keeping the congestion window size constant, but rather adjusting the congestion window size according to the value of the measured round-trip time, the TCP flow not only achieves lower packet losses for itself, but also achieves lower packet losses for contending standard TCP flows.

[0066] The congestion window size of a TCP flow that knows the round-trip time can be beneficially set by any of the following methods: setting a relatively large value of the congestion window size when the round-trip time is relatively short and setting a relatively small value of the congestion window size when the round-trip time is relatively long.

[0067] InFigure 6 In the example illustrated in [example reference], the congestion window size of the modified TCP flow is determined using Equation (1) below based on the relative value of the measured round-trip time (RTT) between the minimum RTT and the maximum RTT min and linearly interpolated between the minimum congestion window size (CWND) and the maximum CWND as follows: max the relative RTT between the minimum and maximum measured round-trip times current between the minimum CWND min and the maximum CWND max is used to set the congestion window size by linear interpolation:

[0068]

[0069] In simulations, it has been found through an iterative method that a range of 16 packets for the congestion window size gives good performance, and the range should be from a minimum of 43 packets to a maximum of 59 packets to achieve a throughput approximately equal to that of a contending TCP New Reno flow. The values of the minimum and maximum round-trip times (RTT) are set using the iterative method such that the set values are approximately equal to the subsequently measured values. min and the maximum round-trip time value RTT max are set using an iterative method to make the set values approximately equal to the subsequently measured values.

[0070] It has been observed that, as described above, by setting the congestion window based on the round-trip time, the total number of dropped packets can be reduced in the network configuration described above. The amount of dropped packets that can be reduced depends on the range allowed for the modified congestion window to change. As the range increases to an optimal amount, the reduction in dropped packets increases, and as the range is further increased within this range, the reduction in dropped packets decreases. In the simulations of the network configuration described above, when the modified congestion window size is allowed to change between 45 packets and 53 packets (approximately + / - 8% around the average), a 6% reduction in dropped packets has been observed. When the modified congestion window size can change between 43 packets and 59 packets (approximately + / - 17% around the average), a 12% reduction in dropped packets has been observed, while for larger ranges over which the modified congestion window size can change, a smaller amount of reduction has been observed.

[0071] As the range over which the modified congestion window size is allowed to change increases, the average buffer level increases, i.e., after a set of packet drop events, the buffer does not drop much because as soon as a decrease in the round-trip time due to a decrease in the buffer level is detected, the congestion window size increases accordingly. A higher average buffer level results in a longer average round-trip time, meaning that, on average, it takes longer for a packet to pass through the buffer. As the TCP New Reno congestion window grows over time to the extent that buffer overflow depends on the round-trip time, this results in an increase in the time between sets of packet drop events because the congestion window size increases by one packet per round-trip time

[0072] However, since the fair share of the bandwidth remains the same (the same bottleneck bandwidth being shared by the same two flows), the increased average round-trip time results in a need for an increased average congestion window size to achieve the same bandwidth fair share. Thus, as the range over which the congestion window size can change increases, for a flow contending with a TCP New Reno flow, the center point of that range must increase to achieve the higher average congestion window size required to maintain the same average network throughput.

[0073] Accordingly, an iterative method involving the following is preferably used to select the parameters for changing the congestion window size (as given in the above equation): measure the throughput achieved with a given set of parameters, measure the average congestion window size used, and measure the minimum and maximum round-trip times. Below, this method will be described in more detail with reference to Figure 3 the flowchart shown.

[0074] Figure 3 FIG. is a flowchart outlining the steps of an example of the present invention, in which a modified congestion window is used to deliver data from a server to a client. In this example, the data is media content (such as a video segment) delivered as part of a streaming session, but the present invention can be applied to other types of data, such as file downloads.

[0075] The steps of the example will be described with reference to a content segment referred to as the "first segment". This first segment need not be the first segment in the streaming session between the server and the client and can refer to any segment being transmitted as part of the streaming session. A segment can include one or more contiguous parts, and the example of the present invention describes a method of adjusting the congestion response after a portion of each segment of a media sequence has been delivered to deliver the segment within a specified time interval, where a portion can be a single packet or multiple packets.

[0076] In step 300, client 108 requests media content by sending a request to data server 104. This content request can be an HTTP request, for example, an HTTP GET request. The requested content is composed of multiple segments, each of which includes multiple data packets, as described above. A request can be issued for each segment of the media content.

[0077] In response to receiving the request, in step 302, the data server 104 begins to deliver the requested content. Packets are sent continuously from the data server 104 starting from the initial part or the first part of the first fragment. The client 108 can send an acknowledgment packet back to the server via the network 106 for each received packet. The acknowledgment packet can be used by the delivery monitoring unit 218 in the data server 104 to determine the round-trip time associated with the delivery of the corresponding packet. In this example where the content is media content, once the client 108 receives sufficient content, it can start decoding and playing the content.

[0078] In this example, each content fragment has an associated time interval ΔT for delivering fragment n to the client 108 via the network 106. n The applicant's international application WO2014 / 155031 describes TCP congestion control, where the TCP congestion window is controlled during the delivery of data fragments to ensure that the data fragment is delivered within a specified time interval, and where packet loss is monitored during delivery, and where the packet loss measured during the delivery of one or more previous fragments is used to calculate the constraint on the congestion window to be used for delivering the next data fragment.

[0079] For example, for a content streaming application, the specified time interval can be set to a relatively short time, in which case it is necessary to deliver the content within a certain time to prevent playback pauses. Conversely, for a file download, if the user does not urgently need the file, the specified time interval can be set to a relatively long time.

[0080] The time interval for delivering content fragments to the client 108 via the network 106 can be specified by the client. For example, the client can append a request to the server indicating the time at which it wishes to have the fragment delivered. Alternatively, the time interval for delivery can be specified by the server 104. The server can specify the time interval for delivery based on considerations such as delivering the content as a whole to the client 108 in a timely manner with minimum delay. This type of content delivery, where the server specifies the time interval for delivering content fragments, can be referred to as HTTP push, where the server 104 is said to implement the HTTP push mechanism.

[0081] Returning to step 302, any conventional implementation of TCP can be used to control the delivery of the first part of the fragment, which can include a phase called slow start, where two packets can be sent for each received acknowledgment packet; and can include other phases such as congestion avoidance, where the congestion window increases during periods when no packet loss occurs; but some other initial startup processes can also be used.

[0082] Next, in step 304, during the delivery of the first part, the data server 104 uses the acknowledgment packets received from the client 108 to measure the round-trip time (RTT) associated with the delivery of each data packet.

[0083] Then, in step 306, the data server checks to see if all of the requested data has been delivered. If all of the data has been delivered, the process ends in step 322. If not all of the data has been delivered, the process proceeds to step 308.

[0084] Then, in step 308, the data server 104 uses the RTT measured in step 304 (or from step 322 if available) to determine the following RTTs: the RTT associated with the most recently delivered data packet, RTT current ; the average RTT, RTT central ; the low RTT, RTT low ; and the high RTT, RTT high . The RTT current is the RTT associated with the most recently successfully delivered data packet, which is the most recent data packet in the segment for which an acknowledgment packet has been received. The RTT central can be determined as the average RTT or mean RTT of all the RTTs measured in step 304, the median of the RTTs, or a specified fraction (such as, the midpoint) between the RTT low and the RTT high . The RTT low can be determined as the minimum of all the RTTs from step 304, and the RTT high is the maximum of all the RTTs according to step 304.

[0085] Then, in step 310, the data server 104 determines the amount D remaining of the remaining undelivered data in the segment, d and the available time ΔT d for delivering this remaining data. Note that ΔT n is actually equal to ΔT

[0086] minus the time elapsed since the start of the delivery in step 302. req In step 312, the delivery rate R remaining required to ensure the delivery of the content data segment by the deadline is calculated according to the following equation (2) based on the amount D d of the remaining data to be delivered within the content data segment and the remaining time interval ΔT.

[0087]

[0088] In step 314, the data server 104 calculates the required congestion window size CWND req , where CWND req is to use R req and RTT central In the remaining time interval ΔT d Deliver the remaining data within D remaining The required fixed congestion window size (see above) Figure 5 Required congestion window size CWND req It is calculated according to the following formula (3):

[0089] CWND req =R req ×RTT central (3)

[0090] However, as described above, it is beneficial to adjust the congestion window based on the measured round trip time rather than keeping the congestion window constant. Therefore, the maximum congestion window CWND is set by the data server 104. max and minimum congestion window CWND min In this example, CWND max and CWND min Set relative to CWND req For example, you can use CWND max Set to CWND req 8% higher and can be CWND min Set to CWND req 8% lower. Other percentage offsets can be used, such as 17%. And the percentage offset does not need to be in CWND req Is centrally symmetrical.

[0091] Then, in step 318, the data server 104 uses equation (1) to calculate the minimum RTT value. min and maximum RTT max Measured round trip time RTT current To calculate the CWND min With CWND max The modified congestion window size CWND is linearly interpolated between modified .

[0092] Therefore, using the above method, as the round trip time of the delivered packets increases or decreases, the modified congestion window size also changes according to equation (1).

[0093] Once the CWND has been calculated modified, that is, in step 320, the CWND is sent through the data server 104 modified for further data for delivering the remaining part of the segment, and in step 322, the data server 104 uses the acknowledgment packets received from the client 108 to measure the RTT associated with the delivery of each data packet of the further data.

[0094] The process then returns to step 306, where the data server checks to determine whether all the data requested by the client 108 has been delivered. If not all the data has been delivered, the updated modified congestion window is calculated using the data delivered so far (including the new RTT from step 322) for calculating the revised parameters in steps 308 to 318, and then the updated modified congestion window is used to deliver further data in step 320, etc., until all the data has been delivered.

[0095] The above example has been described with reference to the modified TCP protocol, but those skilled in the art should realize that the present invention can equally be used to modify other delivery protocols, such as QUIC.

[0096] The above example has been described in the context of a server delivering segments of media content to a client over a network. The server can be, for example, a source server, a content delivery network (CDN) node, or a residential gateway device. More generally, the functions of the server described herein can be implemented by a suitably configured transmitter for delivering media content over a network. The client can be an HTTP adaptive bitrate streaming client. The client can be adapted to support MPEG DASH, HLS, SmoothStreaming, or some other adaptive bitrate streaming protocol. More generally, the client can be any suitably configured receiver for receiving media content over a network.

[0097] In general, any of the functions, methods, techniques, or components described above for the components of a communication system can be implemented in software, firmware, hardware (e.g., fixed logic circuitry), or any combination thereof. The terms "unit", "detector", and "calculator" as used herein can generally represent software, firmware, hardware, or any combination thereof. In the case of a software implementation, the unit, detector, and calculator represent computer program code or computer-readable instructions that, when executed on a processor, perform a specified task. The algorithms and methods described herein can be executed by one or more processors that execute code that causes the processor to execute the algorithms / methods. The computer program code can be stored on a non-transitory computer-readable storage medium. Examples of computer-readable storage media include: random access memory (RAM), read-only memory (ROM), optical discs, flash memory, hard disk memory, and other memory devices that can use magnetic, optical, and other technologies to store instructions or other data and that can be accessed by a machine.

[0098] The applicant hereby individually discloses each of the individual features described herein and any combination of two or more such features to the extent that such features or combination can be carried out based on the common general knowledge of a person skilled in the art and based on the present specification as a whole, regardless of whether such features or combination of features solve any of the problems disclosed herein, and without limiting the scope of the claims. The applicant represents that various aspects of the present invention can be constituted by any such individual feature or combination of features. From the foregoing description, it will be apparent to a person skilled in the art that various modifications can be made within the scope of the present invention.

Claims

1. A method for delivering content from a server to a client over a network, the content including a plurality of time segments having associated times that can be used for delivery, and each time segment including a plurality of data packets, the method comprising the following steps: a) Delivering a first portion of the segment from the server to the client; b) Measuring a plurality of round-trip times associated with delivering at least the first portion; c) Determining a current round-trip time, a central round-trip time, a low round-trip time, and a high round-trip time based on the plurality of round-trip times, wherein the central round-trip time is determined as the average round-trip time or mean round-trip time of all measured round-trip times, the median of the plurality of round-trip times, or a specified fraction between the low round-trip time and the high round-trip time; d) Calculating a required congestion window size for delivering the remaining data in the segment within the time available for delivering the remaining data in the segment, wherein the required congestion window size depends on the central round-trip time and the delivery rate required to ensure delivery of the segment before a deadline; e) Calculating a modified congestion window size, wherein the modified congestion window size falls between a minimum congestion window size and a maximum congestion window size, the minimum congestion window size and the maximum congestion window size being set as percentage offsets from the required congestion window size, the modified congestion window size being relatively large when the current round-trip time is close to the low round-trip time and relatively small when the current round-trip time is close to the high round-trip time; f) Using the modified congestion window size to deliver further data from the remaining portion of the segment from the server to the client; g) Measuring a plurality of round-trip times associated with delivering the further data from the remaining portion of the segment; and h) Repeating steps c) to f) at least using the plurality of round-trip times from step g).

2. The method according to claim 1, wherein The current round-trip time is the round-trip time associated with delivering the most recent packet.

3. The method according to claim 1, wherein, The low round-trip time is the minimum of the measured round-trip times, and the high round-trip time is the maximum of the measured round-trip times.

4. The method according to claim 1, wherein The modified congestion window size CWND modified is given by: where CWND min is the minimum congestion window size, CWND max is the maximum congestion window size, RTT high is the high round-trip time, RTT low is the low round-trip time, and RTT current is the current round-trip time.

5. A server for delivering content to a client over a network, the functionality of the server being implemented by a transmitter configured to deliver media content over the network, the content including a plurality of time segments having associated times that can be used for delivery, and each time segment including a plurality of data packets, the server being adapted in operation to: a) Delivering a first portion of the segment from the server to the client; b) Measuring a plurality of round-trip times associated with delivering at least the first portion; c) Determine a current round-trip time, a center round-trip time, a low round-trip time, and a high round-trip time according to the plurality of round-trip times, wherein, The central round-trip time is determined as the average round-trip time or mean round-trip time of all measured round-trip times, the median of the plurality of round-trip times, or a specified fraction between the low round-trip time and the high round-trip time; d) Calculate the required congestion window size needed to deliver the remaining data in the segment within the time capable of delivering the remaining data in the segment, wherein the required congestion window size depends on the round-trip time to the center and the delivery rate required to ensure that the segment is delivered before the deadline; e) Calculate a modified congestion window size, wherein the modified congestion window size falls between a minimum congestion window size and a maximum congestion window size, the minimum congestion window size and the maximum congestion window size are set as percentage offsets from the required congestion window size, the modified congestion window size is relatively large when the current round-trip time is close to the low round-trip time, and the modified congestion window size is relatively small when the current round-trip time is close to the high round-trip time; f) Use the modified congestion window size to deliver further data from the remaining portion of the segment from the server to the client; g) Measure a plurality of round-trip times associated with delivering further data from the remaining portion of the segment; and h) Repeat steps c) to f) at least using the plurality of round-trip times from step g).

Images