At present, we are scanning out from a single test host. If we run the same scans from multiple hosts throughout the world, we will discover many more edges, and create a more accurate map of the ``middle'' of the Internet. We will discover the incoming paths to test hosts from the outgoing paths of other test hosts. Clearly, we need to expand the number of test locations. If we use enough of these, we should be able to fill in almost all the links that we can't see now because we never use them in out-going paths.
We originally thought that we would need to locate computers world-wide, or obtain volunteers to run our mapping. Jorg Nonnenmacher suggested that we might offer a screen saver that displays an updated network map, and would perform modest mapping chores from sites scattered all over the world when instructed from a central site.
Jorg's suggestion is seductive, but it would have to be engineered very carefully to avoid abuse. The real problem, however, is that the tracing packets are slightly noxious. It would be best if we could preserve the return address, so they always appear to come from ches-netmapper. This makes filtering and reporting easier for those who watch and care about these packets.
Others have suggested that we use loose source routing to guide the probe packets down the desired paths. Though some have reported some success with this approach [10], we have found that a large majority of the Internet either blocks IP packets with options, or at least refuses to process them. We could display these nodes on our map--an interesting visualization.
We intend to use IP tunneling to distribute probe packets. We need volunteers to add a simple tunnel to their router for us. Then we tunnel packets to their router, with return addresses of ches-netmapper. Packets would trace outward paths from each tunneling router, and the results neatly returned to us. Sensitive sites would see familiar packets, though they may come in over new links. Of course, the tunneling routers would see each packet twice. These wide scans would need a lot more packets, so we probably couldn't run them daily. Also, such packets might be dropped by ingress filters.
The resulting data ought to enable us build a mesh that closely describes the core of the Internet. We are not yet sure how to plot it--the data surely will look like our ``peacock'' and will need reduction or interactive visualization tools. And our layout tool only works on rooted trees at the moment.
There is also a tricky problem sewing this data together. Traceroutes going in two different directions through a router may result in the router reporting two different IP addresses. How do we determine that those different IP addresses belong to the same router? There are several possibilities, including looking at the return IP of ICMP error messages [10].
We will still need to determine the number and position of sites needed to adequately map the ``center'' of the Internet.
Utilizing a third dimension in representing the graph is very tempting, either by doing the layout in three dimensions or using the third dimension to represent distance from us. The graph is too large for current VRML implementations that we are aware of, but ought to be easily handled by rendering engines. The other major problem is in order to avoid `background clutter,' fog must be used, which means that a viewer can only see a local picture of the Internet at any given time.
Several people have taken our data to run through their visualization tools. Alas, modern displays simply lack the pixels to display the whole thing at once without some form of abbreviation. We look forward to their results.
We now have almost two years of data concerning the Internet. We would like to create a movie of how the Internet's topology has changed over our dataset. The problem is making the picture for January 12th look enough like the picture for January 11th that the movie is fairly smooth while still showing a decent picture for both days. This is complicated by the fact that companies change ISPs and ISPs change internal connectivity, peering arrangements, routing decisions, and router - IP address assignments.