Internet cartography is a serious and challenging research topic. Such maps are useful for e.g. evaluating applications and algorithms in simulation. As Rob Sherwood, who is now with Deutsche Telekom USA, highlighted when taking question after his talk given at ACM Sigcomm 2008 about DisCarte: we have conferences dealing with Internet Measurement, but we don’t know how exactly the Internet looks like. While traceroute, as an active measurement technique, it highlights parts of the Internet topology, other parts are hidden as routers don’t respond to traceroutes’ probes and are thus not visible. Moreover, traceroute will reveal only interfaces and not the routers itself. As routers are usually equipped with many interfaces, mapping interfaces obtained from traceroute probes to routers is another issue that makes Internet cartography a complex activity. In his paper, Rob Sherwood proposed a combined approach, which makes use of the Record Route (RR) mechanism provided by IP (cf. RFC 791) and outperforms current mapping techniques. The offered record route option will maintain a set of IP addresses (up to a certain length) used to record the route of an Internet datagram. Obviously, it is merely a matter of time until network providers which want to obfuscate their backbone topology configure their routers to no longer append their addresses to the RR list, but I agree with Sherwood’s view: having an, maybe, old but rather accurate map of the Internet is better than nothing.
While traceroute represents an active measurement approach, partial information about the network topology can also be obtained from passive measurements, as Brian Eriksson, who is with the University of Wisconsin-Madison, showed in his Sigcomm 2008 paper. However, a certain degree of active probes are still necessary, as Eriksson highlighted in his talk.
Map sources:
- A source of publicy available topologies of commercial and research backbone networks, which can be directly fed into simulators, can be found here.
- Internet Mapping Project: Larger number of maps maintained until 2000.
- Backbone maps as pixel graphics can be found here.
- EPFL’s netscope is designed to monitor overlay networks
If you know of more mapping sources, please place a link in the comments of this post. Many thanks in advance.
Why do TCP flows, that carry the vast majority of the Internet traffic, transmit at rates they do? A user upgrades his access line to a pipe which is able to carry 16 Mbit/s downstream. However, when retrieving data from the Internet, the user observes that the maximum throughput is not reached. What are possible reasons for this behaviour? How can root causes for low throughput be identified? Knowledge of factors that determine TCP’s throughput is therefore valuable for users as well as network operators.
Those answers are provided by tools used for TCP Root Cause Analysis. While some factors are obvious, others need further investigation. However, identifying possible causes that explain the observed throughput at a given time instant is non-trivial when traffic can only be observed at a particular point in the network without accessing e.g the client host.
TCP’s throughput may be limited for several reseaons. A server might not have enough bandwidth to saturate the users’ access line, or a link connecting the user to the server might be bottlenecked and thus limit the throughput. High load in the network can cause congestion and a TCP sender will limit its sending rate in congestion avoidance phases. Furthermore, the sending rate might be simply application limited, e.g. in case of a voice over IP client which sends a small amount of data in very frequent intervals and thus the application will not attempt to use all of the available network resources. The latter is a major cause for a throughput limitation (Siekkinen, PAM 2007).
While most of the rate limiting factors cannot be controlled by the users, some can. The amount of unacknowledged data that can be outstanding at any time is defined by the TCP window. Assume the window size is 64 Kb and the round trip time (RTT) is one second. Then his will result in 64 kb that can be transferred per second. Thus, also the RTT, that will increase with increasing distance to the remote server, can be a limiting factor. Moreover, if the window size is low, either at the sender (sender window) or at the receiver (receiver window), the application will also experience low throughput. In contrast to other limiting factors, the size of the (advertised) receiver window can be directly controlled by the user and a misconfiguration might be one possible cause of low throughput. The pioneering work by Zhang et al. found that congestion and limited windows are common causes for low throughput in observed TCP connections and showed that congestion is not always the cause for throughput limitations. Therefore, the view that throughput is limited by the network only is too restrictive.
Some root causes can be identified using a nice online tool. It allows to quickly get some TCP connection statistics (like RTT and congestion window measurements) for performing a TCP Root Cause Analysis by simply accessing a web page. The tool can be accessed here. An extended tool is proposed by Siekkinen et al.
Readers interested in TCP Root Cause Analysis should consider reading the following papers:
ohohlfeld.com : blog
