Peer-to-Peer Networks (3) - IPTV

Hongli Luo

CEIT, IPFW

Internet Video Broadcasting

References: “Opportunities and Challenges of Peer-to-Peer

Internet Video Broadcast” by Liu et al. “Insights into PPLive: A Measurement Study of a

Large-Scale P2P IPTV System” by Hei et al.

Background

Large-scale video broadcast over Internet Real-time video streaming Applications:

• Internet TV• Broadcast of sports events• Online games• Distance education

Need to support large numbers of viewers• AOL Live 8 broadcast peaked at 175,000 (July 2005)• CBS NCAA broadcast peaked at 268,000 (March 2006)

Very high data rate• TV quality video encoded with MPEG-4 would require 1.5 Tbps

aggregate capacity for 100 million viewers• NFL Superbowl 2007 had 93 million viewers in the U.S.

(Nielsen Media Research)

Possible Solutions

Broadcasting is possible in air, cable networks, or local area networks

Possible solutions for broadcasting over Internet Single server - unicast IP multicast Multicast overlay networks Content delivery networks (CDNs) Application end points (pure P2P)

Single Server

Application-layer solution Single media server unicasts to all clients

Needs very high capacity to serve large number of clients CPU Main memory Bandwidth

Impractical for millions of simultaneous viewers

IP Multicast

Network-layer solution Routers responsible for multicasting

Efficient bandwidth usage Requires per-group state in routers

High complexity Scalability concern Violates end-to-end design principle

IP Multicast

Unicast via Multicast

S

C

C

C

Server

Clients

S

C

C

C

Server

Clients

Unicast Multicast

Multicast group

IP Multicast

End-to-end design principle: a functionality should be Pushed to higher layers if possible, unless Implementing it at the lower layer can achieve

significant performance befits that outweigh the cost of additional complexity

Slow deployment IP multicast is often disabled in routers

Difficult to support higher layer functionality Error control, flow control, and congestion control

Needs changes at the infrastructure level

IP Multicast

“Smart Network”

Berkeley

Gatech Stanford

Per-group Router State

Source:

Purdue

Source: Sanjay Rao’s lecture from Purdue

Multicast Overlay Network

Consists of user hosts and possibly dedicated servers scattered through the Internet

Hosts, servers and logical links between them form an overlay network, which multicasts traffic from the source to users

Originally in IP multimcast, router responsible for forwarding packets, application run on the end systems.

New applications can now make their own forwarding decisions.

A logical network implemented on top of a physical network. Consists of application-layer links Application-layer link is logical link consisting of one or more

links in underlying network Each node in the overlay processes and forwards packets in

an application-specific way Used by both CDNs and pure P2P systems

MBone

The multicast backbone (MBone) is an overlay network that implements IP multicast.

Mbone was an experimental backbone for IP multicast traffic across the Internet

It connects multicast-capable networks over the existing Internet infrastructure

One of the popular applications run on top of the MBone is Vic

Vic Supports multiparty videoconferencing Broadcast both seminars and meetings across the

Internet, e.g. IETF meetings

Content distribution networks (CDNs)

Content replication challenging to stream large

files (e.g., video) from single origin server in real time

solution: replicate content at hundreds of servers throughout Internet content downloaded to

CDN servers ahead of time placing content “close” to

user avoids impairments (loss, delay) of sending content over long paths

CDN server typically in edge/access network

origin server in North America

CDN distribution node

CDN serverin S. America CDN server

in Europe

CDN serverin Asia

Content distribution networks (CDNs)

Content replication CDN (e.g., Akamai)

customer is the content provider (e.g., CNN)

CDN places CND servers close to ISP access networks and the clients

CDN replicates customers’ content in CDN servers.

when provider updates content, CDN updates servers

origin server in North America

CDN distribution node

CDN serverin S. America CDN server

in Europe

CDN serverin Asia

Content distribution networks (CDNs)

When a client requests content, the content is provided by the CDN server that can best deliver the content to the specific The closest CDN server to the client CDN server with a congestion-free path to the client

A CDN server typically contains objects from many content providers

CDN example

origin server (www.foo.com) distributes HTML replaces: http://www.foo.com/sports.ruth.gif

with

http://www.cdn.com/www.foo.com/sports/ruth.gif

HTTP request for

www.foo.com/sports/sports.html

DNS query for www.cdn.com

HTTP request for

www.cdn.com/www.foo.com/sports/ruth.gif

1

2

3

origin server

CDN’s authoritative DNS server

CDN server near client

CDN company (cdn.com)

distributes gif files uses its authoritative

DNS server to route redirect requests

client

More about CDNs

routing requests CDNs make use of DNS redirection in order to guide

browsers to the correct server. The browser does a DNS lookup on www.cdn.com, which

is forwarded to authoritative DNS server. CDN’s DNS server returns the IP address of the CDN

server that is likely the best for the requesting browser. when query arrives at authoritative DNS server:

server determines ISP from which query originates uses “map” to determine best CDN server

CDN nodes create application-layer overlay network CDN: bring content closer to clients

Why P2P?

Previous problems Sparse deployment of IP multicast High cost of bandwidth requirement for server-based

unicast and CDNs. Limit video broadcasting to only a subset of Internet

content publishers

Why P2P?

Every node is both a server and client Easier to deploy applications at endpoints No need to build and maintain expensive routers and

expensive infrastructure Potential for both performance improvement and

additional robustness Additional clients create additional servers for

scalability Performance penalty

Can not completely prevent multiple overlay edges from traversing the same physical link

• Redundant traffic on physical links Increasing latency

Peer-to-peer Video Broadcasting

Characteristics of video broadcasting Large scale, corresponding to tens of thousands of

users simultaneously participating the broadcast. Performance-demanding,

• involving bandwidth requirements of hundreds of kilobits per-second and even more.

Real-time constraints, requiring timely and continuously streaming delivery.

• While interactivity may not be critical and minor delays can be tolerated through buffering, it is critical to get video uninterrupted.

Gracefully degradable quality, • enabling adaptive and flexible delivery that

accommodates bandwidth heterogeneity and dynamics.

Peer-to-peer Video Broadcasting

Stringent real-time performance requirement Bandwidth and latency

On-demand streaming – users are asynchronous Audio/video conferencing – interactive, latency more

critical File downloading

No time constraint, segments of contents can arrive out of order

Needs efficient indexing and search P2p video broadcasting

Simultaneously support a large number of participants, Dynamic changes to participant membership, High bandwidth requirement of the video Needs efficient data communication.

Overlay construction

Criterion: Overlay efficiency Scalability and load balancing Self-organizing Honor per-node bandwidth constraint System considerations

Approaches Tree-based Data-driven randomized

P2P Overlay

Tree-based Peers are organized into trees for delivering data Each packet disseminated using the same structure Parent-child relationships Push-based

• When a node receives a data packet, it forwards copies of the packet to each of its children.

Failure of nodes result in poor transient performance. Uplink bandwidth not utilized at leaf nodes

• Data can be divided and disseminated along multiple trees (e.g., SplitStream)

The structure should be optimized to offer good performance to all receivers.

Must be repaired and maintained to avoid interruptions Example: End System Multicast (ESM)

P2P Overlay Data-driven

Do not construct and maintain an explicit structure for delivering data

Use gossip algorithms to distribute data• A node sends a newly generated message to a set of

randomly selected nodes.• These nodes do similarly in the next round, and so do other

nodes until the message is spread to all. Pull-based

• Nodes maintain a set of partners• Periodically exchange data availability with random partners

and retrieve new data• Redundancy is avoided since node pulls data only it does not

have it. Similar to BitTorrent, but must consider real-time

constraints• Scheduling algorithm schedules the segments that must be

downloaded to meet the playback deadlines Example: CoolStreaming, PPLive

Tree-based vs. Data driven

Data driven Simple Suffer from a latency-overhead trade-off

Tree-based No latency-overhead trade-off Instability Bandwidth under-utilization

A combination of both

P2P live streaming system CoolStreaming

X.Zhang, J. Liu, B. Li, and T. S. P. Yum. Coolstreaming/donet: A data-driven overlay network for efficient live media streaming. In Proceedings of IEEE INFOCOM’05, March 2005.

PPLive http://www.pplive.com

PPStream http://www.ppstream.com

UUSee http://www.uusee.com

AnySee X. Liao, H. Jin, Y. Liu, L. M. Ni, and D. Deng. Anysee: Peer-to-peer

live streaming. In Proceedings of IEEE INFOCOM’06, April 2006.

Joost http://www.joost.com/

Case Study: PPLive

PPLive: free P2P-based IPTV As of January 2006, the PPLive network provided

200+ channels with 400,000 daily users on average. Typically over 100,000 simultaneously users

It now covers over 120 TV Chinese stations, 300 live channels and 20,000 VOD (video-on-demand) channels (from Wiki)

The company claimed that they have more than 200 million user installations and 105 million active monthly user base (as of Dec 2010). (from Wiki)

The bit rates of video programs mainly range from 250 Kbps to 400 Kbps with a few channels as high as 800 Kbps.

The channels are encoded in two video formats: Window Media Video (WMV) or Real Video (RMVB).

The encoded video content is divided into chunks and distributed to users through the PPLive P2P network.

Employs proprietary signaling and video delivery protocols

Case Study: PPLive

BitTorrent is not a feasible video delivery architecture Does not account for the real-time needs of IPTV

Bearing strong similarities to BitTorrent Video chunk has playback deadline No reciprocity mechanism deployed to encourage

sharing between peers

Two major application level protocols A gossip-based protocol

• Peer management• Channel discovery

P2P-based video distribution protocol• High quality video streaming

Data-driven p2p streaming

Case Study: PPLive

1. User starts PPlive software and becomes a peer node.

2. Contact channel server for list of available channels

3. Select a channel 4. Sends query to root

server to retrieve an online peer list for this channel

5. Find active peers on channel to share video chunks

Channel and peer discoveryfrom “Insights into PPLive: A MeasurementStudy of a Large-Scale P2P IPTV System” by Hei et al.

TV Engine Download video chunks from PPLive network Stream the downloaded video to a local video player

Streaming process traverses two buffers PPLive TV engine buffer Media player buffer

Cached contents can be uploaded to other peers watching the same channel.

This peer may also upload cached video chunks to multiple peers.

Peer may also download media content from multiple active peers

Received video chunks are reassembled in order and buffered in queue of PPLive TV engine, forming local streaming file in memory.

When the streaming file length crosses a predefined threshold, the PPLive TV engine launches media player, which downloads video content from local HTTP streaming server.

After the buffer of the media player fills up to required level, the actual video playback starts.

When PPLive starts, the PPLive TV engine downloads media content from peers aggressively to minimize playback start-up delay.

PPLive uses TCP for both signaling and video streaming When the media player receives enough content and

starts to play the media, streaming process gradually stabilizes.

The PPLive TV engine streams data to the media player at media playback rate.

Measurement setup

One residential and one campus PC “watched” channel CCTV3

The other residential and campus PC “watched” channel CCTV10

Each of these four traces lasted about 2 hours. From the PPLive web site, CCTV3 is a popular channel

with a 5-star popularity grade and CCTV10 is less popular with a 3-star popularity grade.

Start-up delays

A peer search for peers and download data from active peers.

Two types of start-up delay: the delay from when one channel is selected until the streaming player

pops up; the delay from when the player pops up until the playback actually starts.

The player pop-up delay is in general 10-15 seconds

The player buffering delay is around 10-15 seconds. Therefore, the total start-up delay is around 20 - 30

seconds. Nevertheless, some less popular channels have a

total start-up delays of up to 2 minutes. Overall, PPLive exhibits reasonably good start-up

user experiences

Video Traffic Redundancy It is possible to download same video blocks more than

once Transmission of redundant video is a waste of network

bandwidth Define redundancy ratio as ratio between redundant traffic

and estimated media segment size. The traffic redundancy in PPLive is limited

Partially due to the long buffer time period Peers have enough time to locate peers in the same channel

and exchange content availability information.

Video Buffering

Estimation of size of media player buffer: at least 5.37 MBytes

Estimation of size of PPLive engine buffer: 7.8 MBytes to 17.1 Mbytes

The total buffer size in PPLive streaming 10 - 30 Mbytes

A commodity PC can easily meet this buffer requirement

PPLive Peering Statistics

A campus peer has many more active video peer neighbors than a residential peer due to its high-bandwidth access network.

A campus peer maintains a steady number of active TCP connections for video traffic exchanges.

Peers with less popular channel have difficulty in finding enough peers for streaming the media

If the number of active video peers drops, the peer searches for new peers for additional video download.

Peer constantly changes its upload and download neighbors