[PATCH 1/5] CCID 4: Adds Kconfig, Makefile, and new CCID to

[PATCH 1/5] CCID 4: Adds Kconfig, Makefile, and new CCID to

[Tommi Saviranta]

Adds Kconfig-entries, modified Makefile, and adds DCCP_CCID enum for for
CCID 4. Kconfig-entries are derived from CCID 3, and are probably
invalid.


Signed-off-by: Tommi Saviranta <wnd@iki.fi>

---
diff --git a/include/linux/dccp.h b/include/linux/dccp.h
index b569947..dc19d6b 100644
--- a/include/linux/dccp.h
+++ b/include/linux/dccp.h
@@ -173,6 +173,7 @@ enum {
 enum {
 	DCCPC_CCID2 = 2,
 	DCCPC_CCID3 = 3,
+	DCCPC_CCID4 = 4,
 };
 
 /* DCCP features (RFC 4340 section 6.4) */
diff --git a/net/dccp/ccids/Kconfig b/net/dccp/ccids/Kconfig
index a0c42d7..e402869 100644
--- a/net/dccp/ccids/Kconfig
+++ b/net/dccp/ccids/Kconfig
@@ -115,4 +115,87 @@ config IP_DCCP_TFRC_DEBUG
 	bool
 	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.
+
+	  This text was extracted from RFC 4340 (sec. 10.2),
+	  http://www.ietf.org/rfc/rfc4340.txt, and modified to match CCID4.
+	  
+	  To compile this CCID as a module, choose M here: the module will be
+	  called dccp_ccid4.
+
+	  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.
+
+	    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
+
+config IP_DCCP_TFRC_SP_DEBUG
+	bool
+	default y if IP_DCCP_CCID4_DEBUG
+
 endmenu
diff --git a/net/dccp/ccids/Makefile b/net/dccp/ccids/Makefile
index 438f20b..fa21407 100644
--- a/net/dccp/ccids/Makefile
+++ b/net/dccp/ccids/Makefile
@@ -5,5 +5,9 @@ dccp_ccid3-y := ccid3.o
 obj-$(CONFIG_IP_DCCP_CCID2) += dccp_ccid2.o
 
 dccp_ccid2-y := ccid2.o
+ 
+obj-$(CONFIG_IP_DCCP_CCID4) += dccp_ccid4.o
+
+dccp_ccid4-y := ccid4.o
 
 obj-y += lib/

Re: [PATCH 1/5] CCID 4: Adds Kconfig, Makefile, and new CCID to include/linux/dccp.h

[Gerrit Renker]

|  +# 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
|  +
|  +config IP_DCCP_TFRC_SP_DEBUG
|  +       bool
|  +       default y if IP_DCCP_CCID4_DEBUG
|  +
You can delete these lines - they are already enabled through CCID3 configuration option,
or integrate (OR) with the CCID3 dependencies. Since there are dependencies to CCID3,
it may be useful to replace the above by adding 
	select IP_DCCP_CCID3 
to the menu of IP_DCCP_CCID4

Re: [PATCH 1/5] CCID 4: Adds Kconfig, Makefile, and new CCID to include/linux/dccp.h

[@ 2007-09-20 13:25 UTC (permalink / raw)]

Yes, this is one of my fixes.

Leandro.

2007/9/20, Gerrit Renker <gerrit@erg.abdn.ac.uk>:
> |  +# 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
> |  +
> |  +config IP_DCCP_TFRC_SP_DEBUG
> |  +bool
> |  +default y if IP_DCCP_CCID4_DEBUG
> |  +
> You can delete these lines - they are already enabled through CCID3 configuration option,
> or integrate (OR) with the CCID3 dependencies. Since there are dependencies to CCID3,
> it may be useful to replace the above by adding
>         select IP_DCCP_CCID3
> to the menu of IP_DCCP_CCID4
> -
> 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
>

Re: [PATCH 1/5] CCID 4: Adds Kconfig, Makefile, and new CCID to include/linux/dccp.h

[@ 2007-09-20 17:49 UTC (permalink / raw)]

2007/9/20, Tommi Saviranta <wnd@iki.fi>:
> Adds Kconfig-entries, modified Makefile, and adds DCCP_CCID enum for for
> CCID 4. Kconfig-entries are derived from CCID 3, and are probably
> invalid.
>
>
> Signed-off-by: Tommi Saviranta <wnd@iki.fi>
>
> ---
> diff --git a/include/linux/dccp.h b/include/linux/dccp.h
> index b569947..dc19d6b 100644
> --- a/include/linux/dccp.h
> +++ b/include/linux/dccp.h
> @@ -173,6 +173,7 @@ enum {
>  enum {
>         DCCPC_CCID2 = 2,
>         DCCPC_CCID3 = 3,
> +       DCCPC_CCID4 = 4,
>  };
>
>  /* DCCP features (RFC 4340 section 6.4) */
> diff --git a/net/dccp/ccids/Kconfig b/net/dccp/ccids/Kconfig
> index a0c42d7..e402869 100644
> --- a/net/dccp/ccids/Kconfig
> +++ b/net/dccp/ccids/Kconfig
> @@ -115,4 +115,87 @@ config IP_DCCP_TFRC_DEBUG
>         bool
>         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.
> +
> +         This text was extracted from RFC 4340 (sec. 10.2),
> +         http://www.ietf.org/rfc/rfc4340.txt, and modified to match CCID4.
> +
> +         To compile this CCID as a module, choose M here: the module will be
> +         called dccp_ccid4.
> +
> +         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.
> +
> +           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
> +
> +config IP_DCCP_TFRC_SP_DEBUG
> +       bool
> +       default y if IP_DCCP_CCID4_DEBUG
> +
>  endmenu
> diff --git a/net/dccp/ccids/Makefile b/net/dccp/ccids/Makefile
> index 438f20b..fa21407 100644
> --- a/net/dccp/ccids/Makefile
> +++ b/net/dccp/ccids/Makefile
> @@ -5,5 +5,9 @@ dccp_ccid3-y := ccid3.o
>  obj-$(CONFIG_IP_DCCP_CCID2) += dccp_ccid2.o
>
>  dccp_ccid2-y := ccid2.o
> +
> +obj-$(CONFIG_IP_DCCP_CCID4) += dccp_ccid4.o
> +
> +dccp_ccid4-y := ccid4.o
>
>  obj-y += lib/
> -
> 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
>

NAK.

How about do as gerrit suggested "select IP_DCCP_CCID3" or like this:

# The TFRC Library: currently has CCID 3 and CCID 4 as customer
config IP_DCCP_TFRC_LIB
       depends on IP_DCCP_CCID3 || IP_DCCP_CCID4

My patchset about this fixes this issue and also remove unnecessary
repetition of the TFRC menu declaration.

Re: [PATCH 1/5] CCID 4: Adds Kconfig, Makefile, and new CCID to include/linux/dccp.h

[Ian McDonald]

On 9/20/07, Tommi Saviranta <wnd@iki.fi> wrote:
> Adds Kconfig-entries, modified Makefile, and adds DCCP_CCID enum for for
> CCID 4. Kconfig-entries are derived from CCID 3, and are probably
> invalid.
>
>
> Signed-off-by: Tommi Saviranta <wnd@iki.fi>
>
> +config IP_DCCP_CCID4
> +       tristate "CCID4 (TCP-Friendly, Small Packet Variant) (EXPERIMENTAL)"

But it doesn't depend on EXPERIMENTAL... This should be fixed.

> +       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
> +
This part should say that is an Internet Draft and give the URL for
that. When it becomes a RFC a patch can then give the RFC number.

> +config IP_DCCP_CCID4_RTO
> +         int "Use higher bound for nofeedback timer"
> +         default 100
> +         depends on IP_DCCP_CCID4 && EXPERIMENTAL

This EXPERIMENTAL can be removed with the changes to add to
IP_DCCP_CCID4 as above
> +         ---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)
> +

But Linux actually uses 250 ms for TCP here, not 1000 ms. You might
want to add that.


-- 
Web1: http://wand.net.nz/~iam4/
Web2: http://www.jandi.co.nz
Blog: http://iansblog.jandi.co.nz

Re: [PATCH 1/5] CCID 4: Adds Kconfig, Makefile, and new CCID to include/linux/dccp.h

[Gerrit Renker]

Ian McDonald wrote:
|   +               * 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)
|  > +
|  
|  But Linux actually uses 250 ms for TCP here, not 1000 ms. You might
|  want to add that.
|  
The others are not guilty of this change - the text was copied verbatim from the CCID3 menu.
And the CCID3 menu was copied from emails on dccp@ietf. I think Colin Perkins suggested the
lower, frame-based value, whereas 100ms were suggested by Mark Handley. Good to know about
the Linux value -- this is all meant for experimentation, maybe the 1000ms can then go?
I have been using the default of 100ms for a long while, but not done feedback loss tests.

Re: [PATCH 1/5] CCID 4: Adds Kconfig, Makefile, and new CCID to include/linux/dccp.h

[Ian McDonald]

On 9/25/07, Gerrit Renker <gerrit@erg.abdn.ac.uk> wrote:
> Ian McDonald wrote:
> |   + * 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)
> |  > +
> |
> |  But Linux actually uses 250 ms for TCP here, not 1000 ms. You might
> |  want to add that.
> |
> The others are not guilty of this change - the text was copied verbatim from the CCID3 menu.
> And the CCID3 menu was copied from emails on dccp@ietf. I think Colin Perkins suggested the
> lower, frame-based value, whereas 100ms were suggested by Mark Handley. Good to know about
> the Linux value -- this is all meant for experimentation, maybe the 1000ms can then go?
> I have been using the default of 100ms for a long while, but not done feedback loss tests.

I've just cced you all in on something I dug up through the iccrg list
not so long ago. Makes interesting reading.

Regards,

Ian
-- 
Web1: http://wand.net.nz/~iam4/
Web2: http://www.jandi.co.nz
Blog: http://iansblog.jandi.co.nz