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

[email protected] [email protected]


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

R

R

router packet

S

noreceiver


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

on shortest paths

R

R

2nd packet

S

prune


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

R

R

S

graft

R


MboneMBONE

tunnel endpoint

IP router

WS

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

IP

UDP TCP

SAP HTTP SMTP

SDP

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

1 / N


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)

Title: temp.dviCreator: dvipsk 5.526a Copyright 1986, 1993 Radical Eye SoftwareCreationDate:


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

vs

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

A B C

D

E

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

A B C

D

Eto Ato B

to C

to D

to E



Multidestination AddressingMultidestination AddressingAA

BB

CC

DD

EE

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


AABB

CC

DD

EE

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)



SS xx

yy

zz

wwDestinationsDestinations

toto useuse

SS yy

Routing TableRouting Table

to Groupto Group



AABB

CC

DD

EE

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


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 minute


DVMRP Forwarding (cont.)

Basic idea is to flood and prune

R

R

router

S

noreceiver

packet


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

on shortest paths

R

R

S

prune

2nd packet


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

R

R

S

R

Report

graft


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

AABB

CC

DD

EE

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

pkts

gen

erat

ed (

rece

ived

)

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

b

r


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

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

originator

source

rcvr1

rcvr2

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

R

R

R D

D

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

. . .

AC

K

ACK

ACK

ACK

ACK

AC

K AC

K

sender

rcvrs


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

X

sender

receivers

AC

K AC

K


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

X

sender

receivers

NA

K


Sender vs. Receiver (cont.)

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

0

20

40

60

80

100

120

140

160

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

1.2

1.3

1.4

1.5

1.6

1.7

1.8

1.9

2

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

NAK

X


Performance of Feedback Suppression

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

0

5

10

15

20

25

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.6

0.65

0.7

0.75

0.8

0.85

0.9

0.95

1

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.5

1

1.5

2

2.5

3

3.5

4

4.5

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

D1

D1D2

D2

D3

D3

D1D3 D2

D1

D1D2

D2

D3

D3

P

P

P

Initial Transmission

Data Retransmission

Parity Retransmission

One parity pkt can recover different data pkts at different rcvrs

P=D1 D2 D3

X

X

X


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

1.5

2

2.5

3

3.5

4

1 10 100 1000 10000 100000 1000000

No. Receivers

no FEC

(7,8)

(7,9)

(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

B

B

BB

BB B B B B

J

J

JJ J J J J J J

HH H H H H H H H H

F

F

FF

F F F F F F

Ñ

ÑÑ

Ñ Ñ Ñ Ñ Ñ Ñ ÑÉ

É É É É É É É É É0

1000

2000

3000

4000

5000

6000

7000

8000

9000

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

0.00

0.10

0.20

0.30

0.40

0.50

0.60

0.70

0.80

0.90

1.00

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)

MjM

i R

Mj j i max ,

1

Mj i,


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

High

Med.

Low

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

IPIP



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

CD

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

B

DAC

BD

AC

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

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

ATM Cluster

Source

Receivers

ATM MultipointConnection

MARS

MARS Request

Reply


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

MARS Request

Reply

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


Other Topics

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

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

Documents