[net-next-2.6.git] / net / dccp / ccids / Kconfig

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.  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)"
	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 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_TFRC_LIB
	depends on IP_DCCP_CCID3
	def_tristate IP_DCCP_CCID3

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.


endmenu
Commit	Line	Data
7c657876 ACM	1	menu "DCCP CCIDs Configuration (EXPERIMENTAL)"
	2	depends on IP_DCCP && EXPERIMENTAL
	3
2a91aa39	4	config IP_DCCP_CCID2
057fc675	5	tristate "CCID2 (TCP-Like) (EXPERIMENTAL)"
2a91aa39	6	depends on IP_DCCP
057fc675	7	def_tristate IP_DCCP
2a91aa39 AB	8	select IP_DCCP_ACKVEC
	9	---help---
	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
e333b3ed	23	also prefer CCID 2. See RFC 4341 for further details.
2a91aa39	24
e333b3ed	25	CCID2 is the default CCID used by DCCP.
2a91aa39	26
8d424f6c	27	config IP_DCCP_CCID2_DEBUG
84116716	28	bool "CCID2 debugging messages"
8d424f6c AB	29	depends on IP_DCCP_CCID2
8d424f6c AB	30	---help---
84116716 GR	31	Enable CCID2-specific debugging messages.
	32
	33	When compiling CCID2 as a module, this debugging output can
	34	additionally be toggled by setting the ccid2_debug module
	35	parameter to 0 or 1.
8d424f6c AB	36
	37	If in doubt, say N.
	38
7c657876	39	config IP_DCCP_CCID3
057fc675	40	tristate "CCID3 (TCP-Friendly) (EXPERIMENTAL)"
7c657876	41	depends on IP_DCCP
057fc675	42	def_tristate IP_DCCP
7c657876 ACM	43	---help---
	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.
	53
0e64e94e GR	54	CCID 3 is further described in RFC 4342,
0e64e94e GR	55	http://www.ietf.org/rfc/rfc4342.txt
2a91aa39 AB	56
	57	The TFRC congestion control algorithms were initially described in
	58	RFC 3448.
7c657876	59
0e64e94e GR	60	This text was extracted from RFC 4340 (sec. 10.2),
0e64e94e GR	61	http://www.ietf.org/rfc/rfc4340.txt
7c657876	62
84116716 GR	63	To compile this CCID as a module, choose M here: the module will be
	64	called dccp_ccid3.
	65
7c657876 ACM	66	If in doubt, say M.
7c657876 ACM	67
5cea0ddc ACM	68	config IP_DCCP_TFRC_LIB
	69	depends on IP_DCCP_CCID3
	70	def_tristate IP_DCCP_CCID3
	71
56724aa4 GR	72	config IP_DCCP_CCID3_DEBUG
	73	bool "CCID3 debugging messages"
	74	depends on IP_DCCP_CCID3
	75	---help---
	76	Enable CCID3-specific debugging messages.
	77
	78	When compiling CCID3 as a module, this debugging output can
	79	additionally be toggled by setting the ccid3_debug module
	80	parameter to 0 or 1.
	81
	82	If in doubt, say N.
8a508ac2 GR	83
	84	config IP_DCCP_CCID3_RTO
	85	int "Use higher bound for nofeedback timer"
	86	default 100
	87	depends on IP_DCCP_CCID3 && EXPERIMENTAL
	88	---help---
	89	Use higher lower bound for nofeedback timer expiration.
	90
	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
	95	frequently.
	96
	97	This option enables to set a higher lower bound for the nofeedback
	98	value. Values in units of milliseconds can be set here.
	99
	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
	102	experimental use:
	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)
	106
	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.
	110
	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.
	114
	115
7c657876	116	endmenu