1 / 15

P4P: Towards Cooperation between P2P and ISPs

P4P: Towards Cooperation between P2P and ISPs. Haiyong Xie (Yale) Arvind Krishnamurthy (U. Washington) Avi Silberschatz (Yale) Y. Richard Yang (Yale). 2007-7-25. http://www.cachelogic.com. P2P Content Distribution.

karlyn
Download Presentation

P4P: Towards Cooperation between P2P and ISPs

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: Towards Cooperation between P2P and ISPs Haiyong Xie (Yale) Arvind Krishnamurthy (U. Washington) Avi Silberschatz (Yale) Y. Richard Yang (Yale) 2007-7-25

  2. http://www.cachelogic.com P2P Content Distribution • Traffic volume: up to 60-70% of Internet traffic is contributed by P2P applications [cachelogic] • Traffic pattern: random peering (e.g., BitTorrents) 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 to other applications P4PWG July Meeting

  3. 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 • Uses random ports • Encrypts traffic Bandwidth Battle between ISPs and P2P • The battle results in a lose-lose situation P4PWG July Meeting

  4. Where is the Fundamental Problem? • Traditional ISP application feedback/control: • Routing/traffic engineering (TE) • Rate control through congestion feedback (packet drops) • Ineffective for P2P • due to highly dynamic, scattered traffic pattern caused by dynamic, unguided (network-oblivious) peer selection Objective: design a framework to enable better ISP and P2P cooperation P4PWG July Meeting

  5. 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 • ISP contribution for P2P acceleration P4PWG July Meeting

  6. The P4P Framework • P4P: proactive provider participation for P2P; P2P for providers; provider portal for P2P, … • Two components • Control plane • iTrackers: an ISP portal for P2P and content providers • Three levels: • Network status:e.g., network topology • ISP policy and guideline: e.g., traffic balance ratio for inter-AS peering links, time of day preference • ISP capabilities: e.g., QoS, CoS, ISP servers participation in content distributions • Data plane [optional] • Routers on data paths provide fine-grained, ISP policy-based feedbacks, e.g., utilize TCP ECN bit or feedback fields in an overlay packet header P4PWG July Meeting

  7. appTracker iTracker B 1 1 2 2 iTracker A 3 3 [4] b ISP A ISP B a P4P Control Path: Obtain Network Status/Policy An iTracker for each ISP. 1: Peer queries iTracker of local ISP to obtain network status/policy 2,3: Tracker-based: peer reports status/policy to appTracker; appTracker selects peering set considering both ISP status/policy and application requirements [4]: Trackerless: peers exchange information and make peering decisions P4PWG July Meeting

  8. P4P Control Path : Request Capability 6 appTracker 5 iTracker B iTracker A b a appTracker/content provider requests ISP capabilities to accelerate content distribution. 7 ISP A ISP B 5: appTracker [content provider] requests ISP B’s participation in content distribution 6: ISP B allocates servers to accelerate content distribution 7: appTracker includes ISP B’s servers in returned peering sets to peers Note: this can be extended to handle trackerless systems, as we did in the previous slide 2007-7-25 8 P4PWG July Meeting

  9. P4P Framework: Data Path [optional] ISP A ISP B b a Routers mark packets to provide faster, fine-grained feedbacks, e.g., virtual capacity to optimize multihoming cost and performance Peers adjust traffic rates according to feedbacks 2007-7-25 9 P4PWG July Meeting

  10. Test Plan for P4P • Measurement study with Pando (in progress) • Evaluate P2P self-adaptation schemes (in progress) • Generate best practices for P2P design • Serve as comparison basis • iTracker (in progress) • Network information (roughly completed) • ISP policy and guideline (in progress) • ISP capability (in progress) • Data path (in progress) • Evaluate P4P design with Pando and Verizon (in progress) P4PWG July Meeting

  11. Preliminary Results • 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 • Internet experiments • 53 Internet2 nodes on PlanetLab • iTracker for Abilene network • Use OSPF routing to re-construct traffic load on Abilene links P4PWG July Meeting

  12. Evaluation – BitTorrent on Abilene • 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 P4PWG July Meeting

  13. Evaluation – BitTorrent on AT&T • 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 P4PWG July Meeting

  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 P4PWG July Meeting

  15. Contact and Acknowledgement For further details, please refer to our technical report Yale/DCS TR-1377 It is still a work-in-progress and changes rapidly Questions/comments are highly welcome: Haiyong Xie (haiyong.xie@yale.edu) Y. Richard Yang (yry@cs.yale.edu) Acknowledgements We would like to thank Charles Kalmanek (AT&T Labs), Marty Lafferty (DCIA), Doug Pasko (Verizon), Laird Popkin (Pando), Keith Ross (Polytechnic), Ke Xu (Tsinghua Univ.) for suggestions, discussions and feedback. 2007-7-25 15 P4PWG July Meeting

More Related