TCP Projects for FreeBSD 8.0
Contents
This wiki page is a catalog of known major TCP projects underway for FreeBSD 8.0. More detailed information on the projects may be found below.
Project |
Flag Wavers |
Schedule |
MFC 7? |
Link |
Summary |
TCP Offload |
Merge to CVS in progress |
desired |
? |
Support for complete TCP connection offload to 10gbps network device drivers. |
|
TCP overhaul |
? |
no |
? |
Andre is planning a general cleanup of the TCP implementation. |
|
TCP pluggable congestion control |
SamLeffler, RuiPaulo, AndreOppermann, KipMacy, James Healy, LawrenceStewart |
Prototype in svn |
desired |
Abstract the congestion control mechanism so that they may be plugged; provide alternative algorithms, and support algorithms present for TOE cards. |
|
TCP locking granularity/parallelism |
Planning phase |
partially |
? |
Improve the granularity of TCP locking, and create new opportunities for parallel execution. |
|
TCP ABI cleanup |
Planning phase |
desired |
Clean up data structures exported to userspace by TCP sysctls. |
||
TCP ECN |
Committed to HEAD |
no |
TCP Explicit Congestion Notification (ECN) |
||
TCP ABC |
Committed to HEAD |
desired |
N/A |
TCP Appropriate Byte Counting |
|
TCP UTO |
In preparation to be committed |
no |
? |
Per-connection timeout period defined by the user. |
|
TCP LO |
RuiPaulo (?) |
Waiting for RFC |
no |
? |
Extension of the TCP options field. |
TCP AO |
RuiPaulo (?) |
Waiting for RFC |
no |
? |
Replacement of TCP-MD5 and more. |
Schedule
So far, only a guess at the 8.0 schedule is possible:
Date |
Significance |
December 2008 |
All major TCP changes for 8.0 must be completed to allow six months of testing time before 8.0-RELEASE. |
June 2009 |
Possible 8.0 release date |
Projects
TCP Offload
Support for complete TCP connection offload to 10gbps network device drivers. Kip is the author of the Chelsio 10gbps driver for FreeBSD, and has updated the driver to support the prototype TOE interface now in CVS.
TCP overhaul
TCP pluggable congestion control
Several plans exist to merge support for pluggable congestion control for TCP, as well as provide support for algorithm selection for TOE device drivers. This may require moderate restructuring of TCP to abstract congestion control decisions currently scattered implicitly around the TCP implementation.
TCP locking granularity/parallelism
The TCP implementation is MPSAFE, but the tcbinfo lock protects all global data structures, so is acquired in the input path during lookup and in timers, leading to reduced parallelism. This task works to break down the tcbinfo lock, improving locking granularity, but also attempts to improve parallelism by distributing work over multiple CPUs and introducing weak CPU affinities for TCP connections.
TCP ABI cleanup
Perforce: //depot/user/rwatson/tcpabi/...
The "guts" of TCP data structures are currently exposed to userspace via sysctl, meaning that even minor kernel data structure layouts disturb the monitoring API/ABI used by user processes to track network connections. I.e., netstat. This task creates new exported data structures that contain no kernel-specific structures, such as mutexes or callout structures, and attempts to stabilize monitoring ABIs by adding plenty of padding for future extension.
TCP ECN
Perforce: //depot/projects/tcpecn/...
TCP ECN is a small modification to TCP end hosts and routers that notifies the peers when congestion is about to occur, allowing them to reduce the sending rate.
TCP ABC
TCP appropriate byte counting (RFC 3465) addresses a congestion control (CC) related issue introduced by the early TCP specs. It suggests increasing the congestion window by the number of bytes ACK'ed by a TCP ACK, as opposed to the current scheme which relies on an approximation driven by ACK clocking. ABC will also benefit the modular CC work as many of the new CC algorithms break some of the implicit assumptions required for the currently used approximation to function correctly.
TCP UTO
http://www.rfc-editor.org/rfc/rfc5482.txt
From the Abstract:
The TCP user timeout controls how long transmitted data may remain unacknowledged before a connection is forcefully closed. It is a local, per-connection parameter. This document specifies a new TCP option - the TCP User Timeout Option - that allows one end of a TCP connection to advertise its current user timeout value. This information provides advice to the other end of the TCP connection to adapt its user timeout accordingly. Increasing the user timeouts on both ends of a TCP connection allows it to survive extended periods without end-to-end connectivity. Decreasing the user timeouts allows busy servers to explicitly notify their clients that they will maintain the connection state only for a short time without connectivity.
TCP Long Options
http://www.ietf.org/internet-drafts/draft-eddy-tcp-loo-04.txt
From the Abstract:
This document describes a method for increasing the space available for TCP options. Two new TCP options (LO and SLO) are detailed which reduce the limitations imposed by the TCP header's Data Offset field. The LO option provides this extension after connection establishment, and the SLO option aids in transmission of lengthy connection initialization and configuration options.
TCP Authentication Option
http://www.ietf.org/internet-drafts/draft-ietf-tcpm-tcp-auth-opt-04.txt
From the Abstract:
This document specifies a TCP Authentication Option (TCP-AO) which is intended to replace the TCP MD5 Signature option of RFC-2385 (TCP MD5). TCP-AO specifies the use of stronger Message Authentication Codes (MACs) and provides more details on the association of security associations with TCP connections. TCP-AO assumes an external, out- of-band mechanism (manual or via a separate protocol) for session key establishment, parameter negotiation, and rekeying, replicating the separation of key management and key use as in the IPsec suite. The result is intended to be a simple modification to support current infrastructure uses of TCP MD5, such as to protect BGP and LDP, and to support a larger set of MACs with minimal other system and operational changes. TCP-AO uses a new option identifier, even though it is intended to be mutually exclusive with TCP MD5 on a given TCP connection. It supports IPv6, and is fully compatible with requirements under development for an update to TCP MD5.