P4P: Proactive Provider Assistance for P2P

1. P4P: Proactive Provider Assistance for P2P Haiyong Xie (haiyong.xie@yale.edu) Yale University

2. Roadmap • Motivation • P4P framework • Design rationale • System architecture • Computing peering suggestions • Evaluations • Ongoing work NY P2P Meetup

3. http://www.cachelogic.com 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 NY P2P Meetup

4. ISPs try to “manage” P2P traffic P2P tries to evade from being captured • Upgrade network infrastructure • Deploy P2P caching devices • Terminate connectivity • Rate limit P2P traffic • Use random ports • Encrypt traffic Bandwidth Battle between ISPs and P2P • The battle results in a lose-lose situation NY P2P Meetup

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 NY P2P Meetup

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) NY P2P Meetup

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 NY P2P Meetup

8. pTracker iTracker 2 3 4 1 ISP A peer 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. NY P2P Meetup

9. iTracker 2 2 pTracker 1 1 ISP A Peer a Peer b 3 A Complete P4P Design • 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 NY P2P Meetup

10. Compute Suggested Peering Relationships • Formulate as a joint optimization problem • ISP’s objective: minimize maximum link utilization • P2P’s 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 system’s throughput being maximized • One-step approach through duality transformation min max link_utilization s.t. P2P throughput is maximized NY P2P Meetup

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 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 NY P2P Meetup

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 NY P2P Meetup

13. 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 NY P2P Meetup

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 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 NY P2P Meetup

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 NY P2P Meetup

16. Questions? NY P2P Meetup