1. 1 P4P - Provider Portal for Applications Based On The Article Haiyong Xie, Y. Richard Yang, Arvind Krishnamurthy, Yanbin Liu and Avi Silberschatz, P4P: Provider Portal for Applications Presented By Arkadi Butman

2. 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. 3 ISP traffic over the years

4. 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. 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. 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. 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. 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. 9 Traffic Statistics - Cache

10. 10 Traffic Statistics - Filter

11. 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. 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. 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. 14 Back to P4P – an example

15. 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. 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. 17 iTrackers - Query

18. 18 iTrackers – The big picture

19. 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. 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 p ij.

21. 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. 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. 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. 24 Application Point of View How do we use weights obtained from ISP? Peer i will select peer j with probability according to p ij (using some decreasing function) Set some coefficient s ij 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. 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 p ij is cost of link between from i to j B is some percentile (constant) OPT is optimal total traffic

26. 26 Before We Dive In – Some Notations b e – background traffic in edge e (not P2P) c e – capacity of edge (link) e I e (i,j) – indicator whether edge e is on the route for i to j in the topology T k – set of acceptable traffic demand for session k t k – some specific traffic distribution of T k t k ij – the amount of traffic from ID i to j under selection of specific t k t k e – the amount of traffic on edge (link) e.

27. 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. 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. 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 p e and try to find the minimum of the following equation:

30. 30 Tradition ISP objective - cont Since the p e 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. 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 p e How does the iTracker calculate the values? Using gradients.

32. 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. 33 Bandwidth-Distance Product Some distance metric (value) d e 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. 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 v e, the capacity for P2P traffic on link e If we can bound the traffic to some v e, we ensure that the ISP cost will remain the same ISP objective can be summarized by:

35. 35 Testings of P4P iTracker Implementation AppTracker locality-based Peers Results Conclusions

36. 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. 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. 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. 39 1 st 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. 40 2 nd 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. 41 2 nd 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. 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. 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. 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. 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. 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. 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. 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.