P4P: Provider Portal for Applications

Haiyong Xie, Y. Richard YangArvind Krishnamurthy, Yanbin Liu, Avi Silberschatz

SIGCOMM ’08

Hoon-gyu Choihgchoi@mmlab.snu.ac.kr

2008.10.06

Contents

• Introduction• P4P• Evaluation• Summary

23年 4月 21日 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

23年 4月 21日 MMLAB 3

Internet Protocol Breakdown 1993 - 2006

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

23年 4月 21日 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

23年 4月 21日 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

23年 4月 21日 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

23年 4月 21日 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

23年 4月 21日 MMLAB 8

P4P Architecture

• P4P Potential entities– iTracker: individual network providers– Peer: P2P clients– appTracker: P2P

• Each network provider maintains an iTracker

23年 4月 21日 MMLAB 9

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

23年 4月 21日 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.

23年 4月 21日 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

23年 4月 21日 MMLAB 12

An example of P4P information flows

• Information flow1. 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

23年 4月 21日 MMLAB 13

1 4

3

2appTracker

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

23年 4月 21日 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 native23年 4月 21日 MMLAB 15

Completion time Bottleneck 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 P4P23年 4月 21日 MMLAB 16

Completion time Charging 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

23年 4月 21日 MMLAB 17

Completion timeAverage 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

23年 4月 21日 MMLAB 18

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

23年 4月 21日 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

23年 4月 21日 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

23年 4月 21日 MMLAB 21