Geo location to IP mapping

Tue May 16 02:25:07 UTC 2006

On Mon, 15 May 2006 21:49:31 -0400, Marshall Eubanks
<tme at multicasttech.com> wrote:

> 
> I seriously doubt this would work to better than the regional area.
> 
> My zip code (20124) region is about 5 km across, which would be 15  
> microseconds in vacuum, and
> maybe at most 50 micro seconds in glass. So, you would need  
> accuracies at the 10's of microsecond level to specify zip codes.
> 
> I can believe that you can measure transmission times down a fiber  
> and achieve repeatability at the microsecond level - in fact, I  
> remember a Michelson interferometer that they set up at JPL /  
> Goldstone that tested
> the Sagnac effect in glass, which required substantially better  
> repeatibility than that.
> 
> But do you really think that you can estimate the router delay on the  
> (for example) 9 hops between here and GMU
> to better than 1 millisecond each ? (That would imply a 3 millisecond  
> rms error if these errors were random and Gaussian, or about 1000 km  
> in vacuum, and maybe 500 km error in glass.)
> 
> So, I think that this would fail by at least 2 orders of magnitude for
> zip codes in a real operational network. Which coast of the US, sure,  
> but not much better than that.

I suspect you can do that; a bigger factor is the link type of the last
hop.  Cable modems, DSL, 802.11 -- they all have characteristic delays.

The important insight is that you care about *minimum* time.  You can lots
of queueing delays and jitter most of the time, as long as you get one
packet through unobstructed.  Send enough probes and you'll make it.

I did some similar work in 1992; see
http://www.cs.columbia.edu/~smb/papers/netmeas.pdf for details.  You
couldn't repeat, today, exactly what I did then, because of the way pings
are handled by modern routers, but I suspect one could find analogous
schemes.  To give one example of what I could tell -- and I was looking at
the per-byte cost -- I was able to determine, from New Jersey, that a
router outside Chicago was misconfigured; the site's backbone Ethernet
should have been on the same card as the serial line (in the days of T-1
interfaces...), because copying the packet across the backplane introduced
a noticeable per-byte delay.

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb