Multicast
for Video Streaming
EE290T Spring 2002
Puneet Mehra
pmehra@eecs.berkeley.edu
IP Multicast Overview

Semantics


Approach


1 -> Many or Many -> Many
Build tree connecting source and receivers on
Current Infrastructure in Net [1]

Group Addressing – provides flexibility



Packets delivered throughout tree.
Dynamic changes to tree




Receivers/senders unaware of each other
New Receiver -> graft path onto tree
Receiver leaving -> pruning path from tree
Uses UDP – so no reliability
Challenges

Efficient routing of data to receivers
Video Multicast Over Net[1]

Issues in Multicast over Best Effort




Approaches to Multicast



Fixed Frame Rate – regardless of delay/jitter
Losses – degradation, possibly ungraceful
Heterogeneity of receivers
QoS resource reservation for Multicast
Adaptive Rate Control
Techniques for Rate Adaptation



Single Stream Video Multicast
Replicated Stream Video Multicast
Layered Video Multicast
Single Stream Video Multicast


Only send 1 stream to all receivers.
Pros:


Cons:



Easy To Implement
Ignores Receiver Heterogeneity
Feedback Implosion
INRIA Video Conferencing System


Feedback Problem handled through probabilistic
receiver response
Tradeoff granularity of control vs B/W efficiency
Efficiency Tradeoff in
Single Stream Approach
Replicated-Stream Video Multicast

Destination Set Group (DSG)




Pros:



Small # of video streams of varying quality sent to
different multicast groups
Intra-stream Rate control to adjust stream rate by
receivers
Inter-stream protocol used by receivers to switch
streams
deals with heterogeneity – more fair
Scalable since receiver-driven
Cons: Network carries redundant info
Layered Video Multicast

Receiver-Driven Layered Multicast (RLM)




Send different “layers” to multicast groups, and
receiver subscribes as needed -> scalable solution
Congestion -> layer dropping
Spare B/W -> layer adding
Receivers conduct group join experiments and share
info with others.
Layered Video Multicast Cont.

Layered Video Multicast with Retrans. (LVMR)



Improve reception w/in a layer by retransmission
Deal w/ congestion using Hierarchical Rate Control
Hierarchical Rate Control (HRC)




Congestion info distributed at both sender/receivers
Intelligent partitioning of info -> concurrent
experiments w/ less overhead
Use hierarchy to only inform those who need to know
about an experiment – affected regions
Collaborative layer drop – better approach to
congestion
Error Control in Video Multicast


Pure FEC
ARQ – From LVMR



Local Recovery - designated receivers at
each level in tree help w/ rtx. of pkts ->
lower latency
Don’t rtx packets past deadline
Receivers can trade reliability/latency by
picking parent with desired attributes
Multicast Routing [2,3]


Routing – construct efficient tree from source
to receivers
Theoretical Results [3]



Steiner Tree – minimize total cost of a multicast
tree. NP-Complete. So use heuristics to provide a
“good” approx. to Steiner Tree.
Constrained Steiner Tree – impose b/w delay
constraints on links to receivers. Also NPComplete. So must use heuristics
All practical algorithms based on shortest path
tree – minimize sum of weights on links along
each path from source to receiver
Intra-Domain Routing

Source-based Routing



Tree rooted at source
Dense-mode routing – works best when topology
densely populated with receivers
Core-based Approach


Select a Rendezvous Point (RP) to root the tree
Sparse Mode Routing – More efficient than dense
mode when few, wide-spread receivers
Dense Mode Protocols

Distance Vector Multicast Routing Protocol


Uses broadcast & prune technique to build reverse shortest path
trees (RSP)
Steps:






A lot of state info kept in ALL routers in net.
Multicast extensions to OSPF


Src bcasts pkt on Lan. Local router fwds pkt on all ifaces
If pkt received on RPF iface, then it is forwarded.
Leaf routers send prune toward src if no attached receivers
Prune message forwarded to source, and send own prune if receive
prune message on all ifaces.
Uses IGMP locally, then floods info along with link state to net.
PIM-DM

Less complex than DVMRP since no RPF check is done. More
inefficient as a result
Tree Construction in DVMRP[3]
• S = Source. Black Circles = Receivers
• Periodically flood net w/ datagrams
• Leaf routers send prune toward source if
there are no group members on leaf subnet
• Final Tree is shown in (d).
Core-Based Routing

General Approach






A core, or rendezvous point (RP) is configured for a
multicast group
Info about the RP & mapping from group to RP is discovered
by routers using bootstrap protocol (also finds alternate RP
in case of failure)
Receivers explicitly join tree -> contact RP
Src sends data to RP which sends down tree
More efficient since state only kept in routers on path from
src/receivers to RP.
Examples


CBT – Core-Based Trees
PIM-SM – Protocol Independent Multicast/Sparse Mode
Tree construction in CBT
The Join Process for a new node
•Receiver Contacts Local Router
• Router sends JOIN_REQUEST to
the core router
• When msg reaches on-tree router,
a JOIN_ACK is sent back
• every router receiving JOIN_ACK
updates state information
• Periodically send echo-request to parent router. If echo not received in time,
then router sends quit-notification upstream and deletes state information.
Inter-Domain Routing

Probs w/ multicast described



Large flat topology -> complexity and instability
since no BGP-like protocol
No mechanism to build hierarchical mcast routing
Solution – Immediate Future

Introduce Hierarchy – multi-protocol extensions to
BGP (MBGP)


Each router only knows topology of its own domain &
how to reach other domains
Used to determine next hop for a host
Inter-Domain Routing Cont.


What if you have a src in one domain &
receivers in others?
Multicast Source Discovery Protocol



When src registers w/ RP -> a source active (SA)
msg is sent to MSDP peers
Prevent loops w/ per-RPF flooding (ie: if msg
received on correct iface -> flood)
If MSDP is aware of local group members (use
IGMP), then it will send a join to the src
Long-Term Inter-Domain
Proposals

Border Gateway Multicast Protocol


Bidirectional shared trees between domains
with single root. Need strict allocation of
addresses among domains.
Address Allocation Protocols


Multi Address Set Claim – Helps allocate
addresses dynamically across domains
GLOP – a “glop” of addresses statically
allocated among domains
Problems Deploying IP Multicast [4]

Complexity



Makes old routers useless




disrupts ISP router migration model (routers generally
migrate from core to edge)
Domain Independence


Can’t put it in core routers
Hardware more difficult to manage (probs w/ firewalls)
ISPs don’t want to rely on remote RPs
Don’t want to be RP for non-customers
Security – anyone can send/listen
Address Allocation – anyone can pick a class D addr.
References




[1] “Video Multicast over the Internet.” Xue Li et al. IEEE
Network. 1999.
[2] “The Evolution of Multicast: From the MBone to Interdomain
Multicast to Internet2 Deployment.” Kevin Almeroth. IEEE
Network. 2000.
[3] “Multicast Routing and Its QoS Extension: Problems,
Algorithms, and Protocols.” Bin Wang and Jennifer C. Hou. IEEE
Network. 2000.
[4] “Deployment Issues for the IP Multicast Service and
Architecture.” Christophe Diot et Al. IEEE Network. 2000.