Transcript P4P: Proactive Provider Assistance for P2P

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
1
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
P2P : The Significant Bandwidth Consumer
Bandwidth Battle between ISPs and P2P




ISPs try to “manage”
P2P tries to evade
P2P traffic
from being captured
Upgrade network infrastructure
Deploy P2P caching devices
Terminate connectivity
Limit Rate of P2P traffic


Use random ports

Encrypt traffic
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


Average P2P bit traverses 5.5 metro-hops


P4P reduced to 160 miles
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
5
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)
7
P4P Objectives

ISP perspective:

Guide applications to achieve more efficient network usage, e.g.,


Resource providers (e.g., caching, CDN, ISP)
perspective


Avoid undesirable (expensive/limited capacity) links to more desirable
(inexpensive/available capacity) links
Provide applications with on-demand resources/quality
P2P perspective:


Better performance for users
Dcreased incentive for ISPs to “manage” applications
8
P4P Enables Efficient Delivery
Traditional CDN
P2P
P2P with P4P
Internet Transit
Regional Routers
Edge Network
More Viewers =
Worse performance
Higher cost
More Viewers =
Better performance
Lower cost
Network Aware P2P will reduce costs, improve performance
9
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
Design For Tracker-based P2P

Use BitTorrent in a single
ISP as an example



appTracker
appTracker keeps P2P
system states
iTracker makes
suggestions for peering
relationships
iTracker
2
3
Information flow:




1. peer queries
appTracker
2. appTracker asks
iTracker for guidance
3. iTracker returns highlevel peering suggestions
4. appTracker selects
and returns a set of
active peers, according
to the suggestions
4
1
ISP A
peer
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
13
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
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
15
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
PID1

PID2
20
30
10
PID6
15
Benefit: simplicity and flexibility
Usage of “virtual cost”

70
PID5
60
PID3
10
PID4
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
16
Virtual Cost Interface: Applications’ View
 ISP computes the cost from
PID1
30
70
10
PID2
one PID to another
- link cost and routing
 PID-pair costs are perturbed
60 20
to increase privacy
PID6
PID3
PID5
PID4
Applications query costs of related
PID pairs, adjust traffic patterns to
place less load on more “expensive”
pairs
17
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

1.
2.
3.
4.
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.
23
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)


P2P traffic on top of the most utilized link(P2P bottleneck traffic)


The average number of backbone links that a unit of P2P traffic
traverses in an ISP’s network
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
24
25
BitTorrent on ISP-A: Completion Time
P4P achieves rate between latency-based localized and native BT.
26
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.
27
Abilene Experiment: Completion Time
-P4P achieves similar performance with localized at percentile
higher from 50%. P4P has a shorter tail.
28
Abilene Experiment: Charging Volume
Charging volume of the second link: native BT is
4x of P4P; localized BT is 2x of P4P
29
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
31
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
32
ISP Perspective: Average Hop Each Bit Traverses
5.5
0.89

Why less than 1: many transfers are in the same metroarea; same metro-area peers are utilized more by tit-for-tat.
Initial field test: Feb. 21 - Mar. 2, 2008
33
P2P Perspective: Completion Time
P4P improves completion time by 23%.
Initial field test: Feb. 21 - Mar. 2, 2008
34
Current P4P-WG: 70+ Members
ISP, P2P, Researcher. Scope includes business
processes, protocols, education, etc.
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
35
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
37