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

22

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

3Internet Protocol Breakdown 1993 - 2006 Germany: 70% Internet traffic is P2

P, Ipoque Study 2007

44

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

66

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) or A content distribution provider (e.g., Akamai) or A caching provider (e.g., 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

1010

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

1111

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

1212

ISP A

Design For Tracker-based P2P

1 4

3

2appTracker iTracker

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 Maximizing

up/down link capacity usage

1414

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

PID1 PID2

PID3PID6

PID5 PID4

70

2030

10

6015 10

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

PID1 PID2

PID3PID6

PID5 PID4

70

20

30 10

60

Applications query costs of related PID pairs, adjust traffic patterns to place less load on more “expensive” pairs

1818

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 tk

ij for each pair of PIDs (i,j)

1. be, background traffic on edge e 2. ce, the capacity of edge e3. Ie(i, j), the indicator of edge e being on the route from PID i to j in the topology G.4. tk T∈ k , on link e

to minimize the Maximum Link Utilization (MLU)

1919

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.

2020

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

2121

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

2222

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

3030

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.

31

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

32

ISP-B : VerizonIngress to Verizon: Native is 53% higher than P4P

Egress from Verizon: Native is 70% higher than P4PIntradomain: Native is only 15% of P4P

33

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

34

P2P Perspective: Completion Time

P4P improves completion time by 23%.

Initial field test: Feb. 21 - Mar. 2, 2008

35

Current P4P-WG: 70+ Members

CoreGroup

AT&T Bezeq Intl BitTorrent

Cisco Systems Comcast

Grid Networks Joost

LimeWire

Manatt Oversi

Pando Networks PeerApp

Solid State Telefonica Group

Velocix VeriSign

Telecom ItaliaVerizon Vuze

University of Toronto Univ of

Washington Yale University

Observers

AbacastAHT Intl

AjauntySlantAkamai

Alcatel LucentCableLabsCablevisionCox Comm

Exa Networks

Juniper NetworksLariat Network

Level 3 Communications

Limelight NetworksMicrosoft

MPAANBC Universal

NokiaOrange

Princeton University

RawFlowRSUC/GweepNet

SaskTelSolana Networks

Speakeasy NetworkStanford University

ThomsonTime Warner CableTurner Broadcasting

UCLA

ISP, P2P, Researcher. Scope includes business processes, protocols, education, etc.

3636

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