Game Theory Applications for Content Delivery Networks

Transcription

1 Game Theory Applications for Content Delivery Networks Chaki Ng, Harvard University [ chaki@eecs.harvard.edu ] Version Introduction As Internet topology and user base grow by the minutes, services delivered on the Internet are competing more fiercely against each other for finite network and computing resources. High availability and responsiveness of services are keys to business sites, which may lose valuable customers otherwise. Classic examples of service disasters include Victoria s Secrets and the NASA Pathfinder mission web casts, during which users could not access to the sites or experienced infinite delays. These were caused by the so-called Flash Crowds [4], which are large numbers of users trying to access the same web site simultaneously and thus demanding site resources exponentially. The issue further complicates beyond the site, as traffic from such flash crowds affect the rest of the Internet. Content delivery networks, CDN, are one of the key service management infrastructures that relieve such service degradation. CDN helps its customers, the content providers, run business sites by allowing them to replicate frequently requested objects such as images and videos on CDN cache servers around the globe. This has a few advantages: ) server load is reduced because requests are served by multiple servers; 2) as servers are located across different physical locations and services clients at different locations, network traffic will spread out; and 3) since users will be served by servers located closest to them, the latency the user experience should be reduced. For more background on how CDN works please refer to [5]. We are interested in analyzing several basic technical and business aspects of a Content Delivery Network (CDN) from a game theoretic perspective. CDN is a hot new industry with lots of open and complicated issues. The industry foresees CDNs to further grow into a multi-billion dollar industry, and new technologies that make CDNs better continue to evolve. It is our hope that by starting to study some basic game theoretic issues for CDNs through this paper, we will gain further inspiration for advanced game theory applications in the domain. The three issues we will address are:

2 . How does CDN design its network of cache servers such that network traffic is minimized? 2. For high demand, live streaming events, how can we improve performance in real-time? 3. Are specific Quality of Service agreements advantageous for CDN customers? CDN Basics First we will introduce some terminology. There are three main parties involved in this paper. A content provider, or customer, is one that operates a website that is open to public access (e.g. CNN.com). A CDN is a company that operates CDN services for content providers. The CDN uses its caching servers located at different geographical locations to provide the services. A client is a generic person accessing the content provider website directly from anywhere on the planet and does not involve directly with the CDN the fact that content providers use CDN services is transparent to the client. Clients () All client requests first arrive at CNN site (2) CNN returns basic docs (e.g. cnn/index.html) CNN Get new objects in cache (3) Selected embedded objects (e.g. graphics, movies) will be served by Akamai bos (5) Objects served by servers that are closest and not overloaded sf (4) Forward requests Selection Algorithms uk Servers around the globe Akamai Figure : CDN Workflow Mechanism Figure shows how a typical CDN works. We use CNN.com as the content provider and Akamai as the CDN. First, clients from around the globe all access CNN.com the same way, by using in their browser. Second, when CNN.com receives such a request, its web server will serve the content that it decides to serve internally. These include low bandwidth and 2

3 light items such as the skeleton homepage itself and small graphics. Third, for items that are frequently requested and high bandwidth, CNN.com would automatically forward the client requests to its CDN provider, Akamai. Akamai would then know about the objects CNN.com wants it to serve and the locations of the clients. It needs to determine, for each client, which caching server should deliver the objects. This is done by Akamai s proprietary algorithms. Typically, for a specific client located say in Boston, Akamai will choose from its caching servers in the Boston area and select the one that is not currently overloaded. On first request the selected caching server does not yet have the objects cached in its space, and thus will download the objects directly from CNN.com. This is only done once, and for any subsequent requests the server would simply serve the objects from its own local space. CDN Network Design In this section we will attempt to address question : How does CDN design its network of cache servers such that network traffic is minimized? Because the purpose of the CDN is to improve performance for business sites, it is important that the CDN network of caching servers has good performance. First of all we have to distinguish between what a CDN does and does not have control over to improve performance. A CDN does not have control over the Internet traffic. The Internet is a massive collection of different networks and domains, each owned by different administrative entities (e.g. universities, corporations, government, etc). Such decentralized setup is the main reason why the Internet has blossomed. Traffic can freely flow from one place to another based on individual (the routers that send data round) goals, which are mainly looking for the lowest traffic and latency at all times. A CDN has control over the caching servers and how they are connected among each other and to the business sites. Essentially a CDN is building a global scale network of thousands of caching servers. As such network is built on top of another existing infrastructure, the Internet, and routing of data only exists among these caching servers, it is called an overlay network. By adding an extra abstract layer under its full control, the CDN can derive proprietary algorithms and mange the infrastructure without having bottlenecks from other network domains. In other words, the CDN can choose the best underlying Internet paths that one caching server has to go through to communicate with another server or the customer website (for requested caching objects) and avoid the congested routes. We shall try to model such traffic design as games and see what can be applied in designing CDN network. Our work is based heavily on [2]. 3

4 We will start with some basics on how selfish agents affect Internet traffic. Suppose there is an origin node, FROM, and a destination node, TO. Data traffic goes from the origin to the destination. There are two paths that data can choose from, UPPER and LOWER. Each path has some latency factor, which means that data flowing through a path will be delayed by that factor. For UPPER the latency factor is X, meaning that it is equal to the amount of data flowing through this path. For LOWER the latency is. To calculate latency of a path, we multiply the traffic by the latency factor. Figure 2 shows a specific example. Total data traffic flowing is. Exactly half of the traffic chooses UPPER, and the other half chooses LOWER. The latency for UPPER is ½ * X = ½ * ½ = ¼. The latency for LOWER is ½ * = ½. Total latency between FROM and TO is thus ¼ + ½ = ¾. upper X Flow = /2 From To lower Flow = /2 Figure 2 Is this example realistic? No. Because the two paths yield different latencies, data packets will all prefer to travel to the lower latency path (UPPER). We can verify this with a simple 2 player game as shown in Figure 3. Packet B Upper Lower /2 Upper /2 /2 Packet A /2 Lower Figure 3 4

5 We make things simple by assuming only two packets make up the flow and that they both contribute to ½ of the total flow (equals one). The payoffs in this game are the latency factor that the packets know. Note that we use latency factor, and not latency, because packets do not know beforehand how much traffic will also decide to travel on the same paths. Latencies are calculated after everyone makes its move. Hence, the payoffs are either ½ if a packet chooses UPPER or if it chooses LOWER. Since lower payoffs are better in this game, the Nash Equilibrium of the game is [UPPER, UPPER]. The resulting path choices are depicted in Figure 4: upper X Flow = From To lower Flow = Figure 4 Because both packets choose UPPER, we have a flow of ½ + ½ = for UPPER. Because there is no traffic for LOWER, total latency equals flow for upper + flow for lower = * (remember X means the same as the flow value itself) + * =. We can see that in Nash Equilibrium the total latency is not optimal! We could have done better as in Figure 2 by having packets split paths and obtain a lower latency of ¾ instead. This result is not unexpected since we have learned that Nash Equilibrium is not necessarily optimal. Thus far, we have used a simple latency function which is linear (X and ). In [2] they have shown results for non-linear latency functions and found the Nash latency would be at worst a factor of two of the optimal path combinations. In their paper, it was suggested that we simply double the bandwidth. However, doubling is easier said than done. Recall that the Internet is a network of networks. It is much easier to double the major backbones such as those owned by the major ISP companies like AT&T (analogy: the Interstate highway system) than the lower level links (analogy: local streets). For example, lots of users these days are connected with cable modem or DSL modem, which cannot be doubled in bandwidth due to technological constraints. Hence, doubling would only work on some paths, but not all paths in the CDN network. Therefore, we still would constantly experience latency paths. The main reason is that even if we double the latency, we 5

6 have not solved the selfishness issue. Selfish packets still are looking for the low latency paths, which are the ones that we just doubled. We are now ready to see how CDN can use the above behaviors to design its network. One intuition one may have is to allow more paths with low latency factors be connected together. Suppose we have the paths shown in Figure 5 connecting two CDN caching servers physically on the Internet. Each of the two paths joining FROM and TO includes two sub-paths that have latency and X. In other words the latency of the two are equal (they are just reversed in order). Since CDN has control over how FROM and TO are connected, it will likely want to improve the latency by allowing traffic to go through only the low latency sub-paths. Figure 6 depicts how this is done. CDN establishes a new sub-path (to simplify the example we assume it has a latency of zero) joining the two intermediate nodes, so that traffic from the low latency UPPER path can go through it and join the low latency LOWER path. Thus the latency factors are X--X. Because this path is preferred to other paths, all traffic flow through this path. Flow = /2 X From To X Flow = /2 Figure 5 6

7 Flow = X From To X Figure 6 We can calculate the total latency in both cases: Total latency of Figure 5 = latency of UPPER (with ½ of the flow) + latency of LOWER (with ½ of the flow) = (½ * X + ½ * ) + (½ * + ½ *X) =.5 Total latency of Figure 6 (only one path, flow = ) = latency of sub-path UPPER (X) + latency of new path () + latency of sub-path LOWER (X) = * X + * + * X = * + * = 2 The supposedly new design of the CDN yields higher total latency!? This puzzle is the classic Braess s dilemma ([7]). What this result shows is that, when designing the network, a CDN does not want to join only the low latency paths together. All traffic will go through those optimal paths, and the overall latency is higher than more balanced paths like those in Figure 5. In summary, the CDN should evaluate all possible path combinations, and find path combinations such that the total latency is minimized. For example, if the CDN is given possible paths in Figure 6, it should attempt to take the zero latency path out, so that it can attain the optimal solution as in Figure 5. In essence, standard way of thinking about optimization does not apply in this latency problem. One must consider the independent actions of all agents involve and provide a specific set of rules that the agents must follow. 7

8 QoS Guarantees or Not? In this section, we will analyze whether specific Quality of Service agreements are advantageous for CDN customers. Typically, like many other Internet services, CDNs sign fixed fee contracts with customers with no specific service guarantees. The most common service guarantee on those contracts would be about up time (e.g. 99% up time ), which means that the service will be unavailable less than % anytime. Even if 99% of the requests by the customer are served by the CDN, the customer has no control over other parameters. For example, the CDN does not guarantee how long it will take for a client to download all the objects. Content providers like Amazon would want to make sure that its web pages are fully downloaded to its clients as quickly as possible (the industry often talks about a 7-second rule), because if it takes too long the clients can easily go to Amazon s competitors like Barnes and Noble to buy the same products. Similarly, for important client requests (e.g. someone is on the online shopping checkout page), a customer would not want the CDN to process these with overloaded caching servers. A new trend is to change the terms of the contracts, such that there are some guarantees of specific services. With the above two examples, the agreement may include QoS terms like 9% of all requests must be served within seconds and % of the requests are served by caching servers with load no more than 8%. We will model this as a game and use Forward Induction to solve it. First, we will ignore QoS for now and frame the standard game that CDN and content provider play. For content provider, there are two choices: INCREASE LOAD, or NORMAL. NORMAL means content provider would use the service as-is, while INCREASE LOAD means the content provider will try to increase routing requests to the CDN. At NORMAL content provider will be indifferent with the service CDN provides (in other words, CDN can deliver NORMAL load services reasonably well). At INCREASE LOAD the content provider is hoping that by using more of the CDN s services its customers will be happier. For CDN, it has two choices: PRIORITY or NO. For most content providers, CDN would treat them the same and with NO priority. If it decides to treat a particular content provider with PRIORITY, then the services delivered for that content provider must be satisfactory. Why would a CDN assign PRIORITY to some content providers? Perhaps those content providers are the biggest clients of the CDN or they received bad services from CDN recently and it is trying to keep the relationships. 8

9 Increase Load Content Provider Normal 3 Priority - CDN - No Figure 7 Figure 7 depicts the choices and payoffs. When CDN treat a content provider with NO priority, and content provider uses CDN services with NORMAL load, both have zero payoffs (services are OK). If CDN treats this NORMAL load with PRIORITY, CDN would have a - payoff. This is an opportunity cost for CDN. Since content provider is just using the normal load, CDN could have waived priority and could provide high priority services elsewhere. Now we will see what happens when content provider increases load. If CDN does not make it a priority, then the content provider would have negative payoff of -. Its clients would receive bad services, and it will end up losing revenue and clients. There is a zero payoff for the CDN, since it has not done anything for the situation and is not required to do so. If CDN makes it a priority, then the content provider would receive a high payoff of 3. It invites more clients to use its services via CDN, and the services are of quality. CDN makes the right choice and it will receive a payoff of (the content provider is happy and would likely renew their agreement in the future). 9

10 Increase Load Content Provider Normal 2 - Priority 2 CDN -2 - No Figure 8 Now we will add in the QoS choice. To active QoS agreement, content provider must first pay CDN a fee, similar to buying insurance, for the guarantee. The cost for content provider would be and it adds directly to CDN s payoffs. Figure 8 shows the new payoffs. The deal of the QoS normally works like this. If CDN meets the QoS item, then it will receive an additional payoff of as bonus. The content provider serves its customers well, makes an additional profit of 3 because of it. Its net profit is hence 2 after paying the bonus to the CDN. If the QoS is not met, the CDN will have to refund the QoS fee plus pay a penalty of 2 to content provider. Thus, the payoff of this game with QoS is more complicated than some examples we have seen in examples in class, where the option available would only have a constant payoff effect (+ on a player, and - on the other) on each outcome combinations. Increase Load Content Provider Normal 4 - Priority 3 CDN - No -2 Figure 9

11 The full game is modeled in Figure. We will use Forward Deduction to find the solution. The procedures are: () Remove NORMAL under QoS branch for content provider. It could have stay with no QoS and receive a payoff of rather than -. (2) CDN then can eliminate NO since it will choose PRIORITY with a higher payoff of 3. (3) NORMAL and No QoS for content provider is strongly dominated by QoS INCREASE LOAD ( vs. 4). (4) CDN will choose PRIORITY over NO ( vs. ). (5) We are left with two choices, both PRIORITY, INCREASE LOAD. Content provider will go for QoS guarantee and get payoff of 4. Content Provider QoS Quarantee No (5) Increase Load Content Provider Normal Increase Load Content Provider Normal () Priority Priority - 3 CDN CDN - - No No -2 (4) (3) (2) Figure The result of this game is not surprising. Even after just steps () and (2), we are basically left with the game of the left hand size (with no QoS) and [PRIORITY, INCREASE LOAD] on the right. The payoffs of [PRIORITY, INCREASE] is simply better than any of those in no QoS. This choice

12 is basically a win-win situation for both parties: CDN gets paid to deliver high quality services, which it is capable of doing, and get rewarded with bonuses that other non-qos customers would not pay. Content provider can now offload most of its operations to CDN and focuses on its core business (recruit and retain clients, generate revenue). Content provider also knows that CDN will deliver the highest possible services it can deliver, and rewards CDN with profit sharing (the bonus). Streaming Media Multicasting Sometimes content providers hire CDNs for special web cast events. These are live streaming media broadcast over the Internet, such as a major concert event. The amount of simultaneous requests for such web casts is typically extremely high (for popular events there will be millions of simultaneous requests). Also, streaming media files are much bigger than typical graphics and media file, and because users are viewing the files in real-time, it is necessary that the streaming not be interrupted. Achieving high quality and high volume web casts is not easy. The CDNs uses a solution called Multicasting to address this problem. Basically, the idea is that many requests come from the same paths (group requests in regions, say Cambridge / Boston / Worcester / Springfield, think of each region as a number of clients connecting via the same ISP, hence sharing paths). Sending data on the Internet does not have marginal cost benefits sending the data on a path to one user costs the same as sending to multiple users. Hence, it is more economical to send the streaming files one time along those paths and get as many users as possible to receive them. Interesting work by [6] demonstrates mechanisms for implementing multicasting with incentive compatible mechanism. It uses similar settings as cooperative game theory and the marginal contribution concepts. We shall attempt to apply it to an example and see how it may work for a CDN. We will focus on one of the caching servers of the CDN, say the one in Boston serving clients in the area for a live web cast of a World Cup game. Suppose there are four different destinations where all the clients reside. Figure shows the setup. There are costs associated with each path from the caching server to the destinations (the numbers next to the paths). Each client has a willingness-to-pay value to get the web cast (e.g. {3, 8} means that two clients share the same path, and they have values of 3 and 8 respectively). 2

13 Caching Server {3, 8} {4, 38, 25, } {3, 25} {3, 25, 5} Figure First of all, the caching server has to decide which destinations to send the web cast to, based on net profits. If a destination is accepted, then all clients at that destination are accepted as well (since there is no additional cost). The destinations that have combined client values higher than the path costs would be selected, and we shall apply this rule to each path, and each subset of the whole tree. Checking the lower four paths we can see that they each have combined client values higher than costs. For example, 3+8>2, >4. We then consider the sub trees branching out from the caching server node. Both sides have overall values higher than costs (e.g. the left size client values are higher than = 9). We can conclude that the caching server will serve all of the clients in this example. Second, we need to find out the total value, or pie, of this tree. The total cost of the multicast tree is the same of the cost of each edge. That equals to = 96. The total value = = 276. The pie created is value cost = = 8. We will call this V(N). Third, we calculate the marginal contributions of each client. This is done by finding V(N) V(N\i), where V(N\i) is the total value without client i. To calculate V(N\) for client, we first need to calculate the total costs without it. In this case, the destination belongs will not be served, because we now only have one client with a value of 8 < the cost of the path = 2. Therefore, the total value without = (276 38) (96 2) = 62. Since V(N) = 8, the marginal contribution of client = 8-62 = 8. Similarly, the marginal contributions for the rest of the clients are {8, 4, 38, 25,, 9, 9, 9, 9, 5}. 3

14 [6] suggest payment schemes that would allow this to be implemented. Payment for each client would be its individual value minus marginal contribution. Again for client its payment would be 3 8 = 2. The revenue for the tree would be the total costs of the paths. With this scheme, CDN can serve content providers for web casts with a fair pricing system. In practice, actual clients are not aware of the multicasting structure, and their values are determined by software agents installed by the content providers. Conclusion We have demonstrated three basic CDN issues that can be analyzed using game theoretic methods. The biggest issue in computer science is that all things are assumed to be cooperative (or non-selfish). Because of the Internet things have changed, and one cannot assume other resources/programs would be cooperative. The infusion of game theory with computer science seems very attractive to create new models of computation and analytical thinking. Content delivery networks are one of the most widely used applications on the Internet and they keep it from congestion. We hope to further develop some of these methods and bring them to the realworld. Reference [] Krishnamurthy, Balachander, Craig Wills, and Yin Zhang. On the Use and Performance of Content Distribution Networks. ACM Internet Measurement Workshop, 2. [2] Roughgarden, Tim and Eva Tardos. How Bad is Selfish Routing? FOCS 2. [3] Intel ebusiness Case Studies on Akamai. ( [4] Ratul Mahajan, Steven M. Bellovin, Sally Floyd, John Ioannidisand Vern Paxson, and Scott Shenker. Controlling high bandwidth aggregates in the network. Technical report, (draft), February 2. ( [5] Rabinovich, Michael, and Oliver Spatscheck. Web Caching and Replication. 2. [6] Feigenbaum, J., C. Papadimitriou and S. Shenker. Sharing the Cost of Multicast Transmissions. Journal of Computer and System Sciences 63 (2), pp [7] Braess, D. Uber ein paradoxon der verkehrsplanung. Unternehmensforschung, 2: ,