16 Datagram Congestion Control Protocol (DCCP) is an unreliable, connection
17 based protocol designed to solve issues present in UDP and TCP particularly
18 for real time and multimedia traffic.
20 It has a base protocol and pluggable congestion control IDs (CCIDs).
22 It is at draft RFC status and the homepage for DCCP as a protocol is at:
23 http://www.icir.org/kohler/dcp/
28 The DCCP implementation does not currently have all the features that are in
31 In particular the following are missing:
35 When testing against other implementations it appears that elapsed time
36 options are not coded compliant to the specification.
41 DCCP_SOCKOPT_PACKET_SIZE is used for CCID3 to set default packet size for
44 DCCP_SOCKOPT_SERVICE sets the service. The specification mandates use of
45 service codes (RFC 4340, sec. 8.1.2); if this socket option is not set,
46 the socket will fall back to 0 (which means that no meaningful service code
47 is present). Connecting sockets set at most one service option; for
48 listening sockets, multiple service codes can be specified.
50 DCCP_SOCKOPT_SEND_CSCOV and DCCP_SOCKOPT_RECV_CSCOV are used for setting the
51 partial checksum coverage (RFC 4340, sec. 9.2). The default is that checksums
52 always cover the entire packet and that only fully covered application data is
53 accepted by the receiver. Hence, when using this feature on the sender, it must
54 be enabled at the receiver, too with suitable choice of CsCov.
56 DCCP_SOCKOPT_SEND_CSCOV sets the sender checksum coverage. Values in the
57 range 0..15 are acceptable. The default setting is 0 (full coverage),
58 values between 1..15 indicate partial coverage.
59 DCCP_SOCKOPT_SEND_CSCOV is for the receiver and has a different meaning: it
60 sets a threshold, where again values 0..15 are acceptable. The default
61 of 0 means that all packets with a partial coverage will be discarded.
62 Values in the range 1..15 indicate that packets with minimally such a
63 coverage value are also acceptable. The higher the number, the more
64 restrictive this setting (see [RFC 4340, sec. 9.2.1]).
68 Several DCCP default parameters can be managed by the following sysctls
69 (sysctl net.dccp.default or /proc/sys/net/dccp/default):
72 The number of active connection initiation retries (the number of
73 Requests minus one) before timing out. In addition, it also governs
74 the behaviour of the other, passive side: this variable also sets
75 the number of times DCCP repeats sending a Response when the initial
76 handshake does not progress from RESPOND to OPEN (i.e. when no Ack
77 is received after the initial Request). This value should be greater
78 than 0, suggested is less than 10. Analogue of tcp_syn_retries.
81 How often a DCCP Response is retransmitted until the listening DCCP
82 side considers its connecting peer dead. Analogue of tcp_retries1.
85 The number of times a general DCCP packet is retransmitted. This has
86 importance for retransmitted acknowledgments and feature negotiation,
87 data packets are never retransmitted. Analogue of tcp_retries2.
90 Whether or not to send NDP count options (sec. 7.7.2).
93 Whether or not to send Ack Vector options (sec. 11.5).
96 The default Ack Ratio (sec. 11.3) to use.
99 Default CCID for the sender-receiver half-connection.
102 Default CCID for the receiver-sender half-connection.
105 The initial sequence window (sec. 7.5.2).
110 SELinux does not yet have support for DCCP. You will need to turn it off or
111 else you will get EACCES.
113 DCCP does not travel through NAT successfully at present. This is because
114 the checksum covers the psuedo-header as per TCP and UDP. It should be
115 relatively trivial to add Linux NAT support for DCCP.