P4P - Provider Portal for Applications

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. 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. • “t” stands for session “k” traffic from ID “i” to “j” • “u” is upload capacity • “d” is download capacity • ISP wants to minimize “damage” of traffic, while maintaining reasonable performance • 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.