Better End-to-End Adaptation Using Centralized Predictive Control

Transcription

1 Better End-to-End Adaptation Using Centralized Predictive Control Junchen Jiang July 2, 2015 School of Computer Science Carnegie Mellon University Pittsburgh, PA Thesis Committee: Hui Zhang, Co-Chair Vyas Sekar, Co-Chair Peter Steenkiste, Srinivasan Seshan, Ion Stoica (UC Berkeley) Submitted in partial fulfillment of the requirements for the degree of Doctor of Philosophy. Copyright c 2015 Junchen Jiang

2 Keywords: June 25, 2015

3

4 iv

5 Abstract Transport layer and application layer of network stack use end-to-end adaptation protocols (e.g., TCP and bitrate-adaptive video) to achieve high performance by continuously adapting endpoint behavior to changes of network conditions. The traditional belief is that these protocols must be run independently by endpoints to achieve desirable performance. In essence, they use reactive logic triggered only by locally observable events. For instance, TCP reacts to a packet timeout by halving the congestion window. In this thesis, we argue that centralized predictive control can lead to better endto-end adaptation and large performance improvement at both transport layer and application layer. We show that it is feasible to decouple adaptation logics from endto-end adaptation protocols and centralize them into a global controller that makes predictive control using a global view of different connections performance. For instance, TCP with centralized predictive control can predict the best congestion window using other similar TCP sessions performance. To deliver the promised performance benefits of centralized predictive control, we must address two key technical challenges. First, we present prediction algorithms, which accurately predict the optimal adaptation behavior of endpoints by exploiting the structural information of the global view (e.g., some connections are subjected to same network bottleneck). Second, we present designs of a scalable control platform, which leverage the persistence of optimal decisions to minimize negative impacts of the inherent delay between the controller and widely distributed endpoints. This thesis will present algorithms and system designs of centralized predictive control for both transport layer and application layer. We show that our approach can lead to better performance for TCP, Internet video and real-time communication applications like Skype. Our preliminary experiments have shown significant improvement of Internet video quality by centralized predictive control.

6 vi

7 Contents 1 Introduction Roadmap Background and Related Work Background Related Work CPC Overview CPC vs. Today s Approaches Challenges of CPC Key Insights of CPC Accurate Data-Driven Prediction Logics Technical Overview My Prior Work Proposed Work Scalable CPC Control Platform Technical Overview My Prior work Proposed Work Timeline and Risk Analysis Timeline Risk Analysis Bibliography 25 vii

8 viii

9 List of Figures 3.1 Three components of CPC architecture (local logics, global controller and CPC API), and the logical control loop (measurement collection, predictive control and pushing adaptation decisions) A relatively small number of combinations of critical features (i.e., critical clusters) are shared by many bad quality video sessions Slight staleness (e.g., 30 minutes) of critical features (i.e., structure) does not impact prediction accuracy significantly The best CDNs for different content providers persist on a timescale of tens of seconds to minutes Benefits of CFA: more accurate prediction on video quality and better quality through accurate prediction Benefits of DDA: more accurate prediction on throughput and better bitrate selection based on accurate throughput prediction Splitting CPC controller into three control loops ix

10 x

11 List of Tables 1.1 Mapping my prior work and proposed work to CPC s insights and solutions to address the challenges Some examples of how different end-to-end adaptation protocols impact performance of different layers by tuning their adaptation parameters Terminology used in this document and their description xi

12 xii

13 Chapter 1 Introduction The ultimate goal of end-to-end adaptation protocols in transport layer (e.g., TCP) and application layer (e.g., DASH [2] video) is to ensure high performance by adapting endpoints behaviour to changes of network conditions and resource availability. For instance, TCP tunes congestion window in response to network congestion or queue buildup. DASH video players tune bitrate and CDN to cope with throughput fluctuation and availability of content. Traditional tenet of end-to-end adaptation protocols states that, for fast reaction to network events and fate-sharing principles [6], they should be implemented and run independently by endpoints. For instance, TCP s instant reaction to packet loss when observed by end hosts is necessary to preserve packet conservation [17]. Fate-sharing principle requires that critical states of a connection (e.g., sequence numbering) should be only kept by end hosts. However, with this distributed design, today s end-to-end adaptation has fundamental limitations, including basing on local information (e.g., locally observed events), using reactive (e.g., trial-and-error), and hard-coded one-size-fits-all (same logic is used in different scenarios and over time) logics. For instance, adaptive streaming protocols usually start with a statically configured bitrate. If this bitrate is too low, the protocol might not be even able to reach the optimal rate by the time the video has ended (e.g., for a 30s or 60s news clip). Hard-coded one-size-fitsall logics of TCP do not consistently achieve optimal performance in diverse network contexts, like data center, wireless and large bandwidth-delay product networks. This thesis argues for an alternative approach of centralized predictive control (CPC), where adaptation logics are separated from end-to-end adaptation protocols and run by a global controller, who has a global view of many sessions performance 1. The global view enables predictive control (i.e., ability to predict the optimal decision without trying all decisions) and flexible control logic (i.e., ability to customize control logic based on network context, rather than using one-size-fit-all logics). The technical contribution of this thesis is to address two key challenges of the CPC approach. First, while the global view enables predictive control, it is challenging to accurately predict performance and optimal decisions. We present accurate data-driven prediction logics based on the insight of critical features bottlenecks that impact session performance and are share 1 We generalized the notion of session in this thesis to interaction of two end hosts in the context of different layers, such as TCP session, HTTP session, video session, etc. 1

14 across many sessions. For instance, TCP sessions impacted by the same factors (e.g., congested links) have similar performance and best adaptation decisions (e.g., initial congestion window). Second, as CPC uses a global controller, it creates additional complexity, such as scalability, fault tolerance, stability, additional delay between controller and end hosts. They are challenging for end-to-end adaptation because of the scale (potentially billions of end hosts with global distribution) and highly dynamic nature (adaptation must be made immediately with fresh information). Our design of the CPC control platform addresses these challenges using several key insights, including leveraging persistence of optimal adaptation decisions to minimize negative impacts of delay between controller and end hosts, and deoupling controller design to combine both global analytics and real-time per-session control. To put it in context, CPC is inspired by a diverse set of related research. First, CPC shares similar motivations with SDN (e.g., [28, 45]) in network layer that control plane should be decoupled from data plane and centralized for more flexibility. Second, CPC is inspired by seminal work of CM [4] and SPAND [36], which showed benefits of sharing congestion information between TCP sessions in the context of a web server. CPC extends this work to a global scale by taking advantage of many technological trends such as cloud computing and large-scale analytics platforms. Third, CPC is inspired by recent work of Remy [37, 44], which showed the benefits of customizing congestion control logics for different network characteristics during offline training. CPC generalize this work to online training of adaptation logics, which is supposed to unleash more benefits of customizing adaptation logics based on more accurate knowledge of the targeted network. Organization of the thesis proposal: Chapter 2: Background and related work. Chapter 3: Overview of challenges and insights of CPC Chapter 4: Design of accurate data-driven prediction logics. Chapter 5: Design of scalable control platform. Chapter 6: Timeline of the proposed thesis work and risk analysis. 1.1 Roadmap This thesis makes the case for CPC with three steps ( Table 1.1 maps my prior work and proposed work to the above roadmap): Step 1: We make case for data-driven protocols (design of protocols should be driven by data, such as a global view of real-time performance measurement). The case for data-driven protocols suggests the potential performance benefits of CPC. Step 2: We use measurement studies to present insights that enable the technical designs of CPC ( 3). Step 3: We present techniques to build a practical system of CPC ( 4 and 5). 2

15 My prior work(internet video) Proposed work Future Case for (global) data-driven (Step 1) [27](Not primary contributor) Data-driven protocols Measurement on insights of CPC (Step 2) [21] Accurate data-driven prediction (Step 3) CFA, DDA [23] Scalable control platform (Step 3) C3 [11](Not primary contributor) Skype Table 1.1: Mapping my prior work and proposed work to CPC s insights and solutions to address the challenges. TCP Other protocols 3

16 4

17 Chapter 2 Background and Related Work 2.1 Background End-to-end adaptation protocols are used at transport layer and application layer of the network stack (e.g., TCP in transport layer, and DASH streaming protocols in application layer). These protocols are critical to ensure high performance in each layer. Different protocols use different adaptation parameters to adapt end hosts behavior against changes of network conditions or resource availability. Table 2.1 gives some example of end-to-end adaptation protocols. Network stack Protocols Adaptation parameters Impacted performance DASH, Skype Bitrate/CDN/peer selection Quality of video/skype/web Application layer HTTP Parallel TCP, server/cache selection Throughput Transport layer TCP Congestion control Throughput, Latency Table 2.1: Some examples of how different end-to-end adaptation protocols impact performance of different layers by tuning their adaptation parameters. The ideal design of end-to-end adaptation protocols should tune adaptation parameters optimally and quickly so that each session can adapt to network condition and resource availability. For instance, the ideal bitrate-adaptive video player should always choose the highest bitrate sustainable by throughput, and the ideal TCP should use the largest initial window size that has no packet loss. Table 2.2 below provides a list of terminologies used in this document. Name Description Examples (Adaptation) Parameter Control knob CDN (Adaptation) Decision Specific value of an adaptation parameter Akamai Session Interaction of two end hosts in the context TCP session, HTTP session, of different layers video session Session features Features of a session ISP, CDN, connection type Global view Performance measurements from many distributed end hosts Video quality measurements of all viewers Table 2.2: Terminology used in this document and their description. 5

18 2.2 Related Work June 25, 2015 Related work of this thesis falls into the following categories. Centralized control platform for network protocols: Network layer: Centralized architecture for network-layer functionalities have gain much attention since the seminal work on centralized systems for routing (e.g., [5, 45]) and more recently with a focus on software-defined networks (e.g., [28]) and their applications, including network function virtualization (e.g., [1]), network updates (e.g., [24]) and traffic engineering (e.g., [15, 19, 30]). CPC shares many system issues with these studies, including scalability (e.g., [7, 41]) and fault tolerance (e.g., [31, 46]). The most similar application to CPC is SDN s traffic engineering. However, unlike these studies, CPC makes no assumption on the knowledge of available resource (e.g., total capacity between two points) or the visibility of all traffic. As a result, CPC does not focus on centralized scheduling (as in [15, 19, 30]), but explores a data-driven design of protocols. Transport layer: Traditionally, transport-layer protocols are implemented in a distributed fashion. The closest work to CPC is CM [4] and SPAND [36], which has suggested the benefits of sharing congestion control information across individual TCP sessions, though in the scope of the same host (e.g., server). There has been recent work on applying the concepts of SDN to transport layer (e.g., SDT [14] and FastPass [32]) or taking advantage of existence of SDN (e.g., OpenTCP [12]). So far, they either focus on specific scenarios like data centers or only work with the presence of SDN deployed in the network. Application layer: The most similar work to CPC is the case of global control plane for video (e.g., [26, 27]. It shows a substantial spatial and temporal diversity of performance across different CDNs and content providers [26], which suggest the potential performance improvement brought by making adaptation using a global of client-side measurements. This thesis plans to generalize the concept of centralized control to multiple applications (such as Skype) and give a systematic and practical algorithmic design. Machine learning and other approaches to prediction: CPC leverages the power of datadriven prediction. To put it in context of machine learning techniques, the CPC s prediction algorithm (CFA 4), in essence, is an instance of a variable kernel conditional density estimation method [40]. It addresses the curse of dimensionality by contracting parts of the feature space that are not critical for prediction or in which there is too little available data. It leverages application-specific insights and is thus able to outperform conventional machine learning techniques (e.g., decision tree, naive bayes and SVM[35]) in scalability and accuracy. There are several studies on predicting network performance by leveraging the history of the same client-server pair (e.g., [13, 18, 29, 39, 43]). However, they are less reliable when the available history of the same client and server is sparse. In contrast, CPC is able to predict more accurately by leveraging a global view of many sessions performance measurements. Other improvements on end-to-end adaptation protocols: We focus on other improvements on Internet video and congestion control. Internet video: There is a large literature on measuring video quality in the wild (e.g., content popularity [34, 47], quality issues [21] and server selection [38, 42]) and techniques to 6

19 improve user experience (e.g., bitrate adaptation algorithms [16, 20], cross-cdn optimization and federation [3, 26, 33] and cross-provider cooperation [10, 22, 48]). While our work borrows ideas from the prior work (e.g., critical features are inspired by quality bottleneck in [21]), CPC is an enhancement of these approaches as it uses the accurate prediction to make predictive control. Congestion control: TCP congestion control algorithms have been studied for multiple decades and for brevity, we only focus on recent developments. Remy [37, 44] provides a tool to demonstrate feasibility and limitation of off-line TCP training, which suggests the needs for customization of congestion control algorithm under different network characteristics. PCC [8] argues that using A/B testing and the observed performance results in a simpler congestion control algorithm and better performance. Compared to Remy (offline training) and PCC (local view), CPC stands for a more generalized design point where the congestion control can be determined with real-time global information. Other related work include the studies on the benefit of increasing TCP initial congestion window (e.g., [9]), for which CPC provides a platform to dynamically set the initial congestion window. Another similar system to CPC is split TCP (e.g., [25]), which is different from CPC in that CPC does not split the connection between end hosts. 7

20 8

21 Chapter 3 CPC Overview 3.1 CPC vs. Today s Approaches To motivate CPC, we first revisit two limitations for today s end-to-end protocols local reactive adaptation and hard-code logics, which are inherent to the traditional design tenet that end-to-end adaptation protocols are run independently by endpoints. Local reactive adaptation: Local reactive adaptation uses locally observed information and reactive strategies such as trial-and-error. This is suboptimal for two reasons. Suboptimal initial configurations: Existing protocols typically use static configuration parameters that are often suboptimal. For example, adaptive streaming protocols usually start with a statically configured bitrate. If this bitrate is too low, the protocol might not be even able to reach the optimal rate by the time the video has ended (e.g., for a 30s or 60s news clip). Similarly, in many cases, the initial window size of TCP is too small, which may cause a transfer to take far more RTTs than necessary. Inefficient exploration of decision space: As protocols and applications become more sophisticated the number of configuration choices increases dramatically. For instance, with a video application one can select the initial bitrate, the CDN, and at a finer granularity the proxy or the web server from which to stream the content. This makes it hard, or even infeasible, for a reactive protocol to explore the configuration space and select the best configuration. Hard-coded logics: Today s end-to-end adaptation protocols are hard-coded; E.g., TCP is compiled in OS kernel, and video adaptation logic is hard-coded in the video binary code. This causes two issues: Hampering customization to diverse network context: It is widely known that different network contexts require different TCP logics to deal with different network properties. For instance, wireless network requires different TCP to those used data center or networks with high bandwidth-delay product. Recent work Remy has shown the benefits of customizing congestion control logics to different network characteristics. Difficult to evolve and deploy: There have been tremendous research on TCP that yields many congestion control algorithms. However, their evaluation and deployment is mostly confined to simulation because TCP is hard-coded in OS kernel, which has a long cycle 9

22 for update and deployment. Similar ossification is also common in application layer. For instance, video bitrate adaptation logics are compiled in video players, which typically are part of mobile/smarttv apps, and thus have a long update cycle [11] of up to months. Benefits of CPC: CPC overcomes the above limitations of today s end-to-end adaptation protocols by introducing two new capabilities. Data-driven predictive control: The global view of many connections performance enables the protocols to accurately predict the outcome of making a particular choice, e.g., would a stream be able to sustain a particular bitrate? Would a TCP connection experience any loss given a particular initial window size? In theory, perfect prediction would allow protocols to use optimal configuration parameters and make optimal decisions. For example, it would be possible to pick the largest sustainable bitrate for a video stream, or the largest window size for which a TCP connection won t experience congestion losses. Flexible logics: CPC decouples adaptation logics from end hosts. This enables the adaptation logics to be customized for each session at any time based on its network context and application requirements. 3.2 Challenges of CPC CPC architecture: CPC consists of three major components. (1) Global controller, which runs the data-driven prediction logics and makes predictive decision for end hosts. (2) Local logics, which run inside the end hosts for performance monitoring and executing decisions made by the global controller. (3) CPC API, which provides the interface between global controller and local logics. Logically, CPC uses a control loop that consists of three steps: (1) Measurement collection, which maintains a global view of performance measurements collected from end hosts via CPC API. (2) Predictive control logics that makes predictive adaptation decisions for each session based on the global view, (3) Finally, the adaptation decisions are pushed to end hosts for execution via CPC API. CPC&API& Measurement&collec1on& Global&Controller& Predic1ve&control& CPC&API& Pushing&adapta1on&decisions& & & & & & & & & Local&Logics& & End&Point& Internet& & & Local&Logics& & End&Point& Figure 3.1: Three components of CPC architecture (local logics, global controller and CPC API), and the logical control loop (measurement collection, predictive control and pushing adaptation decisions) Challenge I: Accurate data-driven prediction: The first challenge is to have a highly accurate prediction algorithm in the predictive control logics. However, achieving high prediction accuracy is hard for two reasons. 10

23 Needs for expressive models: First, there are a lot of complex factors that can affect a session s performance, and so the prediction models must be expressive to capture these complex factors. Taking real-world event as an example, when an overloaded Level3 CDN edge server caused bad quality on video sessions in certain Comcast (ISP) and New York City, the prediction model must be able to isolate the sessions associated with the specific ISP and city using specific CDN; otherwise (e.g., all sessions in Comcast), we may not able to identify the bad quality and predict accurately. In addition, different sessions may subject to different factors; some sessions may be bottlenecked by its last connection while others may bottlenecked by the content availability at CDN. Needs for fresh updates: Second, a session s performance changes rapidly, and so the prediction algorithm must be scalable to make prediction based on fresh measurements. This is particularly challenging given the sheer size of performance measurements (millions of concurrent video sessions and billions of concurrent TCP sessions) and the algorithm must be expressive and complex. For instance, a complex machine learning algorithm (e.g., SVM) might take too long to build the prediction model (e.g., it takes SVM more than one hour to process 10 minutes of data of one video site) and the prediction is made only with very stale data, which degrades prediction accuracy. Challenge II: Scalable CPC control platform: A scalable CPC control platform must address two issues: Scalable global controller, which meets three arguably conflicting goals on a scale of potentially billions of end hosts with global distribution: (1) First, accurate prediction benefits from using measurements of a long history (e.g., several hours) as input. (2) Second, given the variability in performance across time and space (e.g., ISP-CDN combinations) the CPC controller needs an up-to-date global view (at most tens of seconds stale). (3) Third, it needs to be responsive at sub-second timescales to handle new session arrivals. Functionality separation between end hosts and controller: The goal of separating the functionalities of end hosts and the global controller is to (1) minimize the negative impact of the delay between end hosts and controller, (2) minimize overhead on both end points and controller, and (3) tolerate failure of controller and communication between controller and end hosts. 3.3 Key Insights of CPC This section describes the key insights and how these key insights are used to address the above challenges. We will give more details of the solutions in the next two chapters. Insight I: Critical features: The key insights underlying our approach to accurate data-driven prediction is that performance of a session is determined by a subset of critical features, and thus sessions matching values on the critical features have similar performance. For instance, if all sessions have good quality except for sessions in a specific CDN, CDN is the critical feature of these bad quality sessions. The critical features naturally offer an expressive prediction model one can predict a session s performance using the history sessions that match the values on its critical features, because their performance is determined by the same features. 11

24 # of clusters (log) /11 0AM 3/12 0AM 3/13 0AM 3/14 0AM 3/15 0AM Problem clusters Critical clusters 3/16 0AM 3/17 0AM Time (hr) Figure 3.2: A relatively small number of combinations of critical features (i.e., critical clusters) are shared by many bad quality video sessions. Insight II: Persistence of critical features: Critical features tend to persist on a long timescale (tens of minutes). For instance (Figure 3.3), using critical features learned 30 minutes ago will yield very similar prediction accuracy to using critical features learned now. Degradation of Accuracy BufRatio AvgBitrate JoinTime VSF Structure Staleness (min) Figure 3.3: Slight staleness (e.g., 30 minutes) of critical features (i.e., structure) does not impact prediction accuracy significantly. Persistence of critical features naturally leads to a scalable implementation of predictive control logics of the global controller. As we will see in next chapter, learning of critical features takes longer than actual prediction and decision making. Therefore, we can decouple the prediction logics into an offline process for learning critical features and an online process for prediction and decision making, such that prediction and decision making can leverage the most recent measurement as well as up-to-date critical features. Insight III: Persistence of optimal decisions: We have found that the optimal decisions of some adaptation parameters have a relatively long persistence, on a timescale of seconds to tens of seconds. For instance (Figure 3.4), the best CDNs for different content providers persist on a timescale of tens of seconds to minutes. Notice that there are adaptation parameters whose optimal decision changes every seconds or even more often. For instance, congestion control window size may need to be updated on the receive of a packet ack to preserve packet conservation principle. This insight naturally suggests that, despite the additional delay between end hosts and global controller, the global controller can make timely decision for the adaptation parameters whose optimal decisions persist on a timescale that is longer than the delay between end hosts and global controller. For instance, CDN of a video client can be selected by the global controller because the optimal CDN typically changes on the timescale of tens of seconds, which is much longer than the delay between end hosts and global controller. 12

25 CDF CP A 0.2 CP B CP C Persistence(min) Figure 3.4: The best CDNs for different content providers persist on a timescale of tens of seconds to minutes. 13

26 14

27 Chapter 4 Accurate Data-Driven Prediction Logics 4.1 Technical Overview The key reason for CPC s better performance is the capability to predict the outcome of a session with specific adaptation decision at any time based on a global view of different sessions performance. For instance, whether a video client using a specific CDN and bitrate will experience any re-buffering. Then a decision-making system can make optimal decision for any session based on the performance prediction on every possible decision. Remember in 3.2 that an accurate prediction algorithm must meet the needs for expressive models and fresh updates. For convenience, in this chapter, we define session to denote a connection using a specific adaptation decision (e.g., a video client using specific CDN and bitrate), and we would like to accurately predict its performance. This section presents a practical prediction system called CFA. CFA uses a data-driven approach: with a global view of performance measurements from many history and concurrent sessions, it is likely to find some similar sessions (e.g., those with same AS and CDN with the session under prediction) whose performance is similar to the session under prediction. Given the insight of critical features ( 3.3), in order to predict performance of a session s, it is sufficient to use sessions matching critical features with s in a short history, because their performance is impacted by the same decisive factors as performance of s. CFA Framework based on critical features: Formally, we denote session aggregation Agg(s, F, T ) as the set of sessions that match session s on features in a feature set F and happened within time window T before s. In particular, the set of all features is denoted by F all. Based on the insights of critical features, CFA uses two steps to predict performance of a session s. Structure learning: First, CFA learns the critical features of s, denoted as Fs critical ; Value estimation: Then CFA estimates the performance of s based on sessions in Agg(s, Fs critical, T est ) (e.g., the average of their performance) where T est is a small time window, e.g., 5 minutes. There are two practical issues of this framework: (1) How to learn the critical features of a session? (2) How to be scalable to use fresh updates? We postpone the later to the next chapter. Learning critical features: By definition, sessions in Agg(s, Fs critical, T est ) should have the same (or very similar) performance distribution to those in Agg(s, Fs all, T est ) because critical features reflect the important factors that determine the performance. So a naive solution is to 15

28 look for the feature set F such that Agg(s, F, T est ) has the most similar performance distribution to Agg(s, Fs all, T est ). However, this naive method is not practical, because it is hard for Agg(s, Fs all, T est ) to have enough sessions to extract a reliable performance distribution. CFA addresses this problem by taking advantage of the persistence of critical features ( 3.3). Critical features tend to persist on a long timescale (tens of minutes), which is an order of magnitude longer than performance persists (minutes). This suggests that if we replace replacing T est by persistence of critical features T learn (>> T est ), we are likely to get much more data in Agg(s, Fs all, T learn ) while still be able to learn the critical features because sessions in Agg(s, Fs all, T learn ) share the same critical features with Agg(s, Fs critical, T learn ). 4.2 My Prior Work Three of my prior studies have focused on the accurate prediction and its insight of critical features. Study on Structures of Internet Video Quality Problems: This work is a first step to understand the structure of Internet video issues in the wild. To quantify the structure of video quality problems, we define problem cluster as a set of bad-quality video sessions matching on certain features (e.g., CDN, ISP, content genre), and define the critical clusters as those likely to cause many problem clusters. Our findings show that (1) a relatively small number of critical clusters (2% of problem clusters) can account for most observe quality problems and (2) they are persistent (50% of problem clusters last for more than 2 hours, with a few pathological critical clusters spanning several hours). CFA for Video Quality Prediction: This work presents a practical prediction algorithm CFA for video quality prediction based on the insights of critical features and their persistence. We present real-world evidence for the needs of expressive models and fresh updates, and why conventional machine learning techniques are not sufficient. Trace-driven evaluation and real-world experiments show that CFA achieves up to 60% improvement in prediction accuracy compared to conventional machine learning techniques (such as decision tree), and up to 15% improvement across different quality metrics relative to current approaches. Improv. over NB (%) BufRatio DT CFA AvgBitrate JoinTime VSF (a) CFA is more accurate than conventional ML. Join time (ms) CFA CDN1 CDN2 CDN3 Random (b) Accurate prediction yields better video quality. Figure 4.1: Benefits of CFA: more accurate prediction on video quality and better quality through accurate prediction. Throughput Prediction for Video Initial Bitrate Selection: In this project, we develop a data- 16

29 driven prediction algorithm DDA for throughput prediction by leveraging throughput measured on sessions of different servers and clients. Trace-driven evaluation of real-world datasets shows that DDA predicts throughput more accurately than simple predictors and conventional machine learning algorithms; e.g., DDA s 80%ile prediction error of DDA is 50% lower than other algorithms. We also show that this improved accuracy enables video players to select a higher sustainable initial bitrate; e.g., compared to initial bitrate without prediction, DDA leads to 4x higher average bitrate. CDF DDA 0.4 DT LS 0.2 NB LM Prediction error (%) (a) DDA is more accurate than conventional ML in predicting throughput. (b) Accurate prediction yields higher average bitrate with less rebuffering. Figure 4.2: Benefits of DDA: more accurate prediction on throughput and better bitrate selection based on accurate throughput prediction. 4.3 Proposed Work CFA for Skype Quality Improvement: This will be a collaborate work with Skype team and researchers in Microsoft. The goal is to use real-time analytics on Skype client-side measurements to generate insights and improve Skype quality. This seems a perfect fit for CFA. In particular, we plan to answer the following the questions: What are the control knobs that have impact on Skype quality? How much do using critical features help predict Skype quality accurately? How to enhance CFA with auxiliary information (e.g., topology and packet-level information)? What are the differences between video streaming and real-time communication such Skype, in terms of applicability and benefits of CPC? Why is CPC/CFA more/less useful for Skype than video streaming? 17

30 18

31 Chapter 5 Scalable CPC Control Platform 5.1 Technical Overview The introduction of a separate controller creates additional complexity to the end-to-end architecture, which must be addressed by a scalable and robust control platform. Scalable global controller: Remember in 3.2 that the global controller must satisfy three requirements: (1) capability of running structure learning over a long-term history (i.e., performance measurements of all users in last 10s of minutes), (2) capability of updating the prediction model with fresh global view of a short history (i.e., performance measurements of all users in last 10s of seconds), and (3) capability of responding end hosts within a second. Unfortunately, simultaneously achieving all three requirements is hard. For instance, the structure learning may take a long time (e.g., tens of minutes), and naively running both the structure learning and making predictive decision together will take too long to produce prediction based on up-to-date global view. Our design achieves these goals by splitting the global controller into three loosely coupled control loops (Figure 5.1). Offline structure learning that operates at the timescale of tens of minutes and runs structure learning of CFA to learn critical features based on performance measurements of last tens of minutes. Online model updating that operates at the timescale of tens of seconds to update a global model the performance estimation of different values of critical features, using up-to-date global view of performance measurement. Fine-grained per-session control that operates at the timescale of millisecond timescale and makes actual decisions for end hosts. The rationale of this triple-loop design is that how often each loop runs matches the persistence of the results of each loop. Offline structure learning happens every tens of minutes and it outputs critical features, which persists on the timescale of tens of mintues ( 3.3). Online model updating happens every tens of seconds and it outputs value estimation of different values of critical feature (e.g., performance of different CDNs and their ranking), which persists on the timescale of tens of seconds ( 3.3). Finally, the cloud computing infrastructure provides a practical platform for implementing 19

32 Offline&Structure&Learning& (Every&10s&of&minutes)& Cri$cal(features( Online&Model&Upda?ng& (Every&10s&of&seconds)& PerAsession&Control& (In&realA?me)& End&hosts& Global(model:(Value(es$ma$on( for(cri$cal(feature(values( Adapta$on(decisions( Figure 5.1: Splitting CPC controller into three control loops the triple-loop architecture of CPC global controller. In particular, it provides a global presence of servers that are close to end hosts, which meets the needs of fine-grained per-session decision making. Second, the proposed triple-loop architecture requires an efficient communication channel between layers, which cloud infrastructure typically provides. Finally, cloud infrastructure provides elastic resource, from which we can benefit to easily scale up to more end hosts. Separation of functionalities between end hosts and controller: CPC control platform decouples the functionalities between end hosts and the global controller. One extreme strawman is to make all adaptation logics by the global controller. However, this strawman has two problems. First, there is an inherent delay between end hosts and the global controller, which may create instability and even pathological cases (e.g., congestion collapse due to the violation of packet conservation). Second, relying on the global controller for all adaptation decisions is not fault tolerant as the performance will degrade if the controller fails. To address the above issues, we make two design decisions. First, controller should only make adaptation decisions whose optimal decisions change more slowly than than the delay between end hosts and controller. For instance, CDN of a video client should be selected by the global controller because the optimal CDN typically changes on the timescale of tens of seconds (Figure 3.4), which is much longer than the delay between end hosts and controller. However, TCP congestion control window should be (for most of the time) selected by local logics of end hosts since it must be changed on timescale of less than a second to meet packet conservation. However, the key parameters of the congestion control algorithm (e.g., initial congestion window and AIMD parameters) can be decided by by the global controller as they are more likely to have persistence on long timescale. Second, for the purpose of fault tolerance, local logics of end hosts should run a default adaptation logic even if the adaptation decisions are overriden by the controller when it is available. Once the controller fails or timeout, the end hosts can automatically fallback to use the default local logics. 5.2 My Prior work Scalable Implementation of CFA (part of CFA): Persistence of critical features naturally leads to a scalable implementation of CFA. CFA learns the critical features at a coarse timescale, and when making prediction, CFA reuses the learned critical features and run simple logics over fresh 20

33 data for prediction. June 25, 2015 C3 (not major contributor): C3 is a scalable global control platform used for optimization of Internet video quality. Its implementation benefits from two key ideas that are introduced in this chapter: decoupling global analytics and per-session control for scalability and fresh global view, and fallback strategy of local logics for fault tolerance. 5.3 Proposed Work CPC for TCP: We propose to build a prototype of CPC for TCP, including the three components of CPC (global controller, local logics and CPC API). The design of CPC for TCP needs to address all the challenges mentioned in the beginning of this chapter and we will examine the effectiveness of the proposed solutions. In a high level, we are interested in answering two questions: What are the design differences between CPC for TCP and CPC for video (C3)? What differences between TCP and Internet video cause these design differences? Can CPC lead to more/less performance improvement for TCP than for video? Another delivery of this project is to deploy CPC for TCP for public use. We envision several modes of deployment. For instance, the global controller of CPC for TCP can run as a public service and the local logics can be released as a kernel patch or part of user-space TCP for wide adoption. 21

34 22

35 Chapter 6 Timeline and Risk Analysis 6.1 Timeline By July 17, 2015 Position paper on case for data-driven protocols (submission to Hot- Nets 15) By Sep, 2015 CFA for video (submission to NSDI 16) By Jan, 2016 CFA for Skype (submission to SIGCOMM 16) By Sep, 2016 CPC for TCP (submission to NSDI 17) 6.2 Risk Analysis CFA for Skype: Because the collaborative nature of the project, the major risk of this project is that the scope may not be controlled by us. The ideal case is to develop some variant of CFA (CFA++) that can predict Skype quality accurately and scalably and demonstrate that CFA++ achieve better Skype quality. As a backup plan, we should be able to argue that applying datadriven techniques on Skype dataset can lead to better understanding of real-time network condition, especially on critical structures (e.g., bottleneck). Another risk of this project is the potential issues of the Skype dataset, such privacy issue with Skype data, incorrectness, broken collection methods. We should confirm that with Microsoft team as soon as possible. CPC for TCP: There is few risks in designing and building a prototype of CPC for TCP. The major risk is that the deployment may be hard to get wide adoption. Plan A: run the local logics in end hosts as a linux patch and release it for public use. Plan B: run the local logics as part of user-level TCP or TCP over UDP Plan C: write the whole system as part of the NS2. Plan D: give up the plan for TCP deployment and deploy it over json video player. In any case, we should run global controller as a service in public cloud. To bootstrap the deployment, we should deploy the local logics in Planetlab or GENI. 23

36 24

37 Bibliography [1] Network functions virtualisation. paper.pdf. 2.2 [2] I. Sodagar. The MPEG-DASH Standard for Multimedia Streaming Over the Internet. IEEE Multimedia, [3] Athula Balachandran, Vyas Sekar, Aditya Akella, and Srinivasan Seshan. Analyzing the potential benefits of cdn augmentation strategies for internet video workloads [4] Hari Balakrishnan, Hariharan S Rahul, and Srinivasan Seshan. An integrated congestion management architecture for internet hosts. In ACM SIGCOMM Computer Communication Review, volume 29, pages ACM, , 2.2 [5] Matthew Caesar, Donald Caldwell, Nick Feamster, Jennifer Rexford, Aman Shaikh, and Jacobus van der Merwe. Design and implementation of a routing control platform. In NSDI [6] David Clark. The design philosophy of the darpa internet protocols. ACM SIGCOMM Computer Communication Review, 18(4): , [7] Advait Dixit, Fang Hao, Sarit Mukherjee, TV Lakshman, and Ramana Kompella. Towards an elastic distributed sdn controller. In ACM HotSDN, [8] Mo Dong, Qingxi Li, Doron Zarchy, P. Brighten Godfrey, and Michael Schapira. Pcc: Rearchitecting congestion control for consistent high performance. In 12th USENIX Symposium on Networked Systems Design and Implementation (NSDI 15), pages , Oakland, CA, USENIX Association. 2.2 [9] Nandita Dukkipati, Tiziana Refice, Yuchung Cheng, Jerry Chu, Tom Herbert, Amit Agarwal, Arvind Jain, and Natalia Sutin. An argument for increasing tcp s initial congestion window. Computer Communication Review, 40(3):26 33, [10] Benjamin Frank, Ingmar Poese, Yin Lin, Georgios Smaragdakis, Anja Feldmann, Bruce Maggs, Jannis Rake, Steve Uhlig, and Rick Weber. Pushing cdn-isp collaboration to the limit. ACM SIGCOMM CCR, 43(3), [11] Aditya Ganjam, Faisal Siddiqi, Jibin Zhan, Ion Stoica, Junchen Jiang, Vyas Sekar, and Hui Zhang. C3: Internet-scale control plane for video quality optimization. In To appear in NSDI. USENIX, , 3.1 [12] Monia Ghobadi, Soheil Hassas Yeganeh, and Yashar Ganjali. Rethinking end-to-end congestion control in software-defined networks. In Proceedings of the 11th ACM Workshop 25

38 on Hot Topics in Networks, pages ACM, [13] Qi He, Constantine Dovrolis, and Mostafa Ammar. On the predictability of large transfer tcp throughput. ACM SIGCOMM Computer Communication Review, 35(4): , [14] Chi-Yao Hong. Software defined transport. PhD thesis, University of Illinois at Urbana- Champaign, [15] Chi-Yao Hong, Srikanth Kandula, Ratul Mahajan, Ming Zhang, Vijay Gill, Mohan Nanduri, and Roger Wattenhofer. Achieving high utilization with software-driven wan. In ACM SIGCOMM [16] Te-Yuan Huang, Ramesh Johari, Nick McKeown, Matthew Trunnell, and Mark Watson. A buffer-based approach to rate adaptation: evidence from a large video streaming service. In ACM SIGCOMM [17] V. Jacobson. Congestion avoidance and control. In ACM SIGCOMM Computer Communication Review, volume 18, pages ACM, [18] Manish Jain and Constantinos Dovrolis. End-to-end estimation of the available bandwidth variation range. In ACM SIGMETRICS Performance Evaluation Review, volume 33, pages ACM, [19] Sushant Jain, Alok Kumar, Subhasree Mandal, Joon Ong, Leon Poutievski, Arjun Singh, Subbaiah Venkata, Jim Wanderer, Junlan Zhou, Min Zhu, et al. B4: Experience with a globally-deployed software defined wan. In ACM SIGCOMM [20] Junchen Jiang, Vyas Sekar, and Hui Zhang. Improving Fairness, Efficiency, and Stability in HTTP-Based Adaptive Streaming with Festive. In ACM CoNEXT [21] Junchen Jiang, Vyas Sekar, Ion Stoica, and Hui Zhang. Shedding light on the structure of internet video quality problems in the wild. In CoNEXT. ACM, , 2.2 [22] Junchen Jiang, Xi Liu, Vyas Sekar, Ion Stoica, and Hui Zhang. Eona: Experience-oriented network architecture. In ACM HotNets, [23] Junchen Jiang, Vyas Sekar, and Yi Sun. Dda: Cross-session throughput prediction with applications to video bitrate selection. arxiv preprint arxiv: , [24] Naga Praveen Katta, Jennifer Rexford, and David Walker. Incremental consistent updates. In Proceedings of the second ACM SIGCOMM workshop on Hot topics in software defined networking, HotSDN 13, pages 49 54, New York, NY, USA, ACM. ISBN doi: / URL / [25] Swastik Kopparty, Srikanth V Krishnamurthy, Michalis Faloutsos, and Satish K Tripathi. Split tcp for mobile ad hoc networks. In Global Telecommunications Conference, GLOBECOM 02. IEEE, volume 1, pages IEEE, [26] Harry Liu, Ye Wang, Yang Richard Yang, Alexander Tian, and Hao Wang. Optimizing Cost and Performance for Content Multihoming. In Proc. SIGCOMM, [27] Xi Liu, Florin Dobrian, Henry Milner, Junchen Jiang, Vyas Sekar, Ion Stoica, and Hui 26

39 Zhang. A case for a coordinated internet video control plane. In Proceedings of the ACM SIGCOMM 2012 conference on Applications, technologies, architectures, and protocols for computer communication, pages ACM, , 2.2 [28] Nick McKeown. Software-defined networking. INFOCOM keynote talk, 17(2):30 32, , 2.2 [29] Mariyam Mirza, Joel Sommers, Paul Barford, and Xiaojin Zhu. A machine learning approach to tcp throughput prediction. In ACM SIGMETRICS Performance Evaluation Review, volume 35, pages ACM, [30] Matthew K Mukerjee, JungAh Hong, Junchen Jiang, David Naylor, Dongsu Han, Srinivasan Seshan, and Hui Zhang. Enabling near real-time central control for live video delivery in cdns. In Proceedings of the 2015 ACM conference on SIGCOMM. ACM, [31] Aurojit Panda, Colin Scott, Ali Ghodsi, Teemu Koponen, and Scott Shenker. Cap for networks. In ACM HotSDN, [32] Jonathan Perry, Amy Ousterhout, Hari Balakrishnan, Devavrat Shah, and Hans Fugal. Fastpass: A centralized zero-queue datacenter network. In Proceedings of the 2014 ACM conference on SIGCOMM, pages ACM, [33] Larry Peterson and Bruce Davie. Framework for cdn interconnection [34] Louis Plissonneau and Ernst Biersack. A longitudinal view of http video streaming performance. In Proc. MMSys, [35] Bernhard Schölkopf and Alexander J Smola. Learning with kernels: support vector machines, regularization, optimization, and beyond. MIT press, [36] Srinivasan Seshan, Mark Stemm, and Randy H Katz. Spand: Shared passive network performance discovery. In USENIX Symposium on Internet Technologies and Systems, pages , , 2.2 [37] Anirudh Sivaraman, Keith Winstein, Pratiksha Thaker, and Hari Balakrishnan. An experimental study of the learnability of congestion control. In Proceedings of the 2014 ACM conference on SIGCOMM, pages ACM, , 2.2 [38] Ao-Jan Su, David R Choffnes, Aleksandar Kuzmanovic, and Fabián E Bustamante. Drafting behind akamai (travelocity-based detouring). ACM SIGCOMM CCR, [39] Martin Swany and Rich Wolski. Multivariate resource performance forecasting in the network weather service. In Proceedings of the 2002 ACM/IEEE conference on Supercomputing, pages IEEE Computer Society Press, [40] George R Terrell and David W Scott. Variable kernel density estimation. The Annals of Statistics, pages , [41] Amin Tootoonchian, Sergey Gorbunov, Yashar Ganjali, Martin Casado, and Rob Sherwood. On controller performance in software-defined networks. In USENIX Workshop on Hot Topics in Management of Internet, Cloud, and Enterprise Networks and Services (Hot- ICE),