Signed-off-by: Leandro Sales <[EMAIL PROTECTED]>
Organize the help for ccid-4 menu with a more apropriate description,
the correct
URL for CCID-4 draft and remove the code duplication for TFRC by using
"depends on CCID3 || CCID4" in the IP_DCCP_TFRC_LIB config.
diff -uprN dccp-ccid4.base/net/dccp/ccids/Kconfig
dccp-ccid4/net/dccp/ccids/Kconfig
--- dccp-ccid4.base/net/dccp/ccids/Kconfig 2007-09-20 11:45:30.000000000
-0300
+++ dccp-ccid4/net/dccp/ccids/Kconfig 2007-09-20 13:53:13.000000000 -0300
@@ -106,9 +106,9 @@ config IP_DCCP_CCID3_RTO
is serious network congestion: experimenting with larger values
should
therefore not be performed on WANs.
-# The TFRC Library: currently only has CCID 3 as customer
+# The TFRC Library: currently has CCID 3 and CCID 4 as customer
config IP_DCCP_TFRC_LIB
- depends on IP_DCCP_CCID3
+ depends on IP_DCCP_CCID3 || IP_DCCP_CCID4
def_tristate IP_DCCP_CCID3
config IP_DCCP_TFRC_DEBUG
@@ -116,86 +116,80 @@ config IP_DCCP_TFRC_DEBUG
default y if IP_DCCP_CCID3_DEBUG
config IP_DCCP_CCID4
- tristate "CCID4 (TCP-Friendly, Small Packet Variant) (EXPERIMENTAL)"
- depends on IP_DCCP
- def_tristate IP_DCCP
- ---help---
- CCID 4 denotes the Small-Packet variant of TCP-Friendly Rate Control
- (TFRC-SP), an equation-based rate-controlled congestion control
- mechanism. TFRC-SP 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-SP has a much lower variation of throughput over time compared
- with TCP, which makes CCID 4 more suitable than CCID 2 for
- applications such streaming media where a relatively smooth sending
- rate is of importance.
-
- CCID 4 is further described in RFC xxxx,
- http://www.ietf.org/rfc/rfcXXXX.txt
-
- The TFRC-SP congestion control algorithms were initially described in
- RFC 4828.
+ tristate "CCID4 (TCP-Friendly, Small Packet Variant) (EXPERIMENTAL)"
+ depends on IP_DCCP
+ def_tristate IP_DCCP
+ ---help---
+ CCID-4 denotes Congestion Control Identifier 4, the Small-Packet
+ variant of TCP-Friendly Rate Control (TFRC), in the Datagram
+ Congestion Control Protocol (DCCP). CCID 4 is for experimental use,
+ and uses TFRC-SP [RFC4828], a variant of TFRC designed for
applications
+ that send small packets. The goal for TFRC-SP is to
achieve roughly the
+ same bandwidth in bits per second (bps) as a TCP flow using
packets of up
+ to 1500 bytes but experiencing the same level of
congestion. CCID 4 is for
+ experimental use for senders that send small packets and would like a
+ TCP-friendly sending rate, possibly with Explicit Congestion
+ Notification (ECN), while minimizing abrupt rate changes.
+
+ CCID-4 is a Internet-Draft and it can be found at:
+ https://datatracker.ietf.org/drafts/draft-floyd-dccp-ccid4/
- This text was extracted from RFC 4340 (sec. 10.2),
- http://www.ietf.org/rfc/rfc4340.txt, and modified to match CCID4.
+ The TFRC-SP congestion control algorithms were initially described in
+ RFC 4828.
- To compile this CCID as a module, choose M here: the module will be
- called dccp_ccid4.
+ To compile this CCID as a module, choose M here: the module will be
+ called dccp_ccid4.
- If in doubt, say M.
+ If in doubt, say M.
config IP_DCCP_CCID4_DEBUG
- bool "CCID4 debugging messages"
- depends on IP_DCCP_CCID4
- ---help---
- Enable CCID4-specific debugging messages.
-
- When compiling CCID4 as a module, this debugging output can
- additionally be toggled by setting the ccid4_debug module
- parameter to 0 or 1.
+ bool "CCID4 debugging messages"
+ depends on IP_DCCP_CCID4
+ ---help---
+ Enable CCID4-specific debugging messages.
+
+ When compiling CCID4 as a module, this debugging output can
+ additionally be toggled by setting the ccid4_debug module
+ parameter to 0 or 1.
- If in doubt, say N.
+ If in doubt, say N.
config IP_DCCP_CCID4_RTO
- int "Use higher bound for nofeedback timer"
- default 100
- depends on IP_DCCP_CCID4 && EXPERIMENTAL
- ---help---
- FIXME
- Use higher lower bound for nofeedback timer expiration.
-
- The TFRC-SP 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.
-
-# The TFRC-SP Library: currently only has CCID 4 as customer
-config IP_DCCP_TFRC_SP_LIB
- depends on IP_DCCP_CCID4
- def_tristate IP_DCCP_CCID4
+ int "Use higher bound for nofeedback timer"
+ default 100
+ depends on IP_DCCP_CCID4 && EXPERIMENTAL
+ ---help---
+ This help is a copy of CCID3 RTO option. It must be updated, if
+ necessary, according to the CCID-4 internet draft.
+
+ Use higher lower bound for nofeedback timer expiration.
+
+ The TFRC-SP 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_SP_DEBUG
- bool
- default y if IP_DCCP_CCID4_DEBUG
+ bool
+ default y if IP_DCCP_CCID4_DEBUG
endmenu
-
To unsubscribe from this list: send the line "unsubscribe dccp" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
