P4P: Proactive Provider Assistance for P2P

1
P4P Proactive Provider Assistance for P2P

• Haiyong Xie (haiyong.xie_at_yale.edu)

Yale University
2
Roadmap

• Motivation
• P4P framework
• Design rationale
• System architecture
• Computing peering suggestions
• Evaluations
• Ongoing work

3
P2P The Significant Bandwidth Consumer

• Traffic
• Up to 60-70 of Internet traffic is contributed
  by P2P applications cachelogic
• Random peering causes traffic spread across PoPs
  and domains
• Problems
• Increased network resource usage (e.g., using
  bandwidth of more links)
• Increased network operational costs
• Degraded performance of other applications

4
Bandwidth Battle between ISPs and P2P

• The battle results in a lose-lose situation

5
Where is the Fundamental Problem?

• Traditional ISP feedback/control to application
  traffic
• Routing/TE
• Rate control through congestion feedback (packet
  drops)
• These are ineffective for P2P
• Due to highly dynamic, scattered traffic pattern
  caused by dynamic, unguided (network-oblivious)
  peer selection
• Need a mechanism for ISPs to communicate with P2P
  about network status and policies

6
Objective

• Design a framework to enable better ISP and P2P
  coordination
• ISPs and P2P jointly decide P2P peer selection
• ISPs guide the peering relationships in P2P
  systems to
• Improve throughput of P2P users
• Make it feasible to implement ISP policies (e.g.,
  intradomain TE, interdomain TE and cost
  optimization)

7
P4P Framework Design Rationale

• Performance improvement for both ISPs and P2P
• Scalability
• Support a large number of P2P users and networks
  in dynamic settings
• Privacy preservation
• Extensibility
• Application-specific requirements
• Tracker-based vs. trackerless P2P systems
• Gossip among peers
• Incremental deploymentability

8
Design For Tracker-based P2P

• 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 trusted third parties.
9
A Complete P4P Design

• iTrackers 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

10
Compute Suggested Peering Relationships

• Formulate as a joint optimization problem
• ISPs objective minimize maximum link
  utilization
• P2Ps objective maximize throughput
• Allow a certain number of random connections to
  ensure robustness
• Naïve approach takes multiple steps
• Compute optimal throughput for each P2P system
• Solve the ISP optimization problem with
  constraints of each P2P systems throughput being
  maximized
• One-step approach through duality transformation

min max link_utilization s.t. P2P throughput is
maximized
11
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 ATT 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

12
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

13
Evaluation ATT 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

14
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 liveswarms1Mbps
• 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
15
Summary and Ongoing Work

• Our design achieves the objective
• Performance improvement for both ISPs and P2P
• Scalability iTracker is light-weight, maintains
  necessary states only
• Privacy preservation
• Extensibility
• Robustness
• Ongoing work
• Evaluate the design through large-scale
  experiments
• More P2P application types (e.g., streaming and
  VoD)
• P4P for multiple domains

16
Questions?