There are currently 3 different variants of ttcp with DCCP support, the two latter ones are more recent. Here[3] is a very early client which worked with earlier versions of DCCP. A more up-to-date implementation is the `acme' variant[4], 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:

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[5]; it requires the MPS support from the DCCP test tree (see notes below).

Here[8] is a simple client server application written using DCCP [9]. A number of current applications are listed on a DCCP applications page[5]. Lastly, here[10] 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[11].

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:

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.

Faster variant: DCCP subtree only

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

Snapshots (single patch or tarball)

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[12] (note: numbers are relative to git; if it does not apply cleanly on a www.kernel.org[13] tree, try earlier version numbers, or report to dccp@vger),

Try it on both CCID2 and CCID3. Instructions on changing CCID are found at the DCCP [9] 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[16]. You may also have an issue with CPU loading - check this when running also.

The byte-blast mode of Iperf [6] 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[17].

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

For more realistic testing, a separate box with at least two interfaces is used as a network emulator using the Netem [18] 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 [19] utilities (the page also has a description of how to set up bridging).