Multicast Challenges in CDN and P2P Systems

1. 15-441: Computer Networking Lecture 25: Multicast Challenges, CDN and P2P systems

2. Overview • Multicast Challenges • Content Distribution Networks • Peer-to-Peer Networks

3. Multicast Issues • Reliable transfer • ACK/NACK Implosion • Exposure • Reliable Multicast Protocols • Scalable Reliable Multicast • Reliable Multicast Transport Protocol • Pragmatic General Multicast • Lightweight Multicast Service • Congestion control

4. Loss Recovery • Sender-reliable • Wait for ACKs from all receivers. Re-send on timeout or selective ACK • Per receiver state in sender not scalable • ACK implosion • Receiver-reliable • Receiver NACKs (resend request) lost packet • Does not provide 100% reliability • NACK implosion

5. S Resend request S 1 2 R1 R1 R2 R2 R3 R4 R3 R4 Implosion All 4 receivers request a resend Packet 1 is lost

6. Retransmission • Re-transmitter • Options: sender, other receivers • How to retransmit • Unicast, multicast, scoped multicast, retransmission group, … • Problem: Exposure

7. Resend request S S Resent packet 1 2 1 1 R1 R1 R2 R2 R3 R4 R3 R4 Exposure Packet 1 does not reach R1; Receiver 1 requests a resend Packet 1 resent to all 4 receivers

8. Repair sent only to those that need packet S Resend request S Resent packet 1 2 1 R1 R1 1 R2 R2 R3 R4 R3 R4 Ideal Recovery Model Packet 1 reaches R1 but is lost before reaching other Receivers Only one receiver sends NACK to the nearest S or R with packet

9. Aside: Using the Routers • Routers do transport level processing: • Buffer packets • Combine ACKs • Send retransmissions • Model solves implosion and exposure, but not scalable • Violates end-to-end argument Router S R1 RTX NACK R2 R3 R4

10. Multicast Issues • Reliable transfer • ACK/NACK Implosion • Exposure • Reliable Multicast Protocols • Scalable Reliable Multicast • Reliable Multicast Transport Protocol • Pragmatic General Multicast • Lightweight Multicast Service • Congestion control

11. Scalable Reliable Multicast (SRM) • Originally designed for wb • Receiver-reliable • NACK-based • Every member may multicast NACK or retransmission

12. Resend request S S Resent packet X 1 2 1 R1 R1 X R2 R2 X Delay varies by distance R3 R3 SRM Request Suppression Packet 1 is lost; R1 requests resend to Source and Receivers Packet 1 is resent; R2 and R3 no longer have to request a resend

13. Request Damping • Deterministic Suppression • Receivers start timers with delay = C1 x ds,r • Stochastic Suppression • Start timers with delay = U[0,D2] x ds,r

14. Resend request S S Resent packet X 1 2 1 R2 R3 R4 R2 R3 R4 Delay is same length SRM Star Topology Packet 1 is lost; All Receivers request resends Packet 1 is resent to all Receivers

15. SRM (Summary) • NACK/Retransmission suppression • Delay before sending • Delay based on RTT estimation • Deterministic + Stochastic components • Periodic session messages • Full reliability • Estimation of distance matrix among members

16. What’s Missing? • Losses at link (A,C) causes retransmission to the whole group • Only retransmit to those members who lost the packet • [Only request from the nearest responder] S 0 0 B A 0 0.99 0 0 E F C D Receiver Sender

17. Local Recovery • Application-level hierarchy • Fixed v.s. dynamic • TTL scoped multicast • Router supported

18. Reliable Multicast Transport Protocol (RMTP) • Reliable Multicast Transport Protocol by Purdue and AT&T Research Labs • Designed for file dissemination (single-sender) • Deployed in AT&T’s billing network

19. Rcvr unicasts periodic ACK to its Designated Receiver (DR) DR unicasts its own ACK to its parent Rcvr chooses closest statically configured (DR) Mcast or unicast retransmission Based on percentage of requests Scoped mcast for local recovery RMTP: Fixed Hierarchy S D R2 R1 D R3 R5 D R4 R R R R R R Router Receiver R* D R DR

20. RMTP: Comments • : Heterogeneity • Lossy link or slow receiver will only affect a local region • : Position of DR critical • Static hierarchy cannot adapt local recovery zone to loss points

21. Pragmatic General Multicast • Cisco’s reliable multicast protocol • NACK-based, with suppression • Repair only forwarded to the NACKers

22. Resent packet S Routers remember resend requests S Resend request 1 1 2 R1 R1 X 1 R2 1 R2 1 1 R3 R4 R3 R4 Pragmatic General Multicast Packet 1 reaches only R1; R2, R3, R4 request resends Packet 1 resent to R2, R3, R4; Not resent to R1

23. Light-weight Multicast Service (LMS) • Enhance multicast routing with selective forwarding • LMS extends router forwarding - what routers are meant to do in the first place • No packet storing or processing at routers • Strictly IP: no peeking into higher layers

24. LMS: Definitions • Replier • Receiver volunteered to answer requests • Turning point • Where requests start to move downstream • Directed mcast • Mcast to a subtree S Replier link Turning point R1 X 1 R2 Replier R3 R4 R5 R6

25. Resend request S Replier link R1 R2 R3 R4 R5 R6 LMS with Replier Links Packet 1 reaches only R1; R2 requests resend Resend requests from each receiver follow replier links Resend request S Replier link 1 2 R1 Turning point X 1 R2 R3 R4 R5 R6

26. Resend request S Resent packet S Replier link Replier link 1 R1 R1 R2 R2 R3 R4 R5 R6 R3 R4 R5 R6 LMS with Replier Links Request from replier links go up towards the Source Packet 1 is resent to all Receivers Turning point

27. Multicast Issues • Reliable transfer • ACK/NACK Implosion • Exposure • Reliable Multicast Protocols • Scalable Reliable Multicast • Reliable Multicast Transport Protocol • Pragmatic General Multicast • Lightweight Multicast Service • Congestion control

28. Multicast Congestion Control • What if receivers have very different bandwidths? • Send at max? • Send at min? • Send at avg? 100Mb/s R 100Mb/s S R 1Mb/s ???Mb/s 1Mb/s R R 56Kb/s

29. Video Adaptation: RLM • Receiver-driven Layered Multicast • Layered video encoding • Each layer uses its own mcast group • On spare capacity, receivers add a layer • On congestion, receivers drop a layer • Join experiments used for shared learning

30. R2 R1 10Mbps 10Mbps 512Kbps S R R 10Mbps 128Kbps R3 Layered Media Streams R1 joins layer 1, joins layer 2 joins layer 3 R2 join layer 1, join layer 2 fails at layer 3 R3 joins layer 1, fails at layer 2

31. Drop Policies for Layered Multicast • Priority • Packets for low bandwidth layers are kept, drop queued packets for higher layers • Requires router support • Uniform (e.g., drop tail, RED) • Packets arriving at congested router are dropped regardless of their layer • Which is better? • Intuition vs. reality!

32. RLM Intuition • Uniform • Better incentives to well-behaved users • If oversend, performance rapidly degrades • Clearer congestion signal • Allows shared learning • Priority • Can waste upstream resources • Hard to deploy • RLM approaches optimal operating point • Uniform is already deployed

33. RLM Intuition Uniform vs. Priority Dropping 70 60 50 Uniform 40 Performance Priority 30 20 10 0 Offered load

34. Receiver-Driven Layered Multicast • Each layer a separate group • Receiver subscribes to max group that will get through with minimal drops • Dynamically adapt to available capacity • Use packet losses as congestion signal • Assume no special router support • Packets dropped independently of layer

35. RLM Join Experiment • Receivers periodically try subscribing to higher layer • If enough capacity, no congestion, no drops Keep layer (& try next layer) • If not enough capacity, congestion, drops Drop layer (& increase time to next retry) • What about impact on other receivers?

36. Join Experiments Layer 4 3 2 1 Time

37. Overview • Multicast Challenges • Content Distribution Networks • Peer-to-Peer Networks

38. Motivation • Problem of traditional client-server model • Single point of failure (DoS Attack) • Not Scalable • Solution • Replication (CDN) • Hosts connect to peers directly (P2P)

39. Content Distribution Networks • Replicate content on many servers • Challenges • How to replicate content • Where to replicate content • How to find replicated content • How to choose among know replicas • How to direct clients towards replica • Discussed in DNS/server selection lecture • DNS, HTTP 304 response, anycast, etc. • Akamai

40. How Akamai Works • How is content replicated? • Akamai only replicates static content • Modified name contains original file • Akamai server is asked for content • First checks local cache • If not in cache, requests file from primary server and caches file

41. How Akamai Works • Clients fetch html document from primary server • E.g. fetch index.html from cnn.com • URLs for replicated content are replaced in html • E.g. <img src=“http://cnn.com/af/x.gif”> replaced with <img src=“http://a73.g.akamaitech.net/7/23/cnn.com/af/x.gif”> • Client is forced to resolve aXYZ.g.akamaitech.net hostname

42. How Akamai Works • Root server gives NS record for akamai.net • Akamai.net name server returns NS record for g.akamaitech.net • Name server chosen to be in region of client’s name server • TTL is large • G.akamaitech.net nameserver choses server in region • Should try to chose server that has file in cache - How to choose? • Uses aXYZ name and consistent hash • TTL is small

43. How Akamai Works End-user cnn.com (content provider) DNS root server Akamai server Get foo.jpg 12 11 Get index.html 5 1 2 3 Akamai high-level DNS server 6 4 7 Akamai low-level DNS server 8 Closest Akamai server 9 10 Get /cnn.com/foo.jpg

44. Akamai – Subsequent Requests End-user cnn.com (content provider) DNS root server Akamai server Get index.html 1 2 Akamai high-level DNS server 7 Akamai low-level DNS server 8 Closest Akamai server 9 10 Get /cnn.com/foo.jpg

45. Consistent Hash • “view” = subset of all hash buckets that are visible • Desired features • Smoothness – little impact on hash bucket contents when buckets are added/removed • Spread – small set of hash buckets that may hold an object regardless of views • Load – across all views # of objects assigned to hash bucket is small

46. Consistent Hash – Example • Construction • Assign each of C hash buckets to random points on mod 2n circle, where, hash key size = n. • Map object to random position on unit interval • Hash of object = closest bucket • Monotone  addition of bucket does not cause movement between existing buckets • Spread & Load  small set of buckets that lie near object • Balance  no bucket is responsible for large number of objects 0 14 Bucket 4 12 8

47. Overview • Multicast Challenges • Content Distribution Networks • Peer-to-Peer Networks

48. Peer-to-peer networks • Typically each member stores content that it desires • Basically a replication system for files • Always the tradeoff between possible location of files and searching difficulties • Peer-to-peer allows files to be anywhere  searching is the challenge • Other challenges: • Dynamic member list • Scale

49. Example: Napster • Centralized Indexing • On startup, client contacts central server and reports list of files • To download a file • Client first contact centralized server to find the location of the file • Transfer is done peer-to-peer • Hybrid scheme • Advantage? Disadvantage?

50. Example: Gnutella • Distribute file location • Idea: multicast the request • Hot to find a file: • Send request to all neighbors • Neighbors recursively multicast the request • Eventually a machine that has the file receives the request, and it sends back the answer • Advantages: • Totally decentralized, highly robust • Disadvantages: • Not scalable; the entire network can be swamped with request (to alleviate this problem, each request has a TTL)