• 1 TAHI Conformance Test Suite
• 2 Applications suitable for DCCP testing
  • 2.1 ttcp
  • 2.2 iperf
  • 2.3 netsend
  • 2.4 Other DCCP source code
• 3 Experimental DCCP source tree
  • 3.1 How to obtain
    • 3.1.1 Cloning the entire tree
    • 3.1.2 Faster variant: DCCP subtree only
    • 3.1.3 Snapshots (single patch or tarball)
  • 3.2 Regression testing
    • 3.2.1 Results for CCID3
    • 3.2.2 Testing with constant bitrate
• 4 Testbed setup for DCCP
  • 4.1 Enabling debugging output
  • 4.2 Setting TX/RX parameters
  • 4.3 Network emulation setup
  • 4.4 Monitoring DCCP

For packet-level tests, please consider using the DCCP Conformance Test Suite.

There are currently 3 different variants of ttcp with DCCP support, the two latter ones are more recent. Here is a very early client which worked with earlier versions of DCCP. A more up-to-date implementation is the `acme' variant, which is based on code developed by Arnaldo de Melo. It has been updated to produce more verbose output for TFRC (-v switch); it should be compiled like:

gcc ttcp_acme.c -o ttcp_acme -I ~/linuxsrc/dccpwork/include/

For comparison, the change to the original is in a different include:

-#include <netinet/tfrc.h>
 // #include <netinet/tfrc.h>
 #include <linux/tfrc.h>

Here is a sample testing setup.

On receive end (10.0.2.2):

ttcp -c -l256 -r

On send end (10.0.7.7):

ttcp -c -l256 -n1000 -t 10.0.2.2

The -l256 is used for the following reason: DCCP is a datagram-oriented protocol and works on fixed datagram sizes (fragmentation is not supported and not likely to be in the near future). To avoid sending datagrams larger than the path MTU, the datagram size must be set using the `-l' switch.

This is automated in the last version of ttcp, which automatically queries the path MTU and warns before sending too large datagrams, or even adjusts outgoing datagram size. This variant can be downloadedhere; it requires the MPS support from the DCCP test tree (see notes below).

Alternatively Iperf works better for many users.

There is a third alternative: netsend. It support nearly all DCCP options but isn't limited or focused on DCCP (e.g. support TCP-Lite, …).

Here is a simple client server application written using DCCP . A number of current applications are listed on a DCCP applications page. Lastly, here is sample code that uses the mmap interface for the 2.4 kernel - if people are interested in writing an mmap interface. It is no use trying it on Linux 2.6!!

Mainline kernel development takes a long time, even if changes are small, and DCCP is in some respects not a finished and fully tested protocol: to enable testing without the constraints of mainline development, a DCCP test tree has been set up.

This tree has features which are more recent than the mainline DCCP implementation. It is based on the netdev subtree by David Miller and contains patches from the DCCP mailing list which have not yet been integrated into the mainline kernel.

We encourage using this tree for tests and report suggestions and comments to the DCCP mailing list.

The experimental tree itself is contained as a subtree named `origin/dccp' within a standard git tree. The next two sections describe how to pull this.

To clone the entire tree (master basis plus `dccp' subtree), do the following:

 git-clone git://eden-feed.erg.abdn.ac.uk/dccp_exp my_dccp

This will give you a basis in the directory `my_dccp'. If you have any sources already, then it is much better and faster to specify a reference repository with the –reference argument - this significantly reduces download time. e.g:

 git-clone --reference mylinustree git://eden-feed.erg.abdn.ac.uk/dccp_exp my_dccp

where mylinustree is the directory with Linus' tree and my_dccp is the new directory you wish to create.

You still need to check out the DCCP sub-branch, by creating a branch named `dccp' (or something else), which needs to be checked out like this:

 git-checkout --track -b dccp origin/dccp

The `origin/dccp' is already in the sources you pulled, but you have to tell git to use it in a local branch.

However, as always, pulling entire source trees over the network takes a lot of bandwidth and time.

If you already have fairly recent git Linux sources, then cloning the subtree is much much faster (the differences amount to at most a few hundred KB). This variant is done from within your current Linux source tree. First, create a new separate branch:

 git-checkout -b dccp master

Now pull the experimental DCCP tree into this branch using

 git-pull git://eden-feed.erg.abdn.ac.uk/dccp_exp dccp

If you don't want to set up git or find the above process too laborious, you can download

• snapshot patches for most recent kernel versions from this directory (note: numbers are relative to git; if it does not apply cleanly on a www.kernel.org tree, try earlier version numbers, or report to dccp@vger),
• a nightly tarball of the DCCP test tree .

If you make changes to DCCP please test it by varying loss and delay as per above and compare the results to http://wand.net.nz/~perry/max_download.php - remember to change delayed acks from 2 to 1 or else the results are wrong.

Test this with Iperf running for 60 seconds, with 1424 byte packets.

iperf -d -l 1424 -c servername -p 5001 -t 60
iperf -d -l 1424 -s -p 5001

Test with:

• 10% loss and 150 millisecond delay
• 1% loss and 40 millisecond delay

Try it on both CCID2 and CCID3. Instructions on changing CCID are found at the DCCP page. Do at least 3 runs as results can vary a bit. Results don't need to exactly match as CCID3 is not exactly the same as TFRC and also the random loss can cause variation as can making losses in the same interval (which reduces loss rate, therefore higher throughput).

You should get close to line speed on two directly connected nodes or running with a router in between. NB There is an issue that Gerrit has identified here. You may also have an issue with CPU loading - check this when running also.

Leaving queue length at its default (5)

The byte-blast mode of Iperf can generate a lot of noise. In several test scenarios it is better to iteratively try higher bandwidths. The combined iperf patch has the -b switch which works in the same way as for UDP and enables CBR test runs. It requires that both the client (with an optional bandwidth specifier, e.g. `-b12m') and the server have CBR mode enabled. Further information can also be found here.

This test mode is very useful for debugging and for running dccp_probe test runs (CBR generates less noise).

For a simple testbed setup, you can use two computers connected via a cross-over cable. However, adding one computer in between – to emulate delay, loss, reordering – gives you a much more realistic test setting (see notes on the use of netem below). In particular, if you are developing DCCP code, we encourage you to use this setting for the above regression testing.

The DCCP debugging output is fairly verbose and can give you good initial hints of what is going on. To enable debugging output, you need to both enable it in the kernel configuration and toggle the `debug' switch of the respective module. To avoid having to do this each time, you can place these into a file underneath /etc/modutils.d or /etc/modprobe.d/ (see manpages for modules.conf and modprobe.conf), containing the following lines

 # options for DCCP
 options dccp            dccp_debug=1
 options dccp_ccid2      ccid2_debug=1
 options dccp_ccid3      ccid3_debug=1

See the DCCP page for scripts to load the individual CCIDs.

There are a number of parameters that can (and should) be fine-tuned for testing. These all reside as read/write variables under

 /proc/sys/net/dccp/default

These DCCP parameters are all described in Documentation/networking/dccp.txt. For example, to alter the TX queue length:

 echo $my_qlen > /proc/sys/net/dccp/default/tx_qlen

Typically use a queue length of 5 if emulating UDP-like traffic and 16K/packet size if emulating TCP (this is default buffer size on a machine using 2.6.20).

For more realistic testing, a separate box with at least two interfaces is used as a network emulator using the Netem kernel module. You can set the box up as router, but it is much simpler to configure it as a bridge and use the `tc' tool to set the traffic parameters. You will need the Netem utilities (the page also has a description of how to set up bridging).

Here is how to turn loss with delay on:

/sbin/tc qdisc add dev lan1 root netem delay $1ms loss $3%
/sbin/tc qdisc add dev lan0 root netem delay $1ms loss $2%

and off:

/sbin/tc qdisc del dev lan1 root netem
/sbin/tc qdisc del dev lan0 root netem

And rate control with delay on:

/sbin/tc qdisc add dev lan0 root handle 1:0 netem delay $1ms
/sbin/tc qdisc add dev lan1 root handle 1:0 netem delay $1ms
/sbin/tc qdisc add dev lan0 parent 1:1 handle 10: tbf rate $2kbit buffer 10000 limit 30000

and off:

/sbin/tc qdisc del dev lan0 parent 1:1
/sbin/tc qdisc del dev lan0 root
/sbin/tc qdisc del dev lan1 root

As you can see you can use Netem to produce scenarios such as no delay, delay, loss, no loss.

NB In most versions of Netem except latest a minimum of 1/HZ delay is introduced per packet.

DccpProbe is a good monitoring tool and helps you to debug. Its use is very much analogous to TcpProbe , i.e. it is loaded as a module

modprobe -v dccp_probe

Then you start a process reading from /proc/net/dccpprobe

cat /proc/net/dccpprobe >outfile & CAPTURE_PID=$!

After running any kind of traffic tests, simply kill the process and read the file:

iperf -d -c target-host -t 60; kill $CAPTURE_PID; less outfile

More detailed information, as well as sample scripts to post-process the output from dccp_probe, can be found on this page.