P4P: Provider Portal for Applications Haiyong Xie, Y. Richard Yang Arvind Krishnamurthy, Yanbin Liu, Avi Silberschatz SIGCOMM ’08 Hoon-gyu Choi

Contents Introduction P4P Evaluation Summary MMLAB 2

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 MMLAB 3 Internet Protocol Breakdown Ipoque Study 2007

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 4

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 5

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 6

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 7

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 8

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

P4P iTracker iTracker –A portal for each network resource provider –Allows P4P to divide traffic control responsibilities between applicati ons 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 10

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 11

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 12

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 appTracker iTracker peer

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 14

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 MMLAB 15 Completion timeBottleneck link utilization

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 MMLAB 16 Completion timeCharging volumes

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 MMLAB 17 Completion time Average Unit BDP

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 18

References Open P4P – Yale P4P – P4P Working group, – MMLAB 19

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 20

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 21