Shortest path to the world
Bill Woodcock
woody at pch.net
Wed Jul 15 15:49:22 UTC 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.sig>
More information about the NANOG
mailing list