Measuring the physical location of an IP address is often like trying to find a moving target in a hall of mirrors. Traditional databases are static, but the Internet is dynamic. During the AIORI-2 Hackathon, our team—ChristUniversityTeam3—tackled this by turning the Internet into a giant ruler. Using the AIORI Active Measurement Framework, we implemented a system that uses light-speed latency to “triangulate” an IP’s position, all while adhering to the data standards of RFC 8805.
1. The Core Concept: Latency as Distance
How do you find a server’s location using only a ping? We followed the principles of RFC 2330 (Framework for Internet Measurement) and RFC 2681 (Round-Trip Delay Metric). By measuring the Round-Trip Time (RTT) from multiple known “vantage points” (probes) across India, we can calculate a maximum distance radius for the target IP.
Our Multi-Algorithm Approach:
- Octant: A mathematical constraint solver that narrows down the IP’s location to a specific geographic “slice.”
- Bézier-Calibrated Octant: We used non-linear curve fitting to account for the fact that network paths aren’t straight lines.
- Trilateration: Finding the intersection of distance circles from multiple AIORI probes.
- Minimum Bounding Circle (MBC): A fallback method that provides a “best-guess” area when probe data is sparse.
2. Technical Implementation & AIORI Integration
We deployed our measurement node at CHRIST (Deemed to be University), Bengaluru, connecting it to the broader AIORI testbed. The system works in a four-stage pipeline:
- Ingestion: Collecting raw RTT data using ICMP probes (RFC 792).
- Filtering: Applying “Minimum-of-N” filtering to remove network jitter and congestion noise.
- Localization: Running our Python-based algorithm suite to find the geographic centroid.
- Export: Formatting the result into an RFC 8805-compliant JSON file.
| Metric | Result | Insight |
|---|---|---|
| Localization Accuracy | ±400 km | Highly stable with 4–6 vantage nodes across India. |
| Computation Speed | ~1.2 seconds | Optimized for real-time visualization and API response. |
| Standard Compliance | RFC 8805 | Outputs valid JSON for self-published geolocation data. |
3. Visualizing the Network
To make the data interpretable, we integrated a Folium-based visualization engine. The dashboard displays the vantage points (blue markers), the calculated distance constraints (gray circles), and the final predicted IP location (red marker).
Why RFC 8805 Matters
By using the RFC 8805 format, our tool ensures that the data we generate can be easily read by other researchers and network operators. It bridges the gap between active measurement (finding the IP) and standard reporting (sharing the location).
4. Lessons from the Sprints: The “Noise” Problem
One of our biggest hurdles was asymmetric routing—the path a packet takes to a server is often different from the path it takes back. This makes pings look “further away” than they are.
- The Fix: We implemented Bézier smoothing and RTT weighting. By giving more “trust” to probes with lower jitter, we improved our centroid consistency by 12%.
“RFC 8805 gave us a blueprint, but AIORI made it practical. Working with real probe data made us appreciate the rigors of Internet measurement reproducibility.” — Tenzin Palden, Team Member
5. Future Work: IPv6 and QUIC
Our current implementation focuses on IPv4 and ICMP. As the Internet evolves, so must our tools. We plan to:
- Extend the framework to IPv6.
- Incorporate QUIC (RFC 9000) telemetry for even more precise latency mapping.
- Contribute our dataset to the IETF MAPRG (Measurement and Analysis for Protocol Research Group).
