1 / 36

A Model Based Approach for Improving Geolocation *

A Model Based Approach for Improving Geolocation *. Péter Hága Eötvös Loránd University Budapest, Hungary. * ” A Model Based Approach for Improving Router Geolocation ” a ccepted for publication in Computer Networks, 2010. Outline. Measurement based geolocation

talib
Download Presentation

A Model Based Approach for Improving Geolocation *

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. A Model Based Approach for Improving Geolocation* Péter Hága EötvösLoránd University Budapest, Hungary * ”A Model Based Approach for Improving RouterGeolocation”accepted for publication in Computer Networks, 2010.

  2. Outline • Measurement based geolocation • Detailed path latency model • To localize internal routers • Case studies • To localize end hosts • Spotter framework

  3. Motivation • Location information can be useful to both private and corporate users • Targeted advertising on the web • Restricted content delivery • Location-based security check • Web statistics • Scientific applications • Measurement visualization • Network diagnostics

  4. Geolocation in General • Passive geolocation • Extracting location information from domain names • DNS and WhoIS databases • Commercial databases • MaxMind, IPligence, Hexasoft • Large and geographically dispersed IP blocks can be allocated to a single entity • Active geolocation • Active probing • Measurement nodes with known locations • Constraint based techniques

  5. Measurement Based Geolocation • Network Delays – with active measurements • Delays can be transformed to geographic distance • Round Trip Time (ping) • One-way delay (measured in the ETOMIC Infrastucture) • Effects of delay underestimation • Effects of delay overestimation

  6. Modeling Packet Delays • A packet delay (d) can be divided into… • Queuing delay (Dq) • Processing delay (Dpc) • Transmission delay (Dtr) • Propagation delay (Dpg) • A given path: Only the propagation component has role in the geolocation n0 n1 n2 nH … • The overall packet delay for a network path:

  7. How to Estimate Propagation Delays • Assumptions used in the model • No queuing:Dq = 0 • The per-hop processing and transmission delays can be approximated by a global constant: dh = Dpc + Dtr • Based on the literature and our observationsdh = 100s • The one-way propagation delay along a given path:

  8. Distance Approximation • An upper approximation of geographical distance from source s to destination d: • where r is the velocity of signal propagation in network [in c units] d • in copper: ~0.7 • in fiber : 0.65 • Physical properties • Length • cable curvatures s

  9. 1. Round-Trip Time Constraint • Using path-latency model • Round-trip propagation delay from a landmark • Upper approximation of one-way propagation delay The node to be localized t L Landmark with known location

  10. 2. Per-link Distances • Link latency estimation • For a symmetric link e • For real links L2 ni e L1 ni-1 ni ni-1 Internet L1 RTT1 – RTT2

  11. 3. One-way Delay Constraint • Limits the geographic length of a given network path • Requires OWD measurements n2 L2 n3 L1 n1

  12. Localizing internal routers

  13. Localizing internal routers

  14. Localizing internal routers Based on one way delays:

  15. Performance Analysis

  16. Extensions • latency vs. distance distribution for each landmark • calibrated to the other landmarks • flat disks -> probability distributions Figure is from the Octant paper.

  17. Case study I. – Where are your YouTube videos?

  18. Case study I.– Where are your YouTube videos? • Where are YouTube’s content delivery servers? • MaxMind result is: Mountain View, CA • Geoloc based on active measurement: • The IP range: 74.125.0.0/16 • 8127 accessible IP addresses • 8127 nodes to be localized • Landmarks: 300 PlanetLab nodes

  19. Case study I.– Where are the YouTube servers?

  20. Case study I. – Where are the YouTube servers?

  21. Case study I. – Where are the YouTube servers? Stockholm London Bremen, Hamburg Moscow Amsterdam, ??? Dresden Dortmund,Frankfurt,??? ???

  22. Case study I. – Where are the YouTube servers?

  23. Case study I. – Where are the YouTube servers? Toronto Seattle New York Minneapolis Chicago ??? San Francisco Atlanta Los Angeles Baltimore,Washington Charlestown,Savannah

  24. Case study I. – Where are the YouTube servers? Hong Kong Tokyo Singapure Taipei • N=1 • 2<=N<10 • 10<=N

  25. Case study II. – Where do the Hungarians live?

  26. Case study II. – Where do the Hungarian live? • target IPs: • google/yahoo/baidu/bing web search • 10 words from the 100 most frequent hungarian words • 4359 globally accessible IP addresses • 4359 nodes to be localized • Landmarks: 300 PlanetLab nodes

  27. Case study II. – Where do the Hungarian live?

  28. Case study II. – Where do the Hungarian live?

  29. Case study II. – Where do the Hungarian live?

  30. Spottergeolocation framework

  31. Framework • Engine: • to evaluate the measurement data • To visualize the result (confidence regions) • store raw and evaluated date in nmVO • active probing based on Planetlab nodes • Management layer: • to reserve nodes • to execute probing • to collect measurement data

  32. Prototype – nm.vo.elte.hu/spotter • Calls the framework • http://nm.vo.elte.hu/spotter • http://nm.vo.elte.hu/spotter/test_version • Feedbacks are welcome! • C# ASP based implementation • Under development, current release is „unstable” • define targets • Filtering: • Landmarks - Planetlab sources • Results – number of „closest” data sources to evaluate

  33. Prototype – nm.vo.elte.hu/spotter

  34. Prototype – nm.vo.elte.hu/spotter

  35. Prototype – nm.vo.elte.hu/spotter

  36. Thank you for your attention!

More Related