View Source: DCCP - Waikato Linux Users Group

Edit PageHistory Diff Info LikePages
[Acronym] for __D__atagram __C__ongestion __C__ontrol __P__rotocol.

DCCP is a transport level protocol (like [TCP] and [UDP]) which aims to solve many different congestion issues. This is useful for applications that don't need the data reliability/re-transmission of [TCP], but want a session and want congestion control unlike [UDP].

DCCP is a series of proposed standard [RFC]s (4340-4342)

The main reference page on the web for DCCP is here:
http://www.read.cs.ucla.edu/dccp/

There is also a [writeup at LWN|http://lwn.net/Articles/149756/].

!!DCCP stack for Linux

Much of this page is shifting to http://linux-net.osdl.org/index.php/DCCP - that page is considered the definitive reference for the DCCP implementation for Linux.

DCCP is present in the [LinuxKernel]. This is being maintained by ArnaldoMelo at present. The history of this is that it draws from the code of Patrick ~McManus, Lulea and the WandGroup that IanMcDonald is part of. It was accepted into the LinuxKernel by LinusTorvalds in 2.6.14. It continues to evolve rapidly at time of writing (preparatory 2.6.20) and it usually pays to get the latest code from a [Git] tree.

The core DCCP stack was written by ArnaldoMelo using the Linux [TCP] implementation as a model, with DCCP being used as a way to identify code in the [TCP] implementation that could be made generic and shared with other INET transport level implementations. This resulted in the generalisation of code related to the minisockets representing both TCP_SYN_RECV/DCCP_RESPOND and TCP_TIME_WAIT/DCCP_TIME_WAIT status, code related to established/timewait/listen sockets (inet_lookup, inet_lookup_established, etc), the interface to get sock  information (tcp_diag), and many other functions and data structures, with more expected to be generalised and eventually used by [SCTP] and any other INET transport protocols that may be introduced in the future.

The [CCID]3 code was, as IanMcDonald mentioned, drawn from the WandGroup, that in turn got it initially from the Lulea [FreeBSD] codebase and made it work in the core DCCP stack written by Patrick ~McManus. It was modified by ArnaldoMelo to fit Linux standards wrt list handling and several other aspects.

The [CCID] modular infrastructure was written to fit the [CCID]3 existing interface, but will probably be changed in the near future in the effort to have a generic CA (Congestion Avoidance) infrastructure shared with [TCP] (and others, who knows), continuing work on the existing [TCP] CA infrastructure put in place by Stephen Hemminger.

To have a look at the theoretical performance of [CCID]3 see http://wand.net.nz/~perry/max_download.php - the codebase currently calculates s using a weighted average.

!!TcpDump support

TcpDump now has DCCP support in the tree. There is TcpDump support available at http://wand.cs.waikato.ac.nz/~iam4/dccp/tcpdump8.diff for older versions. This applies to many versions and at least the weekly build from CVS of tcpdump dated 22nd August 2005. Remember to run tcpdump(8) with a -s0 parameter to capture all data (or some other value) as the default size gets the base DCCP header, but not the options, in many cases.

!![Ethereal] support and [FreeBSD] support (with sample programs)

See http://www.jp.nishida.org/dccp/

!!TIMEWAIT sockets

Arnaldo writes: TIMEWAIT sockets are finally implemented and we have initial support for iproute2, so just enable INET_DIAG and if enabled as a module make sure it is load prior to using the iproute2 utilities, like ss.

The latest iproute2 version, available at: http://developer.osdl.org/dev/iproute2/download/iproute2-ss050901.tar.bz2 now includes DCCP support directly.

Then use it:

<verbatim>
[root@qemu ~]# ./ss -dane
State       Recv-Q Send-Q Local Address:Port Peer Address:Port
LISTEN      0      0                  *:5001             *:*      ino:730 sk:cfd503a0
ESTAB       0      0          127.0.0.1:5001     127.0.0.1:32770  ino:731 sk:cfd51480
ESTAB       0      0          127.0.0.1:32770    127.0.0.1:5001   ino:741 sk:cfd517e0
[root@qemu ~]#
[root@qemu ~]# ./ss -dane
State       Recv-Q Send-Q Local Address:Port Peer Address:Port
TIME-WAIT   0      0          127.0.0.1:32770   127.0.0.1:5001    timer:(timewait,59sec,0)
                                                                  ino:0 sk:cf12a620
</verbatim>

The above listing was with the ttcp test.

!!Netcat support

See http://linux-net.osdl.org/index.php/DCCP#netcat_support

!!Mailing List Archives

http://www1.ietf.org/mail-archive/web/dccp/current/index.html - A discussion of the DCCP protocol by the IETF

http://www.mail-archive.com/dccp@vger.kernel.org/ - a discussion of the Linux implementation of DCCP

!!To do & testing

There is a [Todo list|http://linux-net.osdl.org/index.php/TODO#DCCP] also which tracks the issues needing working on.

There is a [DCCPTesting|http://linux-net.osdl.org/index.php/DCCP_Testing] page which also talks about the status of testing in [DCCP].

For sample code have a look at the applications ported or you can contact IanMcDonald

There are a couple of ttcp implementations for DCCP available for the 2.6 [LinuxKernel]:
* http://wand.net.nz/~iam4/dccp/ttcp_new.c that works with earlier versions of [DCCP]
* http://wand.net.nz/~iam4/dccp/ttcp_acme.c that works with later versions of [DCCP] that require the service option to be set (gives ERRNO of 22 otherwise). This has had include files altered slightly from [ArnaldoMelo]s version (just for TFRC) and should be compiled like
<pre>
gcc ttcp_acme.c -o ttcp_acme -I ~~/linuxsrc/dccpwork/include/
</pre>
change is:
<pre>
-#include <netinet/tfrc.h>
+// #include <netinet/tfrc.h>
+#include <linux/tfrc.h>
</pre>

!!FAQ

See [FAQ|http://linux-net.osdl.org/index.php/DCCP#FAQ]

For more details, ask IanMcDonald from the WandGroup.

See also:

* KernelDevelopment
----
CategoryProtocols
7 pages link to DCCP:
Last edited on Wednesday, May 30, 2007 4:09:28 pm by IanMcDonald
Edit PageHistory Diff Info LikePages