TCP Stack Modularity

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

• 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.

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

rrs@ has written code that accomplishes 1, 2, 3, and 5 above. It also accomplishes some of 4. (See the code review here.)

• 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.

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.