370 likes | 526 Views
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. Outlines. Motivation P4P Framework
E N D
P4P: Provider Portal for Applications Haiyong Xie(謝海永)† Y. Richard Yang† *Arvind KrishnamurthyYanbin Liu§ Avi Silberschatz† †Yale University *University of Washington §IBM T.J. Watson SIGCOMM 2008, AUGUST 17-22, SEATTLE, WA, USA
Outlines • Motivation • P4P Framework • Implementation • Evaluation • Summary 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 Internet Protocol Breakdown 1993 - 2006 Germany: 70% Internet traffic is P2P, Ipoque Study 2007 3
ISPs try to “manage” P2P traffic P2P tries to evade from being captured • Upgrade network infrastructure • Deploy P2P caching devices • Terminate connectivity • Limit Rate of P2P traffic • Use random ports • Encrypt traffic P2P : The Significant Bandwidth Consumer Bandwidth Battle between ISPs and P2P • The battle results in a lose-lose situation 4
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
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… 6
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) or • A content distribution provider (e.g., Akamai) or • A caching provider (e.g., PeerApp)
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
P4P Enables Efficient Delivery P2P P2P with P4P Traditional CDN Internet Transit Regional Routers Edge Network More Viewers = Better performance Lower cost More Viewers = Worse performance Higher cost Network Aware P2P will reduce costs, improve performance 8
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 10
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 11
appTracker iTracker 2 3 4 1 ISP A peer Design For Tracker-based P2P • Use BitTorrent in a single ISP as an example • appTracker keeps P2P system states • iTrackermakes 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. 12
A Motivating Example • ISP objective: • Minimize maximum link utilization (MLU) • P2P objective: • Optimize P2P completion time Maximizing up/down link capacity usage
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 pi jfrom PID-i to PID-j. • P-Distance is used as • Ranks • Black-box Peer Selection 14
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
Virtual Cost Interface: Network’ Internal View 70 PID1 PID2 20 30 10 PID6 PID3 10 15 60 PID5 PID4 • Terms • PIDs: set of nodes each called a PID • E: set of links connecting PIDs • pe: 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
Virtual Cost Interface: Applications’ View PID1 PID2 70 10 30 20 60 PID6 PID3 PID5 PID4 • ISP computes the cost from one PID to another • link cost and routing • PID-pair costs are perturbed to increase privacy Applications query costs of related PID pairs, adjust traffic patterns to place less loadon more “expensive” pairs
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 Tk be the set of acceptable traffic patterns for application k • an element tk in Tk specifies a traffic demand matrix tkij for each pair of PIDs (i,j) • be, background traffic on edge e • ce, the capacity of edge e • Ie(i, j), the indicator of edge e being on the route from PID i to j in the topology G. • tk ∈ Tk , on link e to minimize the Maximum Link Utilization (MLU) 18
P4P-Distance as an optimization decomposition interface • Solution • The problem is naturally decomposed into independent problems for individual application sessions • To pick tk among the set Tk, of all acceptable traffic pattern, so that Σe petek is minimized • not only for MLU, but also for several other common ISP objectives. 19
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 ve available for P4P controlled traffic • use the sliding window approach to predict ve 20
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 21
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 22
Figure 1: Abilene backbone and PlanetLab sites using Abilene.
Evaluation Methodology • Applications • BitTorrent, Liveswarms (streaming) and Pando (commercial) • Performance Metrics • Completion time: the total time for a swarm of peers to finishdownloading a file • P2P unit bandwidth-distance product (BDP) • The average numberof backbone links that a unit of P2P traffic traverses in anISP’s network • P2P traffic on top of the most utilized link(P2P bottleneck traffic) • The total P2Ptraffic 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
BitTorrent on ISP-A: Completion Time P4P achieves rate between latency-based localized and native BT.
BitTorrent on ISP-A: Bottleneck Link Utilization (swarm size is 700) Native Localized P4P The utilization of P4P is less than one-half of localized, which achieves lower than native.
Abilene Experiment: Completion Time • P4P achieves similar performance with localized at percentile higher from 50%. P4P has a shorter tail.
Abilene Experiment: Charging Volume Charging volume of the second link: native BT is 4x of P4P; localized BT is 2x of P4P
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-06-11-01 , University of Washington, 2006. 30
P4P Field Tests • Initial field test: Feb. 21 - 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
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
ISP Perspective: Average Hop Each Bit Traverses 5.5 0.89 • 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. 21 - Mar. 2, 2008
P2P Perspective: Completion Time P4P improves completion time by 23%. Initial field test: Feb. 21 - Mar. 2, 2008
Current P4P-WG: 70+ Members ISP, P2P, Researcher. Scope includes business processes, protocols, education, etc.
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 36
References • [1] V. Aggarwal, A. Feldmann, and C. Scheideler. Can ISPs and P2P systems cooperate for improved performance? ACM CCR, July 2007. • [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. 2006. • [21] Pando Networks, Inc. http://www.pandonetworks.com. • [22] M. Piatek, C. Dixon, A. Krishnamurthy, and T. Anderson. Liveswarms: Adapting bittorrent for end host multicast. Technical Report UW-CSE-06-11-01, University of Washington, 2006. • [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. 2005. • http://www.openp4p.net/ • http://cs-www.cs.yale.edu/homes/yong/p4p.html