1 P4P: Provider Portal for Applications Haiyong Xie( 謝海永 )† Y. Richard Yang† *Arvind Krishnamurthy Yanbin Liu§ Avi Silberschatz† †Yale University *University of Washington §IBM T.J. Watson SIGCOMM 2008, AUGUST 17-22, SEATTLE, WA, USA

2 2 Outlines  Motivation  P4P Framework  Implementation  Evaluation  Summary

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 3 Internet Protocol Breakdown Germany: 70% Internet traffic is P2P, Ipoque Study 2007

4 4 P2P : The Significant Bandwidth Consumer The battle results in a lose-lose situation ISPs try to “manage” P2P traffic  Upgrade network infrastructure  Deploy P2P caching devices  Terminate connectivity  Limit Rate of P2P traffic P2P tries to evade from being captured  Use random ports  Encrypt traffic Bandwidth Battle between ISPs and P2P

5 P2P Problem : Network Inefficiency Network-oblivious P2P applications may not be network efficient  Verizon Average P2P bit traverses 1000 miles  P4P reduced to 160 miles Average P2P bit traverses 5.5 metro-hops  P4P reduced to 0.89 metro-hops  Karagiannis et al. on BitTorrent, a university network (2005) 50%-90% of existing local pieces in active users are downloaded externally

6 6 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 application cooperation Network status Policy…

7 P4P Mission Design a framework to enable better providers and applications cooperation  ISP perspective: guide applications to achieve more efficient network usage  P2P perspective: better user experiences Open standard: any ISP, provider, application can easily implement it P4P: provider portal for (P2P) applications  A provider can be A traditional ISP (e.g., AT&T, Verizon) orVerizon A content distribution provider (e.g., Akamai) orAkamai A caching provider (e.g., PeerApp)PeerApp

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  Dcreased incentive for ISPs to “manage” applications

9 8 Edge Network Regional Routers Internet Transit Network Aware P2P will reduce costs, improve performance Traditional CDN P2P More Viewers = Better performance Lower cost More Viewers = Worse performance Higher cost P4P Enables Efficient Delivery P2P with P4P

10 P4P Framework P4P consists of  Control plane - introduces iTrackers as portals (the focus of this paper) iTrackers: a portal for each network resource providers  The tracker is responsible to help the peers find each other and to keep the download/upload statistics of each peer. The tracker returns a random list of peers. 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  Management plane - to monitor the behavior in the control plane  Data plane (optional) applications mark importance of traffic routers mark packets to provide faster, fine-grained feedbacks

11 Design For Tracker-based P2P P4P Potential entities  iTracker: individual network providers  Peer: P2P clients  appTracker: P2P Each network provider maintains an iTracker The iTracker provides a portal for information regarding the network provider.  The policy interface : to obtain the usage policies  The p4p-distance interface : to query costs and distance between peers  The capability interface : to request network providers’ capabilities

12 ISP A Design For Tracker-based P2P appTrackeriTracker peer Use BitTorrent in a single ISP as an example  appTracker keeps P2P system states  iTracker makes suggestions for peering relationships Information flow:  1. peer queries appTracker  2. appTracker asks iTracker for guidance  3. iTracker returns high- level peering suggestions  4. appTracker selects and returns a set of active peers, according to the suggestions iTracker can be run by trusted third parties.

13 A Motivating Example ISP objective:  Minimize maximum link utilization (MLU) P2P objective:  Optimize P2P completion time  M aximizing up/down link capacity usage

14 The p4p-distance Interface Topology G = (V,E)  A node in V is referred to as a PID (opaque ID).  To map its IP address to its PID and AS (Autonomous System) number. iTracker reveals the p-distance p i j from PID-i to PID-j. P-Distance is used as  Ranks  Black-box Peer Selection

15 The P4P Framework: Control Plane iTracker: a portal for each network resource provider (iPortal) An iTracker provides multiple interfaces  Static topology / policy  Provider capability  Virtual cost  … iTracker of a provider can be identified in multiple ways e.g., through DNS SRV records iTracker can be run by trusted third parties iTracker access protected by access control

16 Virtual Cost Interface: Network’ Internal View Terms  PIDs: set of nodes each called a PID  E: set of links connecting PIDs  p e : the “virtual cost” of link e Benefit: simplicity and flexibility Usage of “virtual cost”  can be used to rank peers, or converted to peering weights  reflects both network status and policy, e.g., OSPF weights higher prices on links with highest util. or higher than a threshold congestion volume PID1PID2 PID3PID6 PID5PID

17 Virtual Cost Interface: Applications’ View  ISP computes the cost from one PID to another - link cost and routing  PID-pair costs are perturbed to increase privacy PID1PID2 PID3PID6 PID5PID Applications query costs of related PID pairs, adjust traffic patterns to place less load on more “expensive” pairs

18 P4P-Distance as an optimization decomposition interface Theoretical foundation behind the interface design in ISP traffic engineering objective  Assume K applications running inside the ISP  Let T k be the set of acceptable traffic patterns for application k an element t k in T k specifies a traffic demand matrix t k ij for each pair of PIDs (i,j) 1. b e, background traffic on edge e 2. c e, the capacity of edge e 3. I e (i, j), the indicator of edge e being on the route from PID i to j in the topology G. 4. t k ∈ T k, on link e to minimize the Maximum Link Utilization (MLU)

19 P4P-Distance as an optimization decomposition interface Solution  The problem is naturally decomposed into independent problems for individual application sessions  To pick t k among the set T k, of all acceptable traffic pattern, so that Σ e p e t e k is minimized  not only for MLU, but also for several other common ISP objectives.

20 P4P Implementation-iTrack static p-distances and dynamic p-distances For dynamic p-distances, update its p-distances every T seconds  Intradomain p-distances is relatively straightforward  Interdomain p-distances need to estimate the virtual capacity v e available for P4P controlled traffic  use the sliding window approach to predict v e

21 P4P Implementation-appTrack Integrated P4P with the application trackers (appTrackers) of BitTorrent, Liveswarms and Pando Only change to client software is to collect experimental statistics

22 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

23 Figure 1: Abilene backbone and PlanetLab sites using Abilene.

24 Evaluation Methodology Applications  BitTorrent, Liveswarms (streaming) and Pando (commercial) Performance Metrics  Completion time: the total time for a swarm of peers to finish downloading a file  P2P unit bandwidth-distance product (BDP) The average number of backbone links that a unit of P2P traffic traverses in an ISP’s network  P2P traffic on top of the most utilized link(P2P bottleneck traffic) The total P2P traffic on the most utilized link in a network  Charging volume This metric is only used in interdomain settings. We compute it using the 95-percentile charging model. 24

25

26 BitTorrent on ISP-A: Completion Time P4P achieves rate between latency-based localized and native BT.

27 BitTorrent on ISP-A: Bottleneck Link Utilization (swarm size is 700) The utilization of P4P is less than one-half of localized, which achieves lower than native. Native Localized P4P

28 Abilene Experiment: Completion Time -P4P achieves similar performance with localized at percentile higher from 50%. P4P has a shorter tail.

29 Abilene Experiment: Charging Volume Charging volume of the second link: native BT is 4x of P4P; localized BT is 2x of P4P

30 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 *[22]Michael Piatek, Colin Dixon, Arvind Krishnamurthy, Tom Anderson. LiveSwarms: Adapting BitTorrent for end host multicast. Technical report: UW-CSE , University of Washington, 2006.

31 P4P Field Tests Initial field test: Feb Mar. 2, 2008 P2P: Pando, 20 Mbytes video to 1.25 million users opted in for newsletters Peers partitioned into: Native, P4P Run iTracker at Yale for Verizon  One load-balancer, two iTrackers (for fault tolerance)  iTracker maps “virtual price” to peering weight directly  iTracker objective: MLU  Verizon: static map and user capacity type

32 ISP-B : Verizon Ingress to Verizon: Native is 53% higher than P4P Egress from Verizon: Native is 70% higher than P4P Intradomain: Native is only 15% of P4P

33 ISP Perspective: Average Hop Each Bit Traverses Why less than 1: many transfers are in the same metro- area; same metro-area peers are utilized more by tit-for-tat. Initial field test: Feb Mar. 2, 2008

34 P2P Perspective: Completion Time P4P improves completion time by 23%. Initial field test: Feb Mar. 2, 2008

35 Current P4P-WG: 70+ Members Core Group AT&T Bezeq Intl BitTorrent Cisco Systems Comcast Grid Networks Joost LimeWire Manatt Oversi Pando Networks PeerApp Solid State Telefonica Group Velocix VeriSign Telecom Italia Verizon Vuze University of Toronto Univ of Washington Yale University Observers Abacast AHT Intl AjauntySlant Akamai Alcatel Lucent CableLabs Cablevision Cox Comm Exa Networks Juniper Networks Lariat Network Level 3 Communications Limelight Networks Microsoft MPAA NBC Universal Nokia Orange Princeton University RawFlow RSUC/GweepNet SaskTel Solana Networks Speakeasy Network Stanford University Thomson Time Warner Cable Turner Broadcasting UCLA ISP, P2P, Researcher. Scope includes business processes, protocols, education, etc.

36 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 P2P application performance and provider efficiency

37 References [1] V. Aggarwal, A. Feldmann, and C. Scheideler. Can ISPs and P2P systems cooperate for improved performance? ACM CCR, July [3] A. Bharambe, C. Herley, and V. Padmanabhan. Analyzing and improving a BitTorrent network’s performance mechanisms. In Proceedings of IEEE INFOCOM ’06, Barcelona, Spain, Apr [21] Pando Networks, Inc. [22] M. Piatek, C. Dixon, A. Krishnamurthy, and T. Anderson. Liveswarms: Adapting bittorrent for end host multicast. Technical Report UW-CSE , University of Washington, [35] H. Wang, H. Xie, L. Qiu, A. Silberschatz, and Y. R. Yang. Optimal ISP subscription for Internet multihoming: Algorithm design and implication analysis. In Proceedings of IEEE INFOCOM ’05, Miami, FL, Apr