Re: Geo location to IP mapping

[sgorman1 () gmu edu]

Well I must admit that zip code was best case under ideal conditions ;-)  There are always plenty of exceptions that 
put sand in the gears.  Putting on my conservative hat the approach is more granular than guessing the right country as 
was being discussed before.  My intention was only to infer there is more than one way to approach the problem and an 
approach that can avoid some of the DHCP issues seen in the datbase approaches.  This was work from 6 years ago so a 
bit fuzzy on the particulars at this point.

best,

sean

----- Original Message -----
From: "Steven M. Bellovin" <smb () cs columbia edu>
Date: Monday, May 15, 2006 10:25 pm
Subject: Re: Geo location to IP mapping

> On Mon, 15 May 2006 21:49:31 -0400, Marshall Eubanks
> <tme () 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 
> lasthop.  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 
> introduceda noticeable per-byte delay.
>
>               --Steven M. Bellovin, http://www.cs.columbia.edu/~smb