Motivation and Use Cases

We address the problem of reducing network latency by better understanding network performance. We have discussed two methods for reducing latency that require knowing about traffic in advance: Server Push and prefetching. Generally, causing content to be

downloaded early can mask limitations in network performance, but this requires deter- mining a systematic way to predict URL requests for apps, which has yet to be done.

Applicability to Server Push: While Server Push is not the use case we will focus on in this chapter, we briefly discuss it as motivation for predicting content. In particular, one recommended approach for implementing Server Push we discussed was by using a proxy. Third-party content and domain sharding are major limitations for Server Push, so why not have a proxy serve as a single point from which the client can request content from disparate sources? In this way, the user would get the full benefits of HTTP/2, including allowing Server Push to have all known content be piggybacked on the initial HTTP page. We did not discuss, however, how the proxy might know what content to push. In some cases, a sort of configuration file could perhaps be sent to the proxy, if the original server knows everything that will be pushed, but that might not be the case. What we would like would be for the server to be able to predict what content will be needed simply by observing traffic as it passes, and then build a model of what sort of content to expect when. This is precisely what we aim to do in this chapter.

Applicability to cloudlets: Cloudlets are servers near access points (either WiFi ac- cess points or cell towers) that phones can offload functionality to, allowing for increased performance [125, 110, 39, 12, 46, 109]. It has been proposed, in particular, that content can be prefetched to these cloudlets in a technique known as data staging [39]. A recent paper, focusing on offloading computation, showed that cloudlets still have the potential to approximately halve response times, as compared to offloading content to the cloud alto- gether [41]. However, determining what to prefetch in this case is also a problem.

We show an example system architecture for a cloudlet prefetching system in Fig- ure 8.1. A cloudlet server near the access point acts as a proxy, and can observe all traffic that passes through it. It can then generate a model of what to prefetch, and use that model to prefetch content to a local prefetch cache. One advantage of a cloudlet is that the cost of mispredictions is lower, since unnecessary content never goes over the congested

Unmodified app server Per-app proxy Logger Prefetch rules User app state

Extract Prefetch Rules Offline

Prefetch Cache

Lightweight app state logging

Figure 8.1: System diagram of how a cloudlet prefetching system might work. and possibly expensive last hop. However, as we will show, one major challenge is that these mispredictions still take time to download, and there is a limited amount of time for prefetching to happen. Finally, there could potentially be some communication between the phone’s OS and the cloudlet. In particular, we could communicate to the cloudlet what activity the device is in, or what apps have started, to let the cloudlet know what to prefetch. System design goals: We therefore want to create a system that can a) predict as much network traffic as possible for an application, and b) do so with reasonable data download overheads. If we use the cloudlet system as our motivating example, we can assume the device has many times the capacity of a phone, and so we can err somewhat on the side of downloading more. We consider several metrics in evaluating the overhead of mispredic- tions: whether we can store data for a reasonable number of apps and servers on a single cloudlet, whether we can migrate data between cloudlets in a timely manner, and whether we can load the prefetched content sufficiently quickly.

1. The amount of traffic successfully predicted

2. The amount of extra data we try and download unnecessarily

3. The estimated number of users/apps that can be stored on a cloudlet server, and difficulty of transferring the data between cloudlets

4. The estimated time and overhead of a migration, and; 5. The estimated time to fetch the prefetched content.

We are able to get positive results for the first metric, and reasonable results for the second if we are targeting cloudlets and can thus afford some excess downloads, but the final three points remain a challenge and will likely require new research directions to properly address. Finally, we do not yet evaluate the latency savings for prefetching, since due in particular to our last metric, it is not yet possible to build an effective prefetching system.

Assumptions and limitations: We only apply this method to certain types of traffic. We focus on apps (that aren’t browsers), which usually have a constrained set of requests that they make, rather than web browsing, where the content fetched draws from a virtually limitless set. We also focus on apps that have network traffic, where the content fetched is pregenerated (i.e. no chat or video apps, or games).

We also assume that the cloudlet can be trusted, and thus can observe network traffic and make decisions as to what to prefetch. Some prior work examines how to use untrusted cloudlets [39], but ultimately, someone has to know what network traffic is being sent for this to work due to how we determine what to prefetch.

Much of our analysis is trace-based, which doe not include the server’s response to malformed packets, or any rate-limiting done by the server, which we find to be a major limitation of a real-world deployment. We find that the cooperation of the server to, for instance, not log you out after sending a bunch of invalid requests, is necessary. For a

real-world deployment with the full cooperation of app developers this should be generally obtainable.