Async: De-congestion and Yield Management inCellular Data Networks

Vijay Gabale∗, UmaMaheswari Devi∗, Ravi Kokku∗, Vinay Kolar∗, Mukundan Madhavan∗, Shivkumar Kalyanaraman†∗IBM Research – India, †IBM Research – Australia

Abstract—

We design and implement a novel system called Async, whichenables a mobile network operator (MNO) to efficiently managethe growth of mobile data by leveraging the delay-elastic natureof certain applications and the price-sensitive nature of certainusers. Specifically, Async introduces an alternate “asynchronous”content-delivery paradigm for heavy content (e.g., videos), andfacilitates an MNO to negotiate with users a delay in deliveryin exchange for appropriate incentives. The MNO uses thenegotiated delays to actively manage Async flows to reducecongestion and improve the quality-of-experience (QoE) of bothdelayed and regular flows. We show that in comparison to state-of-the-art, Async’s network-based flow management enhancesQoE for more than 30% of the regular flows, with up to 60%improvement in per-flow QoE metric, while still meeting thenegotiated delivery times of 95% of the delayed flows. Asyncalso lowers the delivery times of delayed flows by ∼67% andsignificantly increases robustness to traffic unpredictability. Ourdesign is robust to disconnections and does not require anymodifications to existing network infrastructure and protocols.Our prototype deployment (using Apache’s mod proxy and anAndroid app) on live networks confirms Async’s efficacy inmeeting EDTs for diverse deployment scenarios.

I. INTRODUCTION

Predictions show that mobile data traffic will grow at acompound annual growth rate of 66% from 2012 to 2017 [1].Further, more than 50% of mobile data traffic is predicted tobe video [1]. To support the increasing data traffic, mobilenetwork operators (MNOs) are reacting in several ways suchas (1) increasing the capacity by adding more base stations(BSs), introducing Femto cells, enabling WiFi offload, and (2)introducing variable pricing mechanisms such as moving fromunlimited data plans to tiered mobile data packages.

This paper explores a complementary, less-explored direc-tion of better yield management through network-managedtime-shifting of traffic. Despite the challenge of rise in traf-fic, networks often observe significant variation in utilizationlevels, mainly triggered by diurnal patterns of human activ-ity [2]. In fact, our measurements show that flows observehigh variation of throughput even at short timescales of a fewseconds. Such variations cause low utilization at certain timesof a day and overload during others. Overloaded conditionscan have a drastic effect on the quality-of-experience (QoE)of users, especially when streaming videos, thus lowering theeffective yield of the network resources. The yield of a networkdeployment is a function of the number of “useful” bytesdelivered in time without deteriorating user QoE.

Building on the above observations, we introduce an asyn-chronous content delivery system called Async for flexible

Fig. 1. The Async Approach.

content delivery in a mobile operator’s network. Async fa-cilitates an MNO to negotiate with users a delay in contentdelivery in exchange for appropriate incentives. The MNO usesthe negotiated delays to actively manage Async flows in sucha way that QoE improves for both delayed and regular flows.We specifically focus on video content delivery since videotraffic is dominating cellular data traffic [1], and video content(e.g., prime-time shows, movies, sports highlights) is amenableto asynchronous delivery. Nevertheless, the solution is equallyapplicable to other types of traffic that are elastic, such assynchronizing files to the cloud, video uploads, and softwareupdates.

Fig. 1 shows the basic idea of Async. Async essentiallyintroduces a “video sachet” model, in which users (or auto-mated user agents) are allowed to choose the delivery priceand expected delivery time (EDT) of different types of videosat fine granularity. On each video request, the Async systempresents the user with different (price,EDT) options to choosefrom. In the case of a user agent making the choices, the usercan set policies a priori to specify the range of tolerable priceand EDTs for different types of traffic.

The Async system is based on two simple but crucialobservations: (1) the available capacity at BSs fluctuates sig-nificantly even at short timescales, hence, cellular networkelements are in the best position to intelligently schedule thetraffic with varying EDTs, and (2) users are better judges ofthe price they are willing to pay and the EDT they can tolerate.Often, user behavior depends not just on prices and delays, butalso on the specific content (entertainment video vs. businessvideo), and the context of content consumption (e.g. watchingalone vs. watching in a group). To cater to such diverse contentand context, Async enables a variety of price and EDT options.

Further, by managing price and delivery time options at finegranularity, Async enables the MNO to continually operateat different load levels, and evolve as traffic increases. Forinstance, when the overall utilization is low, prices can belower so that adoption increases, and prices for deliveringthe same content can be increased as the average utilizationincreases with time. More generally, the flexible delivery978-1-4799-1270-4/13/$31.00 c©2013 IEEE

model enables systematic de-peaking of network traffic andsignificantly increases the yield of a given deployment, whichcan in turn increase the time-to-upgrade for network infras-tructure.

Thus, Async takes a holistic view and effectively com-bines capacity utilization with dynamic pricing to increase theyield of a network. We simulate Async functionality in ns-2 simulator for several input traffic patterns and degrees oftraffic predictability. We show that in comparison to state-of-the-art methods of deferring requests like TUBE [3], Async’snetwork-based flow management enhances QoE for ∼30% ofthe regular flows, with up to 60% improvement in the per-flowQoE metric, while still meeting the negotiated delivery timesof 95% of the deferred flows. We also show that Async’s flowmanagement reduces the delivery times of delayed flows by upto 67% and is significantly more robust to traffic unpredictabil-ity. This is because Async does not wait until a specific timein the future to deliver the deferred flows, but continuouslymakes use of transmission opportunities that become available.Through a prototype evaluation on an operational cellularnetwork for more than two weeks, we show that Async is(1) deployable with no modifications to existing protocols andnetwork infrastructure except for adding rules into a policycharging and rules functions (PCRF) [4] system for settingdiscounted pricing policies, and (2) can effectively meet theadvertised EDTs in practice.

In summary, we make two main contributions.

1) We propose a novel content delivery model over cellularnetworks that can alleviate congestion and increase networkyield, while empowering users to make a QoE choice. Weshow that the network-managed delivery in Async enablesa more effective way of network yield management, bothqualitatively and quantitatively, compared to other variable-pricing solutions [3].

2) We present the design of an end-to-end system calledAsync of our content delivery model that includes: (1) Alight-weight and distributed content delivery protocol that isadaptive to fluctuating traffic and robust to disconnections.(2) An EDT-aware flow scheduling algorithm that canmeet the promised EDTs while limiting the interferenceto non-Async flows to a specified threshold. (3) A simplemethod for efficient price and EDT computation that hasthe key property that prices offered are monotonically non-increasing with increasing EDTs, thereby simplifying thetask of making choices for users or their agents.

The rest of the paper is organized as follows. In the nextsection (Sec. II), we present the opportunities, challenges, andan overview of the Async delivery model. In Sec. III, wedescribe the three key components of Async a content deliveryprotocol, a threshold-based chunk scheduler, and a dynamicpricing module. Sec. IV discusses the implementation of ourAsync prototype. Sec. V presents our detailed simulation studyand an evaluation of our prototype. Sec. VI discusses relatedwork, while Sec. VII concludes.

II. Async: OPPORTUNITY, CHALLENGES, AND OVERVIEW

This section first presents a user survey to justify a systemlike Async. Design options and challenges associated withAsync are discussed next, followed by an overview of theproposed system deployment.

0 10 20 30 40 50 60Percentage of users

One day

6 hours

2 hours

1 hour

Depends on discount

Depends on time−of−the−day

Depends on content type

Fig. 2. Tolerance to differentdelay extents.

0 10 20 30 40 50 60 70 80Percentage of users

Download old movie

Download movie > 700MB

Upload photos

Upload video

YouTube video > 10 min

YouTube video > 5 min

YouTube video < 5min

View now, No delay

Download newly released music

Fig. 3. Tolerance to any delaybased on content types.

User Study: To understand how users would react to time-shifting, we conducted a web-based survey using the ques-tionnaire at [5]. The survey is ongoing with current responsesfrom only about 100 people. The results are hence onlyindicative and not conclusive. The survey population hasdiverse background including engineers, Internet-savvy non-engineers, people active on social networks such as Facebook,and other tech-savvy users, who use cellular network to accessand consume content.

Due to space constraint, we only present a subset of resultshere. The complete set can be found in [6]. Fig. 2 shows thatmore than 50% users, when choosing delays, are more sensitiveto discounts offered, in comparison to specific content typeor time of day. In fact, more than 20% users in our surveywere willing to delay the download (by 1 to 6 hrs) for anEDT promise for better QoE, even without any discounts. Thisobservation hints at the impression users carry about the lackof enough capacity in the network for displaying video withgood QoE [7]. Fig. 3 shows that only about 10% of the peopleprefer to receive all content with no extra delay. Others showincreased tolerance to different content and transfer types. Asexpected, people are more willing to tolerate longer delays forlarger transfers. Also, more than 50% of the users are willing todelay video and photo uploads, possibly since they themselvesdo not consume the content. We also observe that most usersare willing to wait for 2 hours if given 50% discount, but not asmany users are willing to tolerate higher delays even for 75%discount. These results suggest that a majority of the usersis amenable to traffic deferrals by bounded time durations, inexchange for proportionate discounts.

Design Elements: We now identify some challenges in build-ing a system for time-shifting traffic, and derive the designelements that Async is built on. Time-shifting entails movingtraffic demand from one instant of time (esp. peak time) toa later time. Time-shifting traffic can be done in two ways:(1) Request-shift: by asking (i.e., managing) users to returnback at a certain period of time (when the access will be at adiscounted price) and issue their object requests again, and (2)Delivery-shift: by collecting the object requests immediatelyand providing a longer-time-frame estimate (for a reducedprice of network access) of when the object will be delivered.

The Request-shift approach removes the need for any statemaintenance for outstanding requests. An instance of thisapproach is the TUBE [3] system. However, due to lack ofnetwork management, there is no control of how loaded thenetwork will be during the later low-price periods, and howmany users will be able to return at that period; this couldlead to either overload or underload in low-price periods. Forinstance, plots in Fig. 4 of achievable throughput measuredover different days at the same times of day at a commerciallydeployed base station (BS) show significant variation and lack

0

100

200

300

400

500

600

700

800

900

1000

1100

1200

08:15:00

08:45:00

09:15:00

09:45:00

10:15:00

10:45:00

11:15:00

11:45:00

12:15:00

12:45:00

13:15:00

13:45:00

14:15:00

14:45:00

15:15:00

15:45:00

16:15:00

16:45:00

17:15:00

17:45:00

Ach

ievab

le t

hro

ugh

pu

t (K

bp

s)

Time (hr:min:sec)

Achievable throughput in cellular base stations

30th December (Sunday) Location A31st December (Monday) Location A

1st January (Tuesday) Location A7th January (Monday) Location B8th January (Tuesday) Location B

Fig. 4. Achievable downlink throughput.

of any temporal predictability of traffic at fine granularity.1 Hence, Async chooses the Delivery-shift approach, whichenables content transfers to utilize unpredictable and finertimescale fluctuations in capacity. Essentially, by choosing theDelivery-shift approach, Async decouples the choice of whenthe object gets delivered from when the transfer is done, andlets the user choose the former, while the network gets theflexibility to manage the latter.

On the flip side, with Delivery-shift, the time intervalbetween when the request is made and when the content isactually delivered can be long, leading to a larger numberof outstanding requests. Further, mobility and other humanactivity can result in disconnections and change of networkaccess points (BSs) and network addresses. To achieve ro-bustness to such issues, Async includes an application layerprotocol for the management of content transfer, with the stateof the content transfer managed by the client in an App.Finally, users often find it hard to comprehend schedulingand pricing choices on a per-object basis, unless the model isvery simple. Also, simplicity also enables automation throughpolicies enacted by user agents. Consequently, Async includesa pricing mechanism that exhibits the property that increasingEDTs strictly lead to non-increasing prices.

Overview: Building on these design elements, Fig. 5 showsan overview of the deployment of Async. In contrast to non-Async applications that access content from content serversdirectly, Async apps on mobile devices access content throughthe Async proxy. The proxy fetches content from serversthat either modify the overall content presentation to theuser to be Async-friendly, or let the apps download videocontent directly and view with local players. The proxy canbe positioned anywhere in the MNO’s network, as long asit is accessible to the mobile applications through the HTTPprotocol. Async can be used in several deployment scenarios.

Fig. 5. Async ecosystem

For in-stance, opera-tors in growthmarketssuch as Air-tel [8] alreadydistributemovie and ed-ucational content on their networks with pay-per-object model.Async allows them to deliver this content for reduced pricesat off-peak times. In another scenario, service providers re-tain the content but adapt their services to deliver contentasynchronously. For instance, Netflix is already providing

1We verified that cellular network was the bottleneck which results incapacity variations and the load at the server was fairly constant.

Cablevision with servers directly in the latter’s network tomanage Netflixs content [9].

III. Async DESIGN

Async categorizes requests into two types: those on whichusers are not willing to wait at any cost (hereafter termedregular flows), and those on which users can wait, given in-centives (hereafter termed delayed flows). All flows setup bythe Async apps are delayed flows, with different EDTs. De-peaking traffic by time-shifting essentially involves schedulingthe delayed flows in such a way that the QoE of regular flowsincreases, and the delayed flows complete by their EDTs.

In what follows, we describe the various components of theAsync system: (1) messages exchanged between a client andthe proxy for satisfying each Async request, (2) algorithms atthe client and the proxy, and (3) a sample pricing mechanism.

A. Client-proxy protocol

To set up a delayed flow, the Async App sends a requestmessage to the the Async proxy, much like traditional Webproxies. The request includes a unique application-level cli-entID, BSID, and a video objectID. The clientID can be afunction of subscriber and device identification numbers and isused by the proxy to track requests and other status messageson a per-client basis. The BSID can be easily extracted inoperating systems such as Android and is used to track allthe delayed flows through a BS. The video objectID is theURL to the video file that the user wants to access and is usedto fetch the content from the original content server in thebackground. On receiving a request message, the Async proxyresponds with a set of (price, EDT) options for the user (orthe user agent) to choose from. The Async-App selects a(price, EDT) option and sends it to the proxy. These messagesare exchanged in the negotiation phase on a control channel,which can be enabled using a set of HTTP-based scripts. Theprice chosen is used by the Async proxy to bill the flowsappropriately (explained in Sec. III-D), and the EDT is used byboth the Async Proxy and App to coordinate the data transfer(explained in Secs. III-B and III-C). Once a choice is made,both the client App and the proxy switch to the transfer phasein which the content is delivered over one or more HTTPsessions set up in response to HTTP range requests issued bythe client. This is shown in Fig. 6.

Since EDTs can lead to long transfer periods, with potentialuser mobility, disconnections etc., we introduce a message,BS_UPDATE. This message is sent by an Async-client to theproxy whenever the client perceives that the user device hasmoved to a new BS. This can easily be done in today’s smart-phones; e.g., we implement an event on_cellID_changein Android, on which the Async-client can wait and sendan update in response. After the necessary status update, theclient and proxy coordinate to transfer the content throughHTTP sessions. To provide robustness against disconnections,the client maintains the download state, and invokes HTTPrange requests to resume a disrupted transfer.

B. Client: Deadline-aware Probabilistic Polling

A new HTTP range request is in fact a poll made by aclient for the partial content that it has not received yet. Incomparison to content push from the proxy, such content pullhelps to bypass NATs and handles potential IP address changesdue to mobility. Now, from the Async client’s perspective,

Fig. 6. Async client-proxy protocol

if disconnected then

for each epoch do

if (random < p(t)) then

poll;if download then

state ← connected;break;

end if

sleep for epoch;end if

end for

end if

Fig. 7. EDT-aware probabilistic pollingat the Async client.

for each poll do

if (AT θ ≥ τ ) then

download;else

if lagging then

download;else

come back later;end if

end if

end for

Fig. 8. EDT-aware threshold-based scheduling at the Asyncproxy.

each outstanding content request is in one of two states: (1) thecontent is actively being downloaded over an HTTP session,and (2) the transfer is suspended (a) by the server or (b) due tounavailability of network. When suspended (and only when thetransfer is suspended), the client polls the proxy back intelli-gently based on the EDT and the current progress achieved. Tofacilitate efficient polling, every client has a notion of an epoch.When suspended, time is divided into epochs, and a decisionto poll (or not) happens at the boundary of each epoch. Epochsacross clients need not be synchronized.

While the Async client strives to complete the download bythe EDT, the Async proxy strives to ensure that the downloadsdo not interfere with regular flows; thus, the Async proxydisconnects the downloads when the load at the correspondingBS increases. How should the Async client poll to meet theEDT, without causing overload at the proxy?

To ensure that the delayed flows meet their EDTs, Async in-corporates the notion of “lagging” and “leading” flows. Givenan EDT E for a flow that requires transfer of B bytes, we definea reference delivery progress function D(t), which indicatesthe percentage of total bytes to be delivered by time t. Anumber of functions can be used to represent D(t), includ-

ing linear or quadratic ones such as B.tE

or B.t2

E2. Note that a

quadratic function lets the delayed flows yield more to regularflows compared to a linear function when the EDT is fartheraway. A sample linear delivery function and a leading andlagging scenario for a flow are shown in Fig. 9(a). A flowis termed as lagging at time t if b(t) < D(t), and leadingotherwise. We then define a polling probability function given

by: p(t) = min( B−b(t)B−D(t) , 1).

To ensure low polling overhead at the Async proxy, we use

Fig. 9. (a) Delivery Progress Function and (b) Computation of τ .

a probabilistic polling mechanism. When a flow is suspended,at each epoch boundary, the client picks a random number r in[0.0, 1.0) and polls the proxy with an HTTP range request ifr < p(t). Thus, D(t) is used by the Async client to control thepolling frequency while ensuring that the EDT is met. Suchrandomization in polling essentially helps avoid “poll-bursts”at the proxy when most of the delayed flows are suspended dueto high load of regular flows at a BS. Once a poll is admitted,the flow moves from suspended state to active state, till thetransfer completes or the proxy terminates the HTTP session.If a poll is disallowed, the client sleeps for this epoch, andrepeats the same process at the start of the next epoch. Thisclient-side polling algorithm is summarized in the pseudo-codein Fig. 7.

C. Proxy: Deadline- and Interference-aware Scheduling

For each incoming poll from the Async clients, the proxymakes scheduling decisions (admit or disallow) on a per-BSbasis. The scheduling decisions for a BS are governed by thedegree of interference caused by the delayed flows on regularflows. Interference is termed as the reduction in throughputobserved by a regular flow when a new delayed flow is intro-duced. Async attempts to bound the interference by discon-necting the flows during BS overloads. However, as mentionedin the previous section, BSs often face short time-scale varia-tions in the load due to regular flows. Hence, once disallowed,a flow should be resumed as soon as possible when capacitybecomes available at the BS to utilize the opportunities forcontent transfer.

To minimize interference and enable opportunistic contenttransfer, we introduce a parameter τ , representing a thresholdthroughput. To observe the load at a BS, the Async proxycontinuously keeps track of the (EWMA of) throughput θachieved by each Async flow active at the BS. The proxy usesthe following simple rule to make decisions: at any instant oftime, continue the content transfer if the flow is achieving athroughput of τ or more, or if the flow is lagging behind sig-nificantly that there is danger of missing the EDTs; otherwise,suspend the flow by closing the HTTP session. As shown in theevaluation section (Sec. V-B), it takes only a few seconds (or-der of 12 seconds) to observe the achievable throughput (AT)to make a scheduling decision, thus limiting the interferenceto a short duration before a flow is disconnected. Further, aftereach epoch (order of a minute), a suspended client polls backagain probabilistically as described in the previous section,

Fig. 10. Illustration for determination of (EDT, price) options for anincoming Async flow.

allowing the proxy to observe the new AT of the flow. Thusshort time-scale transfer opportunities are put to use.

Cellular BSs commonly use proportional fair (PF) schedul-ing to balance aggregate system throughput against fairnessto flows. Since one-way delays for a flow do not increasein PF scheduling until the flow achieves its fair share of thebandwidth, it is not clear how the capacity variations can bedetected using commonly used techniques such as [10], [11].In comparison, our approach ensures that if an Async flowis receiving a throughput of τ or more, then regular flowswith similar channel conditions will also receive at least τas long as they have traffic to transmit. Furthermore, sincecellular access links are often the bottlenecks, Async proxycan be placed anywhere in the operator’s network to observethe throughputs and make the scheduling decisions.

To choose an appropriate value for threshold (τ ), we ana-lyze the historical achieved throughputs (AT) observed at theBS. A high AT indicates that, the flow has a good channelquality and there is large available bandwidth at the BS. Hence,we derive a cumulative distribution function (CDF) using theAT values measured over several days and choose the medianvalue as τ . Thus, τ is a statistical metric that we expect not tovary significantly across days. Once the system is instantiatedby these measurements and the corresponding threshold, asmore and more users use the Async system, the AT valuesmeasured by the proxy shape the CDF further and tune the τvalue.

No interference: As shown in Fig. 9 (b), if τ > C2 , where

C = maximum capacity of the BS, then, with PF scheduling,whenever a flow is scheduled by Async, content is served with-out causing any interference to regular flows. Thus the degreeof interference can be tuned in Async using an appropriatechoice of τ relative to BS capacity. Algorithm 8 summarizesthe deadline- and interference-aware scheduling.

D. Pricing

We now present a scheme for computing (price, EDT) op-tions for flows arriving at the Async proxy for negotiation withthe end users. While such options can be computed in severaldifferent ways, we give a simple scheme to illustrate and enablepricing of content in Async. The EDT choices presented to endusers can be a small set of pre-defined durations, such as 2,4, and 6 hrs, depending on the context and the length of therequest or other criteria. For each EDT, our pricing frameworkcomputes a price by determining the congestion caused by theaggregate traffic due to the incoming request. To determine thecost of congestion, we compute an allocation of the incomingrequest over time considering an EDT in the manner of water-filling algorithm [12]. Fig. 10 illustrates this with an example.

In Fig. 10, a new Async request arrives at time t1. Theaggregate traffic due to regular flows at any time t, denotedFt, is as shown. This quantity is assumed to be known andcan be estimated offline, for instance, by the same modulethat estimates τ , or using aggregate traffic estimation. ForEDTs 1, 2, and 3 considered for the incoming Async request,the distribution of the request’s content that minimizes theaggregate traffic level is also shown in the figure. This isaccomplished by allocating the incoming content such that thetotal traffic is equalized at all times in which the incomingrequest receives allocation (by, for instance, using a strictlyconvex function for computing congestion cost). It is easyto see that the maximum traffic level cannot increase withincrease in EDT. In our scheme, the price proposed for an EDTis a function of this resulting traffic level. Note that, the Asyncproxy spawns a separate instance of the pricing algorithm forevery BS under its control since the traffic patterns at differentBSs can be different.

Assumptions and definitions. Time is assumed to be dividedinto discrete time periods of configurable duration. C denotesthe BS capacity in terms of total bits that can be transmittedin a time period. The total number of Async flows that havearrived by time t and active at t is denoted Yt and the numberof bits allocated to Async flow i in period t is denoted yi,t.The total traffic at the BS at time t is then given by λt =Ft +

∑Yt

i=1 yi,t.

We classify the congestion experienced at a BS into oneof a set of L distinct levels. For this, we partition the BS’stransmission capacity [0, C) into L discrete sub-ranges, givenby [T0, T1), . . . , [TL−1, TL), where T`−1 < T` for 1 ≤ ` ≤ L.The congestion level at a BS in period t is given by thesub-range in which the total traffic, λt, it sees in that pe-riod lies, and is said to be ` if λt ∈ [T`−1, T`). For eachlevel `, we assign a constant but monotonically increasingcongestion weight K`. We then define a convex congestion-cost function (which is piecewise linear) at time t as: Dt =∑L

`=1 K`max (min(λt, T`+1)− T`, 0). It is easy to see thatthis function is non-decreasing with λt. Such a cost functionallows the MNOs to choose different level thresholds (T`) andappropriate cost for the level (K`) based on their experience.

Allocating Async flows to minimize congestion cost: Tocompute a price for an EDT, we first formulate and solve theproblem of allocating Y Async flows over N time periods (inthe manner of water-filling) so that the aggregate congestioncost over the time periods is minimized. This optimizationproblem is formulated as follows.

MINCONG

Minimize∑N

t=1Dt,

such that Si =∑N

t=1yi,t, ∀i = 1 . . . Y

∑Y

i=1yi,t ≤ C − Ft, ∀t = 1 . . . N

yi,t ≥ 0, ∀t = 1..N, ∀i = 1..Y (1)

where Si is the size (in bits) of Async flow i. The constraintsin (1) ensure that the BS capacity is not exceeded while theflow is served completely. Note that even though the objectivecost function is piecewise-linear, the problem can be solvedoptimally since the slope of the objective is bounded and all theconstraints are linear. We assume that at least one of congestionweights and congestion level widths is strictly increasing andthe other is monotonically increasing.

Computing per-flow (price, EDT ) options: When a new

flow arrives at the proxy, we solve the optimization problemMINCONG once for each EDT to be presented to the user(with N set to that EDT). In solving the problem, we usethe allocations in the future periods to previously-acceptedAsync flows (obtained as solutions to instances of MINCONGsolved when those flows arrived) and estimates of F (trafficdue to regular flows). If the problem is infeasible for the largestacceptable EDT, then we declare that the incoming requestcannot be scheduled and send a notification back to the client.We compute a pricing factor for EDT N , pN , as follows:

pN =∑

N

t=1Dt∑

N

t=1

∑L

`=1K`(T`−T`−1)

, where Dt = 0 if yi,t = 0 to

avoid a large value of Ft (regular traffic) for some t (with noAsync traffic allocated) affecting the price computation; i isthe new request under consideration. Note that pN lies between0 and 1, and can be used along with a base price. For instance,a fraction pN of the base price may be charged for the request.

Proposition 3.1: The prices offered by the Async pricingscheme are monotonically decreasing with increase in EDTs.

Proof: Let N and N ′ (N ′ > N) be two EDTs, and let ibe an incoming request. Now, consider MINCONG for EDTN ′ with the following additional constraints: yi,t = 0, ∀t > N .These constraints decrease the feasible space for MINCONGwith EDT N ′, and p′N = pN . Now, suppose the additionalconstraints are removed. Since the feasible space increases,and since MINCONG strives to minimize the objective value,∑N ′

t=1 Dt ≤∑N

t=1 Dt where Dt = 0 if yi,t = 0. Thus, itfollows that p′N ≤ pN .

Proposition 3.1 ensures that Async users are offered higherincentives for waiting a longer amount of time, which, unlikemodels in prior work such as in TUBE [3], gives users an easyto understand interface: wait more, gain more [13]. Moreover,Async offers higher discounts to the requests delivered duringlow-congestion periods, thus incentivizing users to increasetheir usage.

IV. Async PROTOTYPE

We have realized Async design in a fully-functional pro-totype, relevant details of which are discussed below.

Fig. 11. Components of the Async prototype.

As shown in Fig. 11, the Async proxy consists of: Asynccontrol scripts in PHP which implement the proxy side ofthe content delivery protocol, a database module to store theachievable throughput values and compute τ per BS, an ApacheHTTP server, and the Async pricing module. The proxy listenson port 8081 for control messages and uses ports 8082 to 8084for content transmission. The proxy can download an objectfrom the content server using Apache’s mod_proxy module.As the content becomes available (partially or completely),it can be served to the Async clients. We assume that the

download rate from the content server to the proxy is muchgreater than that between the proxy and the clients, since thelatter includes the cellular link, which is more constrained.When the object download completes at the client, it can beconsumed, e.g., using an embedded video player in the clientApp in the case of a video object.

For ease of integration of pricing in the operator’s network,we enable a small set of ports at the Async proxy for servingthe content to the clients. Each port maps to a price-per-byterule (src-id=proxy-IP and src-port=i) into the PCRF.While presenting (price, EDT ) options to users, we choosethe closest matching price in the set of prices in the pricingrules, and assign the corresponding port to serve the Asyncflow. This approach is minimally intrusive to the cellular net-work since it involves one time addition of only a small set ofrules to the PCRF. Furthermore, a control port can be enabledfor the negotiation phase without charging for the negotiationmessages.

V. EVALUATION OF Async

A. Simulation-based Study

In this section, we describe our simulation experiments toevaluate the efficacy of the Delivery-shift approach of Asyncand the Request-shift approach of TUBE [3] (refer Sec. II)in reducing congestion and improving QoE by spreading/timeshifting of flows that can be delayed. We also implement abaseline scheme that does not manipulate or shape traffic inany way, referred to as unsmoothed.

Performance Measures: Given our objectives of deliveringdelayed flows by time shifting/spreading to the right extents,and improving experience for regular flows (by alleviatingcongestion), we focus on two performance measures: (1) totaldelivery time and (2) buffer underruns. Total delivery time isdefined as the difference between the time the user intendsto issue a request and the time at which the request is fullyserved. Total delivery time is indicative of the extent to whicha scheme time shifts/spreads traffic to ease congestion. Bufferunderruns are indicative of the interference that a regular flowexperiences due to congestion and we determine it as follows(for only regular flows): The total bytes received by eachflow is sampled every 10 secs, and if found to be less thanthe expected amount (based on the playback/desired downloadrate), the underrun count for the flow is incremented by one.In the case of video, the fewer the buffer underruns for a flow,the fewer the number and/or duration of playback stalls, andhence the higher the QoE.

Simulation Setup: The content delivery and threshold-basedscheduling components were implemented using ns-2 [14].High Speed Downlink Packet Access (HSDPA) [15] was cho-sen as the cellular protocol for the wireless link and its fea-tures were simulated using Enhanced UMTS Radio AccessNetwork Extensions (EURANE) [16] for ns-2. EURANE pro-vides support for Universal Mobile Telecommunications Sys-tems (UMTS) [17], a 3GPP specified 3G cellular networksystem, including HSDPA, which can provide peak data ratesup to 10 Mbps.

The Async pricing component was implemented as a stand-alone module. This module takes as input details of flows thatare amenable to deferrals (the Async flows), and an estimate ofthe cumulative non-deferrable foreground traffic (regular trafficgiven by Ft in Sec. III-D), and determines the delivery method

0 10 20 30 40 500.5

1

1.5

2

2.5

3

3.5

period #

ba

nd

wid

th (

Mb

ps)

unsmoothedRequest−shift

Delivery−shift−700KDelivery−shift−900K

(a)

0 50 100 150 200 2500.7

0.75

0.8

0.85

0.9

0.95

1

buffer underruns for non−deferred flows

F(x

)

unsmoothedRequest−shift

Delivery−shift−700KDelivery−shift−900K

unsmoothed

Request−shift

Delivery−shift−700K

Delivery−shift−900K

(b)

0 10 20 30 40 500.7

0.75

0.8

0.85

0.9

0.95

1

delivery times of ALL flows (# periods)

F(x

)

Request−shiftDelivery−shift−700KDelivery−shift−900K

Request−shift

Delivery−shift−900K

Delivery−shift−700K

(c)

0 10 20 30 40 501

1.5

2

2.5

3

3.5

period #

ba

nd

wid

th (

Mb

ps)

unsmoothedRequest−shift

Delivery−shift−700KDelivery−shift−900K

(d)

0 50 100 150 200 250 300 3500.7

0.75

0.8

0.85

0.9

0.95

1

buffer underruns for non−deferred flows

F(x

)

unsmoothedRequest−shift

Delivery−shift−700KDelivery−shift−900K

Delivery−shift (700K & 900K)

Request−shift

(e)

0 10 20 30 40 500.7

0.75

0.8

0.85

0.9

0.95

1

delivery times of ALL flows (# periods)

F(x

)

Request−shiftDelivery−shift−700KDelivery−shift−900K

Request−shift

Delivery−shift−900K

Delivery−shift−700K

(f)

Fig. 12. Performance results under Request-shift and Delivery-shift for the input traffic in Fig. 13. Insets (a)–(c) are with the base traffic, while(d)–(f) are for the overloaded case. (a)&(d) Throughput distribution over time. (b)&(e) Buffer underruns. (c)&(f) Delivery times.

(NOW or deferred) and, if deferred, the EDT, for each Asyncflow. (Async flows for which deliver NOW option is chosenwill be delivered without delay like a regular flow.)

Simulations were performed as follows. We consider 30-minute intervals called periods. We first choose an aggregatetraffic load for 48 continuous periods spanning 24 hours (asspecified in the literature [3] or synthesized to evaluate per-formance under various load patterns). We next generate flowrequests period-by-period to match the aggregate load. In gen-erating the flow requests, we specify the percentage of loadthat comprises regular traffic. Flow arrival times are distributeduniformly within an period. Each flow generated is marked aseither a regular flow or an Async flow and is of one of thefour content types: web request, short video, long video, andfile download. The mean sizes for the four types are chosenfrom different sets, e.g., 200 KB, 2 MB, 50 MB, and 10 MB.The playback rate for each video flow is uniformly distributedbetween 300 and 700 kbps and the desired download rate for aweb request/file download ranges between 400 and 1100 kbps.These settings are used at run-time to track the progress to theflows and to quantify the interference that they are subjectedto by comparing the total bytes delivered and the expectednumber of bytes.

At run-time, regular flows and non-delayed Async flows(that is, flows amenable for deferral but chose not to) arescheduled at their arrival time. The remaining Async flows(delayed flows) are scheduled using the method described inSec. III. Epoch duration for the delayed flows is set to 1 min(based on measurements on temporal validity of achievablethroughput described in Sec. V-B).

To effectively compare Async’s Delivery-shift approachand the Request-shift approach of TUBE, we implement thepricing scheme described in [18] to determine TUBE’s per-period discounts for the specified aggregate loads. We alsoimplement the user model described therein to determine theper-flow shifts, that is, the number of periods after which aflow is willing to return. For fair comparison, we use the sameuser behavior model in Async to select (price,EDT) optionsfor Async flows. Flow transmissions were simulated using ns-2 and EURANE using the outputs obtained from the Asyncand TUBE pricing modules. We point out that the approachdescribed in [18] computes byte-level shifts, i.e., the fractionof bytes that shift from one period to a later period. Since aflow cannot be partially shifted, we adapted their approach tocompute per-flow shifts.

We performed our evaluation under both when the actualtraffic (1) followed predictions and (2) deviated from the pre-dictions. Evaluation under predictable traffic conditions is re-quired primarily for comparison against TUBE, since TUBE’sper-period prices are computed offline using estimated traffic.

Results under predictable traffic conditions: Performanceunder Async with two different interference thresholds (τ ),700K and 900K (referred to as Delivery-shift-700K and Delivery-shift-900K, respectively), the Request-shift approach, and thebasic unsmoothed scheme are plotted in Fig. 12. In this firstexperiment, all flows experience ideal channel conditions andthe input traffic pattern is as shown in Fig. 13. We chose thethreshold values based on the BS capacity of ∼3.5 Mbps underideal channel conditions and the maximum per-flow bandwidthof ∼1.2 Mbps in EURANE. Fig. 12(a) plots the cumulativebandwidth consumed by all the flows on a period-by-period

basis. During the traffic peaks seen until period 27, the twoDelivery-shift (Async) schemes and the Request-shift schemelower traffic to different extents. As can be seen, the Request-shift scheme is the most aggressive of the three in reduc-ing traffic and Delivery-shift-700K, the least. Consequently,Request-shifting shifts the most amount of traffic to the non-peak period after period 35. This is as expected since Asynclowers traffic during peaks that are detected at run-time by lim-iting the transmission of deferable flows (based on their EDTs)but not turning them off entirely. Further, as discussed earlier inSec. II, Async makes use of capacity that becomes availableat shorter time scales to make progress with Async flows.On the other hand, under TUBE’s Request-shift paradigm,certain flows arriving at high-price periods decide to go awayand return to issue their requests at low-price, and hence,presumably, low-traffic periods that are determined offline a-priori.2

Buffer underruns, delivery times, and meeting EDTs:Insets (b) and (c) of Fig. 12 plot the CDF of buffer underrunsand delivery times experienced by the flows, respectively. Ascan be seen, more than 15% fewer flows experience under-runs under Delivery-shift than under Request-shift, with ∼30%flows experiencing fewer underruns. The maximum number ofunderrun instances for any flow under Delivery-shift is ∼43%of that under Request-shift. This is due to the following reason:The throughput plotted in Fig. 12 is smoothed over 1-hour du-ration. The throughput is more bursty over shorter timescales,exhibiting many short-term peaks.

0 5 10 15 20 25 30 35 40 45 500

0.5

1

1.5

2

2.5

3

3.5

period #

ba

nd

wid

th (

Mb

ps)

base

overload

Fig. 13. Traffic pattern for the experi-ments with results in Fig. 12.

Under Async, delayedflows back-off duringsuch peaks, loweringthe impact to regularflows. Such flow dis-crimination and con-trol are absent un-der Request-shift, andhence, the flows ex-perience more under-runs. Thus, Delivery-shift de-peaks conges-tion in an effectivemanner and performsbetter than state-of-the-art in lowering the

interference and enhancing the QoE. Also, as shown in in-set (c), the extent to which flows are deferred under Request-shift is significantly higher than under Delivery-shift. Themaximum delivery time for any flow under Delivery-shift isonly around one-third (lower by ∼67%) in comparison tothat under Request-shift. This is because, as discussed earlier,Delivery-shift does not wait until an advertised low-price, low-traffic period (which is determined at coarse granularity) tostart a deferrable flow, but rather makes use of transmissionopportunities that become available at shorter time-scales tomake progress with deferrable flows. Thus, under the metricschosen, Delivery-shift is more effective in alleviating the

2The throughput results of TUBE pricing evaluation presented in [18] aresmooth and not as bursty as those in Fig. 12. This is partly because (1) theirapproach operates at byte-level and assumes that a fraction of traffic seen inone period can be shifted to a later period; such perfect shifts are not possiblewhen operating at flow-level, at which shifts occur in practice, and (2) theiraggregate traffic is much larger due to aggregation at a much higher level thana BS.

3−per shft 5−per shft10−per shft15−per shft overload0

10

20

30

40

50

60

70

80

90

100

underr

uns

Request−shiftDelivery−shift−700KDelivery−shift−900K

(a)

3−per shift 5−per shift 10−per shift 15−per shift0

0.5

1

1.5

2

2.5

3

3.5

4

4.5

deliv

ery

tim

e (

# p

eriods)

Request−shiftDelivery−shift−700KDelivery−shift−900K

(b)

Fig. 14. (a) Mean buffer underruns and (b) delivery times with variousdegrees of traffic unpredictability under the Delivery- and Request-shift approaches.

effects of congestion since spectrum does not remain unusedwhen there is opportunity for transmission. Finally, althoughthe Delivery-shift approach delays flow deliveries, most ofthe flows are delivered by their EDTs, and these EDTs arecomparable to (and, in many cases, shorter than) the per-flowshifts under TUBE. Both the number of flows not deliveredby their EDTs (< 1%) and the amount of additional timetaken are negligible. Furthermore, just as Async EDTs arecomparable to TUBE’s per-flow shifts, the incentives (in termsof price discounts) provided by the MNO are also comparablein both cases. Thus, Async de-peaks congestion in a betterfashion within the same price budget as that of TUBE.

Results under unpredictable traffic: The above experimentsassume absolute traffic predictability, i.e., full knowledge ofaggregate per-period traffic for Request-shift and regular trafficfor Delivery-shift, which cannot be assured in practice. Hence,we next study the impact of deviations from this assumption.For this, we performed experiments wherein the actual traffic isperturbed in comparison to the assumed traffic. We tested withtwo types of perturbations. In the first type of perturbation,referred to as overload, during the non-peak period after period30, the actual aggregate traffic is higher, but follows a patternsimilar to the assumed traffic; traffic in earlier periods remainsunchanged. In the second type of perturbation, referred to asshift, the actual input traffic is shifted by a certain number ofperiods in comparison to the assumed traffic.

Results for the overloaded case are shown in Figs. 12(d)-(f). Observe that, due to lack of network-side control, theRequest-shift approach is unable to react when the actual trafficdeviates from the estimated one and prevent deferral of flowrequests to periods later than 35. As a result, flows shift-ing to perceived low-traffic periods suffer from significantlyhigher buffer underruns. On the other hand, degradation underDelivery-shift is much less severe. This is due to (1) the run-time determination of EDTs and discounts with Delivery-shift,which is better able to react to deviation to traffic, and (2)network managed delivery, which is better able to utilize theresources that become available at short time scales.

Results with traffic shifts are shown in Fig. 14. As can beseen, under Request-shift, both the mean number of underrunsper flow and its variance increase as the extent of shiftingincreases. On the other hand, the Delivery-shift approach ismore robust, for reasons provided above.

Results with non-ideal channels: The above experimentswere repeated for varying channel conditions and differentdegrees of mobility for users. Results obtained exhibitedsimilar trends as above. We omit presenting detailed plots dueto lack of space.

Impact of Async’s interference threshold (τ ): In the aboveresults, as expected, opportunities for transmission are lowerfor a higher τ , and hence, delivery times are longer forτ = 900K in comparison to that under 700K. Consequently,interference to regular flows is lower with the higher τ of900K.

We repeated the experiments for other input traffic patterns,and, in general, obtained consistent results.

B. Prototype Evaluation

Using the prototype that we developed (described inSec. IV), we characterize the performance of our Async sys-tem in live networks. We conducted a pilot study and collecteddata from five different users over 17 days with Android-basedSamsung Galaxy phones. Our study involves four 3G BSs inBangalore, India, of two leading service providers (supportingmore than 100 million users in India). We instrument theAsync client App to automatically download a video file withan EDT (of {1, 2, 3} hour) for three times a day between8 a.m. and 7 p.m. For lack of space, we only report ourmeasurements for two BSs (referred to as B1 and B2), from thetwo service providers. B1 is in a residential area while B2 isin a commercial area. Through our prototype-based evaluation,we answer the following questions: What is an appropriateduration to observe a reliable achievable throughput (AT) valueand is it reasonable enough that it is non-interfering withregular flows? What is a reasonable setting for threshold τ?How do the CDF of AT and τ values vary over days? Howmany times does a client need to poll to download a content fora given a threshold τ and an EDT value? How many downloadsmeet the EDT?

Duration to observe AT: For this experiment, we downloada 77MB video file by varying the observation duration from2 sec to 20 sec. We let the client app continuously poll withoutany break and repeat the experiment on two days at differenthours. As shown in Fig. 15, for probing durations ≥ 12 sec,AT reaches its limit and remains fairly stable. This value canbe used by the Async proxy to observe AT values and limitthe interference to a short duration. Thus, for the rest of theexperiments, we choose 12 sec as the probing duration. Asecond set of measurements show that most of the connectionsmaintain the AT values for a duration of one to two minutesbefore facing any deviation. Based on this observation, werecommend epochs that are approximately 1 min long and usean epoch duration of 1 min in our simulations.

Achievable throughput CDF and τ : In Figs. 16 and 17,we plot the CDF of AT on three weekdays for B1 and fourweekdays for B2, respectively. These measurements show that,for a given BS, the CDF of AT values remains reasonablypredictable. Based on the measurements, we compute themedian value of the CDF as the threshold τ . For B1, τ =412 Kbps while for B2, τ = 554 Kbps, which also confirms awell-known observation that a BS in commercial areas is moreloaded than a BS in residential areas.

Meeting EDTs: In a controlled experiment, we initiatedmultiple transfers of a single file at the same instant by three

devices with three different EDTs through B1. As shown inthe Figs. 18 and 19, the Async system distributed the pollsand hence the downloads over time and aligned them as perthe EDTs, in an attempt to minimize the overhead of pollsat a given time. As shown in Fig. 20, for a given τ , theEDT required to deliver the content can be reasonably metfor different requests (of different file sizes). Thus, a serviceprovider can vary τ to control interference while trying tomeet the promised EDTs. Over 17 days across five users, theAsync proxy experienced 57 downloads and only 7 downloadsexceeded the promised EDT (6 having a 1 hr EDT and one a 2hr EDT), resulting in a success rate of 87%. All of the exceededrequests completed within 15 mins after the promised EDTs.

VI. RELATED WORK

We discuss prior work related to Async in three broadcategories: (1) managing demand for data in cellular networks,(2) background transfer with controlled interference, and (3)enabling dynamic pricing in communication networks.

Managing data growth in cellular networks. A simpleand commonly employed option to reduce peak-time loadis capping the usage. While this is unpopular with users tobegin with, as reported in [1], the bandwidth consumption gapbetween tiered and unlimited data plans is narrowing with theincreased consumption of cloud-based services. Another ap-proach is to use WiFi or Femto-offloading [19]. This approachis complementary, and also benefits from Async to maximizethe yield of such alternate network deployments.

Background transfers. Background transfer mechanisms suchas TCP-Nice [10] and TCP-LP [20] may be extendable toachieve the same notion as Async in wireless networks.However, the techniques depend on increased delays as anindication to backoff background flows for causing minimalinterference to foreground flows. This idea does not work wellin cellular networks for two reasons: (1) delays also vary due towireless channel scheduling, channel quality fluctuations, etc.,(2) proportional fair scheduling at BSs results in backgroundflows getting their fair share of resources before they start per-ceiving congestion-related delays, thereby causing interferencethat scales with number of background flows.

Opportunistic transmission of background flows in cellularnetworks has been considered in [21]. While the higher-levelidea therein is similar to that of Async, [21] is limited toperforming a feasibility analysis and determining the scopeof background transfers for lowering congestion (using realcellular data traces). It neither considers incentivizing time-shifting of traffic nor does it deal with the design of the variouscomponents that are necessary to realize an end-to-end systemthat can be deployed in practice.

Congestion-aware pricing. Differential pricing to combatcongestion and share network resources efficiently is a well-studied topic in multiple disciplines [22]. [23] and [13] proposeto smoothen traffic by providing incentives of the form ofhigher access rates during off-peak hours. However, theseschemes miss fine-timescale opportunities of capacity avail-ability in cellular networks. Decoupling selection of EDTsfrom scheduling of flows before the EDTs (i.e., delivery-shift approach) significantly improves the chance of utilizingthe opportunities. More recently, TUBE [3] has set a nicebackground for renewing this direction of research in thecellular domain. However, as mentioned in Sec. II, TUBE

0

300

600

900

1200

1500

1800

2100

2400

2700

3000

2 4 6 8 10 12 14 16 18 20

Avg T

hro

ugh

pu

t (K

bp

s)

Probe duration

Probes on B1Probes on B2

Fig. 15. Stabilization of AT over time.

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 500 1000 1500 2000 2500 3000

Pro

bab

ilit

y

Achievable throughput (Kb)

06-0305-0304-03

Fig. 16. Evolution of CDF of AT for B1.

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

0.8

0.9

1

0 500 1000 1500 2000 2500 3000

Pro

bab

ilit

y

Achievable throughput (Kb)

19-0220-0221-02

Fig. 17. Evolution of CDF of AT for B2.

0

10

20

30

40

50

60

70

3 6 9 12 15 18 21 24 27 30

Fil

e A

ccu

mu

late

d (

MB

)

Time bins (6 min each)

77MB 1 Hour EDT77MB 2 Hour EDT77MB 3 Hour EDT

Fig. 18. Download progression as per EDTs.

0

40

80

120

160

200

240

280

320

360

400

440

3 6 9 12 15 18 21 24 27 30

Th

rou

gh

pu

t (K

bp

s)

Time bins (6 min each)

77MB 1 Hour EDT77MB 2 Hour EDT77MB 3 Hour EDT

Fig. 19. Download rates as per EDTs.

4 MB 25 MB 77 MB 123 MB 177 MB0

10

20

30

40

50

60

70

80

File Size

De

live

ry t

ime

(m

in)

Fig. 20. EDT choices for different file sizes.

falls under the Request-shift category, operating at coarsegranularity and does not also incorporate delivering contentwithin any expected time.

VII. CONCLUSION

In this work, we proposed an approach to enable asyn-chronous content delivery for smart data pricing that canalleviate congestion and improve yield in mobile networks.We believe that the approach proposed in the paper is onlyillustrative, and various versions of delayed delivery are inter-esting avenues for future work. The applicability of delayeddelivery for better network resource management is broad.For instance, with the emergence of significant entertainmentcontent, a number of educational services with free access toinformative videos, etc., we believe that Async can enable alow-cost video delivery solution to people in developed anddeveloping world alike. Async can also be adapted to enableopportunistic and low-cost upload of social networking contentor personal cloud updates.

REFERENCES

[1] “Cisco visual networking index: Global mobile data traffic forecastupdate, 20122017,” http://www.cisco.com/en/US/solutions/collateral/ns341/ns525/ns537/ns705/ns827/white paper c11-520862.html.

[2] Y. Zhang and A. Arvidsson, “Understanding the characteristics ofcellular data traffic,” in CellNet, 2012.

[3] S. Ha, S. Sen, C. Wong, Y. Im, M. Chiang, “TUBE: Time-DependentPricing for Mobile Data,” in ACM SIGCOMM, 2012.

[4] “3GPP, TS 23.203 Policy and charging control architecture,”http://http://www.3gpp.org/ftp/Specs/html-info/23203.htm.

[5] “Affordable pricing for cellular data networks,”https://docs.google.com/forms/d/12Ac6LUzJ7qJI-I8r-xSGlpquBBcKUrG8edHPaDGQOyE/viewform.

[6] V. Gabale, U. Devi, R. Kokku, and S. Kalyanaraman, “Asynchronouscontent delivery and pricing in cellular data networks,” in Smart DataPricing, S. Sen, C. Wong, S. Ha, and M. Chiang, Eds. John Wiley &Sons, Inc.,, to appear.

[7] X. Liu, F. Dobrian, H. Milner, J. Jiang, V. Sekar, I. Stoica, and H. Zhang,“A case for a coordinated internet video control plane,” SIGCOMMComput. Commun. Rev., 2012.

[8] “Airtel-live,” http://www.airtel.in/airtellive/home.

[9] “Bandwidth hog netflix to help cablevision manage network de-mands,” http://blogs.wsj.com/digits/2013/01/08/bandwidth-hog-netflix-to-help-cablevision-manage-network-demands/.

[10] A. Venkataramani, R. Kokku, and M. Dahlin, “Tcp nice: a mechanismfor background transfers,” SIGOPS Oper. Syst. Rev., 2002.

[11] P. Kay, L. Massoulie, and B. Wang, “Emulating low-priority transportat the application layer: a background transfer service,” in Proceedingsof the joint international conference on Measurement and modeling ofcomputer systems, ser. SIGMETRICS ’04/Performance ’04, 2004.

[12] J. G. Proakis, “Digital Communications,” in McGraw-Hill Companies,01-Oct-1995.

[13] N. Laoutaris and P. Rodriguez, “Good things come to those who (can)wait or how to handle delay tolerant traffic and make peace on theinternet,” in ACM HotNets-VII, 2008.

[14] “The network simulator – ns-2,” http://www.isi.edu/nsnam/ns, July2012.

[15] “3GPP, Release 5,” http://www.3gpp.org/specifications/Releases/article/release-5.

[16] “Eurane user guide (release 1.6),” http://eurane.ti-wmc.nl/eurane/, June2010.

[17] “3GPP, Release 99,” http://www.3gpp.org/specifications/Releases/article/release-1999.

[18] C. Joe-Wong, S. Ha, and M. Chiang, “Time-Dependent BroadbandPricing: Feasibility and Benefits,” in ICDCS, 2011.

[19] A. Balasubramanian, R. Mahajan, and A. Venkataramani, “Augmentingmobile 3g using wifi,” in Proceedings of the 8th international confer-ence on Mobile systems, applications, and services, ser. MobiSys ’10,2010.

[20] A. Kuzmanovic and E. Knightly, “TCP-LP: Low-priority service viaend-point congestion control,” IEEE/ACM Transactions on Networking,vol. 14, no. 4, pp. 739 –752, Aug 2006.

[21] U. Paul, M. Buddhikot, and S. Das, “Opportunistic traffic schedulingin cellular data networks,” in DySPAN, 2012.

[22] S. Sen, C. Joe-Wong, S. Ha, and M. Chiang, “Pricing Data: Past Pro-posals, Current Plans, and Future Trends,” arXiv, July 2012, availableat http://arxiv.org/abs/1201.4197.

[23] P. Key, L. Massoulie, and M. Vojnovic, “Farsighted users harnessnetwork time-diversity,” in Proceedings of 24th IEEE INFOCOM,vol. 4, 2005, pp. 2383–2394.