CS 414 – Multimedia Systems Design Lecture 24 – P2P Streaming

download CS 414 – Multimedia Systems Design Lecture 24 – P2P Streaming

of 24

  • date post

  • Category


  • view

  • download


Embed Size (px)


CS 414 – Multimedia Systems Design Lecture 24 – P2P Streaming. Klara Nahrstedt Ramsés Morales. Streaming from servers. clients. …. servers. …. Video service. Bandwidth at video service and number of servers have to grow with demand Flash crowds have to be taken into account. - PowerPoint PPT Presentation

Transcript of CS 414 – Multimedia Systems Design Lecture 24 – P2P Streaming

PowerPoint Presentation

CS 414 - Spring 2009CS 414 Multimedia Systems Design Lecture 24 P2P Streaming

Klara NahrstedtRamss Morales1Streaming from serversBandwidth at video service and number of servers have to grow with demandFlash crowds have to be taken into accountCS 414 - Spring 2009clientsVideo serviceserversP2P StreamingUse the participating nodes bandwidthMore nodes watching stream = more shared bandwidthApp-level multicastHow?CS 414 - Spring 2009Live stream source(could be a member of the p2p network)P2P networkPeers watching streamP2P StreamingCommon arrangements to multicast the streamSingle TreeMultiple TreeMesh-basedAll nodes are usually interested in the streamThey all have to deal with node dynamism (join/leave/fail/capacity-changes)CS 414 - Spring 2009Streaming in a single treeCS 414 - Spring 2009SourceFramescoder321packets321321(using RTP/UDP)Single TreePeers interested in the stream organize themselves into a treeCS 414 - Spring 2009SourceNodes send as many copies of a data packet as they have childrenJoining the treeFind a node with spare capacity, then make it parentIf contacted node lacks capacity, pick childRandom childRound robinChild closest in physical network to joining node

CS 414 - Spring 2009Parent?Try one of my childrenLeaving the tree or failingOrphan nodes need a new parentPolicies for new parentChildren pick sourceSubtree nodes pick sourceChildren pick grandfatherSubtree nodes pick grandfatherthen repeat join procedure

CS 414 - Spring 2009Orphan children after parent leavesEx-parentgrandfatherSingle tree issuesLeaves do not use their outgoing bandwidthPackets are lost while recovering after a parent leaves/failsFinding unsaturated peer could take a whileTree connections could be rearranged for better transferCS 414 - Spring 2009Multiple TreesChallenge: a peer must be internal node in only one tree, leaf in the restCS 414 - Spring 2009122313312SourceAre nodes 1, 2, 3 receiving the same data multiple times?Multiple Description Coding (MDC)Each description can be independently decoded (only one needed to reproduce audio/video)More descriptions received result in higher quality

CS 414 - Spring 2009coderFrames302010Packets for description 0Packets for description n3n2n1nStreaming in multiple-trees using MDCAssume odd-bit/even-bit encoding --description 0 derived from frames odd-bits, description 1 derived from frames even-bitsCS 414 - Spring 20094123312302010312111(using RTP/UDP)Multiple Tree Streaming in Pastry DHT -- SplitStreamPastry routes messages using id prefix matchingCS 414 - Spring 2009

Multiple Tree Streaming in Pastry DHT -- SplitStreamAssign an id to each coded descriptionIf most significant digit is different, then trees will be interior-node-disjoint, example,Id tree 1: d46a1cId tree 2: a1321d65a1fc: route(m, d46a1c) -> d13da3 -> d4213f -> d462ba65a1fc: route(m, a1321d) -> a0b14f -> a1b987 -> a1321a Stream flows through reverse path

CS 414 - Spring 2009Multiple Tree Streaming in Pastry DHT -- SplitStreamPeer is internal node in only one tree, due to interior-node-disjoint trees and Pastrys routingCS 414 - Spring 2009d462bad4213fd13da365a1fca1321aa1b987a0b14f65a1fcDescription 0d462bad4213fd13da3a1321aa1b987Description 1a0b14fMultiple-Tree IssuesComplex procedure to locate a potential-parent peer with spare out-degreeDegraded quality until a parent found in every treeStatic mapping in trees, instead of choosing parents based on their (and my) bandwidthAn internal node can be a bottleneck

CS 414 - Spring 2009Mesh-based streamingBasic ideaReport to peers the packets that you haveAsk peers for the packets that you are missingAdjust connections depending on in/out bandwidthCS 414 - Spring 2009Description 0/1/2Description 1Description 0Description 1,2Description 0,1,2(Nodes are randomly connected to their peers, instead of statically)Description 0/1/2(mesh uses MDC)Content deliveryCS 414 - Spring 20091410111252613141573816179Description 0Description 2Description 1(1) Diffusion Phase ( ) (2) Swarming Phase ( )(Levels determined by hops to source)Diffusion PhaseAs a new segment (set of packets) of length L becomes available at source every L secondsLevel 1 nodes pull data units from source, then level 2 pulls from level 1, etc.Recall that reporting and pulling are performed periodicallyCS 414 - Spring 20093020103222124042Segment 0Segment 1Have segment 03Send meSegment 02212(during period 0)3Have segment 092212(during period 1)Send meSegment 0(drawings follow previous example)Swarming PhaseAt the end of the diffusion all nodes have at least one data unit of the segmentPull missing data units from (swarm-parent) peers located at same or lower levelCan node 9 pull new data units from node 16?Node 9 cannot pull data in a single swarm intervalCS 414 - Spring 2009(drawings follow previous example)101112213141571617920102111211111211020BufferingDue to diffusion nodes need a bufferSize: c * L(diffusion tree dept + minimum number of swarming intervals)