111 lines
3.7 KiB
Plaintext
111 lines
3.7 KiB
Plaintext
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 proposed standard RFC status and the homepage for DCCP as a protocol
|
|
is at:
|
|
http://www.read.cs.ucla.edu/dccp/
|
|
|
|
Missing features
|
|
================
|
|
|
|
The DCCP implementation does not currently have all the features that are in
|
|
the RFC.
|
|
|
|
The known bugs are at:
|
|
http://linux-net.osdl.org/index.php/TODO#DCCP
|
|
|
|
Socket options
|
|
==============
|
|
|
|
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.
|
|
|
|
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]).
|
|
|
|
Sysctl variables
|
|
================
|
|
Several DCCP default parameters can be managed by the following sysctls
|
|
(sysctl net.dccp.default or /proc/sys/net/dccp/default):
|
|
|
|
request_retries
|
|
The number of active connection initiation retries (the number of
|
|
Requests minus one) before timing out. In addition, it also governs
|
|
the behaviour of the other, passive side: this variable also sets
|
|
the number of times DCCP repeats sending a Response when the initial
|
|
handshake does not progress from RESPOND to OPEN (i.e. when no Ack
|
|
is received after the initial Request). This value should be greater
|
|
than 0, suggested is less than 10. Analogue of tcp_syn_retries.
|
|
|
|
retries1
|
|
How often a DCCP Response is retransmitted until the listening DCCP
|
|
side considers its connecting peer dead. Analogue of tcp_retries1.
|
|
|
|
retries2
|
|
The number of times a general DCCP packet is retransmitted. This has
|
|
importance for retransmitted acknowledgments and feature negotiation,
|
|
data packets are never retransmitted. Analogue of tcp_retries2.
|
|
|
|
send_ndp = 1
|
|
Whether or not to send NDP count options (sec. 7.7.2).
|
|
|
|
send_ackvec = 1
|
|
Whether or not to send Ack Vector options (sec. 11.5).
|
|
|
|
ack_ratio = 2
|
|
The default Ack Ratio (sec. 11.3) to use.
|
|
|
|
tx_ccid = 2
|
|
Default CCID for the sender-receiver half-connection.
|
|
|
|
rx_ccid = 2
|
|
Default CCID for the receiver-sender half-connection.
|
|
|
|
seq_window = 100
|
|
The initial sequence window (sec. 7.5.2).
|
|
|
|
tx_qlen = 5
|
|
The size of the transmit buffer in packets. A value of 0 corresponds
|
|
to an unbounded transmit buffer.
|
|
|
|
Notes
|
|
=====
|
|
|
|
DCCP does not travel through NAT successfully at present on many boxes. This is
|
|
because the checksum covers the psuedo-header as per TCP and UDP. Linux NAT
|
|
support for DCCP has been added.
|