docs/76462: [patch] Handbook, net.inet.tcp.inflight_* -> net.inet.tcp.inflight.*

[Joel Dahl]

>Number:         76462
>Category:       docs
>Synopsis:       [patch] Handbook, net.inet.tcp.inflight_* -> net.inet.tcp.inflight.*
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-doc
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          doc-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed Jan 19 12:50:29 GMT 2005
>Closed-Date:
>Last-Modified:
>Originator:     Joel Dahl
>Release:        FreeBSD 5.3-STABLE i386
>Organization:
>Environment:
System: FreeBSD dude.automatvapen.se 5.3-STABLE FreeBSD 5.3-STABLE #0: Sat Jan 1 14:36:28 CET 2005 joel at dude.automatvapen.se:/usr/obj/usr/src/sys/WRK i386

	
>Description:
$ sysctl net.inet.tcp.inflight
net.inet.tcp.inflight.enable: 1
net.inet.tcp.inflight.debug: 0
net.inet.tcp.inflight.min: 6144
net.inet.tcp.inflight.max: 1073725440
net.inet.tcp.inflight.stab: 20

	
>How-To-Repeat:
	
>Fix:
	

--- dot.diff begins here ---
Index: chapter.sgml
===================================================================
RCS file: /home/ncvs/doc/en_US.ISO8859-1/books/handbook/config/chapter.sgml,v
retrieving revision 1.198
diff -u -r1.198 chapter.sgml
--- chapter.sgml	14 Jan 2005 12:51:52 -0000	1.198
+++ chapter.sgml	19 Jan 2005 12:26:37 -0000
@@ -2171,12 +2171,12 @@
 
 	<indexterm>
 	  <primary>TCP Bandwidth Delay Product Limiting</primary>
-	  <secondary><varname>net.inet.tcp.inflight_enable</varname></secondary>
+	  <secondary><varname>net.inet.tcp.inflight.enable</varname></secondary>
 	</indexterm>
 
 	<para>The TCP Bandwidth Delay Product Limiting is similar to
 	  TCP/Vegas in NetBSD.  It can be
-	  enabled by setting <varname>net.inet.tcp.inflight_enable</varname>
+	  enabled by setting <varname>net.inet.tcp.inflight.enable</varname>
 	  sysctl variable to <literal>1</literal>.  The system will attempt
 	  to calculate the bandwidth delay product for each connection and
 	  limit the amount of data queued to the network to just the amount
@@ -2187,9 +2187,9 @@
 	  with a high bandwidth delay product), especially if you are also
 	  using window scaling or have configured a large send window.  If
 	  you enable this option, you should also be sure to set
-	  <varname>net.inet.tcp.inflight_debug</varname> to
+	  <varname>net.inet.tcp.inflight.debug</varname> to
 	  <literal>0</literal> (disable debugging), and for production use
-	  setting <varname>net.inet.tcp.inflight_min</varname> to at least
+	  setting <varname>net.inet.tcp.inflight.min</varname> to at least
 	  <literal>6144</literal> may be beneficial.  However, note that
 	  setting high minimums may effectively disable bandwidth limiting
 	  depending on the link.  The limiting feature reduces the amount of
@@ -2202,7 +2202,7 @@
 	  / server side).  It has no effect on data reception (downloading).
 	</para>
 
-	<para>Adjusting <varname>net.inet.tcp.inflight_stab</varname> is
+	<para>Adjusting <varname>net.inet.tcp.inflight.stab</varname> is
 	  <emphasis>not</emphasis> recommended.  This parameter defaults to
 	  20, representing 2 maximal packets added to the bandwidth delay
 	  product window calculation.  The additional window is required to
@@ -2211,7 +2211,7 @@
 	  links (though still much lower than you would get without the
 	  inflight algorithm).  In such cases, you may wish to try reducing
 	  this parameter to 15, 10, or 5; and may also have to reduce
-	  <varname>net.inet.tcp.inflight_min</varname> (for example, to
+	  <varname>net.inet.tcp.inflight.min</varname> (for example, to
 	  3500) to get the desired effect.  Reducing these parameters
 	  should be done as a last resort only.</para>
       </sect3>
--- dot.diff ends here ---


>Release-Note:
>Audit-Trail:
>Unformatted: