* dccp test tree [RFC/RFT] [Patch 1/3] dccp: minor Kconfig cosmetics
@ 2009-01-05 14:42 ` Gerrit Renker
0 siblings, 0 replies; 10+ messages in thread
From: Gerrit Renker @ 2009-01-05 14:42 UTC (permalink / raw)
To: dccp, netdev
dccp ccid-3: Reformat Kconfig option for RTO timeout
Apart from fixing indenting, it also updates the references
(RFC 5348 has replaced RFC 3448).
Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
---
net/dccp/ccids/Kconfig | 58 ++++++++++++++++++++++++-------------------------
1 file changed, 29 insertions(+), 29 deletions(-)
--- a/net/dccp/ccids/Kconfig
+++ b/net/dccp/ccids/Kconfig
@@ -48,35 +48,35 @@ config IP_DCCP_CCID3_DEBUG
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.
+ int "Use higher bound for nofeedback timer"
+ default 100
+ depends on IP_DCCP_CCID3
+ ---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 5448, 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 5448. 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
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: dccp test tree [RFC/RFT] [Patch 1/3] dccp: minor Kconfig cosmetics
2009-01-05 14:42 ` Gerrit Renker
@ 2009-01-05 20:03 ` Ian McDonald
-1 siblings, 0 replies; 10+ messages in thread
From: Ian McDonald @ 2009-01-05 20:03 UTC (permalink / raw)
To: dccp
On Tue, Jan 6, 2009 at 3:42 AM, Gerrit Renker <gerrit@erg.abdn.ac.uk> wrote:
>
> dccp ccid-3: Reformat Kconfig option for RTO timeout
>
> Apart from fixing indenting, it also updates the references
> (RFC 5348 has replaced RFC 3448).
>
> Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: Ian McDonald <ian.mcdonald@jandi.co.nz>
--
Web: http://wand.net.nz/~iam4/, http://www.jandi.co.nz
Blog: http://iansblog.jandi.co.nz
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: dccp test tree [RFC/RFT] [Patch 1/3] dccp: minor Kconfig cosmetics
2009-01-05 14:42 ` Gerrit Renker
@ 2009-01-06 1:06 ` Wei Yongjun
-1 siblings, 0 replies; 10+ messages in thread
From: Wei Yongjun @ 2009-01-06 1:06 UTC (permalink / raw)
To: dccp
Gerrit Renker wrote:
> dccp ccid-3: Reformat Kconfig option for RTO timeout
>
> Apart from fixing indenting, it also updates the references
> (RFC 5348 has replaced RFC 3448).
>
> Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
> ---
> net/dccp/ccids/Kconfig | 58 ++++++++++++++++++++++++-------------------------
> 1 file changed, 29 insertions(+), 29 deletions(-)
>
> --- a/net/dccp/ccids/Kconfig
> +++ b/net/dccp/ccids/Kconfig
> @@ -48,35 +48,35 @@ config IP_DCCP_CCID3_DEBUG
> 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.
> + int "Use higher bound for nofeedback timer"
> + default 100
> + depends on IP_DCCP_CCID3
> + ---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 5448, 4.3). On LANs
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
RFC 5448 should be RFC 5348.
> + 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 5448. The following values have been suggested as bounds for
>
RFC 5448 should be RFC 5348.
> + 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
> --
> To unsubscribe from this list: send the line "unsubscribe dccp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: dccp test tree [RFC/RFT] [Patch 1/3] dccp: minor Kconfig cosmetics
@ 2009-01-06 1:06 ` Wei Yongjun
0 siblings, 0 replies; 10+ messages in thread
From: Wei Yongjun @ 2009-01-06 1:06 UTC (permalink / raw)
To: Gerrit Renker, dccp, netdev
Gerrit Renker wrote:
> dccp ccid-3: Reformat Kconfig option for RTO timeout
>
> Apart from fixing indenting, it also updates the references
> (RFC 5348 has replaced RFC 3448).
>
> Signed-off-by: Gerrit Renker <gerrit@erg.abdn.ac.uk>
> ---
> net/dccp/ccids/Kconfig | 58 ++++++++++++++++++++++++-------------------------
> 1 file changed, 29 insertions(+), 29 deletions(-)
>
> --- a/net/dccp/ccids/Kconfig
> +++ b/net/dccp/ccids/Kconfig
> @@ -48,35 +48,35 @@ config IP_DCCP_CCID3_DEBUG
> 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.
> + int "Use higher bound for nofeedback timer"
> + default 100
> + depends on IP_DCCP_CCID3
> + ---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 5448, 4.3). On LANs
>
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
RFC 5448 should be RFC 5348.
> + 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 5448. The following values have been suggested as bounds for
>
RFC 5448 should be RFC 5348.
> + 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
> --
> To unsubscribe from this list: send the line "unsubscribe dccp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: dccp test tree [RFC/RFT] [Patch 1/3] dccp: minor Kconfig cosmetics
2009-01-06 1:06 ` Wei Yongjun
@ 2009-01-06 1:17 ` Arnaldo Carvalho de Melo
-1 siblings, 0 replies; 10+ messages in thread
From: Arnaldo Carvalho de Melo @ 2009-01-06 1:17 UTC (permalink / raw)
To: dccp
On Mon, Jan 5, 2009 at 11:06 PM, Wei Yongjun <yjwei@cn.fujitsu.com> wrote:
> Gerrit Renker wrote:
>> + value. Values in units of milliseconds can be set here.
>> +
>> + A value of 0 disables this feature by enforcing the value
>> specified
>> + in RFC 5448. The following values have been suggested as bounds
>> for
>>
>
> RFC 5448 should be RFC 5348.
Indeed.
- Arnaldo
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: dccp test tree [RFC/RFT] [Patch 1/3] dccp: minor Kconfig cosmetics
@ 2009-01-06 1:17 ` Arnaldo Carvalho de Melo
0 siblings, 0 replies; 10+ messages in thread
From: Arnaldo Carvalho de Melo @ 2009-01-06 1:17 UTC (permalink / raw)
To: Wei Yongjun; +Cc: Gerrit Renker, dccp, netdev
On Mon, Jan 5, 2009 at 11:06 PM, Wei Yongjun <yjwei@cn.fujitsu.com> wrote:
> Gerrit Renker wrote:
>> + value. Values in units of milliseconds can be set here.
>> +
>> + A value of 0 disables this feature by enforcing the value
>> specified
>> + in RFC 5448. The following values have been suggested as bounds
>> for
>>
>
> RFC 5448 should be RFC 5348.
Indeed.
- Arnaldo
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: dccp test tree [RFC/RFT] [Patch 1/3] dccp: minor Kconfig
2009-01-06 1:17 ` Arnaldo Carvalho de Melo
@ 2009-01-06 12:22 ` Gerrit Renker
-1 siblings, 0 replies; 10+ messages in thread
From: Gerrit Renker @ 2009-01-06 12:22 UTC (permalink / raw)
To: dccp
Quoting Arnaldo Carvalho de Melo:
| On Mon, Jan 5, 2009 at 11:06 PM, Wei Yongjun <yjwei@cn.fujitsu.com> wrote:
| > Gerrit Renker wrote:
|
| >> + value. Values in units of milliseconds can be set here.
| >> +
| >> + A value of 0 disables this feature by enforcing the value
| >> specified
| >> + in RFC 5448. The following values have been suggested as bounds
| >> for
| >>
| >
| > RFC 5448 should be RFC 5348.
|
| Indeed.
|
A genuine blunder - I had verified the section references but not the
RFC number. It is really good to see that people do look: that is why
I don't make changes to the test tree without also submitting these.
The only exception to this rule are a few patches that have been
deleted, such as the one to auto-load CCIDs, and 2 patches that became
obsolete in the CCID-4 tree. At the moment I don't know what to do
with that CCID-4 tree, will just keep it up-to-date, it might be good to
reorganise the about 20 patches some time.
Again thanks a lot to you, Wei, and Ian
Gerrit
Just fixed it in the test tree
http://eden-feed.erg.abdn.ac.uk/cgi-bin/gitweb.cgi?p‹cp_exp.git;a=commitdiff;h\x11fc1dc11eafab0bd18c22f717a9b2155a383383
--
To unsubscribe from this list: send the line "unsubscribe dccp" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 10+ messages in thread
* Re: dccp test tree [RFC/RFT] [Patch 1/3] dccp: minor Kconfig cosmetics
@ 2009-01-06 12:22 ` Gerrit Renker
0 siblings, 0 replies; 10+ messages in thread
From: Gerrit Renker @ 2009-01-06 12:22 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo; +Cc: Wei Yongjun, dccp, netdev
Quoting Arnaldo Carvalho de Melo:
| On Mon, Jan 5, 2009 at 11:06 PM, Wei Yongjun <yjwei@cn.fujitsu.com> wrote:
| > Gerrit Renker wrote:
|
| >> + value. Values in units of milliseconds can be set here.
| >> +
| >> + A value of 0 disables this feature by enforcing the value
| >> specified
| >> + in RFC 5448. The following values have been suggested as bounds
| >> for
| >>
| >
| > RFC 5448 should be RFC 5348.
|
| Indeed.
|
A genuine blunder - I had verified the section references but not the
RFC number. It is really good to see that people do look: that is why
I don't make changes to the test tree without also submitting these.
The only exception to this rule are a few patches that have been
deleted, such as the one to auto-load CCIDs, and 2 patches that became
obsolete in the CCID-4 tree. At the moment I don't know what to do
with that CCID-4 tree, will just keep it up-to-date, it might be good to
reorganise the about 20 patches some time.
Again thanks a lot to you, Wei, and Ian
Gerrit
Just fixed it in the test tree
http://eden-feed.erg.abdn.ac.uk/cgi-bin/gitweb.cgi?p=dccp_exp.git;a=commitdiff;h=11fc1dc11eafab0bd18c22f717a9b2155a383383
^ permalink raw reply [flat|nested] 10+ messages in thread