Docstoc

Multicast for Video Streaming

Document Sample
Multicast for Video Streaming Powered By Docstoc
					      Multicast
for Video Streaming

  EE290T Spring 2002
     Puneet Mehra
pmehra@eecs.berkeley.edu
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
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
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
Efficiency Tradeoff in
Single Stream Approach
Replicated-Stream Video Multicast
   Destination Set Group (DSG)
       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
   Pros:
       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 NP-
        Complete. 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:
             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
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
       Can’t 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 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.

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:27
posted:7/21/2010
language:English
pages:20