diff options
Diffstat (limited to 'Documentation/networking/dccp.txt')
| -rw-r--r-- | Documentation/networking/dccp.txt | 84 |
1 files changed, 69 insertions, 15 deletions
diff --git a/Documentation/networking/dccp.txt b/Documentation/networking/dccp.txt index 74563b38ffd..dda15886bcb 100644 --- a/Documentation/networking/dccp.txt +++ b/Documentation/networking/dccp.txt @@ -19,21 +19,17 @@ 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/ +It is at experimental 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 draft RFC. +the 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. +The known bugs are at: + http://linux-net.osdl.org/index.php/TODO#DCCP Socket options ============== @@ -47,12 +43,70 @@ 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 ===== -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. +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. |