15-744: Computer Networking L-17 Multicast Reliability and Congestion Control

L -15; © Srinivasan Seshan, Multicast Issues Reliable transfer Congestion control Assigned reading [F+97] A Reliable Multicast Framework for Ligh-Weight Sessions and Application Level Framing [MJV96] Receiver-driven Layered Multicast

L -15; © Srinivasan Seshan, Overview Reliability Scalable Reliable Multicast Reliable Multicast Transport Protocol Lightweight Multicast Service Receiver-driven Layered Multicast Other Issues

L -15; © Srinivasan Seshan, 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

L -15; © Srinivasan Seshan, R1 Implosion S R3R4 R2 21 R1 S R3R4 R2 Packet 1 is lostAll 4 receivers request a resend Resend request

L -15; © Srinivasan Seshan, Retransmission Re-transmitter Options: sender, other receivers How to retransmit Unicast, multicast, scoped multicast, retransmission group, … Problem: Exposure

L -15; © Srinivasan Seshan, R1 Exposure S R3R4 R2 21 R1 S R3R4 R2 Packet 1 does not reach R1; Receiver 1 requests a resend Packet 1 resent to all 4 receivers 1 1 Resend request Resent packet

L -15; © Srinivasan Seshan, Ideal Recovery Model S R3R4 R2 2 1 S R3R4 R2 Packet 1 reaches R1 but is lost before reaching other Receivers Only one receiver sends NACK to the nearest S or R with packet Resend request 11 Resent packet Repair sent only to those that need packet R1

L -15; © Srinivasan Seshan, R1 Aside: Using the Routers S R3R4 R2 Routers do transport level processing: Buffer packets Combine ACKs Send retransmissions Model solves implosion and exposure, but not scalable Violates end-to-end argument NACK RTX Router

L -15; © Srinivasan Seshan, Overview Reliability Scalable Reliable Multicast Reliable Multicast Transport Protocol Lightweight Multicast Service Receiver-driven Layered Multicast Other Issues

L -15; © Srinivasan Seshan, SRM Originally designed for wb Receiver-reliable NACK-based Every member may multicast NACK or retransmission

L -15; © Srinivasan Seshan, R1 SRM Request Suppression S R3 R2 21 R1 S R3 R2 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 1 X X Delay varies by distance X Resend request Resent packet

L -15; © Srinivasan Seshan, Deterministic Suppression d d d d 3d Time data nack repair d 4d d 2d 3d = Sender = Repairer = Requestor Delay = C 1  d S,R

L -15; © Srinivasan Seshan, SRM Star Topology S R2 21 R3 Packet 1 is lost; All Receivers request resends Packet 1 is resent to all Receivers X R4 Delay is same length S R2 1 R3R4 Resend request Resent packet

L -15; © Srinivasan Seshan, SRM: Stochastic Suppression data d d d d Time NACK repair 2d session msg Delay = U[0,D 2 ]  d S,R = Sender = Repairer = Requestor

L -15; © Srinivasan Seshan, 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

L -15; © Srinivasan Seshan, 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] Sender Receiver A B E F S CD

L -15; © Srinivasan Seshan, Local Recovery Application-level hierarchy Fixed v.s. dynamic TTL scoped multicast Router supported

L -15; © Srinivasan Seshan, Overview Reliability Scalable Reliable Multicast Reliable Multicast Transport Protocol Lightweight Multicast Service Receiver-driven Layered Multicast Other Issues

L -15; © Srinivasan Seshan, 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

L -15; © Srinivasan Seshan, RMTP: Fixed Hierarchy 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 D R2 R5 S R3 R4 R1 RRRR D RR D D DR R Receiver R* Router

L -15; © Srinivasan Seshan, 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

L -15; © Srinivasan Seshan, Overview Pragmatic General Multicast

L -15; © Srinivasan Seshan, Pragmatic General Multicast Cisco’s reliable multicast protocol NACK-based, with suppression Repair only forwarded to the NACKers

L -15; © Srinivasan Seshan, R1 Pragmatic General Multicast S R3R4 R2 21 R1 S R3R4 R2 Packet 1 reaches only R1; R2, R3, R4 request resends Packet 1 resent to R2, R3, R4; Not resent to R1 1 1 X 11 1 Routers remember resend requests 11 1 Resend requestResent packet

L -15; © Srinivasan Seshan, Overview Reliability Scalable Reliable Multicast Reliable Multicast Transport Protocol Lightweight Multicast Service Receiver-driven Layered Multicast Other Issues

L -15; © Srinivasan Seshan, 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

L -15; © Srinivasan Seshan, The LMS Concept Heavy-weight model LMS: Receiver acts as surrogate R Control messages R Router stores packets, receives NACKs and sends retransmissions Router chooses a receiver as a surrogate Router steers all control messages to surrogate Router relays messages from surrogate to the subtree

L -15; © Srinivasan Seshan, LMS: Definitions Replier Receiver volunteered to answer requests Turning point Where requests start to move downstream Directed mcast Mcast to a subtree R1 S R3R6 R2 Replier link R4R5 Turning point Replier

L -15; © Srinivasan Seshan, R1 LMS with Replier Links S R3R6 R2 21 Packet 1 reaches only R1; R2 requests resend Resend requests from each receiver follow replier links 1 X Resend request Replier link R4R5 R1 S R3R6 R2 Resend request Replier link R4R5

L -15; © Srinivasan Seshan, R1 LMS with Replier Links S R3R6 R2 Request from replier links go up towards the Source Packet 1 is resent to all Receivers Resend request Replier link R4R5 R1 S R3R6 R2 1 Resent packet Replier link R4R5

L -15; © Srinivasan Seshan, LMS: Comments Replier problems Selection? Fault tolerance? Works with unidirectional shared trees (PIM) Needs to relay requests from core/RP to sender Difficulties with bi-directional shared trees Needs per-source state

L -15; © Srinivasan Seshan, Overview Reliability Scalable Reliable Multicast Reliable Multicast Transport Protocol Lightweight Multicast Service Receiver-driven Layered Multicast Other Issues

L -15; © Srinivasan Seshan, Multicast Congestion Control What if receivers have very different bandwidths? Send at max? Send at min? Send at avg? R R R S ???Mb/s 100Mb/s 1Mb/s 56Kb/s R

L -15; © Srinivasan Seshan, 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

L -15; © Srinivasan Seshan, Layered Media Streams S R R1 R2 R3 R 10Mbps 512Kbps 128Kbps 10Mbps R3 joins layer 1, fails at layer 2 R2 join layer 1, join layer 2 fails at layer 3 R1 joins layer 1, joins layer 2 joins layer 3

L -15; © Srinivasan Seshan, 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!

L -15; © Srinivasan Seshan, 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

L -15; © Srinivasan Seshan, RLM Intuition

L -15; © Srinivasan Seshan, 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

L -15; © Srinivasan Seshan, 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?

L -15; © Srinivasan Seshan, Join Experiments Time Layer

L -15; © Srinivasan Seshan, 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

L -15; © Srinivasan Seshan, RLM Receiver Coordination Receiver advertises intent to add layer Other receivers Avoid conflicting experiments If experiment fails, will see increased drops => don’t try adding layer! (shared learning) OK to try adding lower layer during higher layer experiment Won’t cause drops at higher layer!

L -15; © Srinivasan Seshan, Overview Reliability Scalable Reliable Multicast Reliable Multicast Transport Protocol Lightweight Multicast Service Receiver-driven Layered Multicast Other Issues

L -15; © Srinivasan Seshan, Inferring Topology What if packet is lost on link? All children of link will not get packet Idea: use loss “fingerprints” to identify siblings Siblings will have the most similar fingerprints Various techniques to build tree from collection of fingerprints

L -15; © Srinivasan Seshan, Session Messages SRM Identify what node knows about global state Multimedia & other applications Identify list of members Communicate loss rates  possibly for congestion control or other feedback What if it is a large group? Periodic transmissions can flood network!!

L -15; © Srinivasan Seshan, Next Lecture: QOS & IntServ QOS IntServ Architecture Assigned reading [She95] Fundamental Design Issues for the Future Internet [CSZ92] Supporting Real-Time Applications in an Integrated Services Packet Network: Architecture and Mechanisms