On 11/12/10 17:41, Lawrence Stewart wrote: > Author: lstewart > Date: Fri Nov 12 06:41:55 2010 > New Revision: 215166 > URL: http://svn.freebsd.org/changeset/base/215166 > > Log: > This commit marks the first formal contribution of the "Five New TCP > Congestion > Control Algorithms for FreeBSD" FreeBSD Foundation funded project. More > details > about the project are available at: http://caia.swin.edu.au/freebsd/5cc/ > > - Add a KPI and supporting infrastructure to allow modular congestion > control > algorithms to be used in the net stack. Algorithms can maintain > per-connection > state if required, and connections maintain their own algorithm pointer, > which > allows different connections to concurrently use different algorithms. The > TCP_CONGESTION socket option can be used with getsockopt()/setsockopt() to > programmatically query or change the congestion control algorithm > respectively > from within an application at runtime. > > - Integrate the framework with the TCP stack in as least intrusive a manner > as > possible. Care was also taken to develop the framework in a way that > should > allow integration with other congestion aware transport protocols (e.g. > SCTP) > in the future. The hope is that we will one day be able to share a single > set > of congestion control algorithm modules between all congestion aware > transport > protocols. > > - Introduce a new congestion recovery (TF_CONGRECOVERY) state into the TCP > stack > and use it to decouple the meaning of recovery from a congestion event and > recovery from packet loss (TF_FASTRECOVERY) a la RFC2581. ECN and delay > based > congestion control protocols don't generally need to recover from packet > loss > and need a different way to note a congestion recovery episode within the > stack. > > - Remove the net.inet.tcp.newreno sysctl, which simplifies some portions of > code > and ensures the stack always uses the appropriate mechanisms for > recovering > from packet loss during a congestion recovery episode. > > - Extract the NewReno congestion control algorithm from the TCP stack and > massage it into module form. NewReno is always built into the kernel and > will > remain the default algorithm for the forseeable future. Implementations of > additional different algorithms will become available in the near future. > > - Bump __FreeBSD_version to 900025 and note in UPDATING that rebuilding code > that relies on the size of "struct tcpcb" is required. > > Many thanks go to the Cisco University Research Program Fund at Community > Foundation Silicon Valley and the FreeBSD Foundation. Their support of our > work > at the Centre for Advanced Internet Architectures, Swinburne University of > Technology is greatly appreciated. > > In collaboration with: David Hayes <dahayes at swin edu au> and > Grenville Armitage <garmitage at swin edu au> > Sponsored by: Cisco URP, FreeBSD Foundation > Reviewed by: rpaulo > Tested by: David Hayes (and many others over the years) > MFC after: 3 months > > Added: > head/sys/netinet/cc/ > head/sys/netinet/cc.h (contents, props changed) > head/sys/netinet/cc/cc.c (contents, props changed) > head/sys/netinet/cc/cc_module.h (contents, props changed) > head/sys/netinet/cc/cc_newreno.c (contents, props changed) > Modified: > head/UPDATING > head/sys/conf/files > head/sys/netinet/tcp_input.c > head/sys/netinet/tcp_output.c > head/sys/netinet/tcp_sack.c > head/sys/netinet/tcp_subr.c > head/sys/netinet/tcp_timer.c > head/sys/netinet/tcp_usrreq.c > head/sys/netinet/tcp_var.h > head/sys/sys/param.h
I screwed up a bit, and this commit also includes a diff to disable seeding cwnd from the hostcache. Details about the issue and the diff are here: http://lists.freebsd.org/pipermail/freebsd-net/2010-November/026865.html I should have gotten Andre to commit his patch first before committing the modular CC patch, but I had pulled his patch into my development tree and it all got rolled into one. To avoid a lot of mucking about, I plan to do a direct commit MFC to the stable branches of only Andre's patch in a week's time so that it makes it into 7.4/8.2. The MFC schedule for the remainder of the modular CC patch will stay as it was at 3 months. Once the modular CC work is MFC'd, the mergeinfo will go back to being properly in sync and life will be good again. Apologies for the mess. Cheers, Lawrence _______________________________________________ svn-src-all@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
