Group (Multicast) Communication in Wide Area Networks

Group (Multicast) Communication in Wide Area Networks
Walid Dabbous INRIA Sophia Antipolis

Definition Multicast: is the act of sending a message to multiple receivers using a single local “transmit” operation

A Spectrum of Paradigms
Unicast Broadcast Multicast Send to one Send to some Send to All

The Layering of Multicast
by Unicast Multicast by Broadcast Multicast by

The Many Uses of Multicasting
Teleconferencing Distributed Games Software/File Distribution Video Distribution Replicated Database Updates

Scope of Tutorial Support for multicast communication in
Transport Network Link Layer Also important: enforcing reception semantics across receivers (ordering, atomicity) in distributed computing literature

Multicast Support Challenges
Overhead for network layer support Scalability Dealing with heterogeneity

Outline Multicast Routing QoS and Real-Time support
Reliable Multicast Transport Multicast Flow Control ATM and IP/ATM Multicast Summary

Multicast Routing

Theoretical Basis The Steiner Tree Problem is NP-Complete
Graph G = (V, E) Positive Edge Weights W(e) R a subset of V B positive integer bound Is there a subtree of G that includes all R with cost no more than B? Heuristic less than twice optimum

Principles of Multicast Routing
Addressing List Addressing Not Scalable Group Addressing Less Control

Principles of Multicast Routing
Reuse of unicast routing infrastructure Desirable Too Constraining Multicast routing overhead Needs to be minimized

Principles: Source-Oriented Multicast
source sets up one-to-many multicast « group » each source responsible for its own group examples: ATM (explicit connection to each receiver) ST-II (receivers listed in setup message) for connection-oriented services discourages dynamic groups

Principles: Receiver-Oriented Multicast
Deering, 1991 senders need not be members groups may be of any size no topological restrictions on membership membership dynamic and autonomous host groups may be transient or permanent

Basic Multicast Routing Protocols
Problem: Given a source and a set of destinations, Route same packet to at least (or exactly) this set of destinations Source A B C D E

Multicast by Broadcast Filter above network layer Natural in Broadcast Networks (Satellite, Bridged LANs) Use Flooding in PSN Bandwidth inefficient, Security concerns

Separately addressed packets Source A B C D E to A to B to C to D to E

Multidestination Addressing A B C D E Source to (A,B) to (B) to (A,B) to (C,D,E) to (C) to (A,B,C,D,E) to (D,C)

Spanning Tree Forwarding Shared or Source-Based A B C D E Source

Reverse Path Forwarding Dalal and Metcalfe Basis for DVMRP (the original Mbone routing protocol) Main advantage: Use of existing unicast routing infratsrutcure

Reverse Path Forwarding
A Broadcast Protocol Group addressing used Routers/Switches Forward based on source of multicast packet

Flood if packet arrives from Source on link that router would use to send packets to source Otherwise Discard Rule avoids flooding loops Uses Shortest Path Tree from destinations to source (reverse tree)

to use S y Routing Table Destinations S x y z w to Group

B C D E Source Shortest Path Tree to Source

Shared Tree VS Source-Based Tree
RPF routes over source-based tree Good delay properties Per source and group overhead Spanning Tree Forwarding uses shared tree Per group overhead Higher delays More Traffic Concentration

Internet Multicast Routing
Group Addressing Class D IP addresses Link Layer Multicast Two Protocol Functions Group Membership IGMP Route Establishment DVMRP, MOSPF, CBT, PIM

Group addressing host-group model
network-level; same packet format, different address routers do all of the work special IP addresses: 28 bits => 268 million groups (plus scope) ttl value limits distribution

Link Layer Multicast Example Ethernet: To join group:
Ethernet multicast addresses Algorithmic mapping between IP mcast address and Ethernet mcast address To join group: Recognize IP mcast address Interface recognizes link layer mcast address Inform local router using IGMP

Internet Group Membership Protocol
Used by end-system to declare membership in particular multicast group to nearest router(s) Version 1: Timed-out Leave Vesrion 2: Fast (Explicit Leave) Version 3: Per-Source Join

IGMPv1 Joining Host send IGMP Report Leaving Host does nothing
Router periodically polls hosts on subnet using IGMP Query Hosts respond to Query in a randomized fashion

IGMPv2 ADDS: Group Specific Queries Leave Group Message Host sends Leave Group message if it was the one to respond to most recent query Router receiving Leave Group msg queries group.

IGMPv3 ADDS: Inclusion/Exclusion of sources
Group-Source Specific Queries, Reports and Leaves Inclusion/Exclusion of sources

Routing Protocols Source -based Tree Protocols: Shared-Tree Protocols
DVMRP MOSPF PIM-DM Shared-Tree Protocols CBT PIM-SM

DVMRP Distance Vector Multicast Routing Protocol
An enhancement of Reverse Path Forwarding that : Uses Distance Vector Routing Packets for building tree Prunes broadcast tree links that are not used (non-membership reports) Allows for Broadcast links (LANs)

Multicast Forwarding in DVMRP
1. check incoming interface: discard if not on shortest path to source 2. forward to all outgoing interfaces 3. don’t forward if interface has been pruned 4. prunes time out every two minutes to remove state information in routers

DVMRP Forwarding (cont.)
Basic idea is to flood and prune R router S no receiver packet

Prune branches where no members and branches not on shortest paths 2nd packet R S prune

Add new user via grafting; departure via pruning R S graft Report

Multicast OSPF Link-State Multicast Routing
Routers maintain topology DBs Group-Membership-LSA broadcast by routers to advertise links with members Routers compute and cache pruned SPTs

Protocol Independent Multicast
Motivation: DVMRP good for dense group membership Need shared/source-based tree flexibility Independence from Unicast Routing Two PIM modes: Dense Mode (approx. DVMRP) Sparse Mode

PIM- Dense Mode Independent from underlying unicast routing
Slight efficiency cost Contains protocol mechanisms to: detect leaf routers avoid packet duplicates

PIM - Sparse Mode Rendezvous Point (Core): Receivers Meet Sources
Reception through RP connection = Shared Tree Establish Path to Source = Source-Based Tree

PIM - Sparse Mode Receiver Source Rendez-Vous Register Source Join
Prune

PIM - Sparse Mode Receiver Source Rendez-Vous

Core-Based Trees A shared-tree protocol
One node on shared tree is Core Sender sends to Core Core forwards over multicast tree

Core-Based Trees A B C D E Source Core-based tree Core

PIM and CBT Issues Unidirectional VS Bidirectional Shared Trees
Core/RP Placement and Selection Multiple Cores/RPs Dynamic Cores/RPs

BGMP Partition Class D address space
A protocol for inter-domain multicast routing Partition Class D address space Default Bidirectional Shared Tree for inter-domain routing Receiver domains can utilize choice of protocol Discussed in the IETF idmr wg

Mbone Mbone = multicast backbone virtual network overlaying Internet
needed until mcast capable routers deployed IP in IP encapsulation limited capacity, resilience MBONE tunnel endpoint IP router WS

Mbone Applications freeware commercial
vic, nv (video), vat, nevot, FreePhone (audio), wb (whiteboard) IVS, RendezVous (teleconferencing) MiMaze (distributed game) commercial IP/TV - teleconferencing (Precept) Most group applications use unicast

Summary Multicast Routing is a well researched problem.
Challenge now is deployment inter-operability management

Real-Time Multicasting and Quality-of-Service (QoS)

The Problem How to get smooth, continuous playout adaptation by appl.
sender receiver time t0 t t2 pkts generated (received) How to get smooth, continuous playout adaptation by appl. playout delay adj. loss concealment perf. guarantees by network

Requirements for Real-Time Applications
transport protocol must provide timing information call admission reservation protocols needed to determine availability of resources for particular performance requirement reserve (allocate) resources support for multicast heterogeneity, scalability

RTP: Real-Time Transport Protocol
timing info. for playout reordering information loss detection for quality estimation, recovery synchronization network jitter clock drift intermedia (lip sync) QoS feedback source identification

RTP: Real-Time Transport Protocol
Schulzrinne, et al. RFC 1889 product of IETF Audio Video Transport Working Group (AVT WG) goals lightweight, interoperability mechanism - not policy scalability - unicast, multipoint s participants separation of control/data

RTCP: RTP Control Protocol
estimate no. participants state of participants (talker indication) QoS feedback - adjust sender rate scalability- randomized control traffic; rate decreases as number increases

Performance Guarantees to Application
deterministic guarantees absolute guarantees on loss, delay or jitter statistical guarantees probabilistic guarantees cell loss probability < e prob. pkt delay exceeds D is less than e different services for different performance requirements

Example: Internet Services
Guaranteed: no loss, upper bound on delay invoked by specifying traffic (TSpec) Controlled load: negligible losses, like unloaded network => delay-adaptive applications invoked by specifying traffic (Tspec) Best Effort: traditional service

Guaranteed Service user specifies traffic (TSpec)
token bucket spec. (r - token rate b - bucket depth in bytes) p - peak rate m - minimum policed unit M - max. packet size and desired service (Rspec) desired bandwidth R > r slack term S

Guaranteed Service (cont.)
delay is function of R for weighted fair queueing user does not provide delay bound; delay bound controlled by choice of R,S call admission, scheduling policy unspecified service oriented towards WFQ

Controlled Load Service
user sees unloaded network buffer loss on order of loss due to noise, faults, etc. delays should be mostly = propagation delay + processing costs TSpec is same as for guaranteed service; no RSpec call admission, scheduling, buffer management unspecified

Call Setup contract between network and application approaches
network guarantees performance application guarantees traffic behavior peak rate average rate burst size approaches one pass -two pass

One Pass sender or receiver oriented
source (rcvr) sends resource reservation to rcvrs (source) cannot specify/guarantee QoS soft state possible periodic refreshes e.g., RSVP one pass w. advertisement rsvtn source rcvr1 rcvr2 rsvtn source rcvr1 rcvr2

Two Pass sender/rcvr initiated
forward phase: check for resources at each link reverse phase inform routers if call admitted reserve resources reserve max resources resource reclamation phase can be added source rcvr1 rcvr2 fwd phase rev phase

RSVP: ReSerVation Protocol
Zhang, etal. 1993 receivers control reservations consistent with IP multicast good scalability supports heterogeneity separate resource reservation from usage packet filters control usage soft state end system periodically refresh state

RSVP Operation D data (mcast) S PATH rcvr joins group via IGMP RESV
source sends PATH messages to rcvrs rcvrs send RESV messages back to source(s) reservations can be lowered, merged between senders (audio) one pass => rcvr does not know final QoS => one pass with advertising

Other Issues policing/traffic shaping interaction with routing
leaky bucket Generic Cell Rate Algorithm (GCRA) peak cell rate, mean cell rate, cell delay variation tolerance interaction with routing what does a guarantee really mean? pricing performance evaluation

Reliable Multicast

Problem How to transfer data reliably from source to R receivers
scalability: 10s s s s s of receivers heterogeneity feedback implosion problem

Feedback Implosion Problem
. . . rcvrs sender

Issues level of reliability ordering full reliability semi-reliability
no ordering ordering per sender full ordering (distr. computing)

Approaches shift responsibilities to receivers feedback suppression
multiple multicast groups local recovery server-based recovery forward error correction (FEC)

Applications application requirements application characteristics
file transfer, finite duration streaming applications (billing, etc.), infinite duration low latency (DIS, teleconferencing) application characteristics one-many: one sender, all other participants receivers (streaming appl. teleconferencing) many-many: all participants send and receive (DIS)

Sender Oriented Reliable Mcast
Sender: mcasts all (re)transmissions selective repeat use of timeouts for loss detection ACK table Rcvr: ACKs received pkts Note: group membership important sender ACK ACK X receivers

Vanilla Rcvr Oriented Reliable Mcast
Sender: mcasts (re)transmissions selective repeat responds to NAKs Rcvr: upon detecting pkt loss sends pt-pt NAK timers to detect lost retransmission Note: easy to allow joins/leaves Significant performance improvement shifting burden to receivers for 1-many; not as great for many-many sender NAK X receivers

Feedback Suppression X randomly delay NAKs multicast to all receivers
+ reduce bandwidth - additional complexity at receivers (timers, etc) X sender NAK

Multiple Multicast Groups
mcast group per pkt all rcvrs belong to one group for original transmissions rcvr losing pkt j joins group for j additional performance improvement for small no. groups (Kasera etal 1997) receivers divided into destination groups identify rcvrs with different capabilities place similar rcvrs into same group additional improvement (Ammar, Wu 1992)

Server-based Reliable Multicast
first transmisions mcast to all receivers and servers each receiver assigned to server servers perform loss recovery can have more than 2 levels LBRM (Cheriton) server sender receivers

Local Recovery Lost packets recovered from nearby receivers
deterministic methods impose tree structure on rcvrs with sender as root rcvr goes to upstream node on tree RMTP (Lucent) self-organizing methods rcvrs elect nearby rcvr to act as retransmitter using scoped multicast and random delays (SRM) hybrid methods

RAMP (TASC) Reliable Adaptive Multicast Protocol
supports sender and rcvr oriented reliability mixture of reliable/unreliable senders/rcvrs supported late joins and leaves supported rate-based flow control

RMTP (Lucent) Reliable Multicast Transport Protocol
imposes a tree structure on rcvrs corresponding to multicast routing tree nodes inside tree aggregate ACKs/NAKs provide repairs to downstream nodes late-joins supported thru 2-level cache rate- and window-based flow control

SRM (LBL) Scalable Reliable Multicast
rcvr-oriented using NAK suppression and self-organizing local recovery supports late-joins and leaves as built in wb, uses rate-based flow control has been used with 100s of participants over the Internet

Other Examples Single Connection Emulation (SCE, Georgia Tech)
sender oriented, offers semantics of TCP (sender ordering, etc) late-joins are not supported. ISIS (Cornell, Isis Dist. Systems) general purpose toolkit for providing reliable data transfer to dist. applications sender and rcvr oriented wide range of ordering semantics supported late-joins and leaves supported

Other Examples Local Group based Multicast Protocol (LGMP, Karlsruhe)
self-organizing local- recovery based scheme Xpress Transport Protocol (XTP) sender-oriented extension of unicast protocol

Forward Error Correction (FEC)
Add redundancy in order to reduce need to recover from losses (e.g., Reed Solomon codes) (k,n) code for every k data pkts, construct n-k parity pkts can recover all data pkts if no more than n-k losses + reduce loss probability - greater overheads at end-hosts Q: can FEC reduce network resource utilization?

Potential Benefits of FEC
Data Retransmission D1 D2 Initial Transmission D3 D3 D2 D1 D1 D2 D3 X D3 D2 D1 D3 D2 D1 X Parity Retransmission D3 D2 X D1 P=D1 D2 D3 P P One parity pkt can recover different data pkts at different rcvrs P

Summary reliable mcast is a hot topic unresolved issues
proper integration of different ideas wrt different applications integration with flow control interaction with group memebrship notion of semi-reliability

Flow Control for Multicast Applications

Problem Match transmission rates to Network capacity
Receiver “consumption” rates

Multicast Flow Control Challenges
Accommodating heterogeneity among receivers and paths leading to them Preserving fairness among receivers of same flow distinct flows Scalability of feedback

Multicast Flow Control Solutions
Loss-Tolerant Applications (e.g., Video) Information content per unit time can be preserved at lower data rates Applications demanding data integrity lower data rates => lower information content per unit time Goal: Co-Existence with TCP?

Multicast Video Flow Control
Scalable Feedback Control (Bolot, Turletti and Wakeman) Receivers measure loss rates Randomly generated feedback Source estimates receivers’ state and adjusts video rate by changing compression parameters Problem: fairness among receivers

Improving fairness using Destination Set Grouping (Cheung, Li, Ammar) Send replicated video streams at different rates Receivers can control rate of each stream within limits Receivers can move among streams Fairness at the expense of increased bandwidth consumption

DSG and Single Stream Comparison Receivers Intra- Stream Protocol DSG High Med. Low Single Group Intra- Stream Protocol Inter- Stream Protocol

Receiver-Driven Layered Multicast (McCanne, Jacobson and Vetterli) Single video stream subdivided into layers Receivers add and drop layers depending on congestion Challenge: Distributed Consensus, Layer Synchronization

Receiver-driven Layered Multicast Source Receivers

Receiver-Driven Layered Multicast Drop Layer: indicated by loss Add Layer: No such indication Use join experiments with shared learning Reluctance to join layers that failed Inform others via multicast of failed experiments

Layered Video Multicast with Retransmissions (LVMR) (Li, Paul, Ammar) Uses agents within network to maintain information about join experiments Reduces overhead of shared learning

Flow Control for Reliable Multicast
Less Understood/Mature Area Some Possibilities: Window flow control (a la TCP) Not Scalable, Not Fair (across receivers) Explicit rate control (e.g., ATM ABR) Not Scalable and in addition not fair Multiple Multicast Groups

The Single Connection Emulation (SCE) Architecture (Window Flow Control) Application TCP SCE IP

ATM Available Bit Rate Source Receivers Explicit Rate Messages

ATM Available Bit Rate Consolidation Algorithm Consolidation Noise Transient Time Volume of Feedback

Multiple Multicast Groups Simulcasting or Destination Set Splitting (Ammar, Wu and Cheung, Ammar) Data Partitioning (Bhattacharyya, Towsley, Kurose, Nagarajan) Cumulative Layering (Vicisano)

Simulcasting: Similar to DSG protocol for Video Send multiple (uncoordinated streams) at different rates Each stream carries all data Receivers join appropriate stream one at a time

Data Partitioning: Send multiple streams at different rates Synchronous start time for receivers Partition data among streams with replication among streams allowed Schedule data for optimum completion time

Data Partitioning Example R1 R2 R3 A B C D Flow 1 rate = 1 B C Flow 2 rate = 1 C D Flow 3 rate = 2

Data Partitioning Can achieve ideal completion time with as many channels as receivers Can achieve close to ideal with a few channels Same completion time as simulcast but less bandwidth consumed Can improve by dynamic rate adjustment Requires coordination and scheduling among channels

Cumulative Layering Multiple data streams at different rates Each stream contains entire data Receivers join asynchronously Streams transmit for indefinite duration Schedule to minimize reception time (Scheme allows for FEC encoding)

Receiver 3, BW = 4 Channel 3 Rate = 2 B D A C Channel 2 Rate = 1 C D A B Receiver 2, BW = 2 Channel 1 Rate = 1 A B C D Receiver 1, BW = 1

Cumulative Layering Can achieve minimum reception timecwith asynchronous receivers Schedulability requires some parameter relationships Synchronization among channels needed

Summary Flow control for multicast communication is a hard problem:
Scalability Heterogeneity Added dynamic dimension (receivers and their join behavior) Plenty of room for innovation!

ATM and IP over ATM Multicast

ATM Multicast ATM: Connection-Oriented (VC)
Multicast connection establishment UNI 3.0/3.1 Source-Controlled Full Knowledge of Receivers required UNI 4.0 Leaf-Initiated Join (LIJ) Group identified by (Source, Tree ID)

IP Multicast over ATM Problem (for UNI3.x): Mapping
IP’s connectionless, receiver-controlled model to ATM’s connection-oriented, source-controlled model

The MARS Architecture MARS: Multicast Address Resolution Server
Stores mapping between IP group address and Unicast addresses of ATM endpoints

MARS -- The Mesh Approach
IP receivers joining group register their ATM addresses with the MARS IP source consults MARS for list of ATM addresses IP source opens multipoint connection to ATM end-points Receivers joining/leaving need to inform MARS

MARS -- The VC Mesh MARS MARS Request Receivers Reply Source
ATM Cluster Source Receivers Reply ATM Multipoint Connection

MARS -- The Multicast Server
The VC Mesh approach requires one multipoint VC per source per group Alternative: Provide a multicast server (MCS) per group One multipoint VC from MCS to receivers Source sends to MCS MARS now returns ATM address of MCS

MARS -- The Multicast Server
MARS Request Receivers ATM Cluster Source Reply Multicast Server

VC Mesh VS MCS VC Mesh MCS : Requires Reflection Suppression
Higher VC consumption Higher signaling overhead Better Delay Less Vulnerability MCS : Requires Reflection Suppression Comparison similar to Shared Tree VS Source-based Tree in multicast routing

The MARS for UNI 4.0 LIJ is closer to IP model than UNI3.x
MARS is still needed to map IP group address to the (source, tree ID) pair

Multipoint-to-Multipoint Support in ATM
How to support multiple sources on same multipoint VC and shared tree Problem: Interleaving of Cells from different AAL PDUs within switch Solution: No problem for AAL 3/4 For AAL 5 : SEAM and SMART

Simple and Efficient ATM Multicasting (SEAM)
Proposes a Core-Based Tree Approach Solves cell interleaving by “cut through” switching Forward cells belonging to same packet together and Buffer other cells for same VC

Shared Many-to-Many ATM Reservations (SMART)
Many-to-Many connection over a single VCC Addresses Cell-interleaving On-demand bandwidth sharing (a la RSVP) Solution: Take Turns (essentially) Signalling Protocol

Summary ATM and Internet multicast mechanisms are incompatible
Convergence approaches have been defined ATM multicast still has problems: many-to-many QoS routing

Summary

Topics Covered in Tutorial
overview of multicast at network layer (routing, congestion control) transport layer (reliability, flow control) session layer (Internet centric view) examples taken from Internet, MBone ATM

Other Topics application issues session semantics group membership
stronger semantics: ordering requirements, atomicity, etc. (Isis, Horus, Berman et al, Cornell) session semantics group membership performance Evaluation: how to evaluate large networks supporting large numbers of multicast applications

Other Topics Control Issues:
control issues related to TCP have generated 100s of papers and are still not resolved control aspects of multicast add at least one additional layer of complexity a very fruitful area for research and development

References http://www.mbone.com
Christophe Diot, Walid Dabbous, Jon Crowcroft. "Multipoint Communication: A Survey of Protocols, Functions and Mechanisms", IEEE Journal on Selected Area in Communication, Vol 15, No 3, April 1997.

Group (Multicast) Communication in Wide Area Networks

Similar presentations

Presentation on theme: "Group (Multicast) Communication in Wide Area Networks"— Presentation transcript:

Similar presentations

About project

Feedback

Log in

Auth with social network:

Group (Multicast) Communication in Wide Area Networks

Similar presentations

Presentation on theme: "Group (Multicast) Communication in Wide Area Networks"— Presentation transcript:

Similar presentations

About project

Feedback