Post on 15-Jan-2016
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 (???)