Validation of tcpcsm
We installed web servers on eight different machines for the purposes of this validation experiment. The machines were running the following operating systems / configurations:
- Solaris 10
- FreeBSD 5.3
- FreeBSD 7.2
- Linux 2.6.23
- Windows XP SP2
- Windows Vista (Unpatched)
- Windows Vista SP2 (using the CTCP congestion control algorithm)
- Windows Vista SP2 (using the default congestion control algorithm)
The Unix-based operating systems ran an Apache 2.2 web server. The Windows servers used the appropriate version of IIS (5.0 for XP, 7.0 for Vista).
The tests were conducted using the TCP Behavior Inference Tool (TBIT). None of the built-in tests were suitable for our purposes and the tests developed by Rewaskar et al to validate their tool were no longer publicly available, so we were forced to develop our own test suite. In total, we designed and developed 13 distinct tests. The code for the TBIT tests that were developed for this project can be downloaded from here.
Each of the tests operates in a similar fashion. A connection to the web server is established and a large object is requested (in our tests, we simply placed a 10MB binary file full of zeroes on each server). After a fixed number of packets was received (henceforth referred to as N, but 24 packets were the threshold used throughout the validation exercise), the test would begin to withhold, reorder or otherwise manipulate acknowledgements to elicit a particular reaction from the server. Once 100 distinct segments have been received, the test is terminated.
The TBIT tests announce an MSS of 1000 bytes and a receive window of 16 segments. The small receive window limits the amount of data that can be outstanding at any given time, regardless of the size of the congestion window. This also makes life easier when manually analysing the results of tests where we've dropped an entire window of packets.
During the testing, the server and client were separated by a FreeBSD machine acting as a router. DummyNet was used to introduce a fixed amount of delay into the path (250ms one-way delay, or a 500ms RTT). tcpdump was used on this machine to capture traces of the test traffic, which were used as input to the validation process itself. Once a test is completed, the tcpdump capture continues for an additional 30 seconds to ensure that the connection tear-down is captured properly and to provide a suitable gap between each test when they are run as a batch.
There were two components to the validation process. Firstly, the traces were manually analysed with the tcptrace utility to ascertain that the test produced the appropriate acknowledgement sequences and to identify how each operating system behaved in response to the test scenario. Secondly, the trace was provided to tcpcsm and the output analysed to ensure that the events reported were consistent with the events identified through the manual inspection.
Shane Alcock, WAND Network Research Group