Understanding the Intermittent Traffic Pattern ofHTTP Video Streaming over Wireless Networks

(Invited Paper)

Ibrahim Ben Mustafa, Mostafa Uddin, Tamer NadeemOld Dominion University

Email: {iben, muddin, nadeem}@cs.odu.edu

Abstract—We are experiencing huge growth of videostreaming traffic, which is creating big challenges forvideo providers in guaranteeing a satisfactory levelof viewing experience to end users. Furthermore, theincrease in video streaming demands on mobile devicesover dynamic wireless links is creating another obstacletoward providing a high quality video service. In orderto overcome most of these challenges, HTTPs adaptivevideo streaming technology was introduced, along withother great features for streaming videos. However, wefound that HTTPs adaptive protocol can still sufferunder certain situations and conditions. Mostly, theseissues are likely experienced when multiple concurrentplayers compete over the same bottleneck. Several stud-ies have proposed a network side solution at the homegateway or at the cloud aiming to assist the video playersto maximize the viewing experience to all users sharingthe same bottleneck. Although these proposed systemscould provide some enhancements to the video stream-ing, they are unable to provide fine-grained monitoringand understanding of the video traffic to apply desirelevel of dynamic resource management. Considering theabove issues, in this paper we conduct extensive analysisof the video traffic of YouTube; the most popular HTTPsadaptive video player. In our study, we argue thatthrough a deep understanding and careful analysis ofthe HTTPs video traffic, valuable information aboutthe competing streams can be obtained and could beutilized in developing a network based solution thatcan significantly improve the video QoE and assist thevideo players to perform much better.

I. INTRODUCTION

With the exponential proliferation of smartdevices(i.e., smartphone, tablet, smartTV etc.), and the growthof entertainment and multimedia application, we areexperiencing prominent increase in videos data trafficover wireless (i.e., WiFi and cellular) networks. As in-dicated by some studies, the amount of video traffic ofYouTube and Netflix alone comprise 50% of the totaltraffic in the peak hours [1]. Such increase of video

traffic is creating big challenges for video providers inguaranteeing a satisfactory level of viewing experienceto the end users. In addition to the huge increasein the resources required to serve more streamingdemands, the unstable nature of wireless links andthe frequent changes in network loads create anotherobstacle toward providing a high quality video service.

In order overcome most of the above challenges,HTTP adaptive video streaming technology was intro-duced, along with other great features for streamingvideos. When streaming videos over HTTP adaptiveprotocol, the video playing rate can be dynamicallyand seamlessly adjusted according to the change inthe network condition. Moreover, to prevent a possiblewaste in the device and network resources in case thatthe user does not watch the entire video, the videowith this protocol is periodically delivered in parts asthe user continues watching. Moreover, the video nowcan be cached and delivered from any conventionalHTTP web server and can easily traverse the NAT.As a result of these features, most of video providersnowadays such as YouTube, Netflix, and Vimeo havealready adapted this technology in streaming videos.

However, despite the aforementioned features,practical implementation, represented in today’s com-mercial players, reveals that viewing quality can stillsuffer with this protocol under certain situations andconditions. For instance, our measurements show thatYouTube app can suffer from several serious issuesthat would directly impact the QoE of the end userincluding instability in the perceived quality, a longstarting-up time, bandwidth underutilization, and un-fairness between the users. Mostly these issues arelikely experienced when multiple concurrent playerscompete over the same bottleneck due to the in-termittent traffic generated by streaming protocol asindicated by several studies [2], [3], [4].

Having multiple users concurrently streamingvideos through the same WiFi access point (at shop-ping center, coffee shop,..etc ), or the same basestation of cellular network is a very common scenario.Therefore, looking beyond an individual case, andmake the optimization global (over multiple concur-rent streams) is essential for an efficient streamingsolution. To this end, several studies have proposeda network side solution at the home gateway orat the cloud aiming to assist the video players tomaximize the viewing experience to all users sharingthe same bottleneck [5]. Although these proposedsystems could provide some enhancements to thevideo streaming, they are unable to provide fine-grained, scalable and dynamic resource managementpolicies. More specifically, they lack monitoring andunderstanding the video traffic to apply a desired levelof resource management. In addition, many of theseproposed systems work by intercepting the HTTPrequests and responses to collect information about thethe streamed videos. Unfortunately, such monitoring isno longer valid as most of video providers have beenswitching to HTTPS with the goal of preserving theirusers’ security and privacy. For instance, YouTubeand Vimeo have already encrypted their traffic, whileNetflix has announced to switch to HTTPs by the endof 2016 [6].

Considering the above issues, in this paper weconduct extensive analysis of the video traffic fromone of the most popular HTTP adaptive video playerto answer the following two questions: is there still away to assist and optimize the performance of thecommercial video players even with an encryptedtraffic? And, how this can we effectively assist thevideo players? In our studies, we argue that througha deep understanding and careful analysis of theHTTPs video traffic, valuable information about thecompeting streams can be obtained and utilized indeveloping a network based solution that can signif-icantly improve the video QoE and assist the videoplayers to perform much better.

II. OVERVIEW OF HTTP ADAPTIVE VIDEO

STREAMING

There are several HTTP streaming technologiesthat are being widely deployed by the industry in-cluding Apple HTTP live streaming (HLS), Microsoftsmooth streaming, Adobe HTTP Dynamic Stream-ing, and Dynamic Adaptive Streaming over HTTP(DASH). All these technologies follow nearly the

same principle where the original content is processedinto multiple bitrate profiles or versions, and thenthese versions are splitting into small segments, whereeach segment represents a short duration of playbacktime. These segments are made available for down-loading on a conventional HTTP web server alongwith a manifest file, which describes the availablebitrate profiles, the segments URLs, .etc, throughsending a HTTP get request. Prior to the streamingsession, the manifest file is typically provided to theclient, and according to the client device capabilitiesand current network condition, the client requests thebest segment version that fits its situation. Therefore,all the logic and decision is made by the videoplayer at the client side leaving the server to onlyresponding to the client requests. In this way, theclient can dynamically adapt to the change in thenetwork condition by adjusting the video bitrate tothe end-to-end available bandwidth, which can havea significant enhancement on the performance . Forinstance, the video player can request a lower profilewhen it encounters a major drop in the availablebandwidth to avoid possible stalls in the playback if itsticks with the same quality profile. One of the majorchallenges in designing the adaptive algorithm of thevideo players is the decision of requesting the segmentversion that maximizes the viewing experience. Infact, most of the work that have been done in theliterature tried to enhance the performance of videoplayers through designing a better adaptive algorithm.

Typically, HTTP video players have two mainstates: buffering state, in which the players tries tofill its buffer with video frames at the beginning ofthe streaming session, and steady state, in which theplayer starts periodically requesting video chunks afterthe buffer is filled up. The adaptive player typicallymaintains two thresholds, an upper and lower thresh-olds. The player pauses downloading video chunksas soon as the buffer filled and reached to the upperthreshold, and it resumes downloading once the bufferdrops to the lower threshold. Figure 1 illustrates thesetwo states in which the player starts buffering videochunks at the beginning of the streaming session, andwhen the buffer reaches its max threshold at time 70,the player goes off and enters the steady state. At time78, the player goes on again and send a chunk requestto the server when the buffer goes below the minimumthreshold. This behavior recur repeatedly until thevideo chunks are fully downloaded. These intermittenttraffic pattern (ON/OFF periods) introduces a major

0 20 40 60 80 100 120 140 160

5000

4000

3000

2000

1000

0

Buffering state

Time(seconds)

Kbp

s

Steady State

Fig. 1: Player state: buffering state and steady state.

challenge for competing video players to accuratelyestimate the available bandwidth. This pattern is theroot cause of the degradation in the video quality formost commercial video players in the market today,thus it is very important to consider this traffic patternin any future solution.

III. EXPERIMENT SETUP

In the experiment, we use a laptop as Wi-Fi AccessPoint (Wi-Fi AP) which is running Ubuntu OS. ThisWi-Fi AP is also connected to the internet usingethernet interface. In the Wi-Fi AP, we installed OpenvSwitch (OVS) [7] and added the wireless interface(wlan0) of AP as a port with the OVS bridge. Con-sequently, all the traffic coming or going to any of theconnected smartphones should pass through this OVS.In addition, we use Linux Traffic Control (tc) [8] ofthe Wi-Fi AP to control or limit the bandwidth of thevideo traffic. In the experiment setup, we have usedthree Android smartphones (two Samsung S5 and oneNexus 5) which are all connected with the Wi-Fi AP.In the experiment, we use iperf [9] to generate UDPtraffic as a background traffic. In our smartphones, wehave installed and used the latest version of YouTubeapp. This YouTube app comes with a “stats for nerdsoption that enable us to observe the quality requestedby each player in addition to the buffer status and theestimated throughput value.

IV. TRAFFIC AND PERFORMANCE ANALYSIS

In this section, we start analyzing real video trafficstreamed over HTTPs protocol for different networkconditions and scenarios. We divide our analysis intotwo main scenarios: non-competing scenarios, whereonly one video player is streaming, and competing

scenarios where two or more video players are com-peting for the bandwidth over the same bottleneck.

A. Non-Competing Scenario

In this scenario we capture and study the trafficpatterns generated by only one video player withoutany competition from other players in the wirelessnetwork. We use different videos encoded with differ-ent bit-rates and streamed from a regular http server.For the first experiment, we stream a video with 480pquality resolution which encoded at 650kbps (selectedmanually among different available resolutions) withdifferent bandwidth capacity to see its impact on thevideo traffic patterns. Note that, we use the tc toolin the Wi-Fi AP to control the available bandwidthof the video player running in smartphone. At thebeginning we allow the video player to stream at3200kbps, and then we reduce the bandwidth after 27seconds to 1200kbps for 30 seconds before reducingit again to 650kbps. As we observe from figure 2,the duration of OFF period at the steady state shrinksas the throughput rate drops and getting closer tothe video encoding rates till the OFF periods totallyvanish at the last 30 seconds. Therefore, there is astrong correlation between the length of the OFFperiod and the video streaming and encoding rates.The existence of the OFF periods clearly indicates thatthe playback of the current quality profile is utterlystable and the likelihood of experiencing degradationin the viewing quality (e.g, switching to lower qualityor stalling in the playback) is basically not possible aslong as there is no drop in the throughput. On the otherhand, the disappearance of the idle period of videostream as a result of a drop in the throughput mayindicate either the throughput is equal to (or lightlyabove the encoding rate), or below the encoding rate.In the former case, the video playback operation willnot be affected, while in the latter case, the videoplayback may or may not be affected depending onsome factors such as the drop level, buffer condition,and length of the video. Therefore, it is extremelyimportant for the performance to distinguish betweenthese two cases and determine whether the drop in thebandwidth would affect the playback rate.

One technique for distinguishing between the twocases mentioned above is to determine the videoaverage bitrate. Since the video traffic is encrypted,knowing the exact value of the video bitrate is not pos-sible. However, the estimated value would be obtainedif we can calculate the average chunk size and divide

Kb

ps

0 10 20 30 40 50 60 70 80 90 Time(second)

4000

3000

2000

1000

0

Fig. 2: ON/OFF periods correlation with streamingand encoding rates.

it by the average duration of ON and OFF periods.In fact, this becomes quite possible with some newtools and technologies such as OpenvSwitch that allowfor collecting statistical information about the trafficflows in real time. For example, we see in figure 2 thatAt second 57 the throughput drops from 1200kbps toabout 650kbps which completely removes the OFFperiods from the traffic patterns. Now by dividing theaverage chunk size (800KB) by the average length ofboth ON and OFF periods (10 seconds), the estimatedbitrate will be 650kbps which is slightly above theactual value(600kbps). Therefore, the drop in thisexample can definitely affect the video traffic in longplay, and a well-designed assistant system should reactto prevent such possible degradation in the video viewquality through some techniques discussed in sectionV.

Having this situation, it will be more efficientto estimate the number of seconds in the buffer atthe time of the drop. This is very important forthe performance of the overall streaming system. Forinstance, if we know an estimated value of the videoencoding rate and know that the buffer has about xseconds of video frames at the time of the drop, thenthe system can infer when the buffer turns emptyand start harming the viewing quality. In case thedegradation can take long time, we can safely deferits intervention for quite long time waiting for thecondition to be inherently improved (e.g, wait for onestream to finish downloading a video). As a matterof fact, each streaming application has its own settingfor the buffer. For instance, our measurement revealsthat YouTube app on all smartphones uses a 20MBbuffer. This means that at the time of the drop, theplayer can continue playing the current quality forabout 20MB divide by the estimated video bitrate.Thus when the available bandwidth drops below the

0 30 60 90 120 150 180 210 240

Time(seconds)

Kbp

s

Re-buffering

1750

1500

1250

1000

750

500

250

0

360p 480p

Th

rou

gh

pu

t In

crea

se

Fig. 3: Increase in the bandwidth causes a change inthe traffic pattern.

encoding rate, we can have an estimated knowledgeabout when the player might switch the quality or besubjected to playback stalls.

We also identify another scenario that causes theidle periods to vanish. Figure 3 shows the intermittenttraffic pattern of a video player streaming video of400kbps bitrate (360p resolution)disappears for con-siderable period of time when the available bandwidthincreased from 900kbps to 1400kbps. As can be ob-served from the figure, the increase in the throughputhappen at second 30, and starting from second 68 theOFF periods are completely disappeared for nearly140 seconds (persistent pattern) before showing upagain at time 207. This could be interpreted as theplayer increases the quality and re-enters bufferingstate in which some of the low quality packets in thebuffer are replaced by high quality packets. This con-clusion can be confirmed by looking at the chunk sizebefore and after the buffering state. We can clearly seefrom figure 3 that the video chunks streamed after thepersistent period is much larger in size than the chunksstreamed before. This change in the average chunksize is a clear sign of an increase in video qualityas the chunks of a high quality profile typically havehigher bitrate and thus size than the lower quality.Note that the OFF periods can vanish with no changesin the throughput, which indicates the client mostlikely jumps to time offset in the video playback.

While switching to the higher quality video, theplayer flushes all the buffered video packets of lowerquality before starting to re-buffer higher qualityvideo. Thus frequent switch of video quality causesa significant waste of resources in mobile devices as

1500

1000

500

0

Kb

ps

0 5 10 15 20 25 30 35 40Time(second)

Fig. 4: The traffic pattern of high motion video.

1500

1000

500

0

Kb

ps

0 5 10 15 20 25 30 35 40Time(second)

Fig. 5: The traffic pattern of low motion video.

well as increases the overall load on the server. Inaddition, such losses of packets over cellular networkcan become expensive to the user.

In videos, we see mixture of slow and high motionclips such as sport games or action movie, where inother videos, we only see slow motion clips suchas news. Note that, the type of a motion clip ina video has direct impact on the video encodingrate. Similarly, the regularity of the ON/OFF periodalso depends on the variability of the video encodingrate. For example, in Figure 4, the first two chunksof the video is for high motion scenes, and havehigher encoding rates and data size compare to thefollowing two chunks with slower motion scenes.Thus the change between the high and slow motionclips changes the ON/OFF periods to have differentlength as in Figure 4. On the other hand, the videochunks represented in 5 have slow motion scenes withalmost the same encoding rates and date size. Thus,in this case, we observe no changes in the length ofON/OFF periods.

B. Competing Scenario

In this section, we start analyzing the video trafficin more realistic scenarios, where multiple devicesruns video streams with other concurrent flows inthe wireless network.Figure 6 shows the flows patternof two devices playing video streams over the same

3500

3000

2500

2000

1500

1000

500

0

Kb

ps

0 15 30 45 60 75 90 105 120 135 140Time(second)

Player APlayer B

Fig. 6: Two video Players compete for bandwidth overthe same bottleneck.

wireless AP. In order to ensure that both devices haveexactly the same flow characteristics, we place bothdevices at the same distance from the AP and makethe players requesting the same video. In addition, wegenerate background traffic in the wireless networkusing Iperf running on a third device to mimic real-life scenario and make the flows compete.

We start one player (player A), and after 30seconds we start the other player (player B), so atthe beginning the player A achieves high throughput,around 3200kbps, which enables high quality stream-ing profile. However, as soon as the competing flow ofplayer B shows up, the throughput temporally drops to1700kbps. Figure 6 shows an aggressive competitionbetween the two flows which results in an extremefluctuation in the throughput, as we can see, the playerA is clearly getting much higher throughput in averagethan the player B, which is experiencing a very lowthroughput. This unfairness in sharing the bandwidthcontinues for about two minutes before eventually andslowly converse to a fair state as a result of usingTCP as the transport protocol. This slow increase inthe throughput of player B has a terrible impact onthe QoE of the client. First, it forces player B torequest low quality for a considerable amount of time.Second, the slow increase in throughput makes playerB passes through all the quality levels before reachingto the final quality that fits with the fare portion of thebandwidth. This multiple switches cause player B toflush out most the packets from the buffer to replacethem with the higher quality with every increase inquality. This would cause re-requesting a huge portionof the video content which can be a very expensiveunder certain scenarios.

We also examine the effect of competition betweenthree players. We start running two players and after

Kb

ps

0 100 120 140 160 180 200 220 240 Time(second)

3000

2000

1000

0

Fig. 7: The flow of one player competing with twoother players in the wireless network.

Kb

ps

0 10 20 30 40 50 60 70 80 90 100 Time(second)

2500

2000

1500

1000

500

0

Player APlayer B

Fig. 8: The traffic pattern of two players streamingdifferent video bitrates while competing over the samebottleneck.

80 seconds we start the third player. For clarity, figure7 shows only the flow pattern of the third player.Similar to previous experiment, we see a slow increasein the throughput, and the third player also suffersfrom obtaining enough bandwidth to buffer its packetsand starts the playback for its first 40 seconds. Thisin fact create quite a start-up delay before starting theplayback. Under this circumstance, the user could getfrustrated, and decide not to stream video over thenetwork. Note that having a short start-up delay timeis one of the most important metrics for the QoE.Therefore, it is very necessary to have a mechanismthat insures a good performance for all players.

Figure 8 shows the impact of different video bi-trates on the flow competition between two players,player A and player B. We disable the Youtube autoquality selection on both players, and manually setthe quality levels at 720p (130kbps) for player A, and360p (55kbps)for player B. We start both players atthe same time under the same conditions (i.e., samevideo and same distance from Wi-Fi AP). Figure 8shows that player A with higher bitrate stream winsthe competition and dominates the bandwidth. This

Kb

ps

140 150 160 170 180 190Time(second)

2500

2000

1500

1000

500

0

Player A

Player B

Fig. 9: The impact of the wireless link condition onthroughput competition

explains, why player A in the first experiment hashigher throughput than player B which starts later.The reason is that when player A starts, it gets enoughthroughput to request high quality video, while playerB does not find much available bandwidth, thus endup requesting low quality video.

Typically, the wireless link conditions of differentdevices in the same network vary according to dif-ferent conditions such as their distances from the AP.Figure 9 shows the result of an experiment in whichwe use two devices with different link condition, atthe beginning, we start both players while placingboth devices close to the AP, and then we slowly startmoving one device away from the AP. As a result, theplayer of the moved-away device (player B) starts toobserve throughput reduction around time 170s, andplayer B also looses the competition against playerA which starts to experiencing higher throughput.Note that, in this case, we have two causes that arecontributing to the suffering of the video streamingflow: the link condition and the competition amongthe video streaming flows. Although, we have nocontrol on the former cause, but with smarter networkmanagement we can address the second cause to haveacceptable video streaming experience for all players.

To understand the impact of the intermittent trafficpattern of HTTPs adaptive streaming protocol on theQoE, we study and analyze the traffic pattern oftwo players at the steady state. Figure 10 shows thesmoothed throughput of these two players. Beforesecond 350, both players were stable and achievinggood throughputs, but after 350 second, we can ob-serve a drop in their throughput for about 100 secondsfollowed by a dramatic increase in the throughput ofplayer A and a major drop in throughput for playerB.

Kb

ps

300 350 400 450 500 550 600Time(second)

2500

2000

1500

1000

500

0

Player A

Player B

Fig. 10: The smoothed throughput averages of twovideo streams at steady state.

To understand why player B looses the competi-tion, Figure 11 zooms into the first 40 seconds of theprevious figure. This figure shows how both playerwere utilizing the off period of each other for thefirst 25 seconds, and because of a long OFF periodof player B (between second 315 and 325), player Aexperiences a huge increase in the bandwidth duringthat period. This increase in the throughput causesplayer A to switch to a higher quality profile andreentering buffering state, while player B looses itsidle periods. Therefore, we can infer that player Bwas relaying on the player A’s released bandwidth(at OFF periods) in maintaining the current qualitylevel. As a result, both players start fighting again forbandwidth causing their throughputs to go below theircurrent video bitrates. Consequently, their buffers startquickly draining, and because player A can slightlygain more bandwidth than player B in the competition,the buffer of player B get drained before player A.This causes player B to switch down three qualitylevel at one time (from 720p resolution, encoded at1200kbps, to 240p encoded at 400kbps as confirmedby examining the change in the player’s playbackresolution) in order to prevent stalls in the playback.This experiment highlights one main problem raisedfrom the intermittent traffic pattern of HTTP adaptiveplayers and confirms the need of a mechanism toenhance the performance.

V. DISCUSSION

In previous sections, we show how to analyze andobtain some useful information about the HTTP videoflows. In addition, we highlighted some performanceissues with commercial players regarding concurrentvideo stream over the shared wireless network. Asconfirmed by our experiments, most of these issuesare mainly caused by the aggressive competition be-

Kb

ps

305 315 325 335 345Time(second)

4000

3000

2000

1000

0

Player APlayer B

Fig. 11: The throughput competition of two flows atsteady state.

tween the players for the available network resources.Therefore, any future effort that aims to enhance theperformance of video players and the viewing qualityfor all clients, should concentrate on mitigating thiscompetition in such away that ensures the fairnessamong the player and, maximizes the utilization ofthe available bandwidth.

One possible technique, for instance, is to monitorand control the bandwidth utilized by each streamat the network edge. Each time a new stream joinsthe network, the system should instantly react andreallocate a fair portion of the bandwidth to the newstream. This technique might require reallocating thebandwidth, and distributing it again among all players.However, to avoid major degradation in the qualityof the existing (old) players, the system should beaware of the conditions and status of all players andthe characteristics of their flows before performingbandwidth reallocation. As we discussed in sectionIV A, the condition of the player can be estimatedfrom the characteristic of its flow, thus we can usethese in taking the bandwidth allocation decision.

Consider the scenario in figure 12, where two videostreams are in the steady state. Assume a new videostream joins in with the previous two video streams.In the Figure 12, it is clear from the length of the OFFperiod and the size of video chunks that the player B isstreaming at a much higher rate than its video averagebitrate. When, cutting as much as half of the allocatedbandwidth from the player B will not harm the QoE ofits user, while cutting the same portion from the playerA is likely to cause major degradation in its quality.Therefore, a well-designed system should reallocatethe network resource based on the current conditionof all video streaming flow in the network in order tomaximize the overall QoE of all users.

1500

1000

500

0

Kb

ps

0 15 30 45 60 75 90 105 120 135 140 Time(second)

Player APlayer B

Fig. 12: Video stream flows of two video Players atsteady state.

Generally speaking, different factors such asstartup delay time, playback stalls, quality of theimage, .etc, have different impact on the QoE. Forinstance, stalls in the playback has far more negativeimpacts on the QoE than reducing the quality onelevel. Therefore, it is important to consider the impactdegree of these factors on the QoE for different clientswhen reallocating the bandwidth. For example, con-sidering a scenario where we have two video streams;one is in steady state, and another is in bufferingstate. Assume at this moment, a new video streamjoins the other two video streams. This would requirereducing the available bandwidth for both existingstreams to allocate some for the new comer. In thiscircumstance, however, it is better to reallocate somebandwidth from the steady-state video stream to thenew video stream and keep the bandwidth at thesame level for the buffering-state stream. Because,according to our analysis from previous sections, itis more likely that the steady-state video stream hasmore buffered video chunks to playback compared tothe buffered-state video stream. Therefore, reducingthe bandwidth for the steady-state stream may result,in the worst case, in reducing the quality level. On theother hand, reducing the bandwidth for the buffering-state video stream can lead to non-acceptable stallsin the playback. Our experiments shows that the maincause of such stalls with the commercial players is theuse of weighted average in estimating the throughputinstead of using the instantaneous value. One reasonof using this technique is to minimize the impact ofoutliers resulting from the temporary drop or raise inthe bandwidth.

VI. CONCLUSION

In this paper, we have conducted extensive analysisof the video traffic from popular HTTPs adaptive

video player (YouTube). Initially, we have analyzedthe video streaming traffic of non-competing scenar-ios, where we wanted to understand how the HTTPsadaptive video player behaves under different networkconditions. Furthermore, we have analyzed multipleconcurrent video streaming traffic for competing sce-narios, where two or more video players are compet-ing for the shared bandwidth. This study enables usto understand the unfairness in sharing the bandwidthamong the players, and the its impact on the QoE.Finally, based on the analysis of video streamingflows, we have discussed how to enhance the videoQoE and assist the video players to perform muchbetter for all clients.

REFERENCES

[1] T.-Y. Huang, N. Handigol, B. Heller, N. McKeown, andR. Johari, “Confused, timid, and unstable: picking a videostreaming rate is hard,” in Proceedings of the 2012 ACMconference on Internet measurement conference. ACM,2012, pp. 225–238.

[2] J. Jiang, V. Sekar, and H. Zhang, “Improving fairness, effi-ciency, and stability in http-based adaptive video streamingwith festive,” in Proceedings of the 8th international confer-ence on Emerging networking experiments and technologies.ACM, 2012, pp. 97–108.

[3] S. Akhshabi, L. Anantakrishnan, C. Dovrolis, and A. C. Be-gen, “Server-based traffic shaping for stabilizing oscillatingadaptive streaming players,” in Proceeding of the 23rd ACMWorkshop on Network and Operating Systems Support forDigital Audio and Video. ACM, 2013, pp. 19–24.

[4] M. A. Hoque, M. Siekkinen, J. K. Nurminen, M. Aalto,and S. Tarkoma, “Mobile multimedia streaming techniques:Qoe and energy saving perspective,” Pervasive and MobileComputing, vol. 16, pp. 96–114, 2015.

[5] R. Houdaille and S. Gouache, “Shaping http adaptive streamsfor a better user experience,” in Proceedings of the 3rdMultimedia Systems Conference. ACM, 2012, pp. 1–9.

[6] “Most internet traffic will be encrypted by year end. here’swhy.”

[7] A. Unknown, “Open vswitch, an open virtual switch,” DateUnknown but prior to Dec, vol. 30, p. 2, 2010.

[8] I. Delchev, “Linux traffic control,” in Networks and Dis-tributed Systems Seminar, International University Bremen,Spring, 2006.

[9] A. Tirumala, F. Qin, J. Dugan, J. Ferguson, and K. Gibbs,“Iperf: The tcp/udp bandwidth measurement tool,” http://dast. nlanr. net/Projects, 2005.