Optimal Scheduling in Peer-to-Peer Networks

Lee Center Workshop 5/19/06

Mortada Mehyar(with Prof. Steven Low, Netlab)

Outline

Brief description of p2p file sharing and Bittorrent protocol

Our model for Bittorrent-like file sharing

Efficiency of scheduling algorithms with respect to different optimality criteria.

About Bittorrent

A p2p protocol started ~ 2002 The most popular p2p system. It

accounts for 35% of all Internet traffic! (according to British Web analysis firm CacheLogic)

Warner Brothers to distribute films through Bittorrent (May 2006)

Bittorrent Basics

Divide file into small pieces (256KB).

Utilize all peers’ upload capacities

server

client

client

client

Problem: large file (~GB) and large demand (10s, 1000s or more clients.) It is not feasible to set up infrastructure for traditional client-server download.

Bittorrent schematicSeed (peer with entire file)

peer

peer

peer

new peer(with torrent file)

tracker

Bittorrent algorithms: who to upload to?

Tit-for-tat: upload to peers from which most data downloaded in last 30 seconds (4 peers by default.)

Therefore: incentive to upload in order to be chosen by other peers!

Bittorrent Algorithms: What piece to send?

Rarest-first: upload the piece that is rarest among your neighbors first

1 2

1 12

3

The ‘Broadcasting Model’

t = 0 1

t = 1 1

t = 2 1 1

1 1 1 1t = 3

M = 1, N = 7, all upload capacities are 1 piece per unit time

Example: M = 2 , N = 3

t = 0

t = 1 1

t = 2 1 1

1 2

t = 3 2

1

2 1

1 2

2 21

NM log+(rarest first!)NM log⋅

2 2t = 4

Equal capacities, general M, N

Theorem 1:There exists a schedule for a server to broadcast M messages to N nodes in M+logN time [Bar-Noy et al, 2000]

However, it is very difficult to extend the result to networks of different capacities

‘Uplink Sharing Model’

1 server, N peers with possibly different capacities.

Suppose upload capacities are the only bottleneck.

Suppose M >> 1SC

1C

2C3C

F

Optimal Last Finish Time

Theorem 2:the minimal time for all N peers to obtain a file F (optimal last finish time) from a server is

( )*L

*L

*L T, ... ,T,T

where F is the file size and Cs, C1,…,CN are the upload capacities. There always exists a schedule S0 such that the finish time vector is

+=

∑ =

N

j jSS CC

NF

C

F

1

*L ,maxT

Example (Zero Peer Capacities) Suppose all peers have 0 capacity,

consider the following two strategies Divide capacity equally among peers:

Upload to peers one by one:

SSS C

NF

C

F

C

F,....,

2,

SSS C

NF

C

NF

C

NF,....,,

The last finish time is the same, but the latter is obviously better! In fact, the latter can be shown to be ‘average finish time’ optimal.

Optimal Average Finish Time (N=3)

SC2

321 CCC ++2

321

CCC ++0

t1 t2 t30 t1 t2 t3 t1 t2 t3

SC

F

finish time

*LT

*LT

Conclusion and Ongoing Work

Simple model with rich structure for understanding efficiency of p2p file sharing

It captures many issues Bittorrent addresses (e.g. favoring fast peers, rarest first policy)

Lots of questions remain open: understanding fairness-efficiency tradeoff other kinds of optimality criteria

Netlab’s other research projects http://netlab.caltech.edu

More details about this work morr@caltech.edu

Thank You!

Backup slides start here

Another way to look at Ts

( )

( )

−<

−≥

=∑

∑∑

=

=

=

1 if ,

1 if ,

T

1

1

1*S

N

CC

C

F

N

CC

C

NF

N

j j

SS

N

j j

SN

j j

Previous Bittorrent Modeling Work

Qiu & Srikant [Sigcomm’04] Predator-prey-like fluid models Assumes equal capacities among peers Assumes rates of peer joins/leaves and

studies equilibrium and stability

Proof of Theorem 2

+≥

∑ =

N

j jSS CC

NF

C

F

1

*S ,maxT

First notice that the two terms have to be lower bounds of the optimal last finish time

So it remains to show that the equality is achievable. Here’s a strategy for that:

Proof of Theorem 2

11

−≥

∑ =

N

CC

N

j j

S

1−NCi

When

the server allocates to peer i:

N

CC

N

C

NN

CC N

j jS

N

j j

N

j j

S ∑∑∑

==

=+

=−

+−−

11

1

11

Each peer therefore receives:

+=

+=

∑∑ ==

N

j jSSN

j jS CC

NF

C

F

CC

NF

11

*S ,maxT

Proof of Theorem 2

11

−<

∑ =

N

CC

N

j j

S

∑ =

N

j j

Si

C

CC

1

When

the server allocates to peer i:

S

N

iN

j j

Si CC

CC =∑∑==

11

Each peer therefore receives:

+==

∑ =

N

j jSSS CC

NF

C

F

C

F

1

*S ,maxT

Bittorrent Basics Torrent file:

Meta data about the file: filename, size, author, etc.

Hash info for each file piece to verify integrity

Link to centralized tracker Published on the Web

Tracker: Keeps track of the IPs of peers ‘Bootstraps’ new peers Centralized, but does not coordinate data

transfer among peers

P2P systems

Napster (centralized directory) Kazza (semi-decentralized system with super

peers) Gnutella (e.g. Limewire, Bearshare,

decentralized) Bittorrent (most popular and successful for

distribution of large files)

Another way to look at TL

( )

( )

−<

−≥

=∑

∑∑

=

=

=

1 if ,

1 if ,

T

1

1

1*L

N

CC

C

F

N

CC

C

NF

N

j j

SS

N

j j

SN

j j

Non-Zero Peer Capacities

If the peer capacities are not all 0, then the “upload one by one” strategy can be shown to result in these finish times:

However… this is not average finish time optimal!

++++ ∑ −

=

1

1211

,....,3

,2

,1

N

j jSSSS CC

N

CCCCCC

Comparing finish time vectors

Definition: a finish time vector v1 is strictly better than another finish time vector v2 if no component of v1 is larger, and some component of v1 is smaller than the corresponding component of v2

- (2, 3, 3) strictly better than (3, 3, 3) - (1, 2, 3) (2, 2, 2) cannot be compared

with respect to this

The ‘Broadcasting Model'

Assume discrete-time, synchronous system where N nodes have equal upload capacity of 1 “message” per unit time

Objective: find a schedule such that every node receives all M messages in minimal time

Assumptions reasonable for p2p

Size of file pieces (256KB for BT) is usually much smaller than total size of file (~GB). Namely, the number of pieces M >> 1.

Upload links are usually much slower (e.g. DSL lines), so assume upload capacities are the only bottleneck.