Cache-Friendly Streaming Bitrate Adaptation byCongestion Feedback in ICN

Dinh NguyenKDDI R&D Laboratories

Jiong JinSwinburne Univ. of Tech.

Atsushi TagamiKDDI R&D Laboratories

ABSTRACTHTTP adaptive streaming is an attractive solution to theexplosion of multimedia content consumption over the In-ternet, which has recently been introduced to information-centric networking in the form of DASH over CCN. In thispaper, we enhance the performance of such design by takingadvantage of congestion feedback available in ICN networks.By means of utility fairness optimization framework, we im-prove the adaptation logic in terms of fairness and stabilityof the multimedia bitrate delivered to content consumers.Interestingly, we find that such fairness and stability have avery positive impact on caching, making streaming adapta-tion highly friendly to the ubiquitous in-network caches ofthe ICN architectures.

CCS Concepts•Networks → Transport protocols; Cross-layer proto-cols; •Information systems→Multimedia streaming;

KeywordsInformation-Centric Networking, DASH, caching

1. INTRODUCTIONHTTP adaptive streaming (HAS) is an attractive solution

to the explosion of multimedia content consumption over theInternet. The key advantage of HAS is its ready-to-deployfeature, working seamlessly over existing content deliveryinfrastructure on top of HTTP. This very feature, however,also brings the drawback that has been witnessed in severalrecent studies [1, 6, 8, 12]. HAS shifts the responsibility ofquality assurance toward content consumers who unfortu-nately have a very limited view of the network condition.That said, it relies on TCP for stability and fairness. Con-tent delivery throughput over TCP is taken directly as thefair bandwidth share which in many scenarios is an inaccu-rate and unstable measure of the network condition [1, 6, 8,12].

Permission to make digital or hard copies of all or part of this work for personal orclassroom use is granted without fee provided that copies are not made or distributedfor profit or commercial advantage and that copies bear this notice and the full cita-tion on the first page. Copyrights for components of this work owned by others thanACM must be honored. Abstracting with credit is permitted. To copy otherwise, or re-publish, to post on servers or to redistribute to lists, requires prior specific permissionand/or a fee. Request permissions from permissions@acm.org.

ICN’16, September 26-28, 2016, Kyoto, Japanc© 2016 ACM. ISBN 978-1-4503-4467-8/16/09. . . $15.00

DOI: http://dx.doi.org/10.1145/2984356.2984362

HAS has recently been introduced to information-centricnetworking (ICN) [10, 13] as DASH (Dynamic AdaptiveStreaming over HTTP) [15] over CCN [7], which demon-strates the promising performance of this combination bytaking advantage of the receiver-driven, chunk-based con-tent delivery nature of CCN. ICN makes the problem ofadaptive streaming more challenging due to the prevalenceof in-network caches which needs to take into account in de-signing bitrate adaptation [5, 11]. Furthermore, CCN/NDN,to the best of our knowledge, has no established congestioncontrol comparable to TCP that the current Internet has.Routers react to congestion locally to avoid congestion col-lapses and applications are able to react directly to networkcondition. Our contribution in this paper is twofold. First,we take this opportunity to make a case for congestion feed-back to streaming applications and demonstrate that suchECN (explicit congestion notification)-like feedback, doablein CCN/NDN, is of great value to streaming applications inchoosing fair and stable bitrates. We then further evaluateour approach in the context of ICN caching, which shows itscache-friendliness as content consumers over a delivery pathtend to request the same DASH representation.

2. BACKGROUND AND RELATED WORKDASH [15] is a standardized content streaming specifica-

tion which, like CCN/NDN, divides content into segments offixed viewing time for delivery. The segments, pre-encodedin multiple bitrates, i.e., representations, are stored at thecontent source. Viewers or consumers request appropriatesegments in succession for downloading and consuming attheir devices. In addition, to cope with changes and disrup-tion of the network, each consumer maintains a playbackbuffer of segments that are to be played. During a view-ing session, a consumer uses an adaptation logic to adjustthe requested representations according to locally perceivednetwork condition in order to maintain the highest possi-ble bitrate and avoid playback buffer underruns, which, ifhappened, will result in playback stalls.

Despite being easy-to-deploy and well adopted, DASH re-lies on HTTP/TCP for efficiency and fairness of its adapta-tion logic, which has serious drawbacks witnessed in recentstudies. The main limitation is due to wrong estimation ofnetwork condition which is carried out by measuring the de-livery throughput of previous content segments. Such mea-sured throughput is not an accurate congestion signal. Whatis worse, the measured throughput usually cannot convergeto the fair share of bandwidth among multiple users. Theauthors of [6, 8, 12] have proposed several valuable tech-

71

Algorithm 1: Conventional Bitrate Adaptation

1. Estimate bandwidth in the last download

x̃ =segment size

download time

2. Smooth the estimated bandwidth using e.g. EWMA

EWMA(x̃)

3. Choose nearest bitrate as the target video bitrate

x̂ ≤ EWMA(x̃)

4. Request next segment of bitrate x̂ after

∆t =

{0 if B < Bmax

τ if B ≥ Bmax

/* B/Bmax: current/max playback buffer *//* τ: segment length in second */

niques to remedy these drawbacks but the problems of in-accurate congestion signals and unfairness are inherent inthe way DASH is implemented at the application layer overHTTP and the way end-users individually and uncoordinat-edly adapt their target representations.

Several congestion control protocols have been recentlyproposed in CCN/NDN, among which ECN-based conges-tion control such as those in [20, 21] is a very viable ap-proach. These protocols however center on elastic-trafficapplications (e.g file downloads) without consideration forinelastic, adaptive multi-rate streaming applications whichhave different requirements on network resources.

As caching is commonly deployed in content delivery net-works, the interaction between bitrate adaptation and cachingis also an important problem under investigation by recentwork [1, 5, 11] which proposed source/cache-side techniquesto shape traffic or to suggest the right representation to con-sumers. Here, we look into the problem from the oppositeangle, at the bitrate adaptation itself, and aim at making itmore friendly to the existing cache system.

2.1 Conventional Streaming Adaptation LogicConventional streaming adaptation logic (Algorithm 1)

generally consists of 4 steps: available bandwidth estima-tion, bandwidth smoothing, bitrate quantization, and re-quest scheduling. Instability and unfairness are mainly be-cause of step 1, available bandwidth estimation, which in-accurately takes the mean throughput of the most recentsegment download as the fair bandwidth share. This worksunder the assumption that HTTP/TCP can guarantee fairbandwidth allocation. It is, however, not the case withHTTP-based bitrate adaptation due to the ON-OFF requestpattern and the ambiguity in determining fair-bandwidthshare among multiple streaming content consumers over thesame bottleneck [1, 12]. As shown in [8, 12], the estimatedbandwidth is unreliable and highly depends on the time ofbandwidth measurement. A consumer who measures band-width at the OFF periods of other consumers likely observeshigher available bandwidth than its fair share.

2.2 DASH over CCNIn [10], a general architecture and naming convention are

proposed to deploy DASH over CCN [7] taking advantage ofreceiver-driven and chunk/segment-based content delivery

0.01.02.03.04.05.06.07.08.09.0

Est

imat

ed B

andw

idth

[Mbi

t/s]

0.00.51.01.52.02.53.03.54.04.5

0 200 400 600 800 1000 1200 1400 1600 1800

Req

uest

ed B

itrat

e[M

bit/s

]

Time [s]

Figure 1: Eight consumers running conventional bi-trate adaptation over a 24Mbit/s bottleneck.

which both DASH and CCN have in common. Evaluationof this combination [10, 13] shows reasonable overhead andperformance compared with DASH over HTTP. The adap-tation logic used in these studies, however, is a conventionalone which faces the same limitations stated above.

Our objective in this paper is to devise a streaming adap-tation logic to maximize quality of experience, i.e., high andstable playback bitrate without disruption, and to ensurefairness in networks where congestion feedback can be madeavailable to the streaming adaptation logic such as in DASHover CCN.

2.3 A Motivating ExampleUsing mean delivery throughput of previous segments as

a congestion feedback signal is unstable and unreliable sincethe mean throughput fluctuates widely over time and variesamong different consumers sharing the same network bot-tleneck. Figure 1 (bottom) shows the playback bitrates at8 content consumers over a shared bottlenecked link usingconventional adaptation logic (Algorithm 1).1 The instabil-ity and unfairness of streaming bitrates, due to inaccurate,unfair, and unstable bandwidth estimation (Figure 1, top),have also been widely observed in recent work.

Such highly variable bitrates causes difficulty for cachingsince multiple representations need to be cached, which sig-nificantly reduce cache efficiency and cache hit. Further-more, inconsistent caching of multiple representations dis-rupts adaptation logic at consumers, making it harder tochoose the right bitrates. As caches are ubiquitous in ICNarchitectures, this phenomenon is expected to degrade qual-ity of experience (QoE) of streaming application in ICN toa large extent.

3. UTILITY PROPORTIONAL FAIRNESS FORSTREAMING ADAPTATION

To guarantee fairness and stability of bitrate adaptation,we adopt the utility proportional fairness (UPF) framework[18] which generalizes the bandwidth proportional fairness(BPF) [9] for the case of mixed elastic (download) and in-elastic (streaming) traffic. Formally, UPF maximizes the

1See Sec.5 for simulation settings.

72

total transformed utility of all users subject to link capacityconstraints [18]:

maxx≥0

∑n∈N

∫ xn

mn

1

Un(y)dy (1)

s.t.∑

n:i,j∈L(n)

xn ≤ ci,j ∀i, j (2)

where N is the set of all users, Un(·) is continuous utilityfunction of user n over the rate, mn is the minimum raterequested by user n and xn is the rate allocated to this user,L(n) is the set of links user n uses, and ci,j is the capacityof link (i, j). This problem can be solved by adapting therate allocated to user n in each period according to

xn(t+ 1) = U−1n

(1

qn(t)

)(3)

where qn is the accumulated congestion price over the deliv-ery path to user n.

The resulting rates are utility-proportional fair which inreality means users are guaranteed relatively the same utilityover the same delivery path. By giving each content objecta system-wide utility function, i.e., the utility function isthe same to all users who are requesting the content, utilitylevels can be tied to the encoding bitrates of the multime-dia content (we explain utility function shortly in the nextsubsection). This type of fairness is beneficial in the con-text of ICN as being demonstrated in Sec.4 and Sec.5 sinceconsumers of a given content object on the same deliverypath converge to the same representation. Consequently, thenumber of representations for a given content object cachedon the delivery path decreases and the streaming contenthas a higher chance of being hit at caches.

UPF requires that accumulative congestion signal is avail-able at the application for bitrate adaptation which can beimplemented in the form of an ECN field in CCN/NDN datapackets.

3.1 Utility Functions of Adaptive StreamingConsumers

One important factor in using UPF is to define continu-ous utility functions at the consumers. Intuitively, a viewerexperiences higher QoE levels when changing to higher en-coding bitrates. Utility of adaptive streaming content canthus be expressed by a stepwise utility function where eachstep corresponds to one QoE level perceived by the con-sumers [16, 17]. The utility function, therefore, depends onthe content itself, i.e., how many and at which bitrates it isencoded and stored at the source. To make the utility con-tinuous for UPF framework, the stepwise function can beapproximated by a multi-level sigmoidal function as shownin Fig.2 which uses at each step a logistic function:

Un(x) = (4)

01/62/63/64/65/6

1

.1 .35 .7 1.3 2.8 4.5

Util

ity

Bitrate [Mbit/s]

sigmoidal approx.stepwise utility

Figure 2: A stepwise utility function with 6 bitratesand its sigmoidal approximation (α = 125).

0 if 0 ≤ x < r12

1K.( 1

1+e−α(x−r1) ) if r12≤ x < r1+r2

2

...1K.( 1

1+e−α(x−rk) + k − 1) ifrk−1+rk

2≤ x < rk+rk+1

2

...1K.( 1

1+e−α(x−rK ) +K − 1) ifrK−1+rK

2≤ x < 3rK

2

1 if 3rK2≤ x

where K is the number of available encoding bitrates, xis the streaming rate, rk is the k-th encoding bitrate, andα > 0 is a constant.

Consumers, however, might have different capability inrepresenting multimedia content. At the beginning of astreaming session, consumers requests for MPD (media pre-sentation description) that contains a list of available encod-ing bitrates for their interested content, and determine theset of bitrates they are able to consume. The consumers canthen construct their own utility function as described abovefrom the set of chosen bitrates.

3.2 Utility-Fair Bitrate AdaptationUPF is used to estimate the available bandwidth, avoiding

unfairness and instability of the common bandwidth estima-tion used in conventional bitrate adaptation. The proposedbitrate adaptation is given in Algorithm 2. Compared withthe conventional bitrate adaptation, the difference lies in theway fair bandwidth share is estimated in step 1a and step1b. As explained before, utility-fair bitrate adaptation esti-mates bandwidth by congestion feedback to ensure fairnessamong multiple content consumers. In addition, notice thatonce a data packet is received, a new interest packet is gen-erated and sent into the network after a delay ∆t computedin step 4 which depends on the playback buffer level.

4. UTILITY-FAIR ADAPTATION AND CACHINGUtility proportional fairness translates into an equalized

bitrate allocation to consumers (with homogenous capabil-ity) of a given content object over the same path. To illus-trate the effect of this fairness to caching, let us considera stand-alone LRU cache deployed at the access router ofa delivery path with Poisson request arrival. By extendingChe’s approximation [3] to the case content is divided intoS segments, each has R representations requested by con-sumers and making simplified assumption that all segmentsand representations of a content object are requested with

73

Algorithm 2: Utility-Fair Bitrate Adaptation

1a. Measure and smooth congestion price feedback

qn = EWMA[q(D)]

/* qn/q(D): smooth/current congestion price */1b. Compute utility-fair bandwidth share

x̃n = U−1n

(1

qn

)2. Smooth the estimated bandwidth

EWMA(x̃)

3. Choose nearest bitrate as the target video bitrate

x̂ ≤ EWMA(x̃)

4. Request next segment of bitrate x̂ after

∆t =

{0 if B < Bmax

τ if B ≥ Bmax

/* B/Bmax: current/max playback buffer *//* τ: segment length in second */

the same probability, we have cache hit rate (as [5] does)

Phit =

M∑i=1

pi(1− e−piTC̄ ) (5)

where M is the number of content objects and pi is the prob-ability of requests for content object i. Content popularitypi is typically considered as Zipf-like but can generally fol-low any distribution [14]. Here TC̄ is Che’s characteristictime [3] that increases with (normalized) cache size C̄. Thenormalized cache size is computed from actual size C as

C̄ =C

S(∑R

k=1 bk) (6)

where bk is the size of representation k in bytes.Consider the case of a cache deployed at the network edge,

as all streaming sessions of a given content object goingthrough the cache experience the same upstream conges-tion level, an optimally fair bitrate adaptation results in onerepresentation bk∗ being chosen by end-user’s bitrate adap-tation logic and stored in the cache. This, in effect, increases

normalized cache size by∑Rk=1 bkbk∗

> 1, and consequently, in-

creases TC̄ and Phit as of (5) compared with conventionalbitrate adatptation where end-users are not coordinated bycongestion feedback.

5. EVALUATIONWe evaluate performance of the utility-fair bitrate adap-

tation through chunk-level event-driven CCN simulations.Routers have the functionality of CCN and can feedbackcongestion price using an ECN-like field in CCN data pack-ets. Queuing delay is used as the congestion price that isaccumulated and stored in the ECN field of data packets asthey traverse the network.2

2We note that some congestion control schemes pace theinterests (e.g. [19]) and thus are able to keep queuing delayof data packets low. In such cases, the queuing delay of

0.01.02.03.04.05.06.07.08.09.0

Est

imat

ed B

andw

idth

[Mbi

t/s]

0.00.51.01.52.02.53.03.54.04.5

0 200 400 600 800 1000 1200 1400 1600 1800

Req

uest

ed B

itrat

e[M

bit/s

]

Time [s]

Figure 3: Eight consumers running Panda adapta-tion [12] over a 24Mbit/s bottleneck.

0.01.02.03.04.05.06.07.08.09.0

Est

imat

ed B

andw

idth

[Mbi

t/s]

0.00.51.01.52.02.53.03.54.04.5

0 200 400 600 800 1000 1200 1400 1600 1800

Req

uest

ed B

itrat

e[M

bit/s

]

Time [s]

Figure 4: Eight consumers running utility-fair adap-tation over a 24Mbit/s bottleneck.

Content consumers connect to CCN routers and send re-quests for content. There are two types of consumers: in-elastic streaming consumers (e.g., VOD and user-generatedcontent) and elastic consumers (e.g., FTP and Web con-tent). The former uses bitrate adaptation to request forpre-encoded multimedia segments while the latter down-loads chunks of their requested content using a delay-basedcongestion control algorithm similar to TCP Vegas. In to-tal, 2000 content objects are stored at the source, of whichstreaming content is encoded in 6 bitrates from 0.1Mbit/sto 4.5Mbit/s (Fig.2)3.

We implement and compare the performance of utility-fairbitrate adaptation (Algorithm 2) and conventional bitrateadaptation (Algorithm 1) in terms of playback bitrate, fair-ness, instability, total stall time, and cache friendliness. In

interest packets can be added to the ECN fields when datapackets are generated so as to feedback accumulated queuingdelay of both interest and data packets.3To make it easy comparing bitrates allocated to differentviewers, we use the same utility function for all viewers inour simulations. The utility-fairness framework and the pro-posed bitrate adaptation, however, work with heterogeneousutility functions.

74

addition, we implement Panda bitrate adaptation [12] whichemploys TCP-like AIMD (additive increase mulplicative de-crease) rate adjustment as a representative enhancement toconventional bitrate adaptation. Panda parameters are thedefault as suggested in [12]. For all cases, the maximumbuffer size is Bmax=30 segments4 (Bmin=26 segments incase of Panda), and default segment length τ=2s. Whenstarting up, streaming consumers download a start-up bufferof 15 segments and then begin to adapt bitrates.

5.1 Bottlenecked TopologyThe performance is first evaluated in a 24Mbit/s bot-

tlenecked topology with 8 concurrent sessions streaming 8videos of 30-minute length. Requested bitrates of all con-sumers in case of conventional bitrate adaptation is reportedin Fig.1, which shows fluctuation and unfair requested bi-trates (bottom) among consumers as a result of inaccuratebandwidth estimation (top). Results of Panda and utility-fair adaptation are given in Fig.3 and Fig.4, respectively.AIMD artifact is evidenced in the estimated bandwidth andselected bitrates as Panda probes for available bandwidthusing a TCP-like AIMD algorithm (Fig.3). Guided by con-gestion feedback, utility-fair adaptation (Fig.4), is able tomaintain stable estimated bandwidth and requested biratesare relatively the same among 8 players. It is worth notingthat the estimated bandwidth of UPF always reaches themaximum rate of 4.5Mbit/s because of low queuing delaywhen the 8 consumers settle at the fair bitrate of 2.8Mbit/sover 24Mbit/s shared bottleneck5. Playback buffer at allconsumers in these three cases always reaches the maximumlevel and is not reported.

5.2 Impact of Elastic Background TrafficIn this scenario, a consumer downloads 2GB content using

TCP Vegas congestion control sharing the 24Mbit/s bottle-neck with 8 streaming consumers. The requested bitrateof 8 streaming consumers is reported in Fig.5. In the firsthalf of the simulations when elastic consumer is download-ing content, each bitrate adaptation has different aggressive-ness toward background elastic traffic. Utility-fair adapta-tion interestingly guarantees fairness among the 8 consumersboth before and after the elastic traffic completes (at aroundt=1200s).

5.3 Impact of Bitrate Adaptation to CachingWe evaluate the impact of bitrate adaptation to a cascade

of chunk-based LRU caches deployed at 4 content routers ona chain topology with an 1Gbit/s botleneck link in the mid-dle. The LRU caches store all passing content chunks/segments,and has a default size of C=20GB. The source hosts 1200short video clips of 10-minute length, Zipf(.8), chopped into1-second segments and 800 files of size 50MB, Zipf(.8). Weuse a request mix of 60% video streaming and 40% contentdownloading as suggested in [4] with Poisson arrival (meanarrival rate 0.8 request/s). There are roughly 8200 videostreaming sessions completed during 5-hour simulations.

4The reason for this large buffer is to be more generous toconventional bitrate adaptation whose performance deterio-rates badly with small playback buffer size. The large buffersize, in addition, is common in VoD applications [2, 8, 12].5The filter in Algorithm 2 (step 3) plays an important rolein stable the bitrates and we plan to investigate how to dis-tribute the residual bandwidth among users in future work.

0.01.02.03.04.0

Bitr

ate

[Mbi

t/s]

0.01.02.03.04.0

Bitr

ate

[Mbi

t/s]

0.01.02.03.04.0

0 200 400 600 800 1000 1200 1400 1600 1800

Bitr

ate

[Mbi

t/s]

Time [s]

Figure 5: Eight streaming sessions competes withone downloading session: conventional (top), Panda(middle), utility-fair (bottom).

Mean bitrate, Jain fairness index, instability (i.e., degreeof short-time bitrate fluctuation as defined in [8, 12]), andmean stall time (for re-buffering) of the 3 bitrate adapta-tions are reported in Fig.6. Even though Panda adaptationhas improved fairness over conventional adaptation, bothshow fluctuation in the mean bitrate. Utility-fair adapta-tion, on the other hand, exhibits very high Jain fairnessindex and the mean bitrate converges quickly to a stablevalue. Stability of requested bitrate helps utility-fair adap-tation avoid re-buffering which however is visible with theother two adaptation schemes.

Cache hit (total chunks/segments served from caches overtotal requested chunks/segments) is reported in Fig.7. Thanksto its fair and stable bitrate selection, utility-fair adaptiveconsumers enjoy higher hit rate for streaming content (50-80% increase compared with the case of Conventional andPanda). In addition, overall cache hit rate (of both stream-ing and download traffic) is also higher since cache storageis used more efficiently without keeping too many represen-tations of the same streaming content. This is evidenced inFig.8, which shows the ratio of number of cached segmentsto the size of content in segments for the 5 most popularvideos by the end of simulations.

6. CONCLUDING REMARKSWe have demonstrated the advantages of utility-fair bi-

trate adaptation in ensuring fairness and stability for stream-ing content delivery and its friendliness to network caches.The proposed bitrate adaptation is by no means a completesolution to the problem of caching for multi-bitrate stream-ing applications. Here what we want to do is to make a casefor bitrate adaptation on congestion feedback and to showthe positive impact it has on caching. We believe that theadaptation inside streaming applications, caching, and thenetwork can jointly act to deliver the best QoE to end-users,a direction that we plan to investigate in our future work.

AcknowledgmentThe work for this paper was performed in the context ofthe Horizon2020/NICT EU-JAPAN ICN2020 project GrantAgreement No. 723014 and NICT under Contract No. 184.

75

0.00.20.40.60.81.0

0.01.02.03.04.05.0

Bitr

ate

[Mbi

t/s]

0.00.20.40.60.81.0

0.01.02.03.04.05.0

Bitr

ate

[Mbi

t/s]

0.00.20.40.60.81.0

0 1 2 3 4 50.01.02.03.04.05.0

Bitr

ate

[Mbi

t/s]

Time [hour]

Jain

Fai

rnes

s, In

stab

lity,

Mea

n S

tall

Tim

e

Mean BitrateJain Fairness

Mean InstabilityMean Stall Time [s]

Figure 6: Conventional (top), Panda (mid.), andutility-fair (bot.) over a cascade of caches.

0.000.050.100.150.200.250.300.350.400.45

5 10 15 20 25 30 35 40

Hit

Rat

e

Cache Size [GB]

Conventional: StreamingPanda: Streaming

Utility-fair: Streaming

OverallOverallOverall

Figure 7: Utility-fairness increases cache hit.

The authors thank anonymous reviewers for their construc-tive comments which help improve this paper.

7. REFERENCES[1] S. Akhshabi et al. Server-based traffic shaping for

stabilizing oscillating adaptive streaming players.NOSSDAV ’13.

[2] S. Akhshabi et al. An experimental evaluation ofrate-adaptive video players over {HTTP}. SignalProcessing: Image Communication, 27(4):271 – 287,2012.

[3] H. Che et al. Hierarchical web caching systems:modeling, design and experimental results. IEEEJSAC, 20(7):1305–1314, Sep 2002.

[4] C. Fricker et al. Impact of traffic mix on cachingperformance in a content-centric network. INFOCOMWKSHPS 2012.

[5] R. Grandl et al. On the interaction of adaptive videostreaming with content-centric networking. PV 2013.

[6] T.-Y. Huang et al. A buffer-based approach to rateadaptation: Evidence from a large video streamingservice. CCR, 44(4):187–198, 2014.

[7] V. Jacobson et al. Networking named content.CoNEXT ’09

0.0

0.5

1.0

1.5

2.0

1st 2nd 3rd 4th 5th

# C

ache

d S

eg./C

onte

nt S

ize

Video Popularity

ConventionalPanda

Utility-fair

Figure 8: Expansion of the 5 most popular videos incaches (C=20GB).

[8] J. Jiang et al. Improving fairness, efficiency, andstability in http-based adaptive video streaming withfestive. IEEE/ACM TON, 22(1):326–340, Feb 2014.

[9] F. P. Kelly et al. Rate control for communicationnetworks: shadow prices, proportional fairness andstability. ORS, 49(3):237–252, 1998.

[10] S. Lederer et al. Adaptive multimedia streaming ininformation-centric networks. IEEE Network,28(6):91–96, Nov 2014.

[11] D. H. Lee et al. Caching in http adaptive streaming:Friend or foe? NOSSDAV ’14

[12] Z. Li et al. Probe and adapt: Rate adaptation for httpvideo streaming at scale. IEEE JSAC, 32(4):719–733,April 2014.

[13] Y. Liu et al. Dynamic adaptive streaming over ccn: Acaching and overhead analysis. ICC 2013

[14] V. Martina, M. Garetto, and E. Leonardi. A unifiedapproach to the performance analysis of cachingsystems. INFOCOM, pages 2040–2048, April 2014.

[15] I. Sodagar. The mpeg-dash standard for multimediastreaming over the internet. MultiMedia, IEEE,18(4):62–67, April 2011.

[16] M. S. Talebi et al. Utility-proportional bandwidthsharing for multimedia transmission supportingscalable video coding. Com.Com., 33(13):1543 – 1556,2010.

[17] G. Tychogiorgos et al. Distributed network resourceallocation for multi-tiered multimedia applications.INFOCOM 2015

[18] W.-H. Wang et al. Application-oriented flow control:Fundamentals, algorithms and fairness. IEEE/ACMTON, 14(6):1282–1291, Dec 2006.

[19] Y. Wang et al. An improved hop-by-hop interestshaper for congestion control in named datanetworking. In ACM ICN Workshop, pages 55–60,2013.

[20] F. Zhang, Y. Zhang, A. Reznik, H. Liu, C. Qian, andC. Xu. A transport protocol for content-centricnetworking with explicit congestion control. InICCCN, 2014.

[21] J. Zhou et al. A proactive transport mechanism withexplicit congestion notification for ndn. In ICC, pages5242–5247, June 2015.

76