290t_multicast

8/3/2019 290t_multicast

1/20

Multicastfor Video Streaming

EE290T Spring 2002

Puneet [email protected]


2/20

IP Multicast Overview Semantics

1 -> Many or Many -> Many

Approach Build tree connecting source and receivers on

Current Infrastructure in Net [1] Group Addressing provides flexibility

Receivers/senders unaware of each other

Packets delivered throughout tree. Dynamic changes to tree

New Receiver -> graft path onto tree Receiver leaving -> pruning path from tree

Uses UDP so no reliability

Challenges Efficient routing of data to receivers


3/20

Video Multicast Over Net[1] Issues in Multicast over Best Effort

Fixed Frame Rate regardless of delay/jitter Losses degradation, possibly ungraceful Heterogeneity of receivers

Approaches to Multicast QoS resource reservation for Multicast Adaptive Rate Control

Techniques for Rate Adaptation Single Stream Video Multicast Replicated Stream Video Multicast Layered Video Multicast


4/20

Single Stream Video Multicast Only send 1 stream to all receivers. Pros:

Easy To Implement

Cons: Ignores Receiver Heterogeneity Feedback Implosion

INRIA Video Conferencing System Feedback Problem handled through probabilistic

receiver response Tradeoff granularity of control vs B/W efficiency


5/20

Efficiency Tradeoff in

Single Stream Approach


6/20

Replicated-Stream Video Multicast Destination Set Group (DSG)

Small # of video streams of varying quality sent todifferent multicast groups

Intra-stream Rate control to adjust stream rate byreceivers

Inter-stream protocol used by receivers to switchstreams

Pros: deals with heterogeneity more fair Scalable since receiver-driven

Cons: Network carries redundant info


7/20

Layered Video Multicast Receiver-Driven Layered Multicast (RLM)

Send different layers to multicast groups, andreceiver subscribes as needed -> scalable solution

Congestion -> layer dropping

Spare B/W -> layer adding

Receivers conduct group join experiments and shareinfo with others.


8/20

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 -> concurrentexperiments w/ less overhead

Use hierarchy to only inform those who need to knowabout an experiment affected regions

Collaborative layer drop better approach tocongestion


9/20

Error Control in Video Multicast Pure FEC

ARQ From LVMR

Local Recovery - designated receivers ateach level in tree help w/ rtx. of pkts ->lower latency

Dont rtx packets past deadline Receivers can trade reliability/latency by

picking parent with desired attributes


10/20

Multicast Routing [2,3] Routing construct efficient tree from source

to receivers Theoretical Results [3]

Steiner Tree minimize total cost of a multicasttree. NP-Complete. So use heuristics to provide agood approx. to Steiner Tree.

Constrained Steiner Tree impose b/w delayconstraints on links to receivers. Also NP-Complete. So must use heuristics

All practical algorithms based on shortest pathtree minimize sum of weights on links alongeach path from source to receiver


11/20

Intra-Domain Routing Source-based Routing

Tree rooted at source

Dense-mode routing works best when topologydensely populated with receivers

Core-based Approach

Select a Rendezvous Point (RP) to root the tree

Sparse Mode Routing More efficient than densemode when few, wide-spread receivers


12/20

Dense Mode Protocols Distance Vector Multicast Routing Protocol

Uses broadcast & prune technique to build reverse shortest pathtrees (RSP)

Steps: 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.

A lot of state info kept in ALL routers in net.

Multicast extensions to OSPF 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


13/20

Tree Construction in DVMRP[3]

S = Source. Black Circles = Receivers

Periodically flood net w/ datagrams

Leaf routers send prune toward source ifthere are no group members on leaf subnet

Final Tree is shown in (d).


14/20

Core-Based Routing General Approach

A core, or rendezvous point (RP) is configured for amulticast group

Info about the RP & mapping from group to RP is discoveredby routers using bootstrap protocol (also finds alternate RPin 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


15/20

Tree construction in CBTThe Join Process for a new node

Receiver Contacts Local Router

Router sends JOIN_REQUEST tothe core router

When msg reaches on-tree router,a JOIN_ACK is sent back

every router receiving JOIN_ACKupdates state information

Periodically send echo-requestto parent router. If echo not received in time,then router sends quit-notificationupstream and deletes state information.


16/20

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


17/20

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


18/20

Long-Term Inter-DomainProposals

Border Gateway Multicast Protocol

Bidirectional shared trees between domains

with single root. Need strict allocation ofaddresses among domains.

Address Allocation Protocols

Multi Address Set Claim Helps allocateaddresses dynamically across domains

GLOPa glop of addresses staticallyallocated among domains


19/20

Problems Deploying IP Multicast [4]

Complexity Cant put it in core routers

Hardware more difficult to manage (probs w/ firewalls)

Makes old routers useless disrupts ISP router migration model (routers generally

migrate from core to edge)

Domain Independence ISPs dont want to rely on remote RPs

Dont want to be RP for non-customers

Security anyone can send/listen

Address Allocation anyone can pick a class D addr.


20/20

References

[1] Video Multicast over the Internet. Xue Li et al. IEEENetwork. 1999.

[2] The Evolution of Multicast: From the MBone to Interdomain

Multicast to Internet2 Deployment. Kevin Almeroth. IEEENetwork. 2000.

[3] Multicast Routing and Its QoS Extension: Problems,Algorithms, and Protocols. Bin Wang and Jennifer C. Hou. IEEENetwork. 2000.

[4] Deployment Issues for the IP Multicast Service andArchitecture. Christophe Diot et Al. IEEE Network. 2000.

290t_multicast

Documents

Transcript of 290t_multicast