Exploiting In-network Caches for Efficient and ...

Exploiting In-network Caches for Efficient and Robust Communication: ISP and End-point Strategies Dongsu Han March 2011

School of Computer Science Carnegie Mellon University Pittsburgh, PA 15213

Thesis Committee: Srinivasan Seshan, Chair Peter Steenkiste, David Andersen, Dina Papagiannaki (Telefonica Research), Aditya Akella (University of Wisconsin-Madison)

Submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy

School of Computer Science, Carnegie Mellon University, Pittsburgh, PA, USA

Abstract Traffic demand on the Internet is rapidly growing both at an unprecedented rate and scale. This growth is largely driven by transfer of multimedia content. With the ever increasing demand for content, it is increasingly important to design a network that scales with such demand. Another related challenge is providing robustness. As the traffic demand grow rapidly, congestion related loss is likely to be more common in networks whose capacity do not catch up with the demand. Therefore, efficient and robust content delivery is becoming ever more important. To cope with such demand caching content is becoming increasingly popular. This thesis answers the following question: Given the trend of ubiquitous caching in the network, how should end-points and ISPs change their behavior? In response to this question, we explore novel schemes in which in-network caches are leveraged to achieve enhanced network efficiency, communication robustness and user performance, and argue that end-hosts and networks should adapt their strategies to take advantage of various forms of in-network caches.

1

Introduction

Traffic demand on the Internet is rapidly growing both at an unprecedented rate and scale. In 2009, IP traffic grew by 45%. Market reports project that this trend will continue, and the total Internet traffic will approach a zettabyte by 2014 with an expected compound annual growth rate (CAGR) of 34% [1]. This growth is largely driven by multimedia content. Multimedia traffic is increasing 76% every year on average [64]. Cisco projects that “the sum of all forms of video (TV, video on demand, Internet, live video communication, and P2P) will account for over 91% of the global consumer traffic by 2013” [1]. Many factors contribute to the growth in multimedia traffic, including the desire for higher quality video, the increase in the number of video titles, and changes in viewing patterns. Users now expect to watch any video at their convenience, and “time-shifted” viewing patterns are becoming the norm [64] with the use of digital video recorders (DVRs) and on-line video services such as YouTube and Hulu. This explosive growth pose an important challenge to the network– network capacity simply cannot keep up with the exponentially growing demand. Therefore, it is increasingly important to design a network that scales with the demand for content. Another related challenge is providing robustness. As the traffic demand grows rapidly, congestion related loss is likely to be more common in networks whose capacity do not catch up with the demand. Therefore, efficient and robust content delivery is becoming ever more important. With this increasing demand for content transfer, we note that network caches are becoming increasingly popular at various levels. Traditional application proxies, such as Web proxies, employ application specific caching where the application layer explicitly interacts with caches. Similarly, ISPs maintain caches at strategic locations to provide value added services such as networked digital video recording in IPTV networks [17]. On a larger scale, content distribution networks (CDN) replicate application-level data at different locations for performance and availability. On the other hand, in systems such as DOT [72], the transport layer is made responsible for interacting with caches. For example, DOT provides a transport service, at a layer just above the traditional transport, that effectively utilizes end-point [72] and/or in-network caches [23]. As network technologies advance, storage elements are also being increasingly integrated into the network. In such systems, caching is done at the network layer in a transparent manor. For example, packet cache has been incorporated in routers [9] and end-points [5] to remove duplicate transfers of content over the same link. Similarly, WAN optimizers [67] use transparent caches between two networks for better throughput. Future Internet architectures, such as XIA [8] and CCN [41], promote content-addressable networks and facilitate caching within the network. We believe that the motivation for removing duplicate transfers of content and providing new functionality in the network will continue to drive the trend of ubiquitous caches. In this thesis, we answer the following question: Given the trend towards ubiquitous caching in the network, how should end-points and ISPs adapt their behavior? In this thesis, we explore novel schemes that leverage in-network caches to achieve enhanced network efficiency, communication robustness and user performance, and argue that end-hosts and networks should adapt their strategies to better take advantage of in-network 1

caches. As listed above, there are various ways in which cache has been used in the network. To systematically explore the problem space, we classify the use of caching into three categories based on the primary layer of interaction with network caches: application, network and transport layer. We explore end-point’s strategies in each of these environments: • First, we explore strategies for application-level caching in an environment where endpoints cooperatively caches application-specific content to reduce the network traffic. Here, we ask the following question: How should we best utilize the caches to improve network efficiency and reduce demand on bottleneck links? This work focuses on the traditional use of caching to minimize the network bandwidth that ISPs have to provision for. To this end, we explore careful content placement, aggressive prefetching and off-peak bandwidth utilization using end-point caches. • Second, we explore an environment in which the network layer explicitly interacts with innetwork caches. We ask the following questions: Can we can extend the benefits of caching beyond network bandwidth savings? What strategies should end-points employ to improve robustness and user performance given in-network caching? This work focuses on exploring a fundamentally different use of caching in environments where network-level caching is done transparently to applications. • Finally, we design a future Internet transport protocol that captures explicit interactions between end-points and in-network caches. This work focuses on transport-level interaction between end-points and caches. Here, we address the following question: What are the core functions and mechanisms that should be provided in the transport protocol for end-points to take advantage of the in-network caches efficiently? As such, the thesis systematically covers various environments in which caching is used, and explore strategies within each environment. This thesis, however, does not solve all problems in using in-network caches for content delivery. For example issues such as designing in-network caches to scale in bandwidth, and designing a scalable content routing protocol are valid and important, but are beyond the scope of this thesis. We note that many previous [10, 65, 70] and on-going works [41] that try to address the problems show promising results. Three main bodies of work address each of the questions listed above: Addressing ISP’s challenges in bandwidth provisioning This body of work explores aggressive prefetching with cooperative application-level end-point caching in residential access networks. We carefully place the content considering its popularity, connectivity between end-point caches and storage space. Once the content placement is determined, we prefetch content from a video-on-demand service to a set of end-point caches during off-peak hours. The end-points use opportunistic local connectivity provided by home networking technologies, such as WiFi and MoCA, to stream content within the neighborhood on demand. Based on this idea, we design a system that that uses end-point caches in conjunction with the alternative forms of connectivity. Our evaluation shows that the system reduces access network bandwidth by 48%. This work is discussed in Section 2. 2

End-point’s strategies for robust communication Content-aware networks, including redundancy elimination networks [9], CCN [41], and XIA [8], employ in-network caches to remove duplicate transfer of content at the network level. In this work, we explore end-point’s strategies for robust communication in this environment where caching is transparent to users and applications. We propose carefully introducing redundancy to provide robustness against packet loss leveraging content-aware network’s core property that redundant transmissions are effectively suppressed. We show that introducing redundancy in a way that the network understands significantly reduces the bandwidth cost of redundancy, while retaining the benefits of redundant data transfer. In particular, this work explores how caching can improve robustness for time-critical communication, and studies the network-wide effect of introducing redundancy in content-aware networks where packets are (temporarily) cached in routers. We show that redundancy-based recovery combined with in-network caching provides enhanced performance and usability benefits to applications. This work is discussed in Section 3. Transport protocol for a new Internet architecture New Internet architectures [8, 41] often incorporate, in their design, mechanisms to take advantage of caches in routers. In particular, XIA provides the ability to perform in-network optimization of content transfer at routers, and enables the in-network caches to potentially participate in content delivery. However, little work has been done to show how end-points might efficiently interact with these in-network caches. Traditional transport protocols capture the interaction between end-points, but do not involve routers in the middle. This work will study how a transport protocol might support the interaction between end-points and caches in the routers. The proposed work will address the following problem: What are the core functions and mechanisms that should be provided in the transport protocol to take advantage of the in-network caches efficiently? The challenge of this work is to design such a protocol without placing too much overhead at the routers. This proposal is discussed in Section 4.

2

Addressing ISP’s challenges in bandwidth provisioning

In [32], we explored aggressive prefetching strategies in access network environment to relieve bottlenecks in residential access networks. Using a high-definition video-on-demand service as an example, we presented an ISP and end-point’s caching and content placement strategy to minimize the aggregate bandwidth demand on access links. Based on this content placement strategy, we designed a VoD system that utilizes off-peak hour bandwidth to prefetch content to end-point caches and uses cached content in conjunction with alternative forms of local connectivity to stream content on demand.

2.1

Primary Contributions

• Explored aggressive prefetching strategies that utilize off-peak hour bandwidth in access network environments.

3

• Surveyed existing technologies provide alternative connectivity within the neighborhood. • Designed a system that monitors the connectivity, adjusts content placement based on content popularity, connectivity and storage capacity, and dynamically schedules content delivery to minimize the access network bandwidth use. • Quantified the benefit of the system using realistic workload and various parameter settings. Our evaluation shows that the system reduces access network bandwidth by 45% while still providing a high-quality VoD service.

2.2

Motivation and Approach

This section outlines the problem and the approach used to solve the problem. This growth in traffic demand has been especially hard on connectivity to the home. This is creating painful challenges for today’s consumer ISPs whose already-strained access networks were never designed to handle this load. For example, Korea Telecom’s access network traffic increased by 125% annually, compared to 40% growth in its core [80]. To better understand the nature of the problem, we illustrate the basic network structure of ISPs in Figure 1. Current designs rely on statistical multiplexing at the aggregation point exploiting the bursty nature of traditional data traffic. The National Broadband Plan (NBP) [2], for example, assumes 17:1 over-subscription at the aggregation point. However, aggressive over-subscription does not work well with streamed video; a typical DSL network designed to provide broadband Internet service to 384 subscribers can only support 27 (7%) simultaneous streams of 1Mbps video. Therefore ISPs are investing to expand their infrastructure, which carries significant cost and typically spans many years. However, access networks are especially hard to upgrade because 1) most access network equipment resides outside the plant; and 2) the number of DSLAM and cable nodes far exceeds the number of COs or headends.1 For example, the NBP allocated less than 5% of the total cost to upgrade the connectivity between the COs because they are relatively well-provisioned, while most cost is associated to upgrading access networks. While major network upgrades are infrequent, deployment of in-home devices such as home routers, set-top-boxes (STB), and DVRs has seen explosive growth. ISPs often install and connect these devices to customers’ home networks using technologies such as WiFi and Multimedia over Coax Alliance (MoCA). Such technologies, originally designed for connectivity within a home, can also provide connectivity between homes. We leverage such local resources to augment the hard-to-upgrade infrastructure in providing a video-on-demand service. In this work, we explore aggressive prefetching of video content to minimize the peak bandwidth demand that ISPs have to provision for, and design a system optimized for an ISP’s videoon-demand (VoD) service based on prefetch content. The system uses off-peak hour bandwidth to prefetch data into a collection of end-point caches in a neighborhood, and utilizes local resources to stream content within the neighborhood on demand. 1

The number of headends in the US is 7,853 [56] Based on subscribers per cable nodes and per headends the number of cable nodes is roughly an order of magnitude lager than the number of headends.

4

Middle Mile Transport (>95% fiber)

Access Network Second Mile Headend

Last Mile coax tap

Public Internet

Aggregation Point (Cable Node)

Internet gateway

Central Office (CO)

Modem, STB, WiFi, MoCA, DVR , etc

Aggregation Point (DSLAM/Fiber Splitter)

Figure 1: Basic network structure [2]

2.3

Design Overview

This section outlines the requirements and design of the system described in the previous section. Requirements The system must address four challenges: First, the placement must take into account the local connectivity between neighbors in a particular neighborhood, the popularity of different content, and the possibility of failures in the local network. Second, the system must keep the content of the DVR disks up-to-date to remain effective despite popularity changes, new content introduction and connectivity changes. Third, the system must continually monitor what interhome connectivity options are available to inform the placement algorithm and decide dynamically at run-time how to retrieve content from neighbors. Finally, the system must be robust to mishaps such as device failures and popularity misprediction. System Components Based on the requirements outlined in the previous section we now describe a VoD system that uses local resources and supports a large number of videos (>10,000) comparable to that of Netflix online. Our proposed neighborhood VoD system has three basic (physical) components (Figure 2): centralized video servers, a centralized management server, and per-home STBs connected locally to one another and by broadband. The video servers store the master copy of all content that the system provides, and the in-home STBs have local replicas of popular content distributed across their disks. The management server serves two functions: placement generation and directory service. Placement generation involves computing the desired placement of the content in the neighbor-nodes, given system parameters such as the viewing patterns of videos and the connectivity between neighbors. The directory service maps content to a set of replicas (homes) within the neighborhood. With this set of physical resources, the logical flow of system operation is as follows: 1. The placement generator computes the ideal replication of content across STBs based on current neighborhood connectivity and popularity of movies.

5

STB

Neighborhood networks Local connectivity

STB

CO

ISP ISP network

CO

VoD server Management server

STB

Figure 2: Overview of the system 2. The replication service uses off-peak bandwidth to download content to the STBs to achieve the target placement. 3. The transfer service dynamically decides where to fetch content given users’ request and satisfies a significant fraction of the request using local connectivity and content stored on neighbors’ STBs. 4. The monitoring system monitors user requests each day to update connectivity and popularity information.

Content Placement The placement generator generates a content placement on a weekly basis. The content placement algorithm is based on the following optimization framework. Optimization. Let B be the matrix that represents the aggregate local bandwidth between peers, where Bi,j is the bandwidth from node i to j provided by the local connectivity (the diagonal elements are set to infinity). A movie is divided into m chunks. xi,j is a zero-one indicator variable that indicates whether node i has chunk j, and yi,j,k is a variable that indicates whether node i should requestPchunk node k. The optimization problem then is: P j from 2 Minimize ( j xi,j ) (storage factor) such that

P P k

j

yi,j,k = m

∀i, ∀j,

X

(m chunks requested)

yi,j,k = 1 (A chunk is requested exactly once)

k

yi,j,k ≤ xk,j

(availability constraint)

j0 ∀i, ∀j 0 X X yi,j,k ≥ R p Bi,k k∈N ode j≤j 0

(bandwidth/streamability)

where p is the fraction of local bandwidth that a node can use. It reflects the expected number of concurrent users that share the local links and may view the local content simultaneously. It is determined as p = 1/ d {number of neighbors in a single broadcast domain} × {fraction of active users at peak} × {hit rate of movies in the neighborhood} e through iteration.

6

We minimize the squared sum of storage use instead of the linear sum to spread chunks more evenly to neighbors for resilience to node failures. We call this term storage factor. The streamability constraint guarantees that all neighbors can stream the content placed in the neighborhood given the bandwidth constraint. Our solution exhibits three key properties: 1) Once a movie is placed in the neighborhood, every neighbor can instantly stream the movie without fetching the content from the remote ISP server. 2) To support instant playback in case of random seek and jump, minimal ISP bandwidth is used initially, but the content is streamable using local resources. 3) The overhead due to popularity changes and node failures is minimized. The first two requirements for streamability are crucial in supporting streamed content and in making efficient use of the access network by broadcasting the popular movies only once to stage them.

2.4

Selected Results

Setup We first evaluate our system using a nine-node testbed. The testbed provides experimental results on a neighborhood-scale deployment using real hardware. Then, these results are used to parametrize our simulator, which can scale the experiments up to the 500–1000 homes that a CO or a node in a cable provider’s hybrid-fiber-coax (HFC) network might serve. In both experiments, each neighbor has a 1TB disk. We emulate a video content library containing 10,000 one-hour videos, each of which is encoded at 10Mbps. As with prior work, we use a Zipf-like distribution with a skew factor α = 0.3 to represent the popularity distribution of videos in the library [4, 81]. In a Zipf-like distribution, 1 content popularity (P) is related to its rank (r): Pr ∼ r1−α Viewing pattern. Multimedia viewing varies diurnally with a “prime time” peak. We use a fixed probability distribution that represents this behavior with a 24 hour period to simulate the arrival of video requests. The shape of the distribution is based on the findings by Qiu et al. [63]. We assume that the probability that a home requests a video at prime time is 40%. This probability gradually falls to 10% in the next 12 hours and comes back up to 40% in 24 hours. The videos thus requested are sampled according to the Zipf-like distribution mentioned above. The same video library and workload is used for the testbed experiments and simulations. Result In the steady state, the ISP’s bandwidth is used for on-demand content that is not stored in the neighborhood and for replicating new content into the neighborhood to accommodate popularity changes. The aggregated bandwidth use for a neighborhood of 500 homes is shown in Figure 3. w/o NaN shows the amount of bandwidth used to serve 500 homes using only the video server. w/ NaN is the bandwidth demand when the content is pre-seeded according to the target placement. w/ NaN + content update shows the aggregate bandwidth of w/ NaN plus two broadcast channels that are only allocated during off-peak hours to update the caches. Note that these additional prefetch channels do not add to the ISP’s costs as they only affect average bandwidth consumption; in fact, they trade average bandwidth for a dramatic reduction in peak bandwidth: With ISP dynamic channel allocation, ISPs can deallocate the broadcast channel during the peak hours and 7

Bandwidth (Mbps)

3000

w/o NaN w/ NaN w NaN + content update

2500 2000 1500 1000 500 0 0

3

6

9

12

15

18

21

24

Time (hour)

Figure 3: 24-hour ISP bandwidth use of 500 neighbors

achieve 45% savings in peak bandwidth. The 95 percentile bandwidth was reduced by 45% (from 1890Mbps to 1037Mbps), and the average bandwidth by 46% (from 651Mbps to 1197Mbps).

2.5

Related Work

The idea of utilizing off-peak bandwidth has previously been explored. Studies on delay tolerant bulk transfer [52, 49] showed that utilizing off-peak bandwidth provide a viable and economic method for very large bulk data transfer across the Internet. Delay tolerant networking [42, 25] also uses end-point and in-network caches to mask intermittent network connectivity. Our system uses off-peak bandwidth to deliver content to the neighborhood caches during off-peak hours and use local connectivity for delivering on-demand within the neighborhood. The system also builds on previous work in multicast-VoD and peer-assisted VoD. MuticastVoD. Traditionally, periodic broadcasting schemes [74, 6, 37] have been used to serve very popular content by broadcasting that content continuously on several channels. Prefix caching [68], combined with these schemes, can reduce the number of broadcast channels [24, 30]. Similarly, caching has been used in conjunction with multicast to disseminate popular content [36, 69]. These schemes typically require very frequent accesses to popular content to batch multiple requests or support a relatively small number (20–40) of popular videos due to various limitations [30]; the system falls back to unicast for the remaining content. Our system, by cooperatively using local storage and connectivity, makes a different and more radical bandwidth trade-off appropriate to today’s environment. Peer-assisted VoD. Many Peer-assisted VoD studies take a content provider-centric view whose goal is to reduce the provider’s bandwidth, using overlay multicast [13, 20, 47] or peer unicast [38, 50, 44, 40]. Recent work combines the P2P and CDN approaches to deliver video streams [39, 79]. Others, who take an ISP-centric view [71, 73, 17, 15] also propose an ISP-driven deployment of ISP-controlled in-home storage, and explore content pre-placement and caching strategies in DSL networks. Suh et al. [71] propose pushing the content to homogeneous peers in a 8

DSL network and present placement algorithms and theoretical analysis. NaDa [73] demonstrates the approach’s effectiveness in saving energy cost. Borst et al. [17] propose a cooperative caching algorithm to minimize the total network footprint using hierarchical caches. Our approach, instead, uses varying level of local connectivity to limit the bandwidth demand at the access network. Our approach can also coexist with caches at different parts of the network. CPM’s [29] primary goal is to reduce the server bandwidth. It combines on-demand multicast with peer assisted unicast. Our primary goal is to reduce the access network bandwidth.

3

RPT: End-point strategies for robust communication

In [31], we presented Redundant Packet Transmission, an end-points’ strategy that takes advantage of in-network caches for robust communication. Redundant Packet Transmission (RPT) leverages these in-network caches and intelligently sends multiple copies of the same packet. While this may seem high-overhead, we show that RPT on content-aware networks can effectively support a variety of time-critical applications with far lower overhead and higher degree of robustness than existing approaches such as FEC-based coding.

3.1

Motivation and Problem

A variety of current and future Internet applications require time critical or low latency communication. Example applications include live/interactive video streams, online games, and video-based calls (e.g., Apple’s FaceTime), all of which send real-time data. Certain classes of inter-datacenter transfers, such as mirroring financial data, also require real-time communication [12]. Within a data center, many soft real-time applications that interact with users require low latency communication [7]. Market reports indicate that real-time video, including Internet TV and streams from monitoring cameras, will account for 13% of consumer Internet traffic [1] in the coming few years. The central challenge in supporting such applications is protecting them from network loss. For example, data loss in video streams can degrade video quality and user experience. Acknowledgmentbased retransmission protocols are traditionally used to provide reliability, but they are not appropriate for real-time communication as retransmissions triggered by timeouts can take several RTTs and violate applications’ timing constraints [66, 51]. Because of the intrinsic limitations, more sophisticated end-to-end behavior such as selective retransmission [26, 58], play-out buffering [58], and modification to codecs [66] are often required to augment retransmission based loss recovery. FEC is another option that is widely used in real-time communication today. However, the use of FEC is constraining in many ways. (1) In FEC, the receiver cannot recover lost packets until the batch is complete. This limits the size of the batch. For example, at most 5 packets are typically batched in video chat applications such as Skype [75]. (2) Small batch size makes FEC more susceptible to bursty loss. For example, adding a single coded FEC packet for every five original data packets is not to recover from two consecutive lost packets. Therefore, in practice, the amount of redundancy used is high, e.g., 20% to 50% [18, 21, 75],which is much higher than the underlying

9

packet loss rate. (3) Furthermore, FEC needs to adapt to changing network conditions [16, 82], which makes parameter tuning even more difficult. In this work, we explore end-point based redundancy scheme that takes advantage of the in-network caching employed by content-aware networks. In content-aware networks, such as Redundancy-Elimination (RE) enabled networks [9, 3] and content-centric networks [41, 8], the network effectively removes duplicate transfer of data across the same link using cached content in routers. We show that introducing redundancy in a way that the network understands significantly reduces the bandwidth cost of redundancy, while providing high robustness and performance benefits.

3.2

Primary Contributions

This work makes four major contributions [31]: • We show that in-network caching can be leveraged to provide robust communication. More specifically, we show that adding redundancy in a way that network understands reduces the cost and increases the benefits of loss protection significantly. • Using Redundant Streaming (RS) as an example, we highlight various features of RPT and establish that is a promising candidate to use in several practical scenarios; we show that RPT decreases the data loss rate by orders-of-magnitude more than typical FEC schemes applicable in live video communications, and delivers higher quality video than FEC using the same bandwidth budget. RS provides fine-grained control to signal the importance of data and satisfies tight delay constraints. Yet, it is easy to use as its performance is much less sensitive to parameter selection. • We show that constant bitrate RPT flows are prioritized over non-RPT flows, but can share bandwidth fairly by incorporating TCP friendly rate control into RS. • Finally, we show that RPT provides an efficient and cost-effective loss protection mechanism in general content-aware networks including SmartRE networks, CCN networks, and networks with lossy links.

3.3

Design Overview

This section summarizes the basic design of [31]. Basic Idea The basic idea of redundant packet transmission (RPT) is to send multiple copies of the same packet. If at least one copy of the packet avoids network loss, the data is received by the receiver. In current network designs, transmitting duplicate packets would incur large overhead. For example, if two duplicates of every original packet are sent, the overhead is 200% and a 1Mbps stream of data would only contain 0.33Mbps of original data. However, in network with RE, duplicate copies of packet are encoded to small packets, and this overhead would be significantly reduced. 10

Decompressed packet Compressed packet Packets

A’ A’ A

RE Encode

RE Decode

RE cache

Virtual Output Queues Incoming interfaces

RE cache

Switching Outgoing Fabric interfaces

Figure 4: Illustration of how Redundant Packet Transmission works in a redundancy elimination router. We explore the details of RPT through Redundant Streaming (RS), a special variant of RPT optimized for delivering real-time video streams. For ease of exposition, we assume RS flows travel through a network with unmodified hop-by-hop RE [9] enabled on every router and end host, and packet losses happen only due to congestion. However, we also explore relaxed requirements and RPT in content-aware networks of various forms in [31]. Figure 4 illustrates how RPT works with redundancy elimination. From the input link, three duplicate packets are received. The first packet is the original packet A, and the other two packets A’, are encoded packets which have been “compressed” to small packets by the previous hop RE encoder. The compressed packet contains a reference (14 bytes in our implementation) used by the RE decoder of the next hop. At the incoming interface, the packets are fully decoded, generating 3 copies of packet A. They are then queued at the appropriate output queue. The figure illustrates a router that uses virtual output queuing. When congestion occurs, packets are dropped at the virtual output queue. Only packets that survive the loss will go through the RE encoder on the output interface. If some of the copies survive the network loss, they will again be encoded to small packets by the RE encoder. In this manner, multiple copies of packets provide robustness to loss and RE in the network reduces bandwidth overhead due to any additional copies. Packet Sequencing in RS In RS, each original packet is transmitted as soon as it is generated by the video encoder. We use two parameters to control RS’s transmission of redundant packets: redundancy (r) and delay (d). Figure 5(a) shows the packet sequence of an RS flow. Redundant packets are sent compressed in between two original packets. In general, a large redundancy parameter r increases reliability at the cost of bandwidth overhead and packet processing overhead. Assuming total bandwidth is fixed, if we increase redundancy, the amount of bandwidth left for original data is reduced. The delay parameter specifies the number of original packets between two redundant packets that encode the same data. The first redundant packet of sequence number n is sent after the original packet of sequence number (n + d). If the loss is temporally bursty, having a large interval 11

d: delay r: replication factor

Original packet Redundant packet

…

…

…

…

(k+1) (k+2) (k+1)-d, …, (k+1)-(r-1)d, (k+1)-rd

Sequence k Number k-d, …, k-(r-1)d, k-rd

(a) Sequence of packets sent by RS(r)

… k

k-2 k-4

(k+1)

(k+2)

k-1 k-3

k

k-2

(k+3)

(k+4)

k+1 k-1

k+2 k

(k+5)

(b) Sequence of packets sent by RS(3) with d=2

Figure 5: Sequence of packets sent by RS between two redundant packet will help. However, extra delay incurs extra latency in recovering from a loss. So, delay (d) can be adjusted to meet the timing requirements of applications. TCP-friendly RS Our result show that RS flows get prioritized in the network over non-RS flows. Thus, enforcing a high sending rate may be much easier with RS than FEC schemes. However, in some environments, fair bandwidth sharing may be more desirable than prioritizing RS flows. To achieve this goal, we adapt TCP friendly rate control (TFRC) [28] to RS. This is achieved by carefully adjusting the estimated loss event rate at the receiver [31].

3.4

Selected Results

Setup We use a combination of real-world experiments, network measurements and simulations. We implemented a RE encoder and decoder using the Click modular router [46], and created a router similar to that of Figure 4. Using this implementation, we created a testbed of a hop-byhop RE network. We use implementation-based evaluation to show the overall end-to-end performance of RS, and simulations to unravel the details and observe how it interacts with other cross traffic. To obtain realistic packet traces and loss patterns from highly multiplexed networks, we also performed active measurements to collect real-world Internet packet traces. We also created background traffic and simulated RS and FEC flows in a hop-by-hop RE network using the ns-2 simulator. End-to-end Video Performance: RS improves video quality over FEC. Using our testbed based on our hop-by-hop RE router implementation, we created a video streaming application that uses redundant streaming. We created a dumbbell topology where an RE router in the middle connects two networks, one at 100Mbps and the other at 10Mbps. To create loss, we generate 12

Encoded RS 37.3 dB FEC 36.9 dB Naive 37.5 dB

Received 37.1 dB 35.3 dB 31.4 dB (a) RS flow

0.4

FEC(10,7)

0.2

38

Naive FEC(10,k) FEC(10,k) random FEC(100,k) FEC(100,k) random RS(r) RS(k) random

FEC(10,6)

0.3

Figure 6: Snapshot of the video

FEC(10,8)

Averge PSNR of the Video (dB)

Overhead per 1Mbps Stream (Mbps)

Table 1: Average PSNR of videos

FEC(10,9)

0.1

RS(4) 0

1E-04

RS(3) 1E-03

Naive

RS(2) 1E-02

1E-01

Data Loss Rate (%)

1E+00

(b) Naive flow

37

Encoded video at sender Received video

36 35 34 33 32 31 30

1E+01

Figure 7: Data loss and overhead: RS flows Figure 8: Sensitivity to parameter: RS’ perperform much better than FEC flows with formance is not sensitive, but FEC’s perforsmall group size. mance is quite sensitive to its parameter setting. traffic from the well-connected network to the 10Mbps bottleneck link. When the network is congested, packets are dropped at the output queue of the router. We generated a 1Mbps UDP video stream and long-running TCP flows as background traffic. We adjust the background traffic to create a 2% loss on the video flow. We then compare the video quality achieved by RS, Naive, and FEC senders that use the same amount of bandwidth. Table 1 shows the average PSNR of the video. RS performs 1.8dB better than FEC and 5.7dB better than Naive schemes. Figure 6 shows snapshots of the video. Low Overhead and High Robustness: RS decreases the data loss rate by orders of magnitude more than FEC schemes applicable to live video communications. Figure 7 shows the overhead and data loss rate of FEC, Naive and RS schemes under 2% loss. Realistic traffic cross traffic was generated to create congestive loss. FEC with small group size (FEC(10,k)) have large overhead compared to RS. With the same overhead, RS decreases the data loss rate by orders of magnitude more than FEC with small group size. On the other hand, FEC with large group size (FEC(100,k)) have small overhead with low data loss rate. However, they are not fit for live 13

FEC(10,6) Original method 180ms Alternative method 240ms

FEC(100,92)

RS(3)

1.3sec 2.4sec

60ms -

Table 2: Maximum one-way latency communication because of the increased latency. (See Table 2.) Sensitivity to Parameter Selection: RS is not sensitive to parameter selection unlike FEC. Our results show that the performance of RS is not sensitive to its parameter selection. Furthermore, RS separates the redundancy decision from delay, allowing applications to independently tune the parameters unlike FEC. Therefore, delay parameter can be set to meet the latency the requirement of an application. Figure 8 shows the quality of the video seen by the receiver compared to the encoded quality at the sender under FEC, Naive and RS schemes with varying parameter. The quality of encoded video decreases as the overhead of redundancy is increased. For example, the Naive sender fully uses the 1Mbps of bandwidth to encode the video, while the FEC(10,5) sender only uses half the bandwidth to encoded the video and uses the other half to encode redundant information. The gap between the encoded video and the received video within the same scheme represents the effect of loss. Since the Naive sender does not have any protection against loss, the resulting video quality is severely degraded from the original video. The result shows that RS flows perform better than any FEC flows regardless of the parameter, and their performance is stable across different parameter settings. In contrast, FEC’s performance is sensitive to the parameter selection. TCP-friendly Redundant Streaming: We evaluated TCP-friendly Redundant Streaming in a highly multiplexed network using a simulation. The results show that RS can be adapted to behave in a TCP friendly manner and the performance of TCP-friendly RS exceeds that of a normal TFRC flow or a TRFC flow that uses FEC.

3.5

Related Work

Using end-point packet caches for reliability has been explored in the context reliable multicast. In these works, packet caching is primarily used to achieve scalability by avoiding message implosion. In Scalable Reliable Multicast [27] (SRM), each receiver caches recently received packets and retransmits the packet upon receiving a NACK from other receivers. Other schemes [59, 34, 78] use a local recovery scheme in which receivers are grouped into local regions based on their physical location. A repair server in each region caches the multicast packet and is responsible for performing error recovery for all receivers in the region. Related works on robust Internet video streaming can be grouped into two categories: networkbased approach and video coding-based approach. 14

Network-based: In a network-based approach, the goal is to reduce the loss seen by the receiver. Redundant Streaming falls into this category. Network-based approach can be further classified into retransmission based error recovery and FEC based error recovery. Related work in this area was discussed in Section 3.1. Video coding based: In a video coding based approach, video coding is modified to exhibit graceful degradation of video quality in the event of loss. The goal of video coding based approach is different from RS in that this approach does not try to minimize data loss, but to minimize the impact of loss. Therefore, this approach is largely orthogonal to our scheme. Layered video coding [54] splits up the video into multiple layers arranged in a hierarchy where each additional layer is designed to provide progressive refinement. It has been combined with receiver-driven multicast [53] to deliver video across users with different loss rates. Multiple Description (MD) source coding [61] uses FEC in conjunction with layered coding scheme to improve robustness against packet loss. ChitChat [75] propose a new coding scheme that achieves smooth degradation of video quality in the event packet loss. SoftCast [43] works in wireless environment. It modifies video encoding scheme and the physical layer of a wireless link to increase robustness against bit errors.

4

Proposed Research: Transport Protocol for XIA

The proposed work will address how clients interact with in-network caches in a future Internet architecture. This interaction is captured by a transport protocol between clients and caches. We plan to design and evaluate a transport protocol that is optimized for cached content delivery in the context of XIA. XIA supports content-aware networking in which content can be directly addressed and routed to. Users use content identifier to request content and the network serves the request by sending the content to the client. Previous work in XIA [8], only addresses the network layer, but falls short in providing a transport protocol that defines the interaction between the client and the network elements who are serving the content.

4.1

Research Issues

The new transport differs from traditional transport protocol, such as TCP, in two regards, which leads to significantly different design requirements: • The new transport protocol specializes in cached content transfer. This results in many different design requirements. For example, multiple sources can have the same content and participate in the content transfer. The transport protocol should be able to choose from one or more content sources to download the content. One option is use a single source, but the data transfer should be switched to a different path when network conditions or connectivity changes. Another option is parallel data transfer from multiple sources. TCP only provides data transfer between two end hosts, which significantly differ from this case. 15

Another related issues is the granularity of congestion control in this environment where a single client makes multiple chunk requests. We should address how each chunk transfer maps to a “flow”, a unit of congestion control. For example, when a client makes 100 chunk requests to the same content source, it is not clear if they should all be a different flow or they should be mapped to a single flow. We believe that this problem becomes more important when designing a transport protocol for content transfer because a single client requesting multiple chunk will be the common case and each chunk may be small. Also, being able to support different granularity of control is important. For example, an autonomous domain may want to allocate bandwidth on an aggregated flow that comes from its customers to differentiate their bandwidth allocation, or to achieve a fair allocation between them. In the current Internet, this is hard to do with TCP. Supporting shared request and verification is also important in the new transport protocol. Unlike TCP, a packet with the same CID and same sequence number will always contain the same content. The transport protocol may be able to take advantage of this and send one response to satisfy multiple request on a particular link. Verification of content also becomes more important as content may be served by untrusted caches in the network. XIA uses self-certifying names which enable verification of the content after downloading a chunk of content. However, the size of the chunk is determined by each application. It also represents a trade-off in that small chunk size increases the overhead of content routing, whereas large chunk size effectively delays verification until the whole chunk is received. • The new transport protocol should efficiently support in-network optimization by leveraging in-network caches. For example, content with in a packet should be easily identified for routers to easily cache content. With TCP, this involves in inspecting transport layer headers and maintaining per-flow state such as its initial sequence and port numbers. This is not acceptable because routers should be able to process a large number of packets. Cached content should also be efficiently served by routers while minimizing the state at the routers for scalability. TCP does not satisfy this requirement because it maintains per-flow state as well as timers for retransmission at the sender, which would burden routers who serve content from their cache. Moreover, connection establishment cost of TCP and its convergence time may be too high compared to say a single 32KB chunk transfer. Therefore, connection establishment and congestion control need to be redesigned. Table 3 summarizes issues in transport protocol design categorized into three parts. The first class of requirements is traditional requirements that all transport protocols share. Thus, the new transport protocol should satisfy these requirements. Second class is specific to cached content delivery. We will explore our initial ideas on each item in Section 4.2. Third class of requirements lists more advanced functions that might be incorporated into the new transport protocol. We will try to incorporate support for the optional requirements while designing a new transport protocol. However, it is likely that a single research paper would not be able to fully address these issues. For example, multi-path transport alone has been addressed in multiple papers [33, 14, 76], but is still under active research. While it is best to incorporate all solutions in this work, for practical reasons the optional requirements will take low priority and will be considered 16

Category

Item

Comment

Traditional

Efficiency and fairness Recovery and reliability Binding Interception Multi-source Receiver-driven Granularity of congestion control Support for caching Sub-chunk verification Security of congestion control Shared request and advanced recovery Multi-source, multi-path

Related to congestion control

Content-specific

Optional

Implicit vs explicit binding Intercepting content request. How to use multi-source Minimizing sender efforts Caching with minimal packet inspection Protection from malicious hosts Removing duplicate transfers of content Advanced support for multi-source, -path

Table 3: Design considerations for transport protocol. optional.

4.2

Proposed Approach

The transport protocol allows a client to fetch content potentially from multiple sources. We divide this process into multiple steps and discuss our initial ideas. Implicit vs Explicit Binding In XIA, an intent can be bound to a specific host or any other XIA identifier. For example, a content request can be bound to a content source, which forces the network to route the packet to the content source before reaching the content. One of the most important issues in content-specific transport is whether a request for a content should be bound to a specific content source in the data transfer phase. With explicit binding, a packet is first routed to the content source directly, but gets routed to the content at the content source using the source route/binding support provided by the XIA’s network layer. (E.g., a request packet’s destination looks like AD:HID:CID, where AD is a domain identifier, HID a host identifier, and CID a chunk identifier.) On the other hand, implicit binding does not specify the content source, and send a packet directly to the content. (E.g., a request packet’s destination looks like AD:CID.) The two alternatives represent a trade-off. The advantage of explicit binding is that it allows flow-level interception while allowing existing end-to-end congestion control mechanisms to be leveraged. Because explicit binding specifies a specific content source, it also naturally lends itself to leveraging multiple sources for recovery, or selecting a path or a content source of application’s choice. On the other hand, implicit binding gives more freedom of interception at the network. Each packet can be intercepted independently, and be served by a different cache. This allows a more fine grained content sharing and more flexibility in routing content requests.

17

However, implicit binding gives end-points much less control and functions traditionally performed by the end-points are made more challenging. Most significantly, end-to-end congestion control becomes challenging for the following reasons: First, with implicit binding, we have to guarantee some amount of stability in the forwarding path in order for the client to perform traditional end-to-end congestion control. If every packet of a CID transfer goes to different caches, end-to-end congestion control becomes impossible. Second, each content transfer is very short. Average Web object size is 8KB and Bittorrent chunk is around 256KB [8]. Even with TCP, it takes only 3 and 8 RTTs respectively to complete the transfer assuming slow start. With a fast convergence congestion control, such as XCP, the RTT-time of a transfer will be even smaller. With such small flows, achieving efficiency is hard because short noisy flows will dominate the link. Achieving fairness is even more difficult because XCP still relies on additive-increase-multiplicativedecrease (AIMD) for fairness. Such issue can be resolved in explicit binding using congestion manger style approach discussed later in the section. Apart from congestion control, it also becomes difficult to specify a different source in case of failure. For example, when a client wants to use a different source for recovery, implicit binding cannot enforce this. With implicit binding, the network has to decide whether to send this packet to a different source. This suggest that explicit binding is needed, unless there is significant support at the network. Sub-chunk verification also becomes more important when implicit binding is used because a piece of content may come from different sources. One example that uses implicit binding is CCN [41]. This inevitably puts more control on the routers, and results in a very different design. In CCN, many functions that are traditionally performed at the end-host are supported by the network routers. For example, CCN does not use end-to-end congestion control, but relies on routers to handle congestion control. CCN routers also control selecting alternative paths or sources in recovery. Such mechanism is viable in CCN because the network enforces that request and response packets traverse symmetric paths, and routers keep per-packet state. However, such mechanism is not in place in XIA. Given the challenges and marginal benefits of implicit binding, we believe that explicit binding is a better alternative, and explore this option initially. The rest of the section explores our design that employs explicit binding. Search/Interception In the beginning of a chunk transfer, the client sends out a request for a piece of content (chunk) with its identifier CID. Note that this packet is not bound, but may contain a fallback address. The packet eventually gets to the content source as part of the routing or gets intercepted by intermediate node who cached the content. The content source sends a response back to the client confirming that it has the content. The content source may send information such as what parts of the content it has as part of the response. As such, the client learns about the content source who is willing to serve the content. Alternatively, multicast search can be used in search for content source. In this case, the network delivers the initial request packet to possibly multiple sources that have this CID. We propose routers duplicate the request whenever find more than one path to the CID. To limit the number of packet duplication, client specifies in the packet the maximum number of duplicate packets that can be generated, and the network enforces it. There are security concerns such as denial-of-service

18

resulting from massive multicast. For practical purposes, we can limit the maximum number of duplicate packets to a few (not greater than 10). Even for huge file transfers, Bit-torrent uses peers on the order tens. The enforcement can be done at edge routers, who will over-write the maximum number of duplicate packets when a packet violates this limit. Multi-source At this point, the client knows possibly multiple content sources that it can download the content from. The issue is whether a client should download a chunk from multiple sources or from a single best source. Transferring from multiple source may benefit the client because performance and reliability may increase. However, if this is the norm most routers who cache content by inspecting packets will only see fragments but not the whole chunk. This makes it difficult to verify the content of the cache. Moreover, routing in this environment is also challenging because routers have to decide whether to announce a chunk when it only has a fraction of the chunk. Even if such practice is allowed, it adversely affect the content routing because of the increased sized of the routing information. We therefore propose using only a single source for a single chunk. However, parallel transfer occurs at a higher level when a client requests multiple chunks. Receiver Driven Protocol Traditional transport protocols often have transport control block associated to each connection, store packets while waiting for acknowledgments, and have timers for retransmission. However, such state is not desirable in this environment as routers who cache the content may be involved in the content transfer. Therefore, an important requirement is to minimize the resource use at the content source (router). We propose using a receiver driven transport protocol to relieve the burden of maintaining per-connection state on the network routers both in the connection establishment phase and the data transmission phase. Here, we briefly sketch the protocol. A client sends a request bound to the particular content source (explicit binding). This request packet contains a requested byte range of the content (less than a MTU) and is signed by its HID. The content source then verifies that the packet is sent by the client and response back with the content. The content source can optionally caches the HID to bypass the verification for subsequent request packets. This step is considered as connection establishment. This is similar to T/TCP [19]’s connection establishment optimized for short message exchanges (request/reply) between a client/server pair. T/TCP has known vulnerabilities [22], but our scheme fix this by using the intrinsic security provided by XIA. Domain Name System’s (DNS) has similar query/response type packet exchange, but is rarely used with congestion controlled transport layer. Subsequent requests are similar to the initial request, but can may skip per-packet verification, and rely on the cached verification result. Recovery is also performed at the receiver as we will see later in the section. Therefore, the content source does not have to keep any state. Congestion Control and its granularity Content transfer might be short-lived, and every new chunk transfer can potentially be satisfied by different sources. Earlier in the section, we showed why this pose a challenge in congestion control. In this environment, a congestion control that provide fast convergence to the available bandwidth is needed. However, TCP style congestion control do not satisfy this requirement. We 19

therefore propose using XCP [45] style congestion control. We plan to combine XCP with receiver driven protocol. We propose aggregating flows that come from the same content source for aggregate congestion control. Reusing congestion information will benefit performance and stability of the network especially in this environment where majority of data transfer will be short. We also believe that the number of content source used will be less than the number of chunk a client will request and that aggregation will provide significant benefit. Our approach is similar to the approach presented in Congestion Manager [11]. It also allows the end host to have control over the allocation of bandwidth to each micro-flows that flow between a pair of end hosts. We will also explore providing different granularities of congestion control. For example, an autonomous domain (AD) may want to perform congestion control on aggregated flows to allocate bandwidth fairly between traffic coming from two different ADs regardless of the number of flows each AD has. We will leverage XCP’s fairness controller’s differential bandwidth allocation mechanism to perform congestion control on aggregate flows. For this, an ingress router at an AD will classify flows and maintain a flow count for every aggregated flows. The ingress router will label packets with its flow count and a weight on the aggregated flow. Routers inside the AD will then use this information to compute feedback. Support for Caching Packets that contain cachable content identifies the content explicitly to help routers to cache content. The XIA network layer address already contains the chunk ID as its source address. We propose adding length, offset of the content contained in the packet and the offset within the packet in the content header which follows the network header. Verification After receiving a chunk, a client has to verify that the data received corresponds to the chunk requested. This can be done by using the self-certifying property of the CID. However, an important issue is whether to allow sub-chunk verification. If the chunk is large, we may want to early detect damages and avoid the malicious source. We have two options: 1) The transport protocol may request sub-chunk hashes and perform checking to detect a corruption early. For example, the authoritative content source can divided a chunk into 16 or 32 sub-chunks and compute the hashed value. The hashed value can be obtained by the client in parallel to the data transfer. 2) The application can divide the large chunk into small chunks. On drawback is that this potentially increases the cost of routing. However, using XIA’s addressing, CIDs can be represented hierarchically (e.g., CID1:CID2). Reliability and Recovery We first propose using traditional end-to-end retransmission based recovery in our the receiver driven protocol. Alternatively, one of the two optimizations can be done if we assume routers hold recent packet caches. We will optionally explore these three advanced functions: 1) Instead of end-to-end retransmission, localized recovery can be done leveraging the recent packet cache. Retransmission request can travel up the path to the content source and will eventually reach a router who dropped the packet. The router will have the packet in its recent packet cache, and the retransmission request will trigger retransmission from the router. However, in this case, it might interfere with congestion control because every packet can potentially come from different caches that are on 20

Time

Task

May – August 2011 Design a transport protocol September – December 2011 Implement and evaluate the system January 2012 Submit to SIGCOMM 2012 February – May 2012 Write dissertation Table 4: Proposed time line. the path and feedback only reflects the path that the packet has actually taken. Moreover, this approach is only effective when the request and response packet traverse symmetric paths. Another challenge is that XIA addressing makes it difficult to only permit on-path interception. We will further explore the feasibility of this approach. 2) We can rely on other content sources for recovery. In this case, granularity of recovery can be a packet or a chunk. 3) Another alternative is redundancy based recovery as explored in Section 3.

4.3

Related Work

As shown earlier, several ideas from traditional transport protocols are leveraged. Here, we summarize other related works. Other transport protocols: Stream Control Transmission Protocol (SCTP) provides reliable message-based communication without enforcing ordering between different messages [57]. An SCTP connection can also fail-over to a different interface within the same host. Receiver driven transport protocols were shown to have performance benefit as well as functionality gain in wireless mobile networks [35] and improve web browsing on the Internet [55]. However, Kuzmanovic and Knightly showed that existing receiver driven protocols have security vulnerabilities with misbehaving receivers and need careful re-design [48]. Multi-path TCP [33, 14] leverages multiple paths between two end-points and provides performance benefits. Recent work on mtcp [14] focuses on congestion control to achieve fairness. Other related works: Downloading content from multiple sources is popular in BitTorrent-like peer-to-peer communication. Many studies [62, 60] explored its performance and robustness. The notion of interception has been explored in the form of Performance Enhancing Proxies (PEP). PEP commonly intercepts a TCP connection in the middle of the network to bridge discrepancies of two different networks. A classic example is a wireless network that employ a split-connection between its wireless network and the back-haul wired network. Broder et. al. presented an extensive survey on PEP in [77].

21

4.4

Time Line for Proposed Work

We expect to write one research paper as a result of the proposed research. Table 4 describes the timeline to complete the remainder of this thesis.

References [1] Cisco visual networking index: Forecast and methodology, 20092014. http://www.cisco.com/, 2010. [2] National broadband plan - the broadband availability gap. http://www.broadband.gov/plan/ broadband-working-reports-technical-papers.html, 2010. [3] Infineta systems. http://www.infineta.com, 2011. [4] Soam Acharya and Brian Smith. Characterizing user access to videos on the world wide web. In Proc. MMCN, 2000. [5] Bhavish Aggarwal, Aditya Akella, Ashok Anand, Athula Balachandran, Pushkar Chitnis, Chitra Muthukrishnan, Ramachandran Ramjee, and George Varghese. EndRE: an end-system redundancy elimination service for enterprises. In Proc. NSDI, pages 28–28, Berkeley, CA, USA, 2010. USENIX Association. [6] C.C. Aggarwal, J.L. Wolf, and P.S. Yu. A permutation-based pyramid broadcasting scheme for video-on-demand systems. In Proc. IEEE ICMCS, 1996. [7] Mohammad Alizadeh, Albert Greenberg, David A. Maltz, Jitendra Padhye, Parveen Patel, Balaji Prabhakar, Sudipta Sengupta, and Murari Sridharan. Data center TCP (DCTCP). In Proc. ACM SIGCOMM, 2010. [8] Ashok Anand, Fahad Dogar, Dongsu Han, Boyan Li, Michel Machado Hyeontaek Lim, Wenfei Wu, Aditya Akella, David Andersen, Srinivasan Seshan John Byers, and Peter Steenkiste. XIA: An architecture for an evolvable and trustworthy Internet. Technical Report CMU-CS-11-100, Carnegie Mellon University, January 2011. [9] Ashok Anand, Archit Gupta, Aditya Akella, Srinivasan Seshan, and Scott Shenker. Packet caches on routers: the implications of universal redundant traffic elimination. In Proc. ACM SIGCOMM, 2008. [10] Ashok Anand, Chitra Muthukrishnan, Steven Kappes, Aditya Akella, and Suman Nath. Cheap and large CAMs for high performance data-intensive networked systems. In Proc. NSDI, pages 29–29, Berkeley, CA, USA, 2010. USENIX Association. [11] H. Balakrishnan, H. S. Rahul, and S. Seshan. An Integrated Congestion Management Architecture for Internet Hosts. In Proc. ACM SIGCOMM, pages 175–187, Cambridge, MA, September 1999. [12] Mahesh Balakrishnan, Tudor Marian, Ken Birman, Hakim Weatherspoon, and Einar Vollset. Maelstrom: transparent error correction for lambda networks. In Proc. USENIX NSDI, 2008. [13] Suman Banerjee, Bobby Bhattacharjee, and Christopher Kommareddy. Scalable application layer multicast. In Proc. ACM SIGCOMM, Pittsburgh, PA, August 2002. [14] S´ebastien Barr´e, Olivier Bonaventure, Costin Raiciu, and Mark Handley. Experimenting with multipath tcp. SIGCOMM Comput. Commun. Rev., 40:443–444, August 2010. [15] S. Bessler. Optimized content distribution in a push-VoD scenario. In Proc. Next Generation Internet Networks, April 2008. [16] Jean-Chrysostome Bolot, Sacha Fosse-Parisis, and Don Towsley. Adaptive FEC-based error control for internet telephony. In Proc. IEEE INFOCOM, 1999. [17] Sem Borst, Varun Gupta, and Anwar Walid. Distributed caching algorithms for content distribution networks(to appear). In Proc. IEEE INFOCOM, San Deigo, CA, March 2010. [18] O. Boyaci, A.G. Forte, and H. Schulzrinne. Performance of video-chat applications under congestion. In Proc. IEEE International Symposium on Multimedia, December 2009.

22

[19] R. Braden. T/TCP – TCP Extensions for Transactions Functional Specification, July 1994. RFC 1644. [20] Miguel Castro, Peter Druschel, Anne-Marie Kermarrec, Animesh Nandi, Antony Rowstron, and Atul Singh. SplitStream: High-bandwidth content distribution in cooperative environments. In Proc. SOSP, October 2003. [21] Luca De Cicco, Saverio Mascolo, and Vittorio Palmisano. Skype video responsiveness to bandwidth variations. In Proc. ACM NOSSDAV, 2008. [22] Marco de Vivo, Gabriela O. de Vivo, Roberto Koeneke, and Germinal Isern. Internet vulnerabilities related to TCP/IP and T/TCP. SIGCOMM Comput. Commun. Rev., 29, January 1999. [23] Fahad Dogar, Amar Phanishayee, Himabindu Pucha, Olatunji Ruwase, and David Andersen. Ditto - a system for opportunistic caching in multi-hop wireless mesh networks. In Proc. ACM MobiCom, San Francisco, CA, September 2008. [24] Derek Eager, Mary Vernon, and John Zahorjan. Bandwidth skimming: A technique for cost-effective video-ondemand. In Proc. IEEE MMCN, 2000. [25] Vijay Erramilli, Mark Crovella, Augustin Chaintreau, and Christophe Diot. Delegation forwarding. In Proceedings of the 9th ACM international symposium on Mobile ad hoc networking and computing, MobiHoc ’08, pages 251–260, New York, NY, USA, 2008. ACM. [26] Nick Feamster and Hari Balakrishnan. Packet loss recovery for streaming video. In Proc 12th International Packet Video Workshop, 2002. [27] S. Floyd, V. Jacobson, S. McCanne, C. G. Liu, and L. Zhang. A Reliable Multicast Framework for Lightweight Sessions and Application Level Framing. In Proc. ACM SIGCOMM, pages 342–356, Cambridge, MA, September 1995. [28] Sally Floyd, Mark Handley, Jitendra Padhye, and J¨org Widmer. Equation-based congestion control for unicast applications. In Proc. ACM SIGCOMM, 2000. [29] V. Gopalakrishnan, B. Bhattacharjee, K.K. Ramakrishnan, R. Jana, and D. Srivastava. CPM: Adaptive video-ondemand with cooperative peer assists and multicast. In Proc. IEEE INFOCOM, 2009. [30] Yang Guo, Subhabrata Sen, and Don Towsley. Prefix caching assisted periodic broadcast: Framework and techniques to support streaming for popular videos. In Proc. IEEE ICC, 2001. [31] Dongsu Han, Ashok Anand, Aditya Akella, and Srinivasan Seshan. RPT: Re-architecting loss protection for content-aware networks. Under submission, 2011. [32] Dongsu Han, David Andersen, Michael Kaminsky, Dina Papagiannaki, and Srinivasan Seshan. Hulu in the neighborhood. In Communication Systems and Networks (COMSNETS), 2011 Third International Conference on, pages 1 –10, January 2011. [33] Huaizhong Han, Srinivas Shakkottai, C. V. Hollot, R. Srikant, and Don Towsley. Multi-path tcp: a joint congestion control and routing scheme to exploit path diversity in the internet. IEEE/ACM Transactions on Networking, 14:1260–1271, December 2006. [34] Hugh W. Holbrook, Sandeep K. Singhal, and David R. Cheriton. Log-based receiver-reliable multicast for distributed interactive simulation. In Proc. SIGCOMM, pages 328–341, 1995. [35] Hung-Yun Hsieh, Kyu-Han Kim, Yujie Zhu, and Raghupathy Sivakumar. A receiver-centric transport protocol for mobile hosts with heterogeneous wireless interfaces. In Proc. MobiCom, 2003. [36] Kien A. Hua, Ying Cai, and Simon Sheu. Patching: a multicast technique for true video-on-demand services. In Proc. ACM MULTIMEDIA, 1998. [37] Kien A. Hua and Simon Sheu. Skyscraper broadcasting: a new broadcasting scheme for metropolitan video-ondemand systems. In Proc. the ACM SIGCOMM, 1997. [38] Cheng Huang, Jin Li, and Keith W. Ross. Can Internet video-on-demand be profitable? In Proc. ACM SIGCOMM, Kyoto, Japan, August 2007.

23

[39] Cheng Huang, Angela Wang, Jin Li, and Keith W. Ross. Understanding hybrid CDN-P2P: why limelight needs its own Red Swoosh. In Proc. ACM NOSSDAV, 2008. [40] Yan Huang, Tom Z. J. Fu, Dah-Ming Chiu, John C.S. Lui, and Cheng Huang. Challenges, design and analysis of a large-scale P2P-VoD system. In Proc. ACM SIGCOMM, 2008. [41] Van Jacobson, Diana K. Smetters, James D. Thornton, Michael F. Plass, Nicholas H. Briggs, and Rebecca L. Braynard. Networking named content. In Proc. ACM CoNEXT, 2009. [42] Sushant Jain, Kevin Fall, and Rabin Patra. Routing in a Delay Tolerant Network. In Proc. ACM SIGCOMM, Portland, OR, August 2004. [43] Szymon Jakubczak, Dina Katabi, and Hariharan Rahul. SoftCast: One video to serve all wireless receivers. Technical Report MIT-CSAIL-TR-2009-005, Massachusetts Institute of Technology, February 2009. [44] Vaishnav Janardhan and Henning Schulzrinne. Peer assisted VoD for set-top box based IP network. In ACM P2P-TV Workshop, 2007. [45] Dina Katabi, Mark Handley, and Chalrie Rohrs. Congestion Control for High Bandwidth-Delay Product Networks. In Proc. ACM SIGCOMM, Pittsburgh, PA, August 2002. [46] Eddie Kohler, Robert Morris, Benjie Chen, John Jannotti, and M. Frans Kaashoek. The click modular router. ACM Transactions on Computer Systems, 18(3):263–297, August 2000. [47] Dejan Kostic, Adolfo Rodriguez, Jeannie Albrecht, and Amin Vahdat. Bullet: High bandwidth data dissemination using an overlay mesh. In Proc. SOSP, October 2003. [48] A. Kuzmanovic and E.W. Knightly. Receiver-centric congestion control with a misbehaving receiver: Vulnerabilities and end-point solutions. Computer Networks, 5(10):2717 – 2737, 2007. [49] Nikolaos Laoutaris, Georgios Smaragdakis, Pablo Rodriguez, and Ravi Sundaram. Delay tolerant bulk data transfers on the internet. In ACM SIGMETRICS, pages 229–238, 2009. [50] Shao Liu, Rui Zhang-Shen, Wenjie Jiang, Jennifer Rexford, and Mung Chiang. Performance bounds for peerassisted live streaming. In Proc. ACM SIGMETRICS, Annapolis, MD, June 2008. [51] Dmitri Loguinov and Hayder Radha. On retransmission schemes for real-time streaming in the internet. In Proc. IEEE INFOCOM, pages 1310–1319, 2001. [52] Massimiliano Marcon, Nuno Santos, Krishna P. Gummadi, Nikolaos Laoutaris, Pablo Rodriguez, and Amin Vahdat. Netex: efficient and cost-effective internet bulk content delivery. In Proc. ANCS, pages 30:1–30:2, 2010. [53] S. McCanne, V. Jacobson, and M. Vetterli. Receiver-driven Layered Multicast. In Proc. ACM SIGCOMM, pages 117–130, Stanford, CA, August 1996. [54] Steven McCanne, Martin Vetterli, and Van Jacobson. Low-complexity video coding for receiver-driven layered multicast. IEEE Journal on Selected Areas in Communications, 15(6):982–1001, 1997. [55] Puneet Mehra, A. Zakhor, and C. De Vleeschouwer. Receiver-driven bandwidth sharing for tcp. In Proc. INFOCOM, March 2003. [56] Industry data - ncta.com. http://www.ncta.com/Statistics.aspx, 2010. [57] L. Ong and J. Yoakum. An Introduction to the Stream Control Transmission Protocol (SCTP). Internet Engineering Task Force, May 2002. RFC 3286. [58] Christos Papadopoulos. Retransmission-based error control for continuous media applications. In Proc. NOSSDAV, 1996. [59] S. Paul, K.K. Sabnani, J.C.-H. Lin, and S. Bhattacharyya. Reliable multicast transport protocol (rmtp). Selected Areas in Communications, IEEE Journal on, 15(3):407 –421, April 1997.

24

[60] Michael Piatek, Tomas Isdal, Thomas Anderson, Arvind Krishnamurty, and Arun Venkataramani. Do incentives build robustness in BitTorrent? In Proc. 4th USENIX NSDI, Cambridge, MA, April 2007. [61] R. Puri and K. Ramchandran. Multiple description source coding using forward error correction codes. In Proc. Asilomar conference on signals, systems, and computers, pages 342 –346, 1999. [62] Dongyu Qiu and R. Srikant. Modeling and performance analysis of BitTorrent-like peer-to-peer networks. In Proc. SIGCOMM, Portland, OR, August 2004. [63] Tongqing Qiu, Zihui Ge, Seungjoon Lee, Jia Wang, Qi Zhao, and Jun Xu. Modeling channel popularity dynamics in a large IPTV system. In Proc. ACM SIGMETRICS, Seattle, WA, June 2009. [64] K. K. Ramakrishnan. CPM - adaptive VoD with cooperative peer assist and multicast. Keynote Speech at the IEEE Workshop on Local and Metropolitan Area Networks, September 2008. [65] Sylvia Ratnasamy et al. A scalable content-addressable network. In Proc. SIGCOMM, San Diego, CA, August 2001. [66] I. Rhee. Error control techniques for interactive low-bit rate video transmission over the Internet. In Proc. ACM SIGCOMM, Vancouver, British Columbia, Canada, September 1998. [67] Riverbed. http://www.riverbed.com/. [68] Subhabrata Sen, Jennifer Rexford, and Donald F. Towsley. Proxy prefix caching for multimedia streams. In Proc. IEEE INFOCOM, 1999. [69] Simon Sheu, Kien A. Hua, and Wallapak Tavanapong. Chaining: A generalized batching technique for videoon-demand systems. In Proc. IEEE ICMCS, 1997. [70] Ion Stoica, Robert Morris, David Karger, M. Frans Kaashoek, and Hari Balakrishnan. Chord: A scalable peerto-peer lookup service for Internet applications. In Proc. SIGCOMM, San Diego, CA, August 2001. [71] Kyoungwon Suh, C. Diot, J. Kurose, L. Massoulie, C. Neumann, D. Towsley, and M. Varvello. Push-to-peer video-on-demand system: Design and evaluation. Selected Areas in Communications, IEEE Journal on, 25(9), December 2007. [72] Niraj Tolia, Michael Kaminsky, David G. Andersen, and Swapnil Patil. An architecture for Internet data transfer. In Proc. 3rd Symposium on Networked Systems Design and Implementation (NSDI), San Jose, CA, May 2006. [73] Vytautas Valancius, Nikolaos Laoutaris, Laurent Massoulie, Christophe Diot, and Pablo Rodriguez. Greening the Internet with nano data centers. In Proc. ACM SIGCOMM CoNext Conference, December 2009. [74] S. Viswanathan and T. Imielinski. Pyramid broadcasting for video on demand service. In Proc. IEEE MMCN, 1995. [75] Jue Wang and Dina Katabi. ChitChat: Making video chat robust to packet loss. Technical Report MIT-CSAILTR-2010-031, Massachusetts Institute of Technology, July 2010. [76] Damon Wischik, Costin Raiciu, Adam Greenhalgh, and Mark Handley. Design, implementation and evaluation of congestion control for multipath tcp. In Proc. NSDI, 2011. [77] L. Yang, R. Dantu, T. Anderson, and R. Gopal. Forwarding and Control Element Separation (ForCES) Framework. Internet Engineering Task Force, April 2004. RFC 3746. [78] Rajendra Yavatkar, James Griffoen, and Madhu Sudan. A reliable dissemination protocol for interactive collaborative applications. In Proc. ACM Multimedia, pages 333–344, 1995. [79] Hao Yin, Xuening Liu, Tongyu Zhan, Vyas Sekar, Feng Qiu, Chuang Lin, Hui Zhang, and Bo Li. Design and deployment of a hybrid CDN-P2P system for live video streaming: experiences with LiveSky. In Proc. ACM Multimedia, 2009. [80] Hosung Yoon. KT FTTH network evolution. Talk at the Optical Fiber Communication Conference, March 2009.

25

[81] Hongliang Yu, Dongdong Zheng, Ben Y. Zhao, and Weimin Zheng. Understanding user behavior in large-scale video-on-demand systems. In In Proc. EuroSys, 2006. [82] Xiaoqing Zhu, Rong Pan, Nandita Dukkipati, Vijay Subramanian, and Flavio Bonomi. Layered internet video engineering (LIVE): Network-assisted bandwidth sharing and transient loss protection for scalable video streaming. In Proc. IEEE INFOCOM, pages 226–230, 2010.

26