15-744: Computer Networking L-20 Multicast

Multicast Routing Unicast: one source to one destination Multicast: one source to many destinations Two main functions: Efficient data distribution Logical naming of a group

Example Applications Broadcast audio/video Push-based systems Software distribution Web-cache updates Teleconferencing (audio, video, shared whiteboard, text editor) Multi-player games Server/service location Other distributed applications

Overview IP Multicast Service Basics Multicast Routing Basics Overlay Multicast Reliability Congestion Control

IP Multicast Architecture Service model Hosts Host-to-router protocol (IGMP) Routers Multicast routing protocols (various)

Multicast – Efficient Data Distribution Src Src

Multicast Router Responsibilities Learn of the existence of multicast groups (through advertisement) Identify links with group members Establish state to route packets Replicate packets on appropriate interfaces Routing entry: Src, incoming interface List of outgoing interfaces

IP Multicast Service Model (rfc1112) Each group identified by a single IP address Groups may be of any size Members of groups may be located anywhere in the Internet Members of groups can join and leave at will Senders need not be members Group membership not known explicitly Analogy: Each multicast address is like a radio frequency, on which anyone can transmit, and to which anyone can tune-in.

IP Multicast Addresses Class D IP addresses 224.0.0.0 – 239.255.255.255 How to allocated these addresses? Well-known multicast addresses, assigned by IANA Transient multicast addresses, assigned and reclaimed dynamically, e.g., by “sdr” program 1 Group ID

Multicast Scope Control – Small TTLs TTL expanding-ring search to reach or find a nearby subset of a group s 1 2 3

Multicast Scope Control – Large TTLs Administrative TTL Boundaries to keep multicast traffic within an administrative domain, e.g., for privacy or resource reasons The rest of the Internet TTL threshold set on interfaces to these links, greater than the diameter of the admin. domain An administrative domain

Overview IP Multicast Service Basics Multicast Routing Basics Overlay Multicast Reliability Congestion Control

IP Multicast Architecture Service model Hosts Host-to-router protocol (IGMP) Routers Multicast routing protocols (various)

Multicast Routing Basic objective – build distribution tree for multicast packets Multicast service model makes it hard Anonymity Dynamic join/leave

Shared vs. Source-based Trees Separate shortest path tree for each sender DVMRP, MOSPF, PIM-DM, PIM-SM Shared trees Single tree shared by all members Data flows on same tree regardless of sender CBT, PIM-SM

Source-based Trees Router S Source R Receiver R R R S S R

Shared Tree Router S Source R Receiver R R RP R S S R

Shared vs. Source-Based Trees Shortest path trees – low delay, better load distribution More state at routers (per-source state) Efficient for in dense-area multicast Shared trees Higher delay (bounded by factor of 2), traffic concentration Choice of core affects efficiency Per-group state at routers Efficient for sparse-area multicast Which is better?  extra state in routers is bad!

Routing Techniques Flood and prune Link-state multicast protocols Begin by flooding traffic to entire network Prune branches with no receivers Examples: DVMRP, PIM-DM Unwanted state where there are no receivers Link-state multicast protocols Routers advertise groups for which they have receivers to entire network Compute trees on demand Example: MOSPF Unwanted state where there are no senders

Routing Techniques Core based protocols Specify “meeting place” aka core Sources send initial packets to core Receivers join group at core Requires mapping between multicast group address and “meeting place” Examples: CBT, PIM-SM

Distance-Vector Multicast Routing DVMRP consists of two major components: A conventional distance-vector routing protocol (like RIP) A protocol for determining how to forward multicast packets, based on the routing table DVMRP router forwards a packet if The packet arrived from the link used to reach the source of the packet (reverse path forwarding check – RPF) If downstream links have not pruned the tree

Example Topology G G S G

Broadcast with Truncation G G S G

Prune G G Prune (s,g) Prune (s,g) S G

Graft G G G Report (g) Graft (s,g) Graft (s,g) S G

Steady State G G G S G

Overview IP Multicast Service Basics Multicast Routing Basics Overlay Multicast Reliability Congestion Control

Supporting Multicast on the Internet Application ? At which layer should multicast be implemented? ? In the hourglass Internet architecture, IP is the compatibility layer in the Internet architecture. All hosts must implement IP Two choices multicast at IP or application: only a subset, customizability One important architecture question is, at which layer should multicast be implemented. The convention wisdom has been to support multicast in the IP layer for efficiency and performance reasons. However, more than 10 years since this is proposed, it still has not been widely deployed. This paper revisits this question with emphasis on Internet evaluation. In particular, we show that multicast at the application layer can be efficient compared to IP Multicast. IP Network Internet architecture

IP Multicast Highly efficient Good delay MIT Berkeley UCSD CMU routers In the IP Multicast architecture, - routers replicate multicast pkts inside the network to all receivers - motivation: highly efficiency - highly efficient: single pkt that traverse each physical link - delay is good from source to all receivers routers end systems multicast flow Highly efficient Good delay

End System Multicast Overlay Tree MIT1 MIT Berkeley MIT2 UCSD CMU1 CMU Recently, we and others have advocated for an alternative architecture, where all multicast functionality, including pkt replication and group management are pushed to end systems. - We call this architecture End System Multicast - In this architecture, end system organize themselves into an overlay tree root at the source - data is sent along the overlay tree. - It is an overlay in the sense that each link in the overlay tree corresponds to a physical path in the underlying network CMU CMU2 UCSD MIT1 MIT2 CMU2 Overlay Tree Berkeley CMU1

Potential Benefits Over IP Multicast Quick deployment All multicast state in end systems Computation at forwarding points simplifies support for higher level functionality MIT1 In ESM, there is no additional support from the routers except unicast, so the deployment can be immediate. In IP Multicast, routers need to maintain per-group state. - This causes concerns regards to scalability to number of groups. - In ESM, all multicast state is pushed to end systems. Finally, computation at end systems can potentially simplify support for higher-layer functionality, - such as congestion control and reliability, - as well as application-specific customization, such as XXX. These high-layer functionality is harder to achieve in IP Multicast because - the data splitting points are at the routers and they are constraint in computation. MIT Berkeley MIT2 UCSD CMU1 CMU CMU2

Concerns with End System Multicast Self-organize recipients into multicast delivery overlay tree Must be closely matched to real network topology to be efficient Performance concerns compared to IP Multicast Increase in delay Bandwidth waste (packet duplication) However, there are several concerns with ESM. - In the absence of support from the routers, there is a challenge to coordinate among end systems to construct efficient overlay tree. Even with an efficient overlay tree, … - there can be an increase in delay because data can travel through multiple overlay hops, as shown for MIT2. In IP Multicast, data is sent directly along the forwarding path. - moreover, there can be waste in bandwidth because duplicated pkts can traverse the same physical links, as shown in links near UCSD. In IP Multicast, a single pkt traverse each physical link at most once. MIT2 Berkeley MIT1 UCSD CMU2 CMU1 IP Multicast MIT2 Berkeley MIT1 CMU1 CMU2 UCSD End System Multicast

Overview IP Multicast Service Basics Multicast Routing Basics Overlay Multicast Reliability Congestion Control

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

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

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

Ideal Recovery Model S S R1 R1 R2 R2 R3 R4 R3 R4 Packet 1 reaches R1 but is lost before reaching other Receivers Only one receiver sends NACK to the nearest S or R with packet 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

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

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 Resend request S Resent packet S X 1 2 1 R1 R1 X R2 R2 X Delay varies by distance R3 R3

Deterministic Suppression Time d d data 2d d d d nack repair = Sender 3d = Repairer d 4d = Requestor Delay = C1dS,R

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

SRM: Stochastic Suppression Time 2d d data 1 d repair session msg d 2 NACK d 3 = Sender Delay = U[0,D2] dS,R = Repairer = Requestor

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

Overview IP Multicast Service Basics Multicast Routing Basics Overlay Multicast Reliability Congestion Control

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

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

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

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?

RLM Intuition

RLM Intuition Uniform Priority RLM approaches optimal operating point 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 Assume no special router support

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?

Join Experiments Layer 4 3 2 1 Time

RLM Scalability? What happens with more receivers? Increased frequency of experiments? More likely to conflict (false signals) Network spends more time congested Reduce # of experiments per host? Takes longer to converge Receivers coordinate to improve behavior