CS 414 - Spring 2012 CS 414 – Multimedia Systems Design Lecture 38 – P2P Streaming (Part 2)...

CS 414 - Spring 2012

CS 414 – Multimedia Systems Design

Lecture 38 – P2P Streaming (Part 2)

Klara Nahrstedt

Administrative MP3 deadline Saturday April 28, 5pm

Demonstrations of MP3, April 30, 5-7pm Groups should sign up as follows:

5-6pm – 3rd floor 3401 SC for groups that work with laptops and need wireless connectivity for MP3

6-7pm - 216 SC basement for groups who work with PCs and need wired connectivity for MP3

Top four groups will be decided Monday, April 30 at 7pm (via email, also posted on the newsgroup/classwebsite) - these groups will compete in front of the judges on Tuesday, May 1


Administrative Competition of final four groups on

Tuesday 5-7pm in 3401 SC/ 216 SC ByteMobile Inc. company – judging competition (and

TA/Instructor) The top four groups should prepare 3-4 power-point

slides to present Intro Slide – name of your system and your names (1 slide) Surveillance System Design – overall architecture (1 slide) Features of Your System - interface (1 slide) Features of Your System – other features (1 slide)

Administrative Homework 2 is posted

Deadline May 2, Wednesday midnight 11:59pm Peer Evaluations – due Friday, May 4, midnight

Peer Evaluation Form and Explanation - available on the class website

Submit your Peer Evaluation to [email protected] Note: if you do not submit your peer evaluations, you get

0 for self-evaluation and 100% for your group mates. ¼ Unit projects – due Friday, May 4 midnight (if

you need more time, arrange deadline with instructor)


Outline

Summary of P2P File Sharing P2P Streaming


Napster

Created in 1999 to share music


Napster’s servers• Store file directory

(Filename/location)

Clients/peers• Store files

Centralized Peer Management: Each Peer registers withthe Napster server and Napster server(s) keep Peer List

Centralized File Management:Searching for other peer file is central, i.e., Peers go to Napster servers which keep file list of files and which peer keeps what files

Gnutella – Example of Unstructured P2P


Servents (peers)

Peer pointer

Peers store:• Their files• Peer pointers (peer management)

Distributed Peer Management (Using Ping/Pong)Distributed File Management (Maintain my own files and search of others via flooding)

DHTs (Distributed Hash Tables) – Example of Structured P2P

Hash table allows these operations on object identified by key: InsertLookup Delete

Distributed Hash Table – same but in a distributed setting (object could be files)


DHT performance comparison

Memory Lookup latency lookup overhead

Napster O(1) at client; O(N) at server

O(1) O(1)

Gnutella O(N) O(N) O(N)

Chord (DHT) O(log(N)) O(log(N)) O(log(N))


Streaming from servers Problem: Bandwidth at video service

and number of servers have to grow with demandFlash crowds have to be taken into account


…

…

clients

Video service

servers

P2P Streaming P2P Streaming is a response to elevate the demand on

bandwidth in video servers Issue: In-band and out-band bandwidth of peers

(in/out bandwidth) P2P Streaming can distribute the bandwidth demand

across peers Issue: find peer that has enough out-band BW

P2P Streaming will require management Peer management Chunk management

P2P Streaming will require streaming distribution protocols

Peer Management for P2P Streaming One could use

Centralized peer management Live source keeps peer list, i.e., each peer

registers with live source Separate session server keeps peer list, i.e.,

each peer registers with session server Distributed peer management

Peers advertise among each other and create peer list of its neighbors (Gnuttela-like)


Chunk Management for P2P Streaming

Video is divided into chunks in P2P streaming Chunk size can be size of GOP (group of pictures) Chunk size can be agnostic to video semantics (e.g., 4K,

or 8K or 32K chunk sizes). Peers hold chunks (not files) in P2P streaming Need chunk management

Centralized chunk management Server (live source or session manager) keeps information which

peer has what chunks Distributed chunk management

Peers keep their own chunk table and other peers send queries to neighbors for requested chunks

P2P Streaming

Use the participating node’s bandwidthMore nodes watching stream = more shared

bandwidth App-level multicast

How?


Live stream source(could be a member of the p2p network)

P2P network

Peers watching stream

P2P Streaming

Common arrangements to multicast the streamSingle TreeMultiple TreeMesh-basedAll nodes are usually interested in the stream

They all have to deal with node dynamism (join/leave/fail/capacity-changes)


Streaming in a single tree


Source

Frames coder

3 2 1

packets

3

2

1

3

2

1(using RTP/UDP)

Single Tree

Peers interested in the stream organize themselves into a tree


…

……Source

Nodes send as many copies of a data packet as they have children

Joining the tree Find a node with spare capacity, then

make it parent If contacted node lacks capacity, pick child

according policy Random child or Round robin or Child closest in physical network to joining node


“Parent?”

“Try one of my children”

Leaving the tree or failing

Orphan nodes need a new parent Policies for new parent

Children pick sourceSubtree nodes pick sourceChildren pick grandfatherSubtree nodes pick grandfather…then repeat join procedure


Orphan children after parent leaves

Ex-parent

grandfather

Single tree issues

Leaves do not use their outgoing bandwidth

Packets are lost while recovering after a parent leaves/fails

Finding unsaturated peer could take a while

Tree connections could be rearranged for better transfer


Multiple Trees

Approach: a peer must be internal node in only one tree, leaf in the rest


1 2

2 3 1 3

3

1 2

SourceAre nodes 1, 2, 3 receiving the same data multiple times?- No, we stripe chunks

across multiple nodes- Example: node 1 receives chunk

1, node 2 receives chunk 2, node 3 receives chunk 3 from source and then they distribute to other nodes in the subtree their chunks

13

2

2

311 3 2

Multiple Trees – Other Approach: Multiple Description Coding (MDC)

Each description can be independently decoded (only one needed to reproduce audio/video)More descriptions received result in higher

qualityCS 414 - Spring 2012

coder

Frames 30 20 10

Packets for description 0

Packets for description n

…

3n 2n 1n

Streaming in multiple-trees using MDC Assume odd-bit/even-bit encoding --

description 0 derived from frame’s odd-bits, description 1 derived from frame’s even-bits


4

1

2 3

3

1 2

3020

10

3121

11(using RTP/UDP)

Multiple-Tree Issues

Complex procedure to locate a potential-parent peer with spare out-degreeDegraded quality until a parent found in every

tree Static mapping in trees, instead of

choosing parents based on their (and my) bandwidthAn internal node can be a bottleneck


Mesh-based streaming Basic idea

Report to peers the packets that you haveAsk peers for the packets that you are

missingAdjust connections depending on in/out

bandwidth


Description 0/1/2

Description 1

Description 0

Description 1,2

Description 0,1,2

(Nodes are randomly connected to their peers, instead of statically)

Description 0/1/2

(mesh uses MDC)

Content delivery


1

4

10 11 12

5

2

6

13 14 15

7

3

8

16 17

9

Description 0 Description 2Description 1

(1) Diffusion Phase ( ) (2) Swarming Phase ( )

(Levels determined by hops to source)

Diffusion Phase

As a new segment (set of packets) of length L becomes available at source every L seconds Level 1 nodes pull data units

from source, then level 2 pulls from level 1, etc.

Recall that reporting and pulling are performed periodically


30 20 10

…

32 22 12

40

42

Segment 0Segment 1

…

…

Have segment 0

3

Send meSegment 0

22

12

(during period 0)

3 Have segment 0

9

22

12

(during period 1)

Send meSegment 0

(drawings follow previous example)

Swarming Phase

At the end of the diffusion all nodes have at least one data unit of the segment

Pull missing data units from (swarm-parent) peers located at same or lower level

Can node 9 pull new data units from node 16? Node 9 cannot pull data in a single swarm interval

CS 414 - Spring 2012(drawings follow previous example)

10 11 12

2

13 14 15

7

16 17

9

20

10

2111

21 11

1121

1020

Conclusion

P2P streaming – strong alternative to CDN (Content Distribution Networks) networks

Examples of P2P streaming technologyPPLive Skype


Many more details in references and source code M. Castro, P. Druschel, A-M. Kermarrec, A. Nandi, A. Rowstron and

A. Singh, "SplitStream: High-bandwidth multicast in a cooperative environment," SOSP 2003.

H. Deshpande, M. Bawa, H. Garcia-Molina. "Streaming Live Media over Peers," Technical Report, Stanford InfoLab, 2002.

N. Magharei, R. Rejaie. "PRIME: Peer-to-Peer Receiver drIven MEsh-Based Streaming," INFOCOM 2007.

N. Magharei, R. Rejaie, Y. Guo. "Mesh or Multiple-Tree: A Comparative Study of Live P2P Streaming Approaches," INFOCOM 2007.

http://freepastry.org


CS 414 - Spring 2012 CS 414 – Multimedia Systems Design Lecture 38 – P2P Streaming (Part 2)...

Documents

Transcript of CS 414 - Spring 2012 CS 414 – Multimedia Systems Design Lecture 38 – P2P Streaming (Part 2)...