P4P: Proactive Provider Assistance for P2P Haiyong Xie (Yale) [email protected] *This is a joint work with Arvind Krishnamurthy (UWashington) and Richard

P4P: Proactive Provider Assistance for P2P

Haiyong Xie (Yale)

[email protected]

*This is a joint work with Arvind Krishnamurthy (UWashington) and Richard Yang (Yale).

2007-5-25 1st NYC P2P Workshop 2

Roadmap

Motivation P4P framework

Design rationale System architecture Computing peering suggestions

Evaluations Conclusion and future work


P2P : The Significant Bandwidth Consumer Up to 60-70% of Internet traffic is contributed by

P2P applications [cachelogic]

Problems Scattered traffic Increased network utilization Degraded performance of other applications Increased network operational costs

http://www.cachelogic.com


Bandwidth Battle between ISPs and P2P

The battle results in a lose-lose situation ISPs: increased financial and operational costs, increased

network utilization, degraded performance P2P: increased complexity of P2P applications, reduced

interoperability, and impeded development of P2P applications

ISPs try to “manage” P2P traffic

Upgrade network infrastructure Deploy P2P caching devices Rate limit P2P traffic

P2P tries to evade from being captured

Use random ports Encrypt traffic


Objective:

Where are the problems? ISPs do not disclose their network information for privacy

concerns P2P does not have sufficient information to determine

network-aware peering relationships

ISPs can expose information to “guide” the peering relationships in P2P systems to Improve the throughput of P2P users Lower traffic costs for ISPs, balance traffic across the network

Design a framework so that ISPs and P2P can work together to

achieve better results


P4P Framework – Design Rationale Scalability

Support a large number of P2P users and networks in dynamic settings

Privacy preservation Try to improve performance for both ISPs and P2P Extensibility

Application-specific requirements Tracker-based vs. trackerless P2P systems Gossip among peers

Incremental deploymentability


ISP A

Design For Tracker-based P2P

1 4

3

2pTracker iTracker

peer

Use BitTorrent in a single ISP as an example

pTracker keeps P2P system states

iTracker makes suggestions for peering relationships

Information flow: 1. peer queries pTracker 2. pTracker asks iTracker

for guidance 3. iTracker returns high-

level peering suggestions 4. pTracker selects and

returns a set of active peers, according to the suggestions iTracker can be run by third parties trusted by ISPs.


Service Interfaces and States Services provided by iTracker

Map an IP address to an opaque, privacy-preserving PIDPID = getpid(ip)

Compute peering suggestions for a given PID-based P2P state

[wij] = getpeering(PID-based-state)

wij : probability with which peers of PID i establish peering relationship with peers of PID j

pTracker keeps states PID-peer state (updated by calling getpid() interface call) P2P state (updated by collecting peer information)

PID counter upcap downcap

…… …… …… ……

i ni ui di

…… …… …… ……

PID Peer list

…… ……

i pi

…… ……


How to Use iTracker Services When a new peer joins the P2P network and queries the pTracker

pTracker gets the PID for this peer by calling getpid() pTracker updates its internal P2P state pTracker gets the PID-based peering suggestion [wij] by calling

getpeering() pTracker selects a set of active peers according to [wij] and returns it

[wij] can be used to represent the peering relationships among peers, and can be used to analyze performance Original BitTorrent protocol selects peers randomly:

wij = nj / ∑nk BitTorrent through caching (each PID has a caching peer only, and the

remaining peers in the same PID peers with the cache):

wij = 0 for non-caching peers and i≠j


Pros and Cons Evaluate the design

Pros iTracker is stateless Need no modification to P2P clients Preserve privacy

Cons Cannot handle trackerless P2P systems Cannot handle gossip


ISP A

The Complete Design

1

pTracker

iTracker

Peer a

iTracker’s responsibilities Keeps P2P system states

(PID-based, light-weight) makes suggestions for

peering relationships Information flow:

1. peers register or update with iTracker

2. iTracker returns PID and PID-based peering suggestions

3. Peers exchange peer information (with associated PID information) through gossips

4. Peers update peering relationships according to the received peering suggestions

Peer b

3

12

2


How iTracker Works – Computing Peering Suggestions ISP’s model

ISP’s network is a graph G=(V,E) Link utilization be due to background traffic on edge e Ie(i,j)=1 iff edge e is on the route from node i to j, determined by ISP’s

routing scheme

P2P’s model There are K P2P systems Uploading/downloading capacity for all peers with PID i: ui

k, dik

Traffic uploaded from PID-i peers to PID-j peers: tijk

Peering suggestion Allow a certain number of random connections to ensure

robustness


How iTracker Works – Computing Peering Suggestions (cont’d) Formulate as a joint optimization problem

ISP’s objective: minimize maximum link utilization P2P’s objective: maximize throughput Joint optimization: min max link utilization for ISP when P2P throughput is

maximized


How iTracker Works – Computing Peering Suggestions (cont’d) Naïve approach takes multiple

steps Get optimal throughput Topt

k for each P2P system k by solving its corresponding optimization problem individually

Solve the ISP optimization problem with constraints of each P2P system’s throughput being maximized

One-step approach through duality transformation Apply dual transformation to

P2P optimization problem Obtain a new optimization

problem by merging ISP and dual P2P problems


Roadmap

Motivation P4P framework

Design rationale System architecture Computing peering suggestions

Evaluations Conclusion and future work


Evaluation – Methodology Simulations

Discrete-event simulation a module for modeling BitTorrent protocol a module for modeling underlying network topology and data

transfer dynamics using TCP rate equation Network topology: PoP-level AT&T and Abilene

topologies Network routing: OSPF routing

PlanetLab experiments 53 Internet2 nodes on PlanetLab iTracker for Abilene network Use OSPF routing to re-construct traffic load on Abilene

links


Evaluation – Abilene Simulation Compared to P4P, native

P2P can result in 2x download completion

time 2x higher link utilization

Native P2P can result in some peers experiencing very long download completion time

Native P2P can result in much larger variance in link utilization


Evaluation – AT&T Simulation Compared to P4P, native

P2P can result in 1.6x download completion

time 3x higher link utilization

Some peers can experience very long download completion time with native P2P

Link utilization variance can be larger for native P2P


Evaluation – Liveswarms on Planetlab Liveswarms* is a P2P-based video streaming application,

which adapts BitTorrent protocol to video streaming context Run liveswarms on 53 PlanetLab nodes for 900 seconds

P4P and native liveswarms achieve roughly the same amount of throughput

P4P reduces link load Average link load saving is

34MB Maximum average link load

saving is 60% Native liveswarms:1Mbps P4P liveswarms: 432Kbps

*Michael Piatek, Colin Dixon, Arvind Krishnamurthy, Tom Anderson. LiveSwarms: Adapting BitTorrent for end host multicast. Technical report: UW-CSE-06-11-01


Conclusion and Future Work Our design achieves the objective

Scalability: iTracker is light-weight, maintains necessary states only

Privacy preservation Extensibility Robustness Performance improvement for both ISPs and P2P

Incremental deploymentability Implementation Incentives


Questions?


Backup Slides


Computation cost is low

Among 34K+ swarms, <1% have more than 100 leechers, and about1% swarms contribute to 50% of traffic demand

Solution time of the optimization problem is linear to number of swarms (slope ≈ 0.025)

Documents

P4P: Proactive Provider Assistance for P2P Haiyong Xie (Yale) [email protected] *This is a joint work with Arvind Krishnamurthy (UWashington) and Richard