The CDN Internetworking Auction

Transcription

1 Market Models for Content Delivery Networks Introduction Chaki Ng, Harvard University Version 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 are constantly battling with congestion issues that would affect customer satisfaction adversely. 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 [8], which are large numbers of users trying to access the same web site simultaneously and thus demanding site resources exponentially. The issue further complicates 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 business sites by allowing them to replicate frequently requested objects such as images and videos around the globe. This has a few advantages: 1) server load is reduced because requests are served by multiple servers; 2) as servers are located across different physical locations, network traffic will spread out; and 3) since users will be served by servers located closest to them, the latency users experience should be reduced. Our motivation is to identify areas where CDN may improve in performance and scalability by using mechanism design methods, particularly auctions. There are several reasons why we believe mechanism design is applicable to CDN. First, there are lots of goods. We can view each web site as a large collection of web objects, each of which has its own specific value and service requirements. Second, there are multiple self-interested parties. Web sites are paying to obtain services that they cannot deliver themselves. Users have values in selecting which web sites to use based on the services they can or cannot provide (e.g. a user is likely to leave a site for another if it takes a long time to process her checkout). Last but not least, the CDN market right now is basically monopolized, with one company (Akamai) serving 90% of the market [9]. Nonetheless, many CDN companies are heating up the competition and are looking for ways to 1

2 provide cheaper and comparable (and hopefully technologically better) services than the incumbent. In this paper, we attempt to analyze how the CDN value chain works and come up with basic auction models, borrowed from existing work in related areas, for three issues: 1) management of cache space for a single server; 2) selection of CDN partners for internetworking; and 3) load balancing of P2P servers to fulfill client requests. CDN Basics First we should 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 in different geographically locations to provide the services. A client is a generic person accessing the content provider website from somewhere and does not involve directly with the CDN the fact that content providers use CDN services is transparent to the client. We are ignoring additional parties in the real world such as the Internet Service Providers for the clients. Figure 1 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 specifying in their browser. Second, when CNN.com receives a request, its web server will serve the content that it decides to serve internally. These include low bandwidth and light items such as the skeleton homepage itself and small graphics. Third, for items that are frequently requested and require high bandwidth, CNN.com would automatically forward the requests to its CDN provider, Akamai. Akamai would then know about the objects CNN.com wants it to serve as well as 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. 2

3 Clients (1) 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 1: Basic work flow of a CDN Cache Space Auction Our first attempt is to study how individual caching server manages its resources. Among the many key issues a server faces, an important one is effective use of its cache space. By cache space we mean the actual physical storage space on a caching server where the cached objects downloaded from the content provider site will be stored and accessed. The problem of cache replacement is this: when the cache space is full while new objects arrive, which of the cache should be removed to accommodate the new ones? Traditional replacement policies do not differentiate user values. The most popular methods are based on Least Frequent Used (LFU) and Least Recently Used (LRU), or a combination of the two. LFU means that objects in the cache that have lowest numbers of access shall be removed from the cache. LRU means that objects in the cache the longest will be removed. 3

4 In the real world setting each object for each content provider has different values. For example, objects on the first page of CNN.com should have higher values than objects of any other page of CNN, since all users must access the first page first. Each content provider also has different values than each other. When the 911 news came out, CNN.com was the most popular website on the planet at that moment, and would require CDN services more than any other sites. We will try to capture some of these concepts in a cache space auction, adopting from the work of [2]. Each caching server (the seller/auctioneer) runs its own auction to manage its cache space. Anyone (the buyer) that wants to access the cache of a server needs to submit a bid for that auction. Therefore, a buyer will be bidding multiple auctions to have the geographic benefit of CDN. In a single CDN case like in Akamai, a buyer may be an agent created by Akamai, and represents one of the content providers like CNN.com. Because all the caching servers are owned by the CDN, the goal of the auction is to maximize welfare rather than revenue. No real currency is exchanged but each buyer agent would be assigned some virtual currency to trade. This is determined by the represented content provider s service level agreement contract. For the most valuable content providers, such as one that is about to release a live web cast, the buyer agents would receive the most currencies. The CDN will need to create some controlling process that assigns and control the currencies among the buyer agents periodically after auctions are cleared. The auction of a caching server has the following structure. The auctioneer decides the time period for which it clears its cache (e.g. 20 minutes). It will run the auction for about a minute before the next cache clearing time. Bids submitted by buyers will be in the form of {price, cache size}. {Price} is a value that the buyer agent assigns for the content provider it is submitting bid for. Content providers that must be served in a specific cache will have higher prices. A buyer cannot submit prices that are higher than its available currencies. The buyer also needs to specify the size of the cache it is asking for, in MB. Note that we are not treating individual objects of a content provider, we are letting them own a piece of the cache and any objects from the content providers can be stored in the cache. The auctioneer collects all the bids and clears the auctions by ranking them in descending order of {price per byte}. It determines the winners (there will be multiple winners, since no one single object will fill up the whole cache space) by selecting them from that ranked list, top to bottom. As long as the object size for a bid fits into the remaining open cache space, the bid will be selected. 4

5 The payment of all the winners would equal to the highest losing bid in the ranked list. If all the bid sizes (say 9GB total) happen to fit into the cache size (say 10GB), then all the winners pay zero. As suggested in [5], the value for an object or web page to be served in the cache can be interpreted as the miss cost, meaning that if the object is not served otherwise the content provider would lose the client and money. Deciding how a buyer should bid the price / value is thus the key for a successful auction. Proposals in [2] and [5] use a generic value chosen from a set randomly for each server: {1, 10, 100, 1000, 10000}. The buyers would submit its price based on this value multiplied by the expected number of hits for those objects. Since in our scheme we are dealing at the content provider level, we shall use the expected number of hits for the content provider website as a whole during the cache time period. We will continue to adopt a value set, though they would not be assigned randomly. Based on the SLA and the conditions at the present round, a buyer agent would assign the values accordingly. For urgent website, the agent would use For a site that has standard access such as an average value of 100 would be submitted. Again these values depend on how much the agent is assigned for the round (we renew currencies each round) and hence an agent for an average site would never receive enough currencies to bid for Figure 2 shows how the auction works graphically. 5

6 Servers (1) Submit bids < value_per_byte, object_size, server_id > Auction Manager Auctions every 20 minutes Bid Selection: - Highest values - Meet reserve price - Fit in open cache space Payment: highest losing bid Push objects on cache Figure 2: Cache Space Auction Workflow CDN Internetworking Auction We now attempt to see what we can do market wise to facilitate the new trend of CDN internetworking. According to [3], Akamai today runs a worldwide deployment of more than 10,000 servers. Running a global CDN thus requires enormous amount of capital and labor. Like airline code sharing, CDN companies are starting to partner together so that each can supply and receive services that one cannot provide to content providers otherwise. We shall describe how this works overall. For technical aspects of how CDNs can internetwork together, see [1]. 6

7 No west coast presence CNN BOS LAX Request HTML Client in SF Serve embedded objects / graphics Figure 3: How CDN Internetworking works Figure 3 shows the workflow of a CDN internetworking system. A client from San Francisco is visiting content provider CNN.com. CNN.com has an exclusive service level agreement with Boston. However, this CDN does not have any caching servers in the west coast, and has thus partnered with another CDN in Los Angeles. When the client request arrives at Boston and it determines that it cannot serve the request well (it can, technically, use the Boston servers but service will not be optimal). In this case, it passes the request to LA and let it handles the caching request and pays LA a fraction of what it receives from CNN. Inspired by the work done in [11], which is a distributed market economy for buying and selling idle CPU time, we are interested in applying similar strategies in structuring a market for CDN internetworking. We have buyers who are CDNs that are looking for CDN services elsewhere. We have sellers who are other CDNs. The interesting setup is that a CDN can be both a buyer and seller a Boston-based CDN may need to buy services from the West Coast, and at the same time selling its capacity to other CDNs. Note that the customers of the CDNs are not aware of such internetworking, as customers only deal with their desired CDNs directly. Each seller holds it own auctions. Each auction is for a region the seller decides (e.g. four auctions for a CDN with US East/South/West/North). The buyers bid for the right to use a region for the amount of time seller decides, and for the amount of cache space the buyer declared in the bid. Note that each buyer is interested in getting one CDN for each region it needs to service, for each content provider. There is a pool of currency, or reservoir, that a buyer is willing to spend to 7

8 outsource to other CDNs and still make a profit on each customer. This is a private value of the buyer that no one else knows. Therefore, what a buyer would implement is a bidding application for each customer, and for the application it has a number of bidding agents for each region of interests. The total prices bidding agents use to bid cannot exceed the reservoir for that customer. We will use the simple average cost bidding strategy as shown below. What to bid for for each auction CDN participates in The expense for running the caching servers CDN owns Bidding value for each region = (Revenue - Internal service sost) / # of external CDNs used Total Revenue CDN would earn from customer during time T The number of regions CDN must outsource and bid Figure 4: Bidding valuation for CDN Real currency will be used for payment in this case, since the participants are agents who represent real businesses. We will assume that payments will be settled with ease, and the use of a central authority or bank is not required. The auction mechanism is sealed-bid, second-price. The winner pays the price declared by the highest losing bid. The auction accepts bids until it closes, and the winner will to use the regional cache servers as soon as the auction is closed. Note that this auction is not only incentive compatible, but since the reservoir is the maximum amount of money a buyer is willing to spend on the auctions, the buyer will likely end up not spending the maximum because of the secondprice nature (and hence still maintain profits to outsource). P2P Load Balancing Exchange Another hot trend in CDN is to use individual computers outside of the CDN network, i.e. idle home and business machines. Companies like Kontiki [6] use a model where a client request may be fulfilled by other nearby clients that previously used Kontiki and thus have the same objects in storage. On the other spectrum, P2P file sharing schemes popularized by Napster and Gnutella are extremely popular these days. We therefore see a likely convergence between the two and some form of extreme P2P CDN system where any machine can be a caching server for a CDN may arrive. We want to propose a CDN exchange hosted by a central CDN company, whose role is more of brokering since it may own none of the caching servers. Our work is inspired by that of [12], who 8

9 proposed a central exchange mechanism to adjust air conditioning supply and demand throughout a building. The exchange is double-blinded, in that each bidder (buyer or seller) only knows its own bid value but no one else s. In our case, a number of individual machines sign up with CDN to be used as caching servers. All servers that can serve a particular region (say Chicago) will be treated equally and grouped together. Thus, the CDN will be managing one auction for each region. All client requests for the CDN for a particular region will be routed to the respective group. A controller is present at each group to direct requests to each server and will change its request flow after each auction is ended. The resource we are trading is the client requests. Each server will be assigned an agent to track its load. An optimal load like 50% is the default, above which it is overloaded (otherwise it is underloaded). When a server is overloaded, it will be a seller of client requests, to be matched and taken over by some buyers, which are underloaded and should serve more requests. Figure 5 depicts the situation. Individual Caching Servers CDN Exchange Overloaded 95% Buy Sell Overloaded 75% OK 50% CDN Controller Flow of Client Requests Underloaded 40% Underloaded 30% Figure 5: P2P Load Balancing Exchange 9

10 Whether a server is over/underloaded is not dependent only on the amount of client requests the server receives. A server has its own system characteristics such as CPU, memory, storage space, bandwidth, etc. that would affect the load. If all servers are homogeneous, we do not need to consider a market mechanism but some round-robin algorithms to split the client requests equally. The market determines a trade price for each round based on supply and demand. It matches all the bids and asks and finds the price where the supply and demand curves overlap. All bids above the trade price and all asks below the trade price will be accepted. Each server agent will have its own utility function to determine price. Each agent will be given some money m to begin with, and will buy and sell to add/subtract from m. The bid/ask price for the agent i for round a would be determined by function B(.): B i (a) = U i (t, m, C) * P(a-1) where t is a function to determine whether the agent is buying or selling (e.g. current load / optimal load), m is the amount of money agent has, C is a function of the system characteristics of the server (as mentioned before, e.g. CPU) and P(a-1)is the trading price in the last round. Experiments in [12] show that the auction works well and agents converge to the optimal load quickly. In their case, the optimal temperate (load) is set higher in the summer and lower in the winter to achieve overall energy savings for the whole system. The rationale is that if we set 70 degrees as a constant in the summer we might have to decrease 20 degrees for each agent. However, the key feature here is relative load, which means that the agents would be happy getting 10 degrees off of 90 degrees in the summer or getting 10 degrees more than 30 degrees in the winter. We can implement similar settings in the caching server case, with optimal load adjusted for expected high traffic season such as web casts. Conclusion We have shown three basic market models that can be applied to the CDN value chain. First, we looked at how individual cache servers can use a straightforward, descending price auction mechanism to manage its cache space. Second, we attempt to apply [11] s second price auction framework on the new field on CDN Internetworking. Third, we mirror the methods in [12] to create an exchange where CDN with P2P architecture can balance load among individual cache servers. Industry discussions suggest that end user satisfaction with performance and QoS are primary drivers for caching ([7]). A great next step is to further investigate these market models and 10

11 attempt to tie quality of service from end to end: from the clients and the content providers, to the CDN and its partners and cache servers. It will be a breakthrough if there are schemes for QoS to be measured consistently through the value chain, and can be factored in any markets taken place universally. Combining such QoS-aware markets with new work in SLA and QoS optimizations ([10]) should provide new CDN or CDN Internetworking architecture that scales and perform well under most conditions. Another step would be to apply more sophisticated techniques in the auction models. Price / value are still the primary driver in the auctions discussed, and it would be ideal to expand this into some form of multi-attribute / combinatorial auctions. The type of auction desired will be highly dependent on the structure of QoS measurements. As a reference, [10] uses three major parameters to determine QoS: server-side response time, probability of rejection, and site throughput. References [1] Biliris, Alexandros, et al. CDN Brokering. International Web Caching and Content Distribution Workshop, ( [2] Chan, Yee Man, Jeffrey K. MacKie-Mason, Jonathan Womer, and Sugih Jamin. One size doesn t fit all: Improving network QoS through preference-driven web caching. Proceedings of the Second Berlin Internet Economics Workshop, May [3] Intel ebusiness Case Studies on Akamai. ( [4] Karaul, Mehmet, Yannis A. Korilis, and Ariel Orda. A Market-Based Architecture for Management of Geographically Dispersed, replicated Web Servers. Proceedings of the First International Conference on Information and Computation Economics, [5] Kelly, Terence, Yee Man Chan, Sugih Jamin, and Jeffrey K. MacKie-Mason. Biased Replacement Policies for Web Caches: Differential Quality-of-Service and Aggregate User Value. Fourth International Web Caching Workshop, March [6] Kontiki web site. ( [7] Oaks, Chris. Can Caching Tame the Web? Wired News. August 18, [8] 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 ( [9] Krishnamurthy, Balachander, Craig Wills, and Yin Zhang. On the Use and Performance of Content Distribution Networks. ACM Internet Measurement Workshop,

12 [10] Menascé, Daniel, Daniel Barbará, and Ronald Dodge. Preserving QoS of E-commerce Sites Through Self-Tuning: A Performance Model Approach. 3 rd ACM Electronic Commerce Conference, [11] Waldsburger, Carl et al. Spawn: A Distributed Computational Economy. IEEE Transactions on Software Engineering 18, [12] Clearwater, Scott. Market-Based Control: A Paradigm for Distributed Resource Allocation