====== TCP Stack Modularity ======

We have started the process of trying to add modularity to the TCP stack.

===== Motivation/Use Cases =====
  * Make it easier to experiment with changes to the TCP stack. At this point, even adding a new TCP option requires modifying the base TCP stack.
  * Make it easier to deploy experimental code without impacting all TCP sessions.
  * Support in-service updates to the TCP stack (for example, in response to serious bugs).
  * Create a framework to allow us to deploy larger changes to the TCP stack for testing purposes only.
  * Create "lite" versions of the TCP stack that support fewer features, but perform better.

===== Long Term Goal =====
  - Allow TCP stacks to be loaded as kernel modules.
  - Allow an administrator to set a default TCP stack.
  - Allow users to choose a non-default TCP stack through a socket option.
  - Allow TCP stacks to override any function except the bare minimum functionality necessary to determine which TCP stack to use.
  - Allow a TCP stack to supplement the tcpcb with stack-specific data.

===== Current Work =====

rrs@ has written code that accomplishes 1, 2, 3, and 5 above. It also accomplishes some of 4. (See the code review [[https://reviews.freebsd.org/D4055|here]].)

===== Ideas for Potential Future Work =====
  * Allow TCP stacks to override the remaining functions.
  * Extend framework to allow TCP sessions to switch stacks after the session has started.
  * Begin shipping the default stack as a module so it can be unloaded and replaced.

===== Testing =====
In addition to testing for correctness, we need to test for performance.

One idea for performance testing is to use a replicable TCP testing load and use PMC to count various statistics (including the number of branch prediction misses, etc.) both with and without this change.