1. CDN Brokering* Presented By Nick Arnold Authors Alexandros Biliris, et. Al

2. Topics* -Conjecture -Introduction -General CDN Brokering -Selection -Redirection -Naming -Accounting -IDNS -DNS Element -Control Element -Performance & Results -Future Work -Questions 2

3. Conjecture 3

4. If caches can do it, so can we! Purpose is the same as caches – Decrease latency – Reduce Web Server work (costly) Inter-cache communication – Could work (optimally) – Not widely used CDNs distinct advantage? – Built on “capital-intensive” network – Better suited for “flash-crowds” 4

5. Introduction 5

6. This is why… CDN Advantages: Can pay a fee to use high-powered operation. This lets the little guy in (15 minutes of fame on your smalltime blog/video). Decreased Latency! 6

7. …and why not. CDN Disadvantages Very Costly. Operationally Complex. Rely on Locality. 7

8. What is CDN Brokering? “Ability of one CDN to redirect clients dynamically among two or more CDNs”. A specific implementation is covered in this paper. The key is dynamic. 8

9. Background / Motivation Equality: CDN x != CDN y Goals: x -> “I want to serve the whole world!” y -> “I love YouTube and no one else!” $$$: 1. Overloaded? I’ll help you for $. 2. I built this server, you can use it too…for $$. 3. It’s a part of the design! 9

10. General CDN Brokering 10

11. Big Components 1.Selection 2.Redirection 3.Naming 4.Accounting (I told you) 11

12. Selection Our first and biggest objective: Where did the request come from? Where should the request go? Quickly. 12

13. Redirection Going somewhere else: Use DNS. Overhead of Brokering vs. Latency. Enforced by TTL. 13

14. Naming DNS Mapping: Name Server (NS) Redirection – The destination CDN is made authoritative for lowest level of domain name. CNAME Redirection – Use Host Header in HTTP to identify content.* *Only works if all servers treated the same. Otherwise, format must be agreed upon. 14

15. Accounting $$$ is the driving factor: CDN is built on shares. Needs to “account” for measuring the usage of links. Would this be included in an academic paper? 15

16. Intelligent Domain Name Server 16

17. IDNS How requests are passed 17

18. External vs. Internal External Forward request to another CDN Give client DNS resolution for new CDN. Client DNS resolves to get A record of Edge Server Internal Options: 1.Return A record 2.Triangular Resolution – forward DNS query, let internal DNS respond to client DNS 3.Redirect to internal DNS just like external 18

19. IDNS Architecture 19 Several Critical Components of the IDNS  DNS Element  DNS Engine  Control Element  Control Component  Configuration Agent  Management Agent  Load Agent

20. DNS Element Main Purpose: – Receive and answer DNS queries from the network. Main Structure: – Consists of only the “DNS Engine”. – Uses tables for lookups of where to route request. 20

21. “Smart” Tables Region table: clustered IP-addresses -> matched by longest prefix-match Distribution table: Distinguished by “Service”. -> Multiple of them. -> 1 entry/region (type, CDN or DNS) Customer Table: defined by your DNS name and particular distribution table 21

22. Resolving a Request One longest prefix match One hash table lookup One array element lookup Simplified Random Number Generator O(1) + O(1) + O(log n) + O(1) 22

23. Control Element Asynchronous Updating -> Dynamic! Regions, customers, and CDNs are our measurements. Load Balancing: -Our most important act- -> Update the tables for the DNS Engine -> Probability Distribution 23

24. Agents 24 Configuration Agent: Task: Initialization Management Agent: Task: Run-time, administrator control Load Agent: Task: Communicate with other CDNs

25. Performance & Results 25

26. What should we test? No established benchmark for this system. Break into three categories: 1.Brokering Server Performance 2.Overhead 3.Overall Performance Got an idea for another test? 26

27. Test 1: Test Single Broker Server Setup Measure the front-end (DNS Engine) with the back-end (Control Element) performance Basics (Simulated): Three situations -> No updates (only DNS Engine) 5 CDNS, 50 customers, 250 regions -> 1 update/sec (Both) 1-10 CDNs, 1-100 customers, 1-500 regions -> Max updates/sec (Heavy back-end) 1-10 CDNs, 1-100 customers, 1-500 regions 27

28. Test 1: Results 28

29. Test 2: Redirection Overhead The big question: Is it worth it? Setup Case Study – Examination of Packet Traces on DNS Includes 6 websites, 25,000 clients Three types of sites: Regular, CDN, and Brokered Used dig to issue requests (Domain Information Groper) Settings - > Cold Client DNS - > “Lukewarm” Client DNS 29

30. Test 2: Results 30

31. Results Continued… 31

32. Test 3: Do we measure up? Setup 2 real CDNs, 2 web sites 11 locations (worldwide) 1 HTML object 13 imbedded images 4 parallel connections 10x test runs. Purpose Want to see if website performance is increased through use of CDN sharing 32

33. Test 3: Results Neither CDN outperformed the other ~= 82 KB/s > 52 KB/s Initial Delay decreased to 0.30 seconds* *by? 33

34. Future Work 34

35. What else can be done? Research into reliance on locality -> CDNs biggest problem Content Bridge -> exchange between symbiotic networks. Closer inspection of load balancing. … 35

36. My Thoughts On the structure… Brokering DNS is a bottleneck. Uses the DNS structure for all routing, not the purpose. Cool because it was actually implemented (IRL) On the paper… A lot of corners cut (e.g. semantic mapping, algorithm for load information) Fault tolerance and improve scale? Doesn’t seem that useful. 36

37. Your Thoughts? 37