Simulator Design

Figure 2: Simulator Design

The simulation process can be considered as three interlinked processes, pre-processing, simulation and post-processing.

Pre-Processing

In the preprocessing stage the input files for the simulator are prepared. These are:

• A ``hostfile'' which contains an entry for each server accessed during the simulation. The entries contain: a unique ID for each host, the DNS name of the host, the maximum window size for the host and the TCP maximum segment size (MSS) for connections to the host.
• A ``logfile'' which contains an entry for each HTTP request. The entry contains the host ID for the server the request is fetched from, the size of the HTTP GET request, the size of the HTTP response and the time taken in the US component of the network.
• The simulation parameters including: the buffer sizes used by the proxies, the presence or absence of a US proxy, the number of connections between the proxies and the international link speed and delay in each direction.

775 simulations (each requiring from around a minute to 15-20 minutes on a 450Mhz Pentium CPU running Linux) were run to produce the graphs reported in this paper.².

Post-Processing

Post processing is mostly a matter of collecting the results of interest from many simulation runs into a single set of plots. This was done with an array of perl scripts. GNU plot was used to draw the plots.

Simulation

Figure 3: Simulator Design

The simulator used in this study was based on the ATM-TN simulator[6] with modifications for this problem. The changes include replacing the ATM infrastructure with a simpler and more general bit serial interface. The main two components used from ATM-TN are the conservative (as opposed to parallel) simulation engine and the TCP model. ATM-TN's TCP model includes the actual TCP code from 4.4 BSD Lite, modified to suit the simulation environment. Connections are simulated on a packet by packet basis and include slow start, congestion control, fast retransmit, and fast recovery algorithms. [7] The simulator design for the US-proxy case is shown in figure 3. The simulator simulates the connections between the NZ proxy and the servers in the US. It does not include the NZ proxy to web client component of the network because this significant to the study. Additional delays that are dependent on the type of connection (e.g. modem or direct connect) will be incurred in the NZ component of the real network. The non-US-proxy case is similar to the US-proxy one with the omission of the US proxy and the replacement of the two TCP connection modules with a single TCP connection module and a single set of end-to-end TCP connections.

HTTP traffic model

The HTTP traffic model is responsible for creating TCP connections, sending HTTP GET requests, receiving the request at the destination and returning and results and for recording the time required to complete the HTTP requests. The HTTP model makes use of the hostfile and the logfile to control the simulation. The delays in the US part of the network are simulated by the HTTP traffic model which releases the packets that make up the HTTP response at a regulated rate so that the complete response arrives at the US proxy at the same mean rate as it did when the page was fetched on the real network.

TCP Connection

The TCP connection model simulates an end-to-end TCP connection and are based on a pair of TCP stacks, one for each end of the connection. It is assumed that the effect of errors is negligible.

US Proxy Model

The US proxy accepts HTTP GET requests across the TCP connections from the NZ proxy and forwards the request to the US server over a new connection to that server (HTTP 1.1 is not simulated). When the first packet of the reply arrives from the server a TCP connection is chosen to carry the HTTP reply to the NZ proxy. The connection with the smallest number of bytes awaiting transmission or transmitted but not acknowledged is chosen. As the packets of the reply arrive they are queued for transmission over the chosen TCP connection. Because multiplexing is used the data from different HTTP replies can be intermixed on a single TCP connection between the caches. The simulation assumes that the proxy has sufficient CPU and memory to manage the workload and that the delay imposed by processing on the proxy not due to TCP queuing and transmission is negligible.

Footnotes

... paper.²

For the curious that's around 3.5 million million CPU cycles