1

Analysis of BitTorrent-like Protocolsfor On-Demand Stored Media Streaming

Khandoker Nadim Parvez

Carey Williamson

Anirban Mahanti

Niklas Carlsson

2

Introduction and Motivation BitTorrent is a popular protocol used for

Peer-to-Peer (P2P) file sharing on the Internet

Very efficient for download of large files, such as media objects (audio/video)

Question: How suitable is BitTorrent for on-demand stored media streaming?

3

Background: BitTorrent 101 Key features of BitTorrent:

– all peers associated with a file are called a swarm (tracker, downloaders, and seeds)

– a single file (e.g., 100 MB movie) is split into many fixed-size pieces (e.g., 256 KB)

– peers can download pieces in any order– “Rarest-First” piece selection policy makes

prevalence of pieces asymptotically uniform– can download pieces concurrently from

multiple peers at a time– “tit-for-tat” reciprocity among peers to

encourage cooperation (upload/download)

4

Background: Streaming Download = Streaming

– D: obtain file first, then do something with it– S: view the file while it is still being obtained

(start-up delay << download latency) Media playback must be sequential Media file has an inherent media playback

rate (frames per second) Playback rate must be sustained for the

duration of the media object (uninterrupted)

5

Background: P2P Streaming The P2P paradigm has also been applied

to media streaming applications– CoolStreaming, PPLive, ZigZag, …

Two types of streaming:– live streaming: usually a single source, and

many peers with shared temporal content focus, joining and leaving at any time

– on-demand streaming: stored media objects, accessed at any time, retrieved in entirety

Our focus: on-demand P2P streaming

6

Research Questions Can BitTorrent-like protocols provide

scalable on-demand streaming? How sensitive is the performance to the

application configuration parameters? – Piece selection policy– Upload/download bandwidth

What is the user-perceived performance?– Startup delay– Probability of disrupted playback

7

A Key Observation MediaStreamingProgress (MSP) depends

on two different things:– DownloadProgress (DP)– SequentialProgress (SP)

These two can be analyzed separately

(useful media pieces per unit time)

(pieces obtained per unit time)

(useful media pieces per pieces obtained)

MSP = DP x SP

9

Sequential Progress Example

E[j] = ------------- k

M - k + 1

10

BitTorrent System Model

Arrival rate =

Departure rate = y

Downloader

Downloader

Downloader

Downloader

Seed

Seed

Download Time T

Residence Time 1/

Torrent(with x downloaders and y seeds)

11

Assumptions and Parameters Single swarm; homogeneous peers x downloaders and y seeds at time t D download conns > U upload conns System is demand-driven: xD > (x+y)U Per-connection throughput is C bps Download latency = T Number of pieces in the file = M Startup delay = Media Playback Rate = r

12

Fluid Model Overview

Arrivals

Departures

Downloaders

Seeds

Conversions

x(t)

y(t)

13

Model: Rarest-First Conversion of downloaders to seeds at rate (x+y)UC.

Therefore the change of swarm population:

yUCyxdt

dx

UCyxdt

dx

)(

,)(

dy

See [Qiu and Srikant 2004]

14

Model: Rarest-First

Download latency:

Sequential progress:

Startup delay: 11

UC

T

rMMk /)1(1

M

M 2)1(21

15

Rarest-First: Observations Download latency is independent of the

peer arrival rate (system is scalable). Latency improves when upload bandwidth

or seed residence time increase.

Sequential progress is very poor (bad news for on-demand streaming!).

Startup delay approximately equals the download latency when M is large.

16

Strict In-Order Model (naïve) Obtain pieces in numerical order Best case for sequential progress Implications:

– Completely breaks the “tit-for-tat” mechanism! (only older peers have useful pieces for you)

– Uneven distribution of demand in system (heaviest at seeds and older peers, who use random selection with purging to handle load)

– Young peers progress quickly, but progress gets slower and slower with age

– Unstable system population (oscillation)

17

Departure rate = y

Downloader

Downloader

Downloader

Seed

Seed

Torrent(with x downloaders and y seeds)

U = # of upload connectionsC = Per connection throughput

Arrival rate =

Peers(sorted by age)

Strict In-Order Model (naïve)

18

Model: Strict In-Order (naïve) The probability of getting a download connection for a downloader of age t is:

Averaging over all downloaders (age 0 to T), the change of swarm population is:

xD

Utyxtp

)()(

yUCyx

dt

dx

UCyx

dt

dx

2

,2

dy

19

Model: Strict In-Order (naïve) Swarm population:

Download latency:

Startup delay:

11

2UC

T

rUC )1(

1112

y

UCx ,

112

20

Strict In-Order(naïve): Observations

System progress is very sluggish due to x/2 term in the conversion rate.

Number of downloaders is much higher.

Number of seeds is same as Rarest-First.

Download latency is almost double compared to Rarest-First (for near 1).

21

Departure rate = y

Downloader

Downloader

Downloader

Seed

Seed

Torrent(with x downloaders and y seeds)

U = # of upload connectionsC = Per connection throughput

Arrival rate =

Peers(sorted by age)

Strict In-Order Model (clever)

22

In-Order(clever) Model Obtain pieces in numerical order Best case for sequential progress Features:

– Pending requests are queued– Queues are served in FCFS order– Closed-loop mechanism for new requests

ensures finite queue size– Load is less uneven, and self-regulated– System is “fair” to peers of all ages

23

Model: Strict In-Order (clever) Swarm population:

Download latency:

Startup delay:

11

UC

T

rUC )1(

111

y

UCx ,

11

24

In-Order(clever): Observations

Population evolution is identical to Rarest-First. Download latency is identical to Rarest-First.

Sequential progress is ideal (unlike Rarest-First). Lowest startup delay among policies evaluated.

We believe this policy is optimal, but do not have a formal proof at this time. (Help!)

25

Model Validation: Scenario Fluid simulation in ns-2 Number of pieces: M = 100

– Range: 100 to 200 Piece size: 128 KB Media playback rate: r = 2000 Kbps Download capacity: 3200 Kbps (D = 16 conns) Upload capacity: 800 Kbps (U = 4 conns)

– Range: 300 Kbps to 2000 Kbps Arrival rate: 50 (per media duration)

– Range: 6.25 to 100.0 Seed residence time: 20 seconds

– Range: 10 seconds to 150 seconds

26

Model Validation (1 of 3)

Swarm population increases linearly with peer arrival rate In-Order(naïve) has higher system pop. In-Order(naïve) is sensitive to seed residence time, while

other policies are not.

27

Model Validation (2 of 3)

Download time improves when the seed residence time is increased

Download time improves when the upload bandwidth is increased

Good agreement with analytical models

28

Model Validation (3 of 3)

Startup delay improves when seed residence time or upload bandwidth are increased

In-Order(clever) achieves lowest startup delay Good agreement between simulation results and analytical

model

29

Conclusions BitTorrent-like protocols can support scalable

and efficient on-demand streaming. Rarest-First attains poor sequential progress. In-Order(clever) achieves best performance for

media playback while attaining the same download latency of Rarest-First.

Our analytic models accurately predict system performance (simulation validation).

30

Key Contributions Decoupling of download progress and

sequential progress (key insight). Download latency and startup delay

characterization for different policies. Effect of upload U and download D

connections, not just total bandwidth. Distribution of download time and

variability of progress (stream quality). Optimal structure for on-demand media

streaming in P2P networks (???)