The OSDL pages have some instructions on how to use this. The
principle is to
- load the kernel module: modprobe
-v dccp_probe
- read /proc/net/dccpprobe in the background: cat /proc/net/dccpprobe
>outfile& PID=$?
- kill the process after running the tests: kill $PID
- perform analysis of `outfile'
when you are done
Here is a
script which automates the
process with some more bells and whistles. Here is a list of scripts
which can be used to analyse the output (the above pictures were
generated that way, you may need to install
gnuplot):
Using a separate box for traffic
manipulation
To emulate network conditions, a separate box running
NetEm is normally
useful. By far the easiest way is to configure such a box (which will
have at least two interfaces) as a layer-2 bridge. Here is a
script to set this up. However, under
Debian there is an even simpler way: install
bridge-utils package and read
the accompanying documentation. The simplest bridge configuration is to
use an
/etc/network/interfaces
such as
auto br0
iface br0 inet manual
bridge_ports eth1 eth2
bridge_maxwait 0
When done setting up a bridge, use tc(8) to set up queueing disciplines
- see the instructions on the
DCCP testing
page. For CCID3 testing, you can find a useful script for
loss/delay (which computes the expected TFRC rate)
here.
Implementing
new CCIDs
Adding a
new CCID requires a
few steps apart from the obvious ones of
adding Kconfig/Makefile entries:
- adding a symbolic identifier in include/linux/dccp.h
- adding an entry to `builtin_ccids' in net/dccp/ccids.c
- adding the symbolic name and and a CCID-specific dependency table
in net/dccp/feat.c
As an
example, we have a
fully working
CCID NULL "(UDP-like)"
which is
a self-contained CCID module sans congestion-control internals. The
UDP-like CCID can be downloaded
here, and
a more detailed description of the steps involved in registering
appeared in
this
posting.