2005-11-10 14:04:33 -07:00
|
|
|
DCCP protocol
|
|
|
|
============
|
|
|
|
|
|
|
|
|
|
|
|
Contents
|
|
|
|
========
|
|
|
|
|
|
|
|
- Introduction
|
|
|
|
- Missing features
|
|
|
|
- Socket options
|
|
|
|
- Notes
|
|
|
|
|
|
|
|
Introduction
|
|
|
|
============
|
|
|
|
|
|
|
|
Datagram Congestion Control Protocol (DCCP) is an unreliable, connection
|
|
|
|
based protocol designed to solve issues present in UDP and TCP particularly
|
|
|
|
for real time and multimedia traffic.
|
|
|
|
|
|
|
|
It has a base protocol and pluggable congestion control IDs (CCIDs).
|
|
|
|
|
|
|
|
It is at draft RFC status and the homepage for DCCP as a protocol is at:
|
|
|
|
http://www.icir.org/kohler/dcp/
|
|
|
|
|
|
|
|
Missing features
|
|
|
|
================
|
|
|
|
|
|
|
|
The DCCP implementation does not currently have all the features that are in
|
|
|
|
the draft RFC.
|
|
|
|
|
|
|
|
In particular the following are missing:
|
|
|
|
- CCID2 support
|
|
|
|
- feature negotiation
|
|
|
|
|
|
|
|
When testing against other implementations it appears that elapsed time
|
|
|
|
options are not coded compliant to the specification.
|
|
|
|
|
|
|
|
Socket options
|
|
|
|
==============
|
|
|
|
|
|
|
|
DCCP_SOCKOPT_PACKET_SIZE is used for CCID3 to set default packet size for
|
|
|
|
calculations.
|
|
|
|
|
2006-09-22 01:33:58 -07:00
|
|
|
DCCP_SOCKOPT_SERVICE sets the service. The specification mandates use of
|
|
|
|
service codes (RFC 4340, sec. 8.1.2); if this socket option is not set,
|
|
|
|
the socket will fall back to 0 (which means that no meaningful service code
|
|
|
|
is present). Connecting sockets set at most one service option; for
|
|
|
|
listening sockets, multiple service codes can be specified.
|
2005-11-10 14:04:33 -07:00
|
|
|
|
2006-11-10 12:43:06 -07:00
|
|
|
DCCP_SOCKOPT_SEND_CSCOV and DCCP_SOCKOPT_RECV_CSCOV are used for setting the
|
|
|
|
partial checksum coverage (RFC 4340, sec. 9.2). The default is that checksums
|
|
|
|
always cover the entire packet and that only fully covered application data is
|
|
|
|
accepted by the receiver. Hence, when using this feature on the sender, it must
|
|
|
|
be enabled at the receiver, too with suitable choice of CsCov.
|
|
|
|
|
|
|
|
DCCP_SOCKOPT_SEND_CSCOV sets the sender checksum coverage. Values in the
|
|
|
|
range 0..15 are acceptable. The default setting is 0 (full coverage),
|
|
|
|
values between 1..15 indicate partial coverage.
|
|
|
|
DCCP_SOCKOPT_SEND_CSCOV is for the receiver and has a different meaning: it
|
|
|
|
sets a threshold, where again values 0..15 are acceptable. The default
|
|
|
|
of 0 means that all packets with a partial coverage will be discarded.
|
|
|
|
Values in the range 1..15 indicate that packets with minimally such a
|
|
|
|
coverage value are also acceptable. The higher the number, the more
|
|
|
|
restrictive this setting (see [RFC 4340, sec. 9.2.1]).
|
|
|
|
|
2005-11-10 14:04:33 -07:00
|
|
|
Notes
|
|
|
|
=====
|
|
|
|
|
|
|
|
SELinux does not yet have support for DCCP. You will need to turn it off or
|
|
|
|
else you will get EACCES.
|
|
|
|
|
|
|
|
DCCP does not travel through NAT successfully at present. This is because
|
|
|
|
the checksum covers the psuedo-header as per TCP and UDP. It should be
|
|
|
|
relatively trivial to add Linux NAT support for DCCP.
|