aboutsummaryrefslogtreecommitdiffstats
path: root/net/dccp/ccids/Kconfig
blob: 32752f7504476013933574f754c87d87f2bf935f (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
menu "DCCP CCIDs Configuration (EXPERIMENTAL)"
	depends on IP_DCCP && EXPERIMENTAL

config IP_DCCP_CCID2
	tristate "CCID2 (TCP-Like) (EXPERIMENTAL)"
	depends on IP_DCCP
	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.

	  CCID 2 is further described in:
	  http://www.icir.org/kohler/dccp/draft-ietf-dccp-ccid2-10.txt

	  This text was extracted from:
	  http://www.icir.org/kohler/dccp/draft-ietf-dccp-spec-13.txt

	  If in doubt, say M.

config IP_DCCP_CCID2_DEBUG
	  bool "CCID2 debug"
	  depends on IP_DCCP_CCID2
	  ---help---
	    Enable CCID2 debug messages.

	    If in doubt, say N.

config IP_DCCP_CCID3
	tristate "CCID3 (TCP-Friendly) (EXPERIMENTAL)"
	depends on IP_DCCP
	def_tristate IP_DCCP
	---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:

	  http://www.icir.org/kohler/dccp/draft-ietf-dccp-ccid3-11.txt.

	  The TFRC congestion control algorithms were initially described in
	  RFC 3448.

	  This text was extracted from:
	  http://www.icir.org/kohler/dccp/draft-ietf-dccp-spec-13.txt
	  
	  If in doubt, say M.

config IP_DCCP_TFRC_LIB
	depends on IP_DCCP_CCID3
	def_tristate IP_DCCP_CCID3

endmenu