1 / 16

P4P: Proactive Provider Assistance for P2P

P4P: Proactive Provider Assistance for P2P. Haiyong Xie (haiyong.xie@yale.edu). Yale University. Roadmap. Motivation P4P framework Design rationale System architecture Computing peering suggestions Evaluations Ongoing work. http://www.cachelogic.com.

frayne
Download Presentation

P4P: Proactive Provider Assistance for P2P

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related