On Feb 26, 2009, at 1:41 PM, Ross Cameron wrote:
Where can I find more documentation on these types of settings in
FreeBSD
The FreeBSD Handbook and Google will help for the general case, but
for specific details, reading the source is recommended.
and
How can I choose between more than just TCP_NewReno, specifically I
will be making use of TCP_Westwood / TCP_Westwood+ and
TCP_Illinois ???
If you have a BSD-licensed implementation of TCP Westwood or the
others handy, feel free to contribute your patches in a PR.
At least some of the notions behind the congestion algorithms you've
mentioned are present in the FreeBSD stack in the form of the
net.inet.tcp.inflight tunables; see netinet/tcp_subr.c:
/*
* TCP BANDWIDTH DELAY PRODUCT WINDOW LIMITING
*
* This code attempts to calculate the bandwidth-delay product as a
* means of determining the optimal window size to maximize bandwidth,
* minimize RTT, and avoid the over-allocation of buffers on
interfaces and
* routers. This code also does a fairly good job keeping RTTs in
check
* across slow links like modems. We implement an algorithm which is
very
* similar (but not meant to be) TCP/Vegas. The code operates on the
* transmitter side of a TCP connection and so only effects the
transmit
* side of the connection.
*
* BACKGROUND: TCP makes no provision for the management of buffer
space
* at the end points or at the intermediate routers and switches. A
TCP
* stream, whether using NewReno or not, will eventually buffer as
* many packets as it is able and the only reason this typically
works is
* due to the fairly small default buffers made available for a
connection
* (typicaly 16K or 32K). As machines use larger windows and/or window
* scaling it is now fairly easy for even a single TCP connection to
blow-out
* all available buffer space not only on the local interface, but on
* intermediate routers and switches as well. NewReno makes a
misguided
* attempt to 'solve' this problem by waiting for an actual failure
to occur,
* then backing off, then steadily increasing the window again until
another
* failure occurs, ad-infinitum. This results in terrible
oscillation that
* is only made worse as network loads increase and the idea of
intentionally
* blowing out network buffers is, frankly, a terrible way to manage
network
* resources.
*
* It is far better to limit the transmit window prior to the failure
* condition being achieved. There are two general ways to do this:
First
* you can 'scan' through different transmit window sizes and locate
the
* point where the RTT stops increasing, indicating that you have
filled the
* pipe, then scan backwards until you note that RTT stops
decreasing, then
* repeat ad-infinitum. This method works in principle but has severe
* implementation issues due to RTT variances, timer granularity, and
* instability in the algorithm which can lead to many false
positives and
* create oscillations as well as interact badly with other TCP streams
* implementing the same algorithm.
*
* The second method is to limit the window to the bandwidth delay
product
* of the link. This is the method we implement. RTT variances and
our
* own manipulation of the congestion window, bwnd, can potentially
* destabilize the algorithm. For this reason we have to stabilize the
* elements used to calculate the window. We do this by using the
minimum
* observed RTT, the long term average of the observed bandwidth, and
* by adding two segments worth of slop. It isn't perfect but it is
able
* to react to changing conditions and gives us a very stable basis on
* which to extend the algorithm.
*/
void
tcp_xmit_bandwidth_limit()
--
-Chuck
_______________________________________________
[email protected] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[email protected]"
