iPlane: An Information Plane for Distributed Services

1
iPlane An Information Plane for Distributed
Services

• Offence by
• Anup Goyal
• Sagar Vemuri

2
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?

3
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.

4
Many solutions already exist!

• IDMaps
• GNP
• Vivaldi
• Meridian
• PlanetSeer

5
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

6
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?

7
CDN

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

8
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

9
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?

10
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?

11
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, iPlanes 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

12
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.

13
Comparing BitTorrent Vivaldi
CDFs of BitTorrent download completion times with
and without informed peer selection at the
tracker
14
Not Real-time
15
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?

16
Security

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

17
Query Interface

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

18
Conclusion

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

19
Questions?

• Thank you!