1 / 21

P4P: Provider Portal for Applications

P4P: Provider Portal for Applications. Haiyong Xie, Y. Richard Yang Arvind Krishnamurthy, Yanbin Liu, Avi Silberschatz SIGCOMM ’08 Hoon-gyu Choi hgchoi@mmlab.snu.ac.kr 2008.10.06. Contents. Introduction P4P Evaluation Summary. P2P: Bandwidth usage.

avani
Download Presentation

P4P: Provider Portal for Applications

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: Provider Portal for Applications Haiyong Xie, Y. Richard Yang Arvind Krishnamurthy, Yanbin Liu, Avi Silberschatz SIGCOMM ’08 Hoon-gyu Choi hgchoi@mmlab.snu.ac.kr 2008.10.06

  2. Contents • Introduction • P4P • Evaluation • Summary MMLAB

  3. P2P: Bandwidth usage • Up to 70% of Internet traffic is contributed by P2P applications • However, the emerging P2P applications expose significant new challenges to Internet traffic control Ipoque Study 2007 Internet Protocol Breakdown 1993 - 2006 MMLAB

  4. P2P Problem: Network inefficiency • Network-oblivious P2P applications may not be network efficient • Verizon • Average P2P bit traverses 1000 miles • Average P2P bit traverses 5.5 metro-hops • Karagiannis et al., BitTorrent on a University network (2005) • 50%-90% of existing local pieces in active users are downloaded externally MMLAB

  5. Attempts to address P2P Problems • ISP Approaches • Increase capacity • Pricing • Rate limit/terminate P2P traffic • Deploy P2P caching devices • P2P Approaches • Locality aware P2P MMLAB

  6. P2P Problem: Inefficient interactions • ISP optimizer interacts poorly with adaptive P2P • ISP • Traffic engineering to change routing to shift traffic away from highly utilized links • Adaptive P2P • Adapt their traffic to changes in the network • Resulting in potential oscillations in traffic patterns and sub-optimal routing decisions • Traditional Internet architectural feedback to applications is limited • Emerging P2P applications can have tremendous flexibility in shaping how data is communicated • The network needs to provide more information and feedback to most effectively utilize this flexibility for improving network efficiency MMLAB

  7. P4P • Design a framework to enable better providers and applications cooperation • P4P: provider portal for (P2P) applications • A provider can be • A traditional ISP (e.g., AT&T, Verizon) • A content distribution provider (e.g., Akamai) • A caching provider (e.g., PeerApp) • Open standard • Any ISP, provider, application can easily implement it MMLAB

  8. P4P Objectives • ISP perspective • Guide applications to achieve more efficient network usage, e.g., • Avoid undesirable (expensive/limited capacity) links to more desirable (inexpensive/available capacity) links • Resource providers (e.g., caching, CDN, ISP) perspective • Provide applications with on-demand resources/quality • P2P perspective • Better performance for users • Decreased incentive for ISPs to “manage” applications MMLAB

  9. P4P Architecture • P4P Potential entities • iTracker: individual network providers • Peer: P2P clients • appTracker: P2P • Each network provider maintains an iTracker MMLAB

  10. P4P iTracker • iTracker • A portal for each network resource provider • Allows P4P to divide traffic control responsibilities between applications and network providers • Makes P4P incrementally deployable and extensible • iTracker of a provider can be identified in various ways • e.g., through DNS query • iTracker can be run by trusted third parties • Examples of iTracker interfaces • Policy interface • Allows applications to obtain the usage polices of a network • Provider capabilities interface • Allows peers to request network providers’ capabilities • P4P-distance (Virtual cost) interface • Allows others to query costs and distances between peers MMLAB

  11. P4P distance • P4P-distance reflect the network’s status and preferences regarding application traffic • P4P-distance should be • Simple, intuitive, … • An ISP can assign P4P-distance in a wide variety of ways • OSPF weights and BGP preferences • Considering financial costs or approaching congestion • ETC. MMLAB

  12. The P4P-distance Interface: two views • Networks’ view seen by an iTracker • The higher the price, the more “cost” to the ISP if an application uses the link • Reflects both network status and policy, e.g., • Higher prices on links with highest util. or higher than a threshold • OSPF weights • Applications’ view seen by applications • Applications adjust traffic patterns to place less load on more expensive P2P node pairs • Both ISP and Application can use this interface in a variety of ways MMLAB

  13. appTracker iTracker 2 3 4 1 peer An example of P4P information flows • Information flow 1. peer queries appTracker 2/3. appTracker asks iTracker for virtual cost (occasionally) 4. appTracker selects and returns a set of active peers, according to both application requirements and iTracker information MMLAB

  14. Evaluation Methodology • Network Topologies • Internet experiments on Abilene and ISP-B • Simulations on PoP(Point of Presence)-level topologies of Abilene and major tier-1 ISPs • Applications • BitTorrent, Liveswarms (streaming) and Pando (commercial) • Performance Metrics • Completion time • P2P bandwidth-distance product (BDP) • P2P traffic on top of the most utilized link • Charging volume MMLAB

  15. Evaluation for Intra-domain • Simulation using Bit Torrent on ISP-A • P4P achieves rate between latency-based localized and native • The utilization of P4P is less than one-half of localized, which achieves lower than native Completion time Bottleneck link utilization MMLAB

  16. Evaluation for Inter-domain • Experiments using BitTorrent on Abilene • P4P achieves similar application performance with localized; but P4P has a shorter tail. • For the charging volume of the second link: native is 4x of P4P; delay-localized is 2x of P4P Completion time Charging volumes MMLAB

  17. Evaluation – Field Tests • Field Tests on ISP-B against Native (Pando) • P4P achieves approximately 5 times in unit BDP • ISP Perspective • P4P improves average completion time by 23%. • P2P Perspective Average Unit BDP Completion time MMLAB

  18. Summary • P4P: provider portal for (P2P) applications • Simple and flexible framework • Explicit cooperation between P2P and network providers • P4P can be a promising approach to improve both application performance and provider efficiency MMLAB

  19. References • Open P4P • http://www.openp4p.net/ • Yale P4P • http://cs-www.cs.yale.edu/homes/yong/p4p.html • P4P Working group, • http://www.dcia.info/activities/p4pwg/membership.html MMLAB

  20. Discussions • What are the incentives for P2P to participate in P4P? • Better network efficiency • P2P by playing nice could avoid being blocked by ISPs • P4P leaves much flexibility for P2P • Benefits the overall society • Why cannot P2P achieves the benefits of P4P by itself? • Probing the network to reverse engineer information such as topology and status is difficult • Cost and policy is difficult to reverse engineer MMLAB

  21. Discussions • Does P4P violate network neutrality? • ISPs and P2P applications mutually agree to participate in P4P • How can it be feasible for P4P to orchestrate all these networks? • iTracker interfaces are light-weight and do not handle per-client application • Do the locality-aware P4P techniques reduce robustness? • P4P does not limit the mechanisms for improving robustness • If iTrackers are down, P2P applications can still make default application decisions MMLAB

More Related