Mul$media Networking
#8 P2P Streaming
Semester Ganjil 2012
Today’s Outline
•
Ways to distribute video online
– Client-‐server
– IP Mul$cast
– P2P Media Streaming
Client-‐Server
•
Applica$on-‐layer solu$on
– Single media server unicasts to all clients
•
Needs very high capacity to serve large
number of clients
– CPU
– Memory
Client-‐Server
10 flows
of the same packet
Unicast
Mul$cast
•
Basic idea: the same data needs to reach mul$ple
receivers
avoid transmicng it once for each receiver
– par$cularly useful if access link has bandwidth limita$ons
– can be implemented at link, network and applica$on layer
– e.g., mailing list as example
IP Mul$cast
•
Network-‐layer solu$on
– Routers responsible for mul$cas$ng
•
Efficient bandwidth usage
•
Requires per-‐group state in routers
– Scalability concern– Violates end-‐to-‐end design principle
•
Slow deployment
– IP mul$cast is ofen disabled in routers
Why P2P?
•
Every node is both a server and client
– Easier to deploy applica$ons at endpoints
– No need to build and maintain expensive infrastructure
– Poten$al for both performance improvement and addi$onal robustness
– Addi$onal clients create addi$onal servers for
P2P Overview
•
Applica$on-‐layer approach
•
Clients send contents to each other
Overlay Network
•
Consists of applica$on-‐layer links
•
Applica$on-‐layer link is logical link consis$ng
of one or more links in underlying network
Overlay Networks
IP Tunneling
• IP tunnel is a virtual point-‐to-‐point link
– Illusion of a direct link between two separated nodes
• Encapsula$on of the packet inside an IP datagram
A B tunnel E F
Logical view:
Server Distribu$ng a Large File
d1
F bits
d2
d3 d4
upload rate us
Server Distribu$ng a Large File
•
Sending an
F
-‐bit file to
N
receivers
– Transmicng NF bits at rate us
– … takes at least NF/us $me
•
Receiving the data at the slowest receiver
– Slowest receiver has download rate dmin= mini{di}
– … takes at least F/dmin $me
Speeding Up the File Distribu$on
•
Increase the server upload rate
– Higher link bandwidth at the server
– Mul$ple servers, each with their own link
•
Alterna$ve: have the receivers help
– Receivers get a copy of the data
– … and redistribute to other receivers
Peers Help Distribu$ng a Large File
d1
F bits
d
d3 d4
upload rate us
Internet
u1 u2 u3
Peers Help Distribu$ng a Large File
•
Components of distribu$on latency
– Server must send each bit: min $me F/us
– Slowest peer must receive each bit: min $me F/
dmin
•
Upload $me using all upload resources
– Total number of bits: NF
– Total upload bandwidth us + sumi(ui)
Peer-‐to-‐Peer is Self-‐Scaling
•
Download $me grows slowly with N
– Client-‐server: max{NF/u s, F/dmin}
– Peer-‐to-‐peer: max{F/us , F/dmin , NF/(us+sumi(ui))}
•
But…
– Peers may come and go
– Peers need to find each other
Loca$ng the Relevant Peers
•
Three main approaches
– Central directory (Napster)
– Query flooding (Gnutella)
– Hierarchical overlay (Kazaa, modern Gnutella)
•
Design goals
– Scalability
– Simplicity
– Robustness
Peer-‐to-‐Peer Networks: BitTorrent
•
BitTorrent history
– 2002: B. Cohen debuted BitTorrent
•
Emphasis on efficient fetching, not searching
– Distribute same file to many peers
– Single publisher, many downloaders
•
Preven$ng free-‐loading
BitTorrent: Simultaneous Downloads
•
Divide file into many chunks (e.g., 256 KB)
– Replicate different chunks on different peers
– Peers can trade chunks with other peers
– Peer can (hopefully) assemble the en$re file
•
Allows simultaneous downloading
– Retrieving different chunks from different peers
– And uploading chunks to peers
BitTorrent: Tracker
•
Infrastructure node
– Keeps track of peers par$cipa$ng in the torrent
– Peers registers with the tracker when it arrives
•
Tracker selects peers for downloading
– Returns a random set of peer IP addresses
– So the new peer knows who to contact for data
Defini$on: Peer
•
Leecher
– A peer that is client and server
– In the context of content delivery
• Has a par$al copy of the content
•
Seed
– A peer that is only server
– In the context of content delivery
P2P Streaming
• Tree-based
– Parent-child relationships
– Push-based
– Uplink bandwidth not utilized at leaves
• Data can be divided and disseminated along multiple trees (e.g., SplitStream)
– Must be repaired and maintained to avoid
interruptions
P2P Multicast
•
Mesh-based
– Data-driven – Pull-based
– Periodically exchange data availability with random partners and retrieve new data
– Unlike BitTorrent, must consider real-time constraints
Overlay Performance
• Even a well-designed overlay cannot be as efficient as IP Mulitcast • But performance penalty can be kept low
• Trade-off some performance for other benefits
Increased
Dumb Network
Gatech
Duplicate Packets: Bandwidth Wastage
Case Study: PPLive
•
Very popular P2P IPTV application
– Free for viewers
– Over 100,000 simultaneous viewers and 400,00 viewers daily
– Over 200+ channels
Case Study: PPLive
•
Gossip-based protocols
– Peer management – Channel discovery
•
Data-driven p2p streaming
•
Recommend papers are measurement
Case Study: PPLive
1. Contact channel
server for available channels
share video chunks Source: “Insights into PPLive: A Measurement
