Date post: | 03-Jan-2016 |
Category: |
Documents |
Upload: | george-fletcher |
View: | 216 times |
Download: | 3 times |
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.
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.
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.
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.
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:
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.