TCP congestion avoidance
Hi there all I spend most of my time maintaining an embedded Linux appliance for a client of mine. One of the features of this client is that depending on connectivity types etc. if has the ability to choose between several different TCP congestion avoidance algorythms. Now I have been approached by another client to produce a BSD derived system (they're GPL alergic) and I would like to impliment a simmilar feature on this new toolchain. Where can I find out what congestion avoidance algorythms FreeBSD supports and how to plug them in and out during runtime (not at boot) ??? Regards,... Ross Cameron -- Opportunity is most often missed by people because it is dressed in overalls and looks like work. Thomas Alva Edison Inventor of 1093 patents, including: The light bulb, phonogram and motion pictures. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Fwd: TCP congestion avoidance
Bump,... Sorry guys (semi-urgent question and I really need the help im not a fBSD guru) -- Forwarded message -- From: Ross Cameron ross.came...@linuxpro.co.za Date: Thu, Feb 26, 2009 at 10:13 AM Subject: TCP congestion avoidance To: freebsd-questions@freebsd.org Hi there all I spend most of my time maintaining an embedded Linux appliance for a client of mine. One of the features of this client is that depending on connectivity types etc. if has the ability to choose between several different TCP congestion avoidance algorythms. Now I have been approached by another client to produce a BSD derived system (they're GPL alergic) and I would like to impliment a simmilar feature on this new toolchain. Where can I find out what congestion avoidance algorythms FreeBSD supports and how to plug them in and out during runtime (not at boot) ??? Regards,... Ross Cameron -- Opportunity is most often missed by people because it is dressed in overalls and looks like work. Thomas Alva Edison Inventor of 1093 patents, including: The light bulb, phonogram and motion pictures. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: TCP congestion avoidance
On Feb 26, 2009, at 1:02 PM, Ross Cameron wrote: Bump,... Sorry guys (semi-urgent question and I really need the help im not a fBSD guru) As a suggestion, you ought to give the FreeBSD mailing lists at least a few hours, or better yet a day or so, before repeating a question due to lack of initial response. -- Forwarded message -- From: Ross Cameron ross.came...@linuxpro.co.za Date: Thu, Feb 26, 2009 at 10:13 AM Subject: TCP congestion avoidance To: freebsd-questions@freebsd.org Hi there all I spend most of my time maintaining an embedded Linux appliance for a client of mine. One of the features of this client is that depending on connectivity types etc. if has the ability to choose between several different TCP congestion avoidance algorythms. Now I have been approached by another client to produce a BSD derived system (they're GPL alergic) and I would like to impliment a simmilar feature on this new toolchain. Where can I find out what congestion avoidance algorythms FreeBSD supports and how to plug them in and out during runtime (not at boot) ??? You should start with the output of sysctl -ad net, in particular: net.inet.tcp.slowstart_flightsize: Slow start flight size net.inet.tcp.local_slowstart_flightsize: Slow start flight size for local networks net.inet.tcp.newreno: Enable NewReno Algorithms net.inet.tcp.delayed_ack: Delay ACK to try and piggyback it onto a data packet net.inet.tcp.rfc3042: Enable RFC 3042 (Limited Transmit) net.inet.tcp.rfc3390: Enable RFC 3390 (Increasing TCP's Initial Congestion Window) net.inet.tcp.sack.enable: Enable/Disable TCP SACK support net.inet.tcp.sack.maxholes: Maximum number of TCP SACK holes allowed per connection net.inet.tcp.sack.globalmaxholes: Global maximum number of TCP SACK holes net.inet.tcp.sack.globalholes: Global number of TCP SACK holes currently allocated net.inet.tcp.inflight.enable: Enable automatic TCP inflight data limiting net.inet.tcp.inflight.debug: Debug TCP inflight calculations net.inet.tcp.inflight.rttthresh: RTT threshold below which inflight will deactivate itself net.inet.tcp.inflight.min: Lower-bound for TCP inflight window net.inet.tcp.inflight.max: Upper-bound for TCP inflight window net.inet.tcp.inflight.stab: Inflight Algorithm Stabilization 20 = 2 packets These can be adjusted at runtime or even via setsockopt() for a few cases like TCP_NODELAY. You might also find that the packet shaper capabilities of dummynet might be helpful for prioritizing traffic and managing odd links (ie, with a high bandwidth * delay cross product). Beyond that, look into the source code such as /usr/src/sys/netinet/ tcp_output.c, netinet/tcp_sack.c, etc... Regards, -- -Chuck ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: TCP congestion avoidance
Hi there Chuck Many thanks for you're reply that does indeed help! Two questions though, Where can I find more documentation on these types of settings in FreeBSD 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 ??? Also a purely optional nicety would be does anyone know of a ported version of Compound_TCP to FreeBSD? Yes I know its a MS designed algorythm but Windows Vista+ use it by default and it would be nice to speak their congestion algorythm natively. Sorry for all the questions. But I kinda need to make a reccomendation to the client as to viability of the project. Many thanks! PS: Should I get the contract,... does FreeBSD have a hardware requests page? Would like to look into contributing some hardware as a thankyou. On Thu, Feb 26, 2009 at 11:27 PM, Chuck Swiger cswi...@mac.com wrote: From: Ross Cameron ross.came...@linuxpro.co.za Date: Thu, Feb 26, 2009 at 10:13 AM Subject: TCP congestion avoidance To: freebsd-questions@freebsd.org Hi there all I spend most of my time maintaining an embedded Linux appliance for a client of mine. One of the features of this client is that depending on connectivity types etc. if has the ability to choose between several different TCP congestion avoidance algorythms. Now I have been approached by another client to produce a BSD derived system (they're GPL alergic) and I would like to impliment a simmilar feature on this new toolchain. Where can I find out what congestion avoidance algorythms FreeBSD supports and how to plug them in and out during runtime (not at boot) ??? -- Forwarded message -- You should start with the output of sysctl -ad net, in particular: net.inet.tcp.slowstart_flightsize: Slow start flight size net.inet.tcp.local_slowstart_flightsize: Slow start flight size for local networks net.inet.tcp.newreno: Enable NewReno Algorithms net.inet.tcp.delayed_ack: Delay ACK to try and piggyback it onto a data packet net.inet.tcp.rfc3042: Enable RFC 3042 (Limited Transmit) net.inet.tcp.rfc3390: Enable RFC 3390 (Increasing TCP's Initial Congestion Window) net.inet.tcp.sack.enable: Enable/Disable TCP SACK support net.inet.tcp.sack.maxholes: Maximum number of TCP SACK holes allowed per connection net.inet.tcp.sack.globalmaxholes: Global maximum number of TCP SACK holes net.inet.tcp.sack.globalholes: Global number of TCP SACK holes currently allocated net.inet.tcp.inflight.enable: Enable automatic TCP inflight data limiting net.inet.tcp.inflight.debug: Debug TCP inflight calculations net.inet.tcp.inflight.rttthresh: RTT threshold below which inflight will deactivate itself net.inet.tcp.inflight.min: Lower-bound for TCP inflight window net.inet.tcp.inflight.max: Upper-bound for TCP inflight window net.inet.tcp.inflight.stab: Inflight Algorithm Stabilization 20 = 2 packets These can be adjusted at runtime or even via setsockopt() for a few cases like TCP_NODELAY. You might also find that the packet shaper capabilities of dummynet might be helpful for prioritizing traffic and managing odd links (ie, with a high bandwidth * delay cross product). Beyond that, look into the source code such as /usr/src/sys/netinet/tcp_output.c, netinet/tcp_sack.c, etc... Regards, -- -Chuck -- Opportunity is most often missed by people because it is dressed in overalls and looks like work. Thomas Alva Edison Inventor of 1093 patents, including: The light bulb, phonogram and motion pictures. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: TCP congestion avoidance
Chuck Swiger wrote: On Feb 26, 2009, at 1:02 PM, Ross Cameron wrote: Bump,... Sorry guys (semi-urgent question and I really need the help im not a fBSD guru) As a suggestion, you ought to give the FreeBSD mailing lists at least a few hours, or better yet a day or so, before repeating a question due to lack of initial response. And while you wait you could do something wild and crazy like google freebsd tcp congestion and read some of what comes up, well other than your query. :-) The top hit when I did it, www.bsdcan.org/2008/schedule/events/87.en.html , should help pass the time. -- --Jon Radel j...@radel.com smime.p7s Description: S/MIME Cryptographic Signature
Re: TCP congestion avoidance
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 ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
