1 menu "DCCP CCIDs Configuration (EXPERIMENTAL)"
2 depends on IP_DCCP && EXPERIMENTAL
5 tristate "CCID2 (TCP-Like) (EXPERIMENTAL)"
10 CCID 2, TCP-like Congestion Control, denotes Additive Increase,
11 Multiplicative Decrease (AIMD) congestion control with behavior
12 modelled directly on TCP, including congestion window, slow start,
13 timeouts, and so forth [RFC 2581]. CCID 2 achieves maximum
14 bandwidth over the long term, consistent with the use of end-to-end
15 congestion control, but halves its congestion window in response to
16 each congestion event. This leads to the abrupt rate changes
17 typical of TCP. Applications should use CCID 2 if they prefer
18 maximum bandwidth utilization to steadiness of rate. This is often
19 the case for applications that are not playing their data directly
20 to the user. For example, a hypothetical application that
21 transferred files over DCCP, using application-level retransmissions
22 for lost packets, would prefer CCID 2 to CCID 3. On-line games may
23 also prefer CCID 2. See RFC 4341 for further details.
25 CCID2 is the default CCID used by DCCP.
27 config IP_DCCP_CCID2_DEBUG
28 bool "CCID2 debugging messages"
29 depends on IP_DCCP_CCID2
31 Enable CCID2-specific debugging messages.
33 When compiling CCID2 as a module, this debugging output can
34 additionally be toggled by setting the ccid2_debug module
40 tristate "CCID3 (TCP-Friendly) (EXPERIMENTAL)"
44 CCID 3 denotes TCP-Friendly Rate Control (TFRC), an equation-based
45 rate-controlled congestion control mechanism. TFRC is designed to
46 be reasonably fair when competing for bandwidth with TCP-like flows,
47 where a flow is "reasonably fair" if its sending rate is generally
48 within a factor of two of the sending rate of a TCP flow under the
49 same conditions. However, TFRC has a much lower variation of
50 throughput over time compared with TCP, which makes CCID 3 more
51 suitable than CCID 2 for applications such streaming media where a
52 relatively smooth sending rate is of importance.
54 CCID 3 is further described in RFC 4342,
55 http://www.ietf.org/rfc/rfc4342.txt
57 The TFRC congestion control algorithms were initially described in
60 This text was extracted from RFC 4340 (sec. 10.2),
61 http://www.ietf.org/rfc/rfc4340.txt
63 To compile this CCID as a module, choose M here: the module will be
68 config IP_DCCP_TFRC_LIB
69 depends on IP_DCCP_CCID3
70 def_tristate IP_DCCP_CCID3
72 config IP_DCCP_CCID3_DEBUG
73 bool "CCID3 debugging messages"
74 depends on IP_DCCP_CCID3
76 Enable CCID3-specific debugging messages.
78 When compiling CCID3 as a module, this debugging output can
79 additionally be toggled by setting the ccid3_debug module
84 config IP_DCCP_CCID3_RTO
85 int "Use higher bound for nofeedback timer"
87 depends on IP_DCCP_CCID3 && EXPERIMENTAL
89 Use higher lower bound for nofeedback timer expiration.
91 The TFRC nofeedback timer normally expires after the maximum of 4
92 RTTs and twice the current send interval (RFC 3448, 4.3). On LANs
93 with a small RTT this can mean a high processing load and reduced
94 performance, since then the nofeedback timer is triggered very
97 This option enables to set a higher lower bound for the nofeedback
98 value. Values in units of milliseconds can be set here.
100 A value of 0 disables this feature by enforcing the value specified
101 in RFC 3448. The following values have been suggested as bounds for
103 * 16-20ms to match the typical multimedia inter-frame interval
104 * 100ms as a reasonable compromise [default]
105 * 1000ms corresponds to the lower TCP RTO bound (RFC 2988, 2.4)
107 The default of 100ms is a compromise between a large value for
108 efficient DCCP implementations, and a small value to avoid disrupting
109 the network in times of congestion.
111 The purpose of the nofeedback timer is to slow DCCP down when there
112 is serious network congestion: experimenting with larger values should
113 therefore not be performed on WANs.