http://www.strom.com/awards/75.html
Like many of you, I have been following the Mars Pathfinder mission and viewing the pictures on the JPL web site when I can. It was a nice change of pace to see some real science and engineering displacing all the Roswell nonsense from our front pages -- not to mention having some nerds get the credit for these accomplishments. One of the things that NASA did was to setup a clickable map showing various mirror servers around the world, in the hopes of sharing the load and improving download times.
But when you think about it, this map is really utter nonsense. The concept of what is "near" in terms of the Internet has nothing to do with geography. Indeed, in some cases the way the Internet is connected together runs counter to the way the physical world is connected.
Let's use the example of the Good Internet Citizen who wants to get those pix from Mars and not consume any more bandwidth than is necessary. Which is the right server to pick? Well, if you are living outside of the US, it is an easier decision, mainly because the Internet outside of the US has fewer pipes. However, you might find yourself in an Asian country, where you have better throughput to Hawaii, say, than to a neighboring country.
When it comes to US-based destinations, things get trickier because the topology of the Internet is more complex and runs counter to geography. Depending on which service provider you use, it may be faster to connect to a server on the west coast, if they are connected via the same backhaul provider.
How can you tell these things? Use traceroute, a tool that will show you the path between where you are and some destination, and the routers and delays along the way. This command comes with Windows 95 (type tracert then a space and the name of a host or web site in a command window), Unix, and there is a Mac program called WhatRoute that does something similar.
For example, my local ISP here on Long Island is connected to Sprint's backbone. This means if I am accessing a web site that is connected to Sprint in Chicago, say, my packets don't even travel over the general Internet to get from my computer to the site and back: everything is contained over Sprint's network. This may be a problem, if Sprint's network is particularly congested, but usually this means that I'll get better performance than if I try to connect to a site that is on, say, MCI's network.
But knowing the path is just one variable that you'll need to understand. Unlike reading a map and judging the distance between two points (and let's not even get into two-dimensional projections of a spherical space), you have to balance several other factors, and you might not know the value of any of them to make an intelligent decision. There is the overall server capacity and throughput, then the throughput of the various connecting pathways between you and the server, and the congestion across those paths. There is the overall latency across that path, something that changes from moment to moment.
Jon Stevens has put together an interesting service that he calls the NetCopter. It records the previous 24 hours of packet delays on routers that he has determined connect the major Internet providers to each other or to the Network Access Points where several providers interconnect. It isn't perfect, but it can give you a picture of what is going on. And John Quarterman has his own series of maps that track latency and traffic on his site.
David Strom
david@strom.com
+1 (516) 944-3407
back issues
entire contents copyright 1997 by David Strom, Inc.