1

P4P - Provider Portal for Applications

Based On The ArticleHaiyong Xie, Y. Richard Yang, Arvind Krishnamurthy,

Yanbin Liu and Avi Silberschatz , P4P: Provider Portal for Applications

Presented By Arkadi Butman

2

Main topics P2P and the ISP – Love & Hate Current disadvantages of P2P (bittorrent) What is the status today? What is P4P Possible autonomous improvements of P2P P4P description P4P testing & results P4P disadvantages \ setbacks.

3

ISP traffic over the years

4

P2P & ISP – Love?

The life of the ISP without P2P: Marketing high-speed (expensive)

connection Large Throughput. Per-traffic

charging Premium services Do we really need all of the above

with no P2P content? .

5

P2P & ISP – Hate?

P2P impact on ISP: Application left running 24/7 Causes high throughput Data mostly extern \ from abroad Tough to detect P2P traffic Caching traffic is a problematic solution Causes Real-time applications

performance decrease.

6

Current disadvantages of P2P (bittorrent)

Peers are selected randomly, not considering:

Traffic load Link cost Geographic location Link type (inner vs cross-ISP) Even when selecting “good” peers, rate

distribution is not smartly selected.

7

Current disadvantages of P2P (bittorrent)

Random peer selection causes: Peering with external users when

data exists locally ISP cannot control source selection

but only load distribution Leads to application low

performance Increases ISP costs.

8

What is the status today?

ISP needs to handle large amounts of P2P traffic

Maintain network neutrality? USA - Comcast and the FCC Traffic shaping Caching Total capacity limitations.

9

Traffic Statistics - Cache

10

Traffic Statistics - Filter

11

What is P4P?

P4P is a cooperation between ISP and P2P, with focus on:

Smart peer selection Better traffic distribution Higher transfer speed Lower ISP costs But, do we really need such

cooperation? .

12

Possible autonomous improvements of P2P

In other words – do we really need ISP cooperation? Why don’t we just select peers by:

Estimated geographic location Low hop-distance Low latency CDN selection

13

Possible autonomous improvements of P2P

Needs information P2P application cannot “learn”, as

Network topology Congestion status Link cost Policies Reverse engineering is difficult or

even impossible.

14

Back to P4P – an example

15

P4P – Main Ideas

Provides multiple interfaces: Network info Network policy “P4P distance” measurement Network capabilities Data queried using iTrackers, that

provide the corresponding information.

16

iTrackers

Operated by ISP Divides responsibility between ISP

and application Each ISP has it’s own iTracker Provides relevant information

regarding the ISP (via the Interfaces) and the current network status.

17

iTrackers - Query

18

iTrackers – The big picture

19

Interface Requirements Simple. Allow application understand

network language Fine Grained. Information is detailed

enough to allow effective optimization Modular. Not specific for application\

network Scalable. Allow cache and Aggregation Private. Not revealing info regarding users Neutral. ISP neutrality can be verified.

20

P4P-distance – Core of P4P Represents the “costs” of the link Updated by ISP according to: load,

geographic distance, link price Retrieved by application and used for peer

selection The Network Can be pictured as a Graph

(V,E) where V is the users and E is the links (which are p4p-distance weighted). Each vertex of the graph is given some ID for further queries.

We denote distance between vertex i & j by pij.

21

P4P distance – ISP and User

The P4P distance is the communication standard between the ISP and the Application

2 main questions arise: How does the ISP compute the

distance? How does the application (bittorent

client) use the distance?.

22

ISP Point of View - Weights

How do we assign weights? Derive from BGP / OSPF weights Give higher weight for high-cost

links Give higher weight for congested

links Use some iterative optimization.

23

ISP point of view - Granularity

What is the graph vertex object? Let’s give each user a unique ID

(each vertex is a user) Lets Give each ISP an ID What about the weights? Let’s give sequential grades (1,2,3,…) Let’s give complex accumulated

weights.

24

Application Point of View How do we use weights obtained from

ISP? Peer i will select peer j with probability

according to pij (using some decreasing function)

Set some coefficient sij as a lower bound for traffic percentage from peer i

Start with peers with weight <=k and add k+1 if performance is low

Since applications tend to build some connectivity spanning tree – run multiple times and select one with lowest weight.

25

ISP & Application Goals Usually, Application simply wants to optimize

Up/Down traffic with disregard to ISP, I.E.

ISP wants to minimize “damage” of traffic, while maintaining reasonable performance

“t” stands for session “k” traffic from ID “i” to “j”

“u” is upload capacity “d” is download capacity

pij is cost of link between from i to j

B is some percentile (constant)

OPT is optimal total traffic

26

Before We Dive In – Some Notations

be – background traffic in edge e (not P2P) ce – capacity of edge (link) e Ie(i,j) – indicator whether edge e is on the

route for i to j in the topology Tk – set of acceptable traffic demand for

session k tk – some specific traffic distribution of Tk

tkij – the amount of traffic from ID i to j

under selection of specific tk

tke – the amount of traffic on edge (link) e.

27

ISP Objectives

ISP may define different objectives regarding the traffic distribution

Let’s pick a specific widespread objective (MLU) and demonstrate the corresponding optimization

Then, we consider the differences under other objectives.

28

Traditional ISP objective Traditional ISP objective is to minimize

the maximum link utilization (MLU)

Well, this is problematic since each session has to share all information, which makes it quite infeasible

Instead, we rewrite our demands to allow a feasible solution.

29

Tradition ISP objective - cont We want to minimize some constant (a),

that indicated the load on each edge

Using Lagrange multipliers we create the variables pe and try to find the minimum of the following equation:

30

Tradition ISP objective - cont Since the pe variables are non-negative, the (a)

parameter is non negative, to achieve minimum of D, and to keep it finite, we want to bring the coefficient of (a) to be zero, i.e.

Resulting:

What is the importance of the result? It states that the whole problem can be decomposed into independent problems for individual sessions! .

31

Application & iTracker Iterative “game”

The application receives coefficients The application optimizes the value The application sends to the iTracker the

selected optimization The iTracker recalculates the load

distribution and sets new coefficients pe

How does the iTracker calculate the values? Using gradients.

32

Application & iTracker Iterative “game” - cont But what if we don’t want to optimize

MLU but something else? ISP might have several other objectives Bandwidth-Distance Product Interdomain Multihoming Cost Control Other objectives also exist

33

Bandwidth-Distance Product Some distance metric (value) de is

assigned for each link Distance is summed up across the

route Objective is defined by minimizing the

weighted traffic sum:

In the simple case of d=1 for each edge, it represents simple hop-count.

34

Interdomain Multihoming Cost Control Most non tier-1 ISP pay other providers for traffic Inter-ISP traffic should be decreased ISPs are usually charged using the “percentile”

model Denote by ve, the capacity for P2P traffic on link e If we can bound the traffic to some ve, we ensure

that the ISP cost will remain the same ISP objective can be summarized by:

35

Testings of P4P

iTracker Implementation AppTracker locality-based Peers Results Conclusions

36

iTracker Implementation P-Distances are dynamic, recalculated each T

seconds Predict future charging by “q” percentile Simply using the “last I intervals” for small “I”

values did not work well enough Using a larger set of samples (~month) to prevent

under\over utilization Predict total traffic volume according to previous

data Use the future charging & traffic estimations to

calculate the virtual capacity of the link

37

AppTracker locality-based Peers Usually, the appTracker randomly selects

peers Here, we used locality based selection by:

similar ID (best), similar AS (good), outside AS (worst)

Try to select up to 70% percent from similar ID Try to select up to 80% percent from similar

AS Don’t use these tactics if p-distances “outside”

are lower than “inside” (ID \ AS)

38

Evaluation Metrics To evaluate the performance of the P4P,

the following metrics are used: Completion Time (application

performance) Bandwidth-Distance Product (ISP

performance). P2P traffic on most utilized link (ISP

performance) Charging volume (ISP Performance)

39

1st Private Experiment

We try to simulate a network: Construct a private network Each link is 100Mbps symmetric Each swarm shares an 256MB file Each swarm has initial 1 seeder

with 1 Gbps upstream link speed

40

2nd Public Experiment Integrate some P4P users to the public

network (P4P users are a small part of all users)

We compare 3 types of appTrackers: regular, locality based (by round trip time) and P4P

A 12MB file is shared among the users Each initial seeder has 100KBps upload

bandwidth

41

2nd Public Experiment – cont We randomly select 160 university

nodes for each if the three simulations All clients randomly join the swarm in a

5 minute period Each experiment ends when all of the

users finish downloading the file Each experiment was executed several

times to provide more reliable results Initial p-distances are “0”, and updated

according to usage increment

42

Results - Simulation Completion type: Native bittorrent

provides worst results Localized is a little

better than P4P

Bottleneck Traffic: Native is still the worst P4P is much better

than Localized

43

Results – Internet Experiment Completion type: Native bittorrent

provides worst results Localized is a little

better than P4P

Bottleneck Traffic: Native is still the worst P4P is much better

than Localized

44

Variations on Swarm Size Completion time by

swarm size Native is always

the worst P4P is better when

using large swarms and worse when using smaller swarms

45

Inter Domain Cost We divide the

network into 2 “virtual” networks connected by 2 inter-domain links

P4P dramatically reduces inter-domain cost for ISP

No significant decrease in completion percentage observed

46

Inter Domain Cost When calculating the total traffic

distribution, we can see that we dramatically improve Inner-ISP traffic amount

Increasing Inner-ISP traffic and therefore decreasing cross-ISP traffic reduces ISP costs

47

P4P disadvantages \ setbacks

Since the P4P is so wonderful, are there reasons that can setback it’s popularity?

Is P2P here to stay? Legality issues Peer privacy issues Incentives for users (applications) Distrusting ISP neutrality

48

Conclusions Current P2P applications have several

problems causing lower performance & higher costs for ISP

P4P can cope with both of there issues P4P experiments show major

improvement for ISP and some improvement for application users

Despite all, it is hard to predict whether P4P will be an integral part of P2P in the future.