9/14/97sigcomm97 tutorial, copyright ammar and towsley group (multicast) communication in wide area...

9/14/97 SIGCOMM97 Tutorial, Copyright Ammar and Towsley

Group (Multicast) Communication Group (Multicast) Communication in Wide Area Networks in Wide Area Networks

Mostafa Ammar Don TowsleyMostafa Ammar Don TowsleyCollege of Computing Dept. of Computer Science

Georgia Tech University of Massachusetts

Atlanta, GA Amherst, MA

ammar@cc.gatech.edu towsley@cs.umass.edu

Definition

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

A Spectrum of Paradigms

UnicastUnicast BroadcastBroadcast

MulticastMulticast

Send toSend tooneone

Send toSend toAllAll

Send to someSend to some

The Layering of Multicast

MulticastMulticastbybyUnicastUnicast

MulticastMulticastbybyBroadcastBroadcast

MulticastMulticastbybyMulticastMulticast

The Many Uses of Multicasting

Teleconferencing Distributed Games Software/File Distribution Video Distribution Replicated Database Updates

Multicast Application Models

Point-to-Multipoint: Single Source, Multiple Receivers

Multipoint-to-Multipoint: Multiple Sources, Multiple Receivers

Sources are receivers Sources are not receivers

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

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

IP Multicast and the Mbone

Server-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(packet header size!)

discourages dynamic groups

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

IP Multicast host-group model network-level; same packet format, different

address routers do all of the work special IP addresses: 224.0.0.0

- 239.255.255.255 28 bits 268 million groups (plus scope) ttl value limits distribution

Multicast Forwarding

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 minute

5. routers may send grafts upstream

Routing done by DVMRP

IP Multicast (cont.)

Basic idea is to flood and prune

router packet

noreceiver

IP Multicast (cont.)Prune branches where no members and branches not

on shortest paths

2nd packet

IP Multicast (cont.)Add new user via grafting; departure via pruning

MboneMBONE

tunnel endpoint

IP router

Mbone = multicast backbone

virtual network overlaying Internet

needed until mcast capable routers deployed

IP in IP encapsulation limited capacity,

resilience

Mbone Protocols IP UDP: best effort RTP: real-time

transport RSVP: resource

reservation protocol SDP/SAP: session

description, announcement protocols

physical layer

UDP TCP

SAP HTTP SMTP

session directory

RSVP RTP, RTCP

conf. control

audio videosharedtools

Session Protocols

session description protocol (SDP)– used to describe (not necessarily) mcast session

» name, purpose

» start time, duration

» media (type, transport protocol, format)

» how to receive media

session announcement protocol (SAP)– mcast protocol for SDP

– periodic transmission to known mcast address

– frequency depends on other announcements and scope

Session Directory

used to allocate multicast addresses to sessions– birthday problem, N addresses support

sessions using random address allocation with negligible collision probability

– random allocation currently used in popular session directory tools sd (LBL), sdr UCL)

advertises multicast sessions– uses SDP

Example: sdr

Title: don-temp4.psCreator: XV Version 3.00 Rev: 3/30/93 - by John BradleyCreationDate:

Title: don-temp3.psCreator: XV Version 3.00 Rev: 3/30/93 - by John BradleyCreationDate:

Mbone Applications

freewarevic, nv (video), vat, nevot (audio), wb (whiteboard)

IVS (teleconferencing)

commercial IP/TV - teleconferencing (Precept)

Most group applications use IP unicastE.g., CuSeeMe builds own mcast tree

MBone Behavior

Motivation: quantitative understanding of session dynamics,

and loss behavior

session dynamics:– sizes, durations of sessions

– join/leave behavior

loss behavior:– loss rates

– spatial and temporal correlation

Mbone Session Dynamics

Goal: to characterize the dynamics of Mbone sessions -- Join/Leave Behavior

capture data using MlistenMlisten toolhttp://www.cc.gatech.edu/computing/Telecomm/mbone/

data pre-processed to account for– Mbone un-reliability,– abnormal usage

Typical Sessions

long-lived (Shuttle)

short-lived (Seminars)

Session Stats

Statistics for interarrival of rcvrs rcvr membership

duration

Tree Size

multicast vs unicast tree cost

sensitivity of multicast tree to source location

Mbone vs Internet tree

Audio/Video

audio receivers

video receivers

Mbone Loss Behavior

Goal: to characterize loss behavior on Mbone metrics

– loss rates, spatial and temporal correlation methodology

– rcvr processes on ~25 MBone hosts

– rcvrs listen to WRN (& other sources) which sends audio at 80ms intervals; record mcast packet receptions

– off-line analysis of trace data

Measurements

Machine Name Locationalpa Georgia Techanhur, spiff Swedish Inst. Computer Sci.artemis, atlas Inst. Blaise Pascal, Parisbagpipe, ocarina U. Kentuckycedar U. Texascollage, zip EIT, Californiadixie UC Irvineedgar U. Washingtonerlang, trantor U. Massachusettsexcalibur USCfloat U. Virginiaganef UCLAlaw UC Berkeleypax INRIA, Sophia Antipolistove U. Marylandursa, lupus GMD Fokus, Berlinwillow U. Arizona

Date Source # rcvrs trace length (pkts)

9/19/95 WRN 8 17K9/20/95 UCB 9 20K10/30/95 WRN 10 57K11/1/95 WRN 9 41K11/13/95 WRN 9 40K11/14/95 WRN 8 30K11/28/95 WRN 7 20K12/4/95 WRN 8 45K12/11/95 WRN 9 70K12/16/95 WRN 7 50K12/18/95 WRN 7 69K4/19/96 RFV 11 45K4/24/96 UCB 12 93K5/8/96 RFV 10 148K

Where does MBone loss occur?

4/16/96 dataset across data sets:

backbone loss small compared to overall loss

no loss in end-systems

Title: /tmp/xfig-export003787Creator: fig2devCreationDate: Sat May 11 23:53:21 1996

Simultaneous Packet Loss

4/19/96 dataset: 47% pkts lost somewhere

similar results across datasets models of packet loss:

– star: end-end loss independent

– full topology: measured per link loss independent

– modified star: source-to-backbone plus star

Title: (Maya:Chart View)Creator: DeltaGraph Professional 3.0CreationDate:

Q: distribution of number of rcvr’s losing pkt?

Temporal Loss Correlation

Q: do losses occur singly or in “bursts”

12/11/95 dataset, rcvr loss vs time– occasional long

periods of 100% loss

– spatial correlation

Title: Creator: gnuplotCreationDate:

Burst Loss Length Distribution

sample distribution from “alps”– 12/1/95 dataset

generally isolated losses with occasional longer bursts

Title: Creator: gnuplotCreationDate:

Temporal Loss Correlation

12/11/95 dataset(above)– similar results over other datasets

“most” loss bursts are 1 packets long but often significant loss in long bursts

Machine % Loss avg. burstlen

medianlength

75percntile

99percntile

length oflongest

% loss in longbursts

alps 5.93 1.21 1 1 3 179 4.3anhur 5.15 1.065 1 1 2 4 0cedar 14.22 1.333 1 1 8 14 0collage 9.08 1.155 1 1 3 175 2.75erlang 10.41 1.921 1 1 4 2518 34.6float 10.44 1.129 1 1 3 7 0law 12.09 1.698 1 1 3 2518 29.8pax 16.98 1.557 1 1 3 2603 21.9tove 5.46 1.097 1 1 3 10 0

MBone Measurements Summary

identifiable backbone loss small wrt overall loss spatial loss correlation: limited temporal loss correlation:

– most loss bursts have length one

– significant loss occurs in long bursts

reference: ftp://gaia.cs.umass.edu/pub/Yajn96:loss.ps lessons for multicast protocols/applications? loss/delay correlation? sensitivity to period, probe size, 1-many, many-many

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 Is there a subtree of G that includes all R with cost no more than B?cost no more than B?

– Heuristic less than twice optimum

Principles of Multicast Routing

Addressing

– List Addressing » Not Scalable

– Group Addressing» Less Control

Reuse of unicast routing infrastructure

– Desirable

– Too Constraining Multicast routing overhead

– Needs to be minimized

Evaluation

– Bandwidth Usage

– Delay -- Average, Maximum, Variance

– Concentration

– Router/Switch overhead

Basic Multicast Routing Protocols

SourceSource

Problem:

Given a source and a set of destinations,

Route same packet to at least (or exactly) this set of destinations

Multicast by BroadcastMulticast by Broadcast

– Filter above network layer

– Natural in Broadcast Networks (Satellite, Bridged LANs)

– Use Flooding in PSN– Bandwidth inefficient, Security concerns

Separately addressed packetsSeparately addressed packets

SourceSource

Eto Ato B

Multidestination AddressingMultidestination AddressingAA

SourceSource

to (A,B,C,D,E)to (A,B,C,D,E)

to (A,B)to (A,B)

to (C,D,E)to (C,D,E)

to (A,B)to (A,B)

to (D,C)to (D,C)

to (B)to (B)

to (C)to (C)

Spanning Tree ForwardingSpanning Tree Forwarding– Shared or Source-Based

SourceSource

Reverse Path ForwardingReverse 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)

wwDestinationsDestinations

toto useuse

Routing TableRouting Table

to Groupto Group

SourceSource

Shortest Path TreeShortest Path Treeto Sourceto Source

Shared Tree VS Source-Based Tree

RPF routes over source-based treesource-based tree– Good delay properties– Per source and group overhead

Spanning Tree Forwarding uses shared treeshared tree– Per group overhead– Higher delays– More Traffic Concentration

Multicast Routing Performance Evaluation

Simulation, Analysis and Experimentation Need

– Network Models (Waxman, GT-ITM, Tiers)– Application Models (Mlisten)– Traffic Models– Data Loss Models

Internet Multicast Routing

Group Addressing

– Class D IP addresses Link Layer Multicast Two Protocol Functions

– Group Management» IGMP

– Route Establishment» DVMRP, MOSPF, CBT, PIM

Link Layer Multicast

Example Ethernet:– 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 Management Protocol

Used by end-systemend-system to declare membership in particular multicast group to nearest router(s)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

Unclear Status?? ADDS:

– Group-Source Specific Queries, Reports and Leaves

Inclusion/Exclusion of sources

Routing Protocols

Source -based Tree Protocols:– DVMRP– MOSPF– PIM-DM

Shared-Tree Protocols– CBT– PIM-SM

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 minute

DVMRP Forwarding (cont.)

Basic idea is to flood and prune

router

noreceiver

packet

DVMRP Forwarding (cont.)Prune branches where no members and branches not

on shortest paths

2nd packet

DVMRP Forwarding (cont.)Add new user via grafting; departure via pruning

Report

Overheard on Mbone Mailing List!

“Help, we are unable to send prunes” Response:

“Well, have you tried to send plums? Raisins or grapes? ……

Perhaps your multicast implementation does not support fruit at all?”

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

ReceiverReceiver

SourceSource

Rendez-VousRendez-Vous

RegisterRegister

JoinJoinSourceSourceJoinJoin

PrunePrune

PIM - Sparse Mode

ReceiverReceiver

SourceSource

Rendez-VousRendez-Vous

Core-Based Trees

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

Core-Based Trees

SourceSource

Core-based treeCore-based tree

CoreCore

PIM and CBT Issues

Unidirectional VS Bidirectional Shared Trees

Core/RP Placement and Selection Multiple Cores/RPS Dynamic Cores/RPs

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

The Problem

sender receiver timet0 t1 t2

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

– easy integration with application

– mechanism - not policy

– scalability - unicast, multipoint 2 - 1000s participants

– separation of control/data

RTCP: RTP Control Protocol

provides monitoring capablities– quality of routes– state of participants (talker indication)

feedback to application– 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 < – prob. pkt delay exceeds D is less than

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 decreasing 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

b M R p R p r prop delay / / .

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– 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

source

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 passive two-phase - notify

originator

source

fwd phaserev 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

rcvr joins group via IGMP 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

Sdata (mcast)

PATHRESV

Other Issues

policing/traffic shaping– 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

Grand-Unified Multicast (GUM)

Putting it all together A protocol for inter-domain multicast routing Bidirectional Shared Tree for inter-domain

routing Receiver domains can utilize choice of

protocol Very New -- Still needs digesting

Summary

Multicast Routing is a well researched problem.

Challenge now is– deployment– inter-operability– management

Reliable Multicast

Problem

How to transfer data reliably from source to R receivers

scalability: 10s -- 100s -- 1000s -- 10000s -- 100000s of receivers

heterogeneity feedback implosion problem

Feedback Implosion Problem

sender

Issues

level of reliability– full reliability (data)

– semi-reliability (video)

ordering– 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– low latency

» file transfer (finite duration)

» DIS, teleconferencing

– high throughputs - streaming applications (billing, etc.)

application characteristics– one-many: one sender, all other participants rcvrs

(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

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

sender

receivers

Sender vs. Receiver (cont.)

Significant performance improvement shifting burden to receivers for 1-many; not as great for many-many

0 100 200 300 400 500 600 700 800 900 1000

No. Receivers

p=0.01

p=0.05

p=0.10

p=0.25

One-to-Many Comparison

0 100 200 300 400 500 600 700 800 900 1000

No. Receivers

p=0.01

p=0.05

p=0.10

p=0.25

Many-to-Many Comparison

Feedback Suppression randomly delay NAKs multicast to all receivers

+ reduce bandwidth

- additional complexity at receivers (timers, etc)

- increase latencies (timers)X

sender

Performance of Feedback Suppression

Additional thruput improvement for 1-many; costly for many-many

0 100 200 300 400 500 600 700 800 9001000No. Receivers

p=0.01

p=0.05

p=0.10

p=0.25

One-to-Many Comparison

0 100 200 300 400 500 600 700 800 9001000

No. Receivers

p=0.01

p=0.05

p=0.10

p=0.25

Many-to-Many Comparison

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

server server

sender

receivers

first transmisions mcast to all receivers and servers

each receiver assigned to server

servers perform loss recovery servers can be subset of rcvrs

or provided by network can have more than 2 levels

LBRM (Cheriton)

Benefits of Adding Servers 2 levels, 4 rcvrs/server equal losses on each link rcvr oriented, NAK

suppression at all levels

Comments: clear performance benefits how to configure

– static/dynamic

– many-many0

0 100 200 300 400 500 600 700 800 900 1000

No. Receivers

p=0.01

p=0.05

p=0.10

p=0.25

One-to-Many

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

Issues with Server- and Local Based Recovery

how to configure tree what constitutes a local group how to permit joins/leaves how to adapt to time-varying network

conditions

no definitive resolution

Some Examples of Protocols

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 leaves send periodic status msgs to upstream nodes nodes inside tree

– provide repairs to downstream nodes– send aggregate status msgs upstream

late-joins supported thru 2-level cache rate- and window-based flow control

SRM (LBL)

Scalable Reliable Multicast framework integrated with application 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

D1D3 D2

Initial Transmission

Data Retransmission

Parity Retransmission

One parity pkt can recover different data pkts at different rcvrs

P=D1 D2 D3

An Integrated Approach using (k,n) Erasure Codes transmit packets in blocks

of k send redundancy packets

in response to NAKs

Assumptions: independent losses, p

significant performance gain achievable with small no. of parity pkts, n-k

1 10 100 1000 10000 100000 1000000

No. Receivers

no FEC

(7,10)

(7,inf)

p=0.01

End-Host Overheads

Software encoding/decoding rates for1KB pkt size (Rizzo)

=> FEC in SW is feasible for many

applications

BB B B B B

JJ J J J J J J

HH H H H H H H H H

F F F F F F

Ñ Ñ Ñ Ñ Ñ Ñ ÑÉ

É É É É É É É É É0

0 10 20 30 40 50 60 70 80 90 100

Percentage Redundancy

B k=10, enc

J k=20, enc

H k=100, enc

F k=10, dec

Ñ k=20, dec

É k=100, dec

End-Host Thruput Comparison: No FEC vs FEC

No FEC, rcvr oriented with NAK suppression

FEC, rcvr oriented with NAK suppression– SW encoding at sender

– HW encoding at sender

SW FEC thruput determined by sender

HW FEC thruput determined by rcvr

1x100 1x101 1x102 1x103 1x104 1x105 1x106

No. Receivers

no FEC

SW FEC

HW FEC

Thruput Comparison (p=0.01, k=20)

Performance Evaluation - no. transmissions to get pkt j to all rcvrs

- no. transmsissions of pkt j needed for rcvr i

well understood for spatially and temporally independent losses

spatial correlation: computationally expensive for general topologies see Towsley85, Tripathi94, Nonnenmacher97

temporal correlation: has not been touched on (see Nonnenmacher etal 97 for one treatment)

Mj j i max ,

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

GoalGoal: 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

Single GroupSingle Group

ReceiversReceivers

Intra-StreamProtocol

DSGDSG

Intra-StreamProtocol

Inter-StreamProtocol

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)» Scalable but still not fair

– Multiple Multicast Groups

The Single Connection Emulation (SCE) Architecture (Window Flow Control)

ApplicationApplication

TCPTCP

SCESCE

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

A D C BFlow 1rate = 1

B CFlow 2rate = 1

Flow 3rate = 2

R1 R2 R3

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)

Channel 1Rate = 1 A B C D

Channel 2Rate = 1 C D A B

Channel 3Rate = 2

Receiver 1, BW = 1Receiver 2, BW = 2

Receiver 3, BW = 4

Cumulative Layering

– Can achieve minimum reception time with asynchronous receivers

– Schedulability requires some parameter relationships

– Synchronization among channels needed

Summary

Flow control for multicast communication is a hardhard 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 Mapping

IP’s connectionless, receiver-controlled model

ATM’s connection-oriented, source-controlled model

The MARS Architecture

MARS: Multicast Address Resolution Server

Stores mapping between

IP group address

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

ATM Cluster

Source

Receivers

ATM MultipointConnection

MARS Request

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

Receivers

ATM Cluster

Source

MARS Request

MulticastServer

VC Mesh VS MCS

VC Mesh– 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

VC Mesh VS MCS

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

9/14/97sigcomm97 tutorial, copyright ammar and towsley group (multicast) communication in wide area...

Documents

riding along with the time-traveling networking...

modeling tcp congestion control don towsley umass amherst...

measurement-based server selection within the...

gothic : a group access control architecture for secure...

v mostafa h. ammar - georgia institute of...

simulation of large-scale communication networks how large?...

authors: taehyun kim and mostafa h. ammar presented by:...

welcome! welcome to the university of michigan towsley

ammar akhtar

1 1 characterizing vlan-induced sharing in a campus network...

detecting network neutrality violations with causal...

rivendale ranch at towsley canyon - hike santa clarita

v mostafa h. ammar · current position: schlumberger,...

mostafa ammar, school of computer science georgia institute...

overview of umass activities d. towsley w. gong. ongoing...

technical capabilities of towsley auditorium

a comparison of layering and stream replication video...

scalable live video streaming to cooperative clients using...

prefix- and lexicographical-order-preserving ip address...

mostafa sayed mostafa