======tcp_testing======

TCP testing in Linux is an continuous process. These tests are concerned with the behavior and correctness of the TCP protocol in the Linux kernel.

//More will be added to this page soon.//
=====Contents=====

  * [[https://www.linuxfoundation.org/#Tools|1 Tools]]
  * [[https://www.linuxfoundation.org/#Tuning|2 Tuning]]
  * [[https://www.linuxfoundation.org/#Experiments|3 Experiments]]
    * [[https://www.linuxfoundation.org/#Congestion_Control|3.1 Congestion Control]]
      * [[https://www.linuxfoundation.org/#Example|3.1.1 Example]]
      * [[https://www.linuxfoundation.org/#Variations|3.1.2 Variations]]
    * [[https://www.linuxfoundation.org/#Performance|3.2 Performance]]
  * [[https://www.linuxfoundation.org/#Protocol_Conformance|4 Protocol Conformance]]
  * [[https://www.linuxfoundation.org/#External_Links|5 External Links]]

===== Tools=====

Many tools are available for building TCP tests, but some of the basic ones are:

  * ** [[:networking:iperf| Iperf ]] **
  *  a simple client/server test application.
  * ** [[:networking:tcpprobe| TcpProbe ]] **
  *  kernel module that creates a way to see TCP endpoint state changes
  * ** [[:networking:netem| Netem ]] **
  *  emulate long delays, packet loss etc.
===== Tuning=====

When running TCP experiments over high [[http://en.wikipedia.com/wiki/Bandwidth-delay_product|Bandwidth Delay Product]] (BDP) you probably want to change the maximum available TCP window size. TCP tuning is done via [[http://en.wikipedia.com/wiki/sysctl|wikipedia:sysctl]] parameters documented in [[:networking:ip-sysctl|Net:Ip-sysctl]] (or Documentation/networking/ip-sysctl.txt) see for more info.
At a minimum increase tcp_rmem[2] for receiver and tcp_wmem[2] for sender to twice the BDP.

If the test involves repeated connections, you should also turn off the route metrics:
<code> sysctl -w net.ipv4.tcp_no_metrics_save=1</code>

Normally Linux will remember the last [[http://en.wikipedia.com/wiki/Slow-start|slow start]] threshold (ssthresh). This modifies the result of the second test, and causes errors.
===== Experiments=====
==== Congestion Control====

The purpose of congestion control tests is to observe how the congestion window changes with different network conditions. These tests have lots of possible variables and there is no one "right answer".
=== Example===

A basic test would be:

  -  Start //iperf// server on the receiver
<code> iperf -s</code>

  -  Insert //tcp_probe// module (as root) on sending machine and filter for iperf port. You can change the mode to allow non-root user access
<code> modprobe tcp_probe port=5001
 chmod 444 /proc/net/tcpprobe</code>

  -  Capture tcp probe output (on sender) and place in background
<code> cat /proc/net/tcpprobe >/tmp/tcpprobe.out &
 TCPCAP=$!</code>

  -  Run //iperf// test on sender for 15minutes
<code> iperf -i 10 -t 300 -c //receiver//</code>

  -  Kill capture process
<code>  kill $TCPCAP</code>

The tcp probe capture file will contain one line for each packet sent.
<code> 0.073678 10.8.0.54:38644 192.168.1.42:5001 24 0xb6b19bb 0xb6b19bb 2 2147483647 5792
 ^        ^               ^                 ^  ^         ^         ^ ^          ^
 |        |               |                 |  |         |         | |          +- [9] Send window
 |        |               |                 |  |         |         | +------------ [8] Slow start threshold
 |        |               |                 |  |         |         +-------------- [7] Congestion window
 |        |               |                 |  |         +------------------------ [6] Unacknowledged sequence #
 |        |               |                 |  +---------------------------------- [5] Next send sequence #
 |        |               |                 +------------------------------------- [4] Bytes in packet
 |        |               +------------------------------------------------------- [3] Receiver address:port
 |        +----------------------------------------------------------------------- [2] Sender address:port
 +-------------------------------------------------------------------------------- [1] Time seconds
 
 * The value of slow start threshold here is (-1) which means it hasn't been determined yet
 * Time since Tcp probe was loaded.</code>

This text file can be easily filtered and modified with standard tools such as [[http://en.wikipedia.com/wiki/Awk|awk]] and [[http://en.wikipedia.com/wiki/Perl|perl]]. A common usage is to make a plot of congestion window and slow start threshold over time using [[http://en.wikipedia.com/wiki/Gnuplot|gnuplot]].
<code> $ gnuplot -persist <<"EOF"
 set data style linespoints
 show timestamp
 set xlabel "time (seconds)"
 set ylabel "Segments (cwnd, ssthresh)"
 plot "/tmp/tcpprobe.out" using 1:7 title "snd_cwnd", \
      "/tmp/tcpprobe.out" using 1:($8>=2147483647 ? 0 : $8) title "snd_ssthresh"
 EOF</code>

The result should look something like this:{{https://wiki.linuxfoundation.org/images/0/05/Cubic.png?nolink|}}

A set of scripts to run test like this and plot are available [[http://developer.osdl.org/shemminger/tcp/tcpprobe-utils.tar.gz|[1]]]
=== Variations===

There are many possible factors that can be evaluated in any test.
For a good discussion of the issues see the paper:[[http://www.sigcomm.org/ccr/archive/1999/oct99/ccr-9910-allman2.html|On the effective evaluation of TCP]] and [[http://www.hamilton.ie/net/eval/ToNfinal.pdf|Experimental evaluation of TCP protocols for high-speed networks]].

  * ** Algorithim **
  *  Linux provides many congestion control algorithms now.
  * ** BDP **
  *  TCP needs to adapt to a wide range of band-width delay products
  * ** Loss **
  *  TCP should recover from moderate loss, but since most congestion control algorithms use loss to estimate BDP; they have trouble distinguishing random packet loss from router queue overflow packet drop.
  * ** Fairness **
  *  //Define fairness and how to measure it//
  * ** Background traffic**
  *  //Describe how to add background traffic via harpoon here//
==== Performance====

On Linux TCP should be able to fully saturate the network given a sufficiently fast CPU and bus for a single connection. Some useful tools are:

  *  [[http://www.netperf.org/netperf/NetperfPage.html|netperf]] allow for measuring CPU utilization
  *  [[http://httpd.apache.org/docs/2.0/programs/ab.html|Apache benchmark]] for measuring lots of web connections
  *  [[http://curl-loader.sourceforge.net/|curl-loader]] web traffic generation (HTTP/S, FTP/S) with 10-20K and more real HTTP sessions

See also [[:networking:performance_testing| Performance Testing ]].
===== Protocol Conformance=====

There are (expensive) TCP protocol validation suites.

[[http://en.wikipedia.com/wiki/Fuzz_testing|Fuzz testing]] is a useful way to find unexpected bugs in the TCP processing.[[http://isic.sourceforge.net|ISIC]] is a suite of utilities to exercise the stability of an IP Stack and its component stacks (TCP, UDP, ICMP et. al.)

\\ 
===== External Links=====

  *  [[http://web100.org/|Web100 project]]
  *  Protocols for Long Distance Networks conference [[http://wil.cs.caltech.edu/pfldnet2007/|2007]] [[http://www.hpcc.jp/pfldnet2006/technical.html|2006]]
  *  [[http://www.hamilton.ie|Hamilton Institute]] [[http://www.hamilton.ie/net/eval/|Experimental testing]]
  *  [[http://ncsu.edu|NCSU]] developers of [[http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/index_files/Page815.htm|CUBIC]] and [[http://www.csc.ncsu.edu/faculty/rhee/export/bitcp/|BIC]], experimental results [[http://netsrv.csc.ncsu.edu/highspeed|[2]]] [[http://netsrv.csc.ncsu.edu/convex-ordering|[3]]]
  *  Stanford Linear Accelerator Testbed [[http://www-iepm.slac.stanford.edu/bw/tcp-eval/|experiments]] and [[http://dsd.lbl.gov/DIDC/PFLDnet2004/papers/Bullot.pdf|report]]
  *  [[http://developer.osdl.org/shemminger/tcp|Stephen Hemminger development tests]] results [[http://developer.osdl.org/shemminger/tcp/2.6.19-rc3|2.6.19-rc3]] [[http://developer.osdl.org/shemminger/tcp/2.6.19-rc4/dsl|2.6.19-rc4]] [[http://developer.osdl.org/shemminger/tcp/net-2.6.22|pre-2.6.22]]