iPlane: An Information Plane for Distributed Services Offence by: Anup Goyal Sagar Vemuri

Do we really need a new plane? The Internet is already quite complex Existing applications are working well Why try to change it by adding another plane?

Already many studies! KnowledgePlane by Clark et al. Reverse Engineering the Internet by Spring et al. Sophia: An information plane for networked systems by Wawrzoniak et al.

Many solutions already exist! IDMaps GNP Vivaldi Meridian PlanetSeer

Anything new in this paper? Just an integration of past work “Previous research efforts have proposed specific ways to measure each of these properties; our goal is to integrate these techniques into a useful prediction system”

Usability Network today is over-provisioned – Only 3% of the bandwidth is used End nodes are the bottleneck – Only the internet core is studied – How much percentage of the Internet applications find this really useful? – Creating a new Internet plane for a handful of applications?

CDN CDNs are mainly concerned with load balancing Unless there is a dense CDN you will end up sending data through the bottleneck link.

Path Prediction Path Prediction highly depends on the vantage points location Closer the vantage point the tighter the bound will be Measuring routes to remote places (eg. Alaska) will induce a significant error – Since no close by vantage point

Edge Measurement Bandwidth that iPlane observes might just be a fraction – BitTorrent clients may have multiple connections open – Only upload bandwidth is considered – Noise in traffic is not considered – What if there is a delayed response from the P2P client?

Measurement Measurement data and results not very convincing Compared the performance of speculative RTT and throughput to the ground truth data – Not even close to the ground truth What is the point of your measurement?

Measurement … 2 Measurement techniques not very accurate – “We can predict the AS path exactly right for around 70% of the paths evaluated” – “For 77% of paths, iPlane’s latency estimates have error less than 20ms, and for 82% of paths, loss rate estimates have error about 10%” – “For 80% of the nodes, the correlation coefficient of TCP Throughput is greater than 0.7”

PlanetLab for Measurement Uses PlanetLab for most of its measurement and evaluation – Ofcourse, we agree that it is inevitable Evaluating in a more controlled environment – Obviously results of the tests are likely to be better than in real world It would be best if none of the sites hosting vantage points are used as clients for evaluation – They do not mention that in the paper.

Comparing BitTorrent & Vivaldi CDFs of BitTorrent download completion times with and without informed peer selection at the tracker

Not Real-time

Scalability Maintenance of many vantage points is difficult What if multiple vantage points go down? – The load of measurement shifts to other vantage points – But can they handle it efficiently?

Security Assume that Traceroute servers provide unbiased data – Not under our control – Could be compromised – No verification in place

Query Interface Not feasible to download the complete atlas of the Internet On-the-fly queries are expensive – Time intensive – CPU intensive

Conclusion Put together lot of random thoughts to make up this paper – Frontier alg, BFS, Clustering alg, SQL Old wine in a new bottle

Questions? Thank you!