/kern_oII/Documentation/networking/dccp.txt
http://omnia2droid.googlecode.com/ · Plain Text · 167 lines · 131 code · 36 blank · 0 comment · 0 complexity · 7b2d975e4685267cee9dc4fa746ca511 MD5 · raw file
- DCCP protocol
- ============
- Contents
- ========
- - Introduction
- - Missing features
- - Socket options
- - Notes
- Introduction
- ============
- Datagram Congestion Control Protocol (DCCP) is an unreliable, connection
- oriented protocol designed to solve issues present in UDP and TCP, particularly
- for real-time and multimedia (streaming) traffic.
- It divides into a base protocol (RFC 4340) and plugable congestion control
- modules called CCIDs. Like plugable TCP congestion control, at least one CCID
- needs to be enabled in order for the protocol to function properly. In the Linux
- implementation, this is the TCP-like CCID2 (RFC 4341). Additional CCIDs, such as
- the TCP-friendly CCID3 (RFC 4342), are optional.
- For a brief introduction to CCIDs and suggestions for choosing a CCID to match
- given applications, see section 10 of RFC 4340.
- It has a base protocol and pluggable congestion control IDs (CCIDs).
- DCCP is a Proposed Standard (RFC 2026), and the homepage for DCCP as a protocol
- is at http://www.ietf.org/html.charters/dccp-charter.html
- Missing features
- ================
- The Linux DCCP implementation does not currently support all the features that are
- specified in RFCs 4340...42.
- The known bugs are at:
- http://linux-net.osdl.org/index.php/TODO#DCCP
- For more up-to-date versions of the DCCP implementation, please consider using
- the experimental DCCP test tree; instructions for checking this out are on:
- http://linux-net.osdl.org/index.php/DCCP_Testing#Experimental_DCCP_source_tree
- 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). On active sockets this is set before connect(); specifying more
- than one code has no effect (all subsequent service codes are ignored). The
- case is different for passive sockets, where multiple service codes (up to 32)
- can be set before calling bind().
- DCCP_SOCKOPT_GET_CUR_MPS is read-only and retrieves the current maximum packet
- size (application payload size) in bytes, see RFC 4340, section 14.
- DCCP_SOCKOPT_AVAILABLE_CCIDS is also read-only and returns the list of CCIDs
- supported by the endpoint (see include/linux/dccp.h for symbolic constants).
- The caller needs to provide a sufficiently large (> 2) array of type uint8_t.
- DCCP_SOCKOPT_CCID is write-only and sets both the TX and RX CCIDs at the same
- time, combining the operation of the next two socket options. This option is
- preferrable over the latter two, since often applications will use the same
- type of CCID for both directions; and mixed use of CCIDs is not currently well
- understood. This socket option takes as argument at least one uint8_t value, or
- an array of uint8_t values, which must match available CCIDS (see above). CCIDs
- must be registered on the socket before calling connect() or listen().
- DCCP_SOCKOPT_TX_CCID is read/write. It returns the current CCID (if set) or sets
- the preference list for the TX CCID, using the same format as DCCP_SOCKOPT_CCID.
- Please note that the getsockopt argument type here is `int', not uint8_t.
- DCCP_SOCKOPT_RX_CCID is analogous to DCCP_SOCKOPT_TX_CCID, but for the RX CCID.
- DCCP_SOCKOPT_SERVER_TIMEWAIT enables the server (listening socket) to hold
- timewait state when closing the connection (RFC 4340, 8.3). The usual case is
- that the closing server sends a CloseReq, whereupon the client holds timewait
- state. When this boolean socket option is on, the server sends a Close instead
- and will enter TIMEWAIT. This option must be set after accept() returns.
- 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_RECV_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]). Partial coverage
- settings are inherited to the child socket after accept().
- The following two options apply to CCID 3 exclusively and are getsockopt()-only.
- In either case, a TFRC info struct (defined in <linux/tfrc.h>) is returned.
- DCCP_SOCKOPT_CCID_RX_INFO
- Returns a `struct tfrc_rx_info' in optval; the buffer for optval and
- optlen must be set to at least sizeof(struct tfrc_rx_info).
- DCCP_SOCKOPT_CCID_TX_INFO
- Returns a `struct tfrc_tx_info' in optval; the buffer for optval and
- optlen must be set to at least sizeof(struct tfrc_tx_info).
- On unidirectional connections it is useful to close the unused half-connection
- via shutdown (SHUT_WR or SHUT_RD): this will reduce per-packet processing costs.
- 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.
- tx_ccid = 2
- Default CCID for the sender-receiver half-connection. Depending on the
- choice of CCID, the Send Ack Vector feature is enabled automatically.
- rx_ccid = 2
- Default CCID for the receiver-sender half-connection; see tx_ccid.
- seq_window = 100
- The initial sequence window (sec. 7.5.2) of the sender. This influences
- the local ackno validity and the remote seqno validity windows (7.5.1).
- tx_qlen = 5
- The size of the transmit buffer in packets. A value of 0 corresponds
- to an unbounded transmit buffer.
- sync_ratelimit = 125 ms
- The timeout between subsequent DCCP-Sync packets sent in response to
- sequence-invalid packets on the same socket (RFC 4340, 7.5.4). The unit
- of this parameter is milliseconds; a value of 0 disables rate-limiting.
- IOCTLS
- ======
- FIONREAD
- Works as in udp(7): returns in the `int' argument pointer the size of
- the next pending datagram in bytes, or 0 when no datagram is pending.
- Notes
- =====
- DCCP does not travel through NAT successfully at present on many boxes. This is
- because the checksum covers the pseudo-header as per TCP and UDP. Linux NAT
- support for DCCP has been added.