Randy H. Katz Computer Science Division Electrical Engineering and Computer Science Department

1. Berkeley-Helsinki Summer CourseLecture #15: Content Distribution Networks and Service Composition Paths Randy H. Katz Computer Science Division Electrical Engineering and Computer Science Department University of California Berkeley, CA 94720-1776

2. Outline • Rationale for Content Distribution • Web Caching Issues and Architectures • Akamai Architecture • Streaming Content Distribution • Business Issues in Content Distribution • Service Composition

3. Outline • Rationale for Content Distribution • Web Caching Issues and Architectures • Akamai Architecture • Streaming Content Distribution • Business Issues in Content Distribution • Service Composition

4. Co-Location Scalable Servers WebCaches Services Within the Network: Caching and Distribution “Internet Grid” Parallel Network Backbones Internet Exchange Points

5. $ $ Caching Advantages for Service Providers Internet Local POP • Move data closer to consumer • Backbone caches save b/w • Edge caches for QoS • 4 billion hits/day@AOL! • Even more crucial for broadband access networks, e.g., cable, DSL ISP Backbone $ $ Local POP Local POP Eric Brewer

6. $ $ Internet Internet Reverse Caching Reverse Proxy Cache Cache fronts origin server Forward Proxy Cache Cache handles client requests Eric Brewer

7. $ $ $ $ Surge Protection viaClustered Caches Reverse caches buffer load across multiple sites Hosting Provider Network www.site 1.com www.site 2.com www.site 3.com Internet www.site 4.com Reverse Proxy Cluster www.site 5.com www.site 6.com Eric Brewer

8. $ $ $ $ $ $ $ $ Content Distribution We can connect these caches! ISP Network Hosting Provider Network Internet Forward Caches Reverse Proxy Cluster Push content out to the edge Eric Brewer

9. Outline • Rationale for Content Distribution • Web Caching Issues and Architectures • Akamai Architecture • Streaming Content Distribution • Business Issues in Content Distribution • Service Composition

10. multicast cloud multicast cloud multicast cloud multicast cloud multicast cloud Example: Application-level Multicast Solve the multicast management and peering problems by moving up the protocol stack Isolated multicast clouds Traditional unicast peering Steve McCanne

11. Example: Application-level Multicast Solve the multicast management and peering problems by moving up the protocol stack Steve McCanne

12. Multicast as anInfrastructure Service • Global multicast as an “infrastructure service”, not a core network primitive • Circumvents technical/operational/business barriers of no interdomain multicast routing, management, billing • No coherent architecture for infrastructure services, because of end-to-end principle • Needed: Service stack to complement the IP protocol stack • Open redirection • Content-level peering Steve McCanne

13. The Service Stack Applications End Host End host Services TCP service End-to-end argument here Network Services IP service Router Steve McCanne

14. The Service Stack Applications End Host End host Services TCP service DNS stub Infrastructure Services Overlay DNS Network Services IP service Router Steve McCanne

15. The Service Stack Applications End Host End host Services TCP service DNS stub Infrastructure Services Overlay Cache Services Proxy Services DNS Network Services IP service Router Steve McCanne

16. The Service Stack Applications End Host End host Services TCP service DNS stub redirection Infrastructure Services Overlay Cache Services Proxy Services DNS Network Services IP service Router Steve McCanne

17. Service Elements for Internet Broadcast Applications End Host End host Services TCP service redirection stub DNS stub Infrastructure Services Overlay Broadcast Redirection DNS Network Services IP and Scoped IP Multicast Router Steve McCanne

18. Incremental Path Applications End Host G2, WMT, QT4 RTSP, RTP End host Services TCP service DNS stub Infrastructure Services Overlay Redirection Broadcast DNS Network Services IP and Scoped IP Multicast Router Steve McCanne

19. Content Distribution Through MulticastOverlay Network Content Broadcast Network Edge Servers Load Balancing Thru Server Redirection; Content Broadcast Management Platform and Tools RedirectionFabric Inter-ISP Redirection Peering Broadcast Overlay Architecture Broadcasters Clients Steve McCanne

20. A New Kind of Internet • Actively push services towards the edges: caches, content distribution points • Manage redirection, not routes • New applications-specific protocols • Push content to the edge • Invalidate remote content for freshness • Collate remote logs into a single log • Internet TV/Radio: streaming media that works • Twilight of the end-to-end argument • Trusted service providers/network intermediaries • Service providers create own application-specific overlays, e.g., cache and streaming media content distribution

21. Outline • Rationale for Content Distribution • Web Caching Issues and Architectures • Akamai Architecture • Streaming Content Distribution • Business Issues in Content Distribution • Service Composition

22. Web Caching Service: Akamai Number of Servers 5000 Number of Networks 350 Number of Countries 50 (as of Fall 2000) Typically 70-90%of Web content

23. ARLs and Akamai Traffic Redirection • http://www.foo.com/images/logo.gif when Akamaized becomes: • http://a836.g.akamaitech.net/7/836/123/e358f5db004e9/www.foo.com/images/logo.gif • Serial #: content “bucket” served from same server • Akamai Domain: redirection to Akamai server • Type Code: identify the Akamai service • Serial # • Content Provider Code: Akamai content provider • Object Data: expiration/version information • URL: original locator, if content not at server

24. Akamai’s DNS Extensions • *.g.akamai.net mapped onto an IP address • Two level hierarchy • HLDNS: redirect lookup to LLDNS “close” to clientRecompute network map every O(10 minutes)Resolution has TTL of 30 minutes • LLDNS: redirect to “optimally located” Akamai server for the clientRecompute network map every O(10 seconds)Resolution has TTL of 30 seconds • Map generation based on: • Internet congestion • System load • User demands • Server status

25. Akamai Fault Tolerance • Machine failures • Buddy system with paired back-up servers • Recovery time is 1 second once detected • Network outages/data center outages • Continuous monitoring • Set response to infinity when out, thereby driving site from network maps • Recovery time is 1-2 minutes due to frequent map updates • Content provider home site must be robust! • 7x24x365 NOC • Geoflow Monitoring Software/Traffic Analyzer

26. Internet Cache Protocols • Internet Cache Protocol (ICP) • Peer-to-peer: check if missing content is in a nearby cache • Cache Array Resolution Protocol (CARP) • Confederation of caches to form a larger, unified cache • Cache Digest Protocol • Exchange descriptions of what is contained in each cache • Used to manage peered caches • Stale cached data can be an issue • Web Cache Coordination Protocol (WCCP) • Intercept HTTP and redirect to cache • Cisco Cache Engine: WCCP manages router redirection

27. Impediments to Caching • Cache busting • Server actively prevents content from being cached • E.g., set EXPIRES field to value in the past, CACHE-CONTROL: no-cache or no-store • Responses • Hit metering: inform origin server of # users accessing cached content • Ad-Insertion: proxy server inserts ads, freeing origin server from doing so • Replication • Mirror sites • In a sense, content distribution is selective mirroring!

28. Outline • Rationale for Content Distribution • Web Caching Issues and Architectures • Akamai Architecture • Streaming Content Distribution • Business Issues in Content Distribution • Service Composition

29. Example CDN Application:Internet Broadcast • Media Distribution • Application-level multicast • Enforceable “content QoS” • Content Peering • Channel peering • Redirection peering McCanne, FFNets

30. Application Level Multicast Redirection Media Distribution Access Networks ? Backbones Access Networks McCanne, FFNets

31. Application Level Multicast Redirection Media Distribution McCanne, FFNets

32. Application Level Multicast Redirection Media Distribution McCanne, FFNets

33. Media Distribution McCanne, FFNets

34. Congested Peering Points McCanne, FFNets

35. CDN Quality of Service • How to overcome congestion at peering points? • Hard because peering policies evolve, hot spots move • A few existing approaches • Route around hot spots • Satellite bypass • Dispersity routing (Maxemchuk, 1977) • A new alternative • Provision the overlay network • Seemingly intractable (QoS across ISP boundaries) • But in reality, not so hard to do approximately perfect… McCanne, FFNets

36. CDN Quality of Service • Build on intradomain SLAs • Given ISP typically offers great SLA for on-net destinations McCanne, FFNets

37. CDN Quality of Service • Build on intradomain SLAs • Given ISP typically offers great SLA for on-net destinations from a “transit/colo” connection • But all bets are off when you cross a peering point McCanne, FFNets

38. CDN Quality of Service • Solution • Create private, content-level peering points • Bypass congested Internet peering points • Enforce application-level QoS polices co-locate transit links co-locate transit links McCanne, FFNets

39. CDN Quality of Service • Solution • Create private, content-level peering points • Bypass congested Internet peering points • Enforce application-level QoS polices McCanne, FFNets

40. Congested Peering Points McCanne, FFNets

41. Congested Peering Points transit links P-NAP P-NAP McCanne, FFNets

42. Bypassing Congestion P-NAP P-NAP

43. Broadcast from Anywhere P-NAP P-NAP McCanne, FFNets

44. Content-level QoS ingress policing • Mark and police traffic at injection point • Signal QoS policies across overlay network • Ensure content QoS on each overlay hop • Map contant QoS to underlying network QoS • e.g., diffserv, rsvp, mpls • No need for ubiquitous, end-to-end QoS in network • No need to modify apps or end hosts ATM PVC MPLS unicast mesh IP Multicast w/ diffserv DSL unicast McCanne, FFNets

45. Application Level Multicast Redirection Content-level QoS } Completely managed and provisioned } The broadcast edge… move it as close as possible to the user McCanne, FFNets

46. Channel Peering • Establish data peering relationships at “content exchange points” • Easy with application-level multicast • Enforce QoS across peering point • The catch • How to do settlement? • Same problem with IP multicast peering (don’t want to turn it on because of lost revenue stream) • The solution: audience tracking • As in EXPRESS Multicast (Hollbrook & Cheriton) McCanne, FFNets

47. Audience Tracking Can now be a transit carrier for broadcast traffic… not viable with vanilla multicast } McCanne, FFNets

48. Audience Tracking So, given such information you can actually make the channel peering component of content peering viable… McCanne, FFNets

49. Redirection Peering Content aggregators (broadcasters) Broadcast transit providers Access networks (affiliates) McCanne, FFNets

50. Redirection Peering Content aggregators (broadcasters) Broadcast transit providers Access networks (affilates) McCanne, FFNets