We used a relatively simple networking setup. We had two Pentium computers, tnt.stanford.edu and detcord.stanford.edu, running RedHat Linux 5.0 (kernel version 2.0.33). Each machine had a wired and wireless connections and two IP addresses. The wireless connection employed Metricom Ricochet SE radios (Firmware version 106503-210P), and the wired connection was a 10-base-T Ethernet network.
The Ethernet network has an Maximum Transmission Unit (MTU) of 1500 bytes, a bandwidth of 10Mb/s, and an average round trip time (RTT) of 4 ms. The Ricochet network has an MTU of 1152 bytes. We used the Ricochet network so that the radios talk peer to peer. In this configuration, the Ricochet network has a bandwidth of 60Kb/s and an average RTT of 170ms. This is not the configuration seen by most Ricochet users (see section VI), but it provides the maximum possible performance for the Ricochet network and avoids the error introduced by sharing bandwidth with other users during the tests.
We spent most of our time configuring our software. We used Apache 1.2.6 [1] as our web server and the libwww robot (release 5.1l) from the W3 Consortium [2] as our client.
The Apache server was not compiled with any special options, other than those required to get it running on RedHat 5.0. However, in the runtime configuration files, we placed in an option to make it emulate an HTTP/1.0 only server. We set the special environment variable "downgrade-1.0" to true regardless of the browser. Thus, we had to start up the server twice: once to gather HTTP/1.0 data and once to gather HTTP/1.1 data. We decided to force the server into HTTP/1.0 mode rather than the robot because we were unable to get the robot to perform correctly in the mandatory HTTP/1.0 mode. We set up a sample web page which was basically a copy of a Microsoft web page. It was meant to simulate current web pages which are graphically intense. The HTML file itself was approximately 25KB and it contained 30 in-line images varying from under 100 bytes to about 10KB. The total amount of data (text and images) was about 69KB.
The robot was run in non-interactive mode, saving the images in order to simulate a GUI browser. In addition, the quiet mode was turned on so that the output would not slow down the time measurements. To time the duration of the connections, we simply took the time elapsed value printed out by the robot. Because the time given by the robot includes the time taken to start up the robot and exit the program, these times are not the exact times between when the first SYN request was sent and the last ACK received. However, the overhead of the robot is small compared to the network events were measuring, so we ignored this source of error.
A more serious source of error is the fact that the robot makes one TCP connection per request and one request at a time in HTTP/1.0 mode. We were unable to do parallel connections to mimic browsers like Netscape (which typically uses four parallel connections). In HTTP/1.1 mode, the robot makes one TCP connection for all requests using the persistent connection protocol and pipelining. We did not use the persistent cache because we are simply measuring the effects on the transfer of TCP packets, not necessarily overall web performance.
We gathered the data using the robot's quiet mode output and using tcpdump on the server side. We started the Apache server (in HTTP/1.0 mode) and then tcpdump on tnt. On detcord, we started the robot with the IP address of the server's wired interface. We then ran the again, this time with the IP address of the server's wireless interface. Then we killed the the server and restarted it with the edited configuration file allowing normal HTTP/1.1 operation. The tests were repeated to get measurements for the HTTP/1.1 specification on both on the wired and wireless interfaces. We ran the test five times for each of the four different setups.