aboutsummaryrefslogtreecommitdiffstats
path: root/net/dccp/ccids/Kconfig
blob: 4b5db44970aa23c8e8032542d0f5d55ea6bed415 (plain) (blame)
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
menu "DCCP CCIDs Configuration (EXPERIMENTAL)"
	depends on EXPERIMENTAL

config IP_DCCP_CCID2_DEBUG
	bool "CCID-2 debugging messages"
	---help---
	  Enable CCID-2 specific debugging messages.

	  The debugging output can additionally be toggled by setting the
	  ccid2_debug parameter to 0 or 1.

	  If in doubt, say N.

config IP_DCCP_CCID3
	bool "CCID-3 (TCP-Friendly) (EXPERIMENTAL)"
	def_bool y if (IP_DCCP = y || IP_DCCP = m)
	---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 5348.

	  This text was extracted from RFC 4340 (sec. 10.2),
	  http://www.ietf.org/rfc/rfc4340.txt

	  If in doubt, say N.

config IP_DCCP_CCID3_DEBUG
	bool "CCID-3 debugging messages"
	depends on IP_DCCP_CCID3
	---help---
	  Enable CCID-3 specific debugging messages.

	  The debugging output can additionally be toggled by setting the
	  ccid3_debug 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
	def_bool y if IP_DCCP_CCID3

config IP_DCCP_TFRC_DEBUG
	def_bool y if IP_DCCP_CCID3_DEBUG
endmenu