87 lines
		
	
	
		
			3.0 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
			
		
		
	
	
			87 lines
		
	
	
		
			3.0 KiB
		
	
	
	
		
			Plaintext
		
	
	
	
	
	
| 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
 |