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