Shortest path to the world

Bill Woodcock woody at pch.net
Wed Jul 15 10:49:22 CDT 2009


On Jul 15, 2009, at 5:07 AM, Sean Donelan wrote:
> The typical network architecture problem, what are the best  
> (shortest latency, greatest bandwidth, etc) locations to connect to  
> the every nation in the world?  As you increase the number of  
> locations, how do the choices change?
> If you only had small (2 3 5 7 11) number of locations, where would  
> they be?
> And what data do you have to prove the choices are best?


As others have noted, this is a many-variables sort of problem, and to  
answer it well requires nailing down a few of those variables by  
combining the statistical output of netflow from your border routers  
with knowledge of the routing tables available at each potential IXP  
gleaned from looking-glasses at those IXes.  ( http://pch.net/routing-tables 
  being the source of such data that I can offer; the RIPE RIS program  
does the same thing with a partially-overlapping and partially-unique  
dataset; the union of the two gives the most complete available  
picture.)

However, if one wanted the beginnings of an answer, without nailing  
down any of the specifics, merely looking at the quantity of routes  
available at each IXP would let you know, on average, how many paths  
there were on offer to each destination.  In all likelihood, different  
paths available to a given destination will be of different lengths.   
The more paths available to each destination, the greater the  
likelihood that one path will be shorter than others or, more to the  
point, shorter than your current shortest.
( https://prefix.pch.net/applications/ixpdir/?show_active_only=0&sort=prefixes&order=desc 
  or just go to http://pch.net/ixpdir and sort by prefixes.  Only a  
router with a full mesh of peers at an IXP could actually show _all_  
of the available routes at an IXP, so nearly all views of this sort  
will be substantially incomplete; take with a healthy dose of  
skepticism, and please let me know if you find more complete public  
sources.)

                                 -Bill




-------------- next part --------------
A non-text attachment was scrubbed...
Name: PGP.sig
Type: application/pgp-signature
Size: 194 bytes
Desc: This is a digitally signed message part
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20090715/552d0e3e/attachment.bin>


More information about the NANOG mailing list