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