Testing environment and methods    List of tests    Some TCP trace validation rules    Back to SSF.OS.TCP page

The tests show the behavior of SSF TCP Tahoe and Reno variants for different networks, TCP parameter settings, and loss conditions. Each TCP test page contains: Test description and expected outcome, plots of tcpdump and other traces, and trace analysis. Links to the tested network DML configuration file and tcpdump traces are provided. Comparison with analogous ns-2 test traces is included. Acknowledgment: Most of the tests have been adapted from the TCP regression test suite developed by Sally Floyd and her collaborators, and distributed with the ns-2 simulator (see ns validation tests). Anja Feldmann, Walter Willinger, and others helped with a detailed critique of a number of early test trace analyses. However, HL and AO are solely responsible for any implementation errors :) that may still be present in SSF.OS.TCP. If you find an error in the SSF.OS.TCP code or in the analysis, or have a suggestion for improvement, please send email to Hongbo Liu hongbol@winlab.rutgers.edu and Andy Ogielski ato@renesys.com

Test Environment: ssfnet v0.7.7 (with NIC and SSF.OS.TCP revisions), jssf v0.4.18. ns-2 v2.1b4.  Tests executed and analyzed by Hongbo Liu. Date: August 1 - 12, 1999. When appropriate, we execute the SSF TCP tests under the conditions as close as possible to the ns-2 tests, but some small differences exist because of different internal parameter settings and/or different level of modeling detail. The table below shows some differences between ns-2 and SSF TCP implementations:   NS-2 SSF Open connection by 3-way handshake depends on variant yes Default queue size 50 packets unlimited Initial retransmission timeout 3 seconds in document,  6 seconds in ns-2 3 seconds Sequence number counting by packets by bytes ACK number equal to the sequence number to be acknowledged equal to the next expected sequence number Round trip time timestamp TCP slow timer counting Minimum retransmission timeout uncertain 1 second

Packet dropping tests: In some tests, packets were dropped "manually" by passing packet number to be dropped to a special test module plugged into the SSF IP. In some other tests, packet drops were forced by a size-limited drop tail queue implemented in a router. In SSF TCP tests, packets are dropped at the router's NIC (Network Interface) connected to the bottleneck link.

tcpdump notes: In SSF plots, the timestamp for outgoing IP packets is the time when they are put into the output queue of the NIC, and the timestamp for incoming IP packets is the time when they are received by the NIC. In NS tests, packets are dumped when they go through the bottleneck link. Every packet is dumped three times: when entering the queue, leaving the queue, and when received at the end of the link. To facilitate the comparison of traces, in the NS plots shown here all ACK numbers are increased by one for plotting. Timestamp for a data packet is enqueuing time. Timestamp for an ACK packet is the receiving time. Because NS TCP implementation has changed since 1997, some trace plots shown in the 1997 documents included with the ns-2 release are different from the trace plots obtained today by running the ns-2 simulator using the same parameter settings.

List of Tests: 0. Basic behavior of TCP timers 1. TCP Tahoe: Fast retransmission, slow start and congestion avoidance with single packet drop 2. TCP Tahoe: Fast retransmission, slow start and congestion avoidance with multiple packet drops 3. TCP Tahoe: Delayed acknowledgment and retransmission 4. TCP Tahoe: Fast retransmission, slow start with multiple packet drop 5. TCP Tahoe : Delayed acknowledgment and retransmission with multiple packet drop 6. TCP Tahoe: Phase effect with two TCP connections and slightly different propagation delay 7. TCP Tahoe: Phase effect with two TCP connections, different queue size and different propagation delay 8. TCP Tahoe: Two TCP connections with very different roundtrip time 9. TCP Tahoe: Multiple fast retransmission simulation 10. TCP Reno: Fast recovery with a single packet drop and maximum congestion window is limited. 11. TCP Reno: Fast recovery with two packet drops and maximum congestion window is limited. 12. TCP Reno: Fast recovery with multiple packet drops. 13. TCP Reno: Fast recovery with multiple packet drops (for comparison with Tahoe test 4 ). 14. TCP Reno: Fast recovery with two packet drops and delayed-ack, comparing the trace with and without maximum  congestion window limit.

Some trace validation rules

A collection of heuristic rules to help in analyzing tcpdump traces, and spotting possible violations of RFC requirements. These rules are not complete, and are meant as a general guide.

General TCP validation rules

Tahoe and later versions:  TCP never resends a packet unless a timeout occured or 3 duplicate ACKs were received. TCP never sends more data in a burst than the minimum of the receive window and the congestion window. Timeout for retransmission of the same packet grows exponentially until it reaches the maximum value. The congestion window size grows exponentially when doing slow start (if no delayed-ack algorithm is used). During slow start, reception of one ACK triggers the sending of two packets. The congestion window size increases roughly one packet each round-trip time when doing congestion avoidance (if no delayed-ack algorithm)  The retransmission after a timeout begins with the slow start algorithm until cwnd reaches ssthresh.

Extra TCP Tahoe validation rules

After fast retransmission, no Fast Recovery is performed. Thus no new packet can be transmitted while duplicate ACKs after the first 3 are received. After receiving a new ACK (most likely the ACK for the fast retransmitted packet), slow start is performed.

Extra TCP Reno validation rules

After fast retransmission, Fast Recovery is performed. New packet may be transmitted after each duplicate ACK received after fast retransmission, if the usable window size permits (it often doesn't). After fast recovery is finished, congestion avoidance is entered: congestion window increases approximately by one MSS per RTT.