1 Introduction
-
Congestion events: video packets sent from the server to the client pass through many network devices. Each device has one or many queues that use a queuing discipline to schedule network packets. The implemented algorithm decides whether to route or drop incoming packets in order to avoid network congestion. The main bottleneck occurs near the home gateway, and more precisely, in the link between DSLAM and home gateway [12]. In fact, the DSLAM may considerably reduce the bandwidth offered to the home network, and it is more likely to drop packets than any other network device. To minimize network effects on the delivery, the TCP protocol implements a “congestion control algorithm” on the sender side, which reduces the bitrate of packets sent to the receiver when a packet is lost. However, this bitrate reduction may degrade QoE. In addition, there are many congestion control variants with different methods of managing the congestion window size, cwnd, and detecting congestion events. These differences may change the QoE between variants.
-
Concurrence with other streams—OFF periods issue: the HAS player estimates the available bandwidth by computing the download bitrate for each chunk when it has finished downloading; this is done by dividing the chunk size by its download duration. As a consequence, the player cannot estimate the available bandwidth during OFF periods, because no data are being received. When a HAS stream concurs with other streams in the same home network, accurate bandwidth estimation becomes more difficult. For example, when two HAS streams are competing for bandwidth and the ON period of the first player coincides with the OFF period of the second player, the first player will overestimate its available bandwidth. This overestimation may lead the player to select a higher quality level for the next chunk. This selection may lead to a congestion event and a resulting fluctuation of quality levels between the two players. Research has demonstrated that traffic shaping can considerably limit this problem [1, 2, 11, 21, 25]. Traffic shaping consists of selecting a target bitrate for each HAS session in the home network based on bitrates of the available quality levels and the available bandwidth. It then shapes the outgoing traffic to each HAS client based on the selected target bitrate.
2 Background and related work
2.1 TCP congestion control variants
-
NewReno [3]: this variant is designed as the standard TCP congestion control approach. It uses the AIMD approach with the loss-based mode. Two mechanisms are employed immediately following congestion detection: fast retransmit and fast recovery [14]. Fast retransmit consists of performing a retransmission of what appears to be the missing packet (i.e., when receiving three duplicate ACKs), without waiting for the retransmission timer to expire. After the fast retransmit algorithm sends this packet, the fast recovery algorithm governs the transmission of new data until a non-duplicate ACK arrives. The reason for using fast recovery is to allow the continual sending of packets when the receiver is still receiving packets, even if some packets are lost.
-
Vegas [4]: this non-AIMD variant is an Additive Increase Additive Decrease (AIAD) variant. It is a delay-based variant that accurately estimates RTT for every sent packet and adjusts cwnd size based on actual throughput and expected throughput. If RTT increases, cwnd decreases by one MSS, and vice versa. Vegas is the smoothest TCP congestion control variant [15]; it is able to allocate a fair share of bandwidth with minimal packet loss events.
-
Illinois [5]: This is a TCP loss-delay-based congestion variant that employs a particular classification of the AIMD approach, C-AIMD, which involves a concave window size curve. Packet loss is used for primary congestion inference to determine the direction (increase or decrease) of cwnd, with a delay for secondary congestion inference to adjust the value of the window size change. More precisely, when the average queueing delay is small (small increase of RTT), the sender supposes that the congestion is not imminent and specifies a large additive increase α and small multiplicative decrease β. In the opposite case, when the average queuing delay is large (large increase of RTT), the sender supposes that the congestion is imminent and selects a small α and large β. Illinois measures RTT for each received ACK to update α and β. Moreover, it retains the same fast recovery and fast retransmit phases as NewReno. Illinois was designed for high-speed and high-latency networks, where the bandwidth-delay product is relatively high. Consequently, it enables higher throughput than NewReno.
-
Cubic [6]: this variant is loss-based, but it uses a non-AIMD approach. A cubic function is used to increase the cwnd in the congestion avoidance phase immediately after the fast recovery phase, and a multiplicative decrease approach is used to update the cwnd after congestion event detection. The cubic function has a concave region followed by a convex region. The plateau between the two regions, or the inflection point (denoted by W max), corresponds to the window size just before the last congestion event. The cubic function enables a slow growth around W max to enhance the stability of the bandwidth, and enables a fast growth away from W max to improve scalability of the protocol. Upon receiving an ACK during the congestion avoidance phase at time t, Cubic computes the new value of cwnd corresponding to the cubic function at time t. As a consequence, Cubic uses the time instead of the RTT to increase the cwnd. Cubic employs a new slow-start algorithm called HyStart [8] (hybrid slow start), which finds a safe exit point to the slow start, the ssthresh value, at which the slow start can finish and safely move to congestion avoidance before cwnd overshoot occurs. HyStart employs the RTT delay increase and the inter-arrival time between consecutive ACKs to identify the safe exit point, and to modify the ssthresh value [8]. This variant does not make any change to the fast recovery and fast retransmit of standard NewReno. Cubic is the smoothest loss-based congestion control variant [15]: it is characterized by a congestion window that falls less abruptly and that remains constant over a wide range of elapsed time. It is also designed for high-speed and high-latency networks. Cubic is implemented and used by default in Linux kernels since version 2.6.19.
-
Congestion events: there are two cases
-
When a congestion event is detected, the Fast Recovery/Fast Retransmit (FR/FR) phase reduces the ssthresh value and sets the cwnd value to ssthresh+3, for the purpose of remaining in the congestion avoidance phase. The ssthresh value after a congestion event is updated as follows:
-
When the retransmission timeout expires before receiving any ACK of the retransmitted packet, ssthresh is reduced as indicated in Algorithm 1, and cwnd is set to a small value and restarts from the slow start phase.
-
-
Idle period: when the server sends a packet after an idle period that exceeds the retransmission timeout (RTO), cwnd and ssthresh are computed for the four congestion control variants as in Algorithm 2:
2.2 Traffic-shaping methods
-
The client-based solution involves only the HAS client in order to reduce its OFF period durations. One of the recent client-based methods is proposed in the FESTIVE method [7]. It randomizes the events of chunk requests inside the player in order to reduce the periodicity of ON periods. Consequently, most of the incorrect estimations of bandwidth could be avoided when several HAS clients compete for bandwidth. However, this method is not efficient enough to prevent all incorrect estimations. In addition, it modifies the HAS player implementation, which is contradictory to our specifications described in Sect. 1. Moreover, the client-based solution does not provide the coordination between HAS clients that is required to further improve bandwidth estimations and QoE.
-
The server-based solution involves only the HAS server. It proceeds according to two steps: first, finding the optimal quality level for each provided HAS flow, and second, shaping the sending rate of the HAS server according to the encoding rate of this level. In [25], the authors propose a server-based method: it consists in detecting the oscillations between quality levels on the server side and deciding which optimal quality level must be selected. Although this method improves the QoE, it cannot conveniently respond to the typical use cases of several concurrent HAS clients that do not share the same HAS server: the shared link is on the HAS client side. Moreover, this server-based solution requires an additional processing task, which becomes burdensome and costly when many HAS clients are demanding video contents from the same HAS server. In addition, the server-based solution is unable to acquire information about the other competing flows with their corresponding HAS clients. Hence, the selection of the optimal quality level at the server is a vague estimation. This estimation is less accurate than a quality level selection based on a sufficient knowledge about the access network of the corresponding HAS client(s).
-
The gateway-based solution that consists of applying the HAS traffic shaping in the gateway is more convenient than client-based and server-based solutions; in fact, the gateway can acquire information about the HAS traffic of all clients of the same home network, which is not possible either at the server or at the client. In addition, the gateway-based solution is able to perform traffic shaping without inducing any modification of HAS implementation code either in the server or the client. Hence, in this paper, our evaluations only consider the gateway-based shaping solution. For the gateway-based solution, the authors assumed that the home gateway can intercept the manifest file during the HAS session initialization and can obtain the characteristics of the available video quality levels of every session. This solution introduces a bandwidth manager in the gateway that defines a shaping rate for each connected active HAS client in the home network. The bandwidth manager should be able to update the number of active connected HAS clients in the home gateway by sniffing the SYN and FIN flags in TCP packets. Therefore, the difference between the gateway-based methods is the manner in which they shape the bandwidth for each HAS session. The two main gateway-based methods found in the literature and used in our comparative study are HTBM [1] and RWTM [2]. They are briefly described in the following.
2.2.1 HTBM
2.2.2 RWTM
3 Methodology and experimental implementation
3.1 Performance metrics
Parameter | Description |
---|---|
I
| Discrete time index |
L
C
(i)
| Video quality level index of client C at time i
|
L
C,opt
(i) | Theoretical optimal value of L
C(i) |
Q
C
(i)
| Video encoding bitrate of client C at time i
|
3.1.1 Video quality-level stability
3.1.2 Fidelity to optimal quality level
3.1.3 Convergence speed
3.1.4 Congestion rate
3.1.5 Frequency of OFF* periods per chunk
3.2 Scenarios
3.3 General framework
3.3.1 HAS clients
3.3.2 Home network
3.3.3 Home gateway
3.3.4 Best effort network
3.3.5 HAS server
4 Results
4.1 Scenario 1
4.1.1 Measurements of performance metrics
Performance metric | Shaping method | TCP congestion control variant | |||
---|---|---|---|---|---|
NewReno | Vegas | Illinois | Cubic | ||
Instability (%) IS1(180) | W/o* | 4.95 | 2.15 | 8.35 | 7.47 |
HTBM | 1.89 | 1.08 | 1.56 | 1.86 | |
RWTM | 1.69 | 4.10 | 1.88 | 1.63 | |
Infidelity (%) IF1(180) | W/o | 41.33 | 52.31 | 74.14 | 50.46 |
HTBM | 49.57 | 47.81 | 7.75 | 20.45 | |
RWTM | 45.87 | 32.24 | 6.17 | 5.02 | |
Convergence speed (s)
V1,60(180) | W/o | 100.93 | 102.11 | 174.13 | 145.03 |
HTBM | 101.83 | 87.11 | 21.10 | 52.06 | |
RWTM | 94.51 | 104.00 | 24.22 | 19.55 |
Performance metrics | Shaping methods | TCP congestion control variants | |||
---|---|---|---|---|---|
NewReno | Vegas | Illinois | Cubic | ||
Instability (%) IS2(180) | W/o | 5.82 | 3.06 | 7.85 | 5.82 |
HTBM | 1.17 | 0.95 | 1.05 | 1.15 | |
RWTM | 1.09 | 0.95 | 1.03 | 1.13 | |
Infidelity (%) IF2(180) | W/o | 26.64 | 70.77 | 39.27 | 36.33 |
HTBM | 4.72 | 3.62 | 4.21 | 4.47 | |
RWTM | 2.49 | 2.30 | 2.47 | 2.61 | |
Convergence speed (s)
V
2,60(180) | W/o | 96.25 | 137.01 | 126.33 | 92.81 |
HTBM | 12.41 | 6.95 | 9.73 | 13.26 | |
RWTM | 6.73 | 5.03 | 6.54 | 8.95 |
-
Combining NewReno or Vegas variants with HTBM or RWTM does not improve the QoE. Additionally, these four combinations have high infidelity value (near 50 %) and very high congestion speed value (around 90–100 ms), but a low value of instability. These values indicate that the player was stable at a low quality level during the first half of the test duration and has difficulties converging to its optimal quality level.
-
HTBM has better QoE with Illinois than with Cubic: it is slightly more stable, 16 % more faithful to optimal quality, and converges 2.4 times faster.
-
RWTM has better QoE with Cubic than with Illinois: it is slightly more stable, slightly more faithful to optimal quality level, and converges 1.24 times faster.
Metric | Shaping method | TCP congestion control variant | |||
---|---|---|---|---|---|
NewReno | Vegas | Illinois | Cubic | ||
CNG
| W/o | 46.13 | 43.00 | 66.11 | 85.65 |
HTBM | 44.06 | 40.50 | 58.68 | 191.72 | |
RWTM | 0.10 | 8.26 | 0.76 | 1.11 | |
fr
OFF*
| W/o | 0.42 | 0.35 | 0.27 | 0.40 |
HTBM | 0.31 | 0.32 | 0.06 | 0.16 | |
RWTM | 0.32 | 0.41 | 0.24 | 0.24 |
-
HTBM was designed to delay incoming packets, which causes an additional queuing delay. In all of the tests, we verified that HTBM induces a queueing delay of around 100 ms in scenario 1 for client 1. On one hand, this delay causes an increase of congestion rate because it increases the risks of queue overflow in the gateway, even when the QoE is good, such as with Cubic or Illinois variants. The dissimilarity of congestion rate between congestion controls variants is investigated in the next Sect. 4.1.2. On the other hand, the RTT C–S value also jumps from 100 to 200 ms, which increases the retransmission timeout value, RTO, to approximately 400 ms, hence reducing OFF* periods. The fr OFF* of HTBM is noticeably lower than RWTM and the case without shaping (W/o). In addition, the assertion “the higher the QoE metric measurement, the lower the fr OFF* value” seems to be valid; for example, HTBM presents better QoE with Illinois than with Cubic, and fr OFF* is lower with Illinois than with Cubic.
-
Nevertheless, RWTM was designed to limit the value of the receiver’s advertised window, rwnd, of each client. Therefore, no additional queuing delay is induced by RWTM. Hence, the congestion rate is very low. Additionally, the RTT C–S estimation is performed only once per chunk. So, the cwnd value is constant during the ON period, even if RTT C–S varies. In our configuration, the standard deviation of RTT C–S is equal to 7 ms, i.e., 0.07.a C–S , as described in Sect. 3.3. Consequently, eliminating OFF* periods will not be possible. Instead, the fr OFF* value will be bounded to a minimum value that characterizes RWTM when the QoE measurements are the most favorable. When testing with the four congestion control variants, this fr OFF* value is equal to 0.24 for the selected standard deviation. This means that RWTM can guarantee, in the best case, one OFF* period every 4.17 chunks. This frequency is useful, and will be discussed in the next subsection and in further detail in scenario 5.
4.1.2 Analysis of cwnd variation
4.2 Scenarios 2 and 3
TCP variant | Scenario | Performance metric | |||||
---|---|---|---|---|---|---|---|
Instability (%) | Infidelity (%) | Convergence speed (s) | |||||
HTBM | RWTM | HTBM | RWTM | HTBM | RWTM | ||
Cubic | 1 | 1.86 | 1.63 | 20.45 | 5.02 | 52.06 | 19.55 |
2 | 3.44 | 1.43 | 32.90 | 3.42 | 64.13 | 10.98 | |
3 | 2.19 | 1.63 | 18.49 | 4.81 | 34.65 | 14.34 | |
MV* | 2.49 | 1.56 | 23.95 | 4.42 | 50.28 | 14.96 | |
Illinois | 1 | 1.56 | 1.88 | 7.75 | 6.17 | 21.10 | 24.22 |
2 | 3.20 | 1.56 | 29.75 | 4.42 | 59.58 | 13.28 | |
3 | 1.85 | 1.76 | 7.92 | 5.66 | 21.03 | 18.80 | |
MV | 2.20 | 1.73 | 15.14 | 5.42 | 33.90 | 18.56 |
Metric | Scenario | Cubic | Illinois | ||
---|---|---|---|---|---|
HTBM | RWTM | HTBM | RWTM | ||
CNG
| 1 | 191.72 | 1.11 | 58.68 | 0.76 |
2 | 375.62 | 0.82 | 33.11 | 0.68 | |
3 | 173.48 | 0.66 | 56.27 | 0.76 | |
MV | 246.92 | 0.86 | 49.35 | 0.73 | |
fr
OFF*
| 1 | 0.16 | 0.24 | 0.06 | 0.24 |
2 | 0.23 | 0.24 | 0.21 | 0.24 | |
3 | 0.13 | 0.26 | 0.05 | 0.26 | |
MV | 0.17 | 0.25 | 0.10 | 0.25 |
4.3 Scenario 4
TCP variant | Scenario | Performance metric | |||||
---|---|---|---|---|---|---|---|
Instability (%) | Infidelity (%) | Convergence speed (s) | |||||
HTBM | RWTM | HTBM | RWTM | HTBM | RWTM | ||
Cubic | WLa
| 1.08 | 1.07 | 3.71 | 1.79 | 7.61 | 4.10 |
4 | 4.86 | 6.40 | 48.2 | 46.14 | 120.3 | 129.3 | |
Illinois | WL | 1.08 | 1.07 | 2.23 | 1.66 | 5.37 | 4.01 |
4 | 2.7 | 2.92 | 15.6 | 17.81 | 35.48 | 42.75 |
Metric | Scenario | Cubic | Illinois | ||
---|---|---|---|---|---|
HTBM | RWTM | HTBM | RWTM | ||
CNG
| WL | 34.2 | 0.98 | 38.51 | 0.79 |
4 | 216.19 | 120.36 | 146.68 | 143.54 | |
fr
OFF*
| WL | 0.03 | 0.36 | 0.03 | 0.43 |
4 | 0.40 | 0.41 | 0.09 | 0.31 |
-
The lowest QoE metric measurements are recorded for the Cubic variant for both shaping methods: their instability is around 5–6 %, their infidelity is near 50 %, and their convergence speed is approximately 125 ms. We also notice that the congestion rate, CNG, is very high, between 120 and 220, and the frequency fr OFF* is important around 0.4 (i.e., one OFF* period occurs for every 2.5 chunks, on average). We observe not only lower measurements, but also a higher degradation rate in performance: the gap of QoE metric measurements, CNG and fr OFF* , is clearly large between scenario WL and scenario 4. Accordingly, Cubic is not suitable as a TCP congestion control variant of the HAS server for both shaping methods when heavy congestion occurs. This result can be verified by examining Figs. 8 and 9 in Sect. 4.1.2, where Cubic has difficulties with rapidly defining the suitable ssthresh value before convergence and after congestion, respectively.
-
The RWTM shaping method presents higher degradation in QoE metric measurements than HTBM when we compare scenario WL to scenario 4 for both TCP congestion variants, Cubic and Illinois. The cause is mainly related to the fact that HTBM is used to generate congestion events and maintain high QoE under normal circumstances, which is not the case with RWTM. Accordingly, we can say that RWTM is more sensitive to induced congestions than HTBM. This result can be verified when examining Figs. 7 and 9 in Sect. 4.1.2, in which a single congestion event instantaneously degrades performance.
-
The second-best combination is {Illinois RWTM}. Here, the QoE metric measurements are acceptable, but the degradation rate is higher than the best combination {Illinois HTBM}. This degradation indicates that {Illinois RWTM} cannot adequately resist against induced congestions, especially when we have a highly congested link between client and server. However, this combination could successfully be used with a link under less frequent congestions.
4.4 Scenario 5
5 Discussion
Scenario | Combination | |||
---|---|---|---|---|
RWTM | HTBM | |||
Cubic | Illinois | Cubic | Illinois | |
{1, 2, 3} | ++ | ++ | ± | + |
4 | – | + | – | ++ |
5 | + | ++ | ± | – |
-
{Cubic RWTM}: Unfortunately, it is very vulnerable to congestions and slightly sensitive to high RTT C–S variation.
-
{Illinois HTBM}: It has the advantage of being robust against heavy congestions. However, it is very sensitive to RTT C–S variation. Furthermore, it causes a high rate of congestion in the gateway that could disturb other sessions in concurrence with HAS sessions.