Some implementation architectures favour extensibility

[obonaventure]

The extensibility of protocols cannot be decoupled from their implementations. Experience shows that it is easier to extend user space implementations than kernel implementations for protocols such as TCP. However, it is also important to note that there are technical solutions that favour the extensibility of implementations.

One example is the adoption of eBPF inside the Linux kernel. Initially, this virtual machine has been used to collect statistics and track various events. Gradually, it became a technique that allows to extend the Linux kernel and this applies to the TCP stack itself.

An important contribution was the TCP-BPF support added by Lawrence Brakmo and described in : https://netdevconf.info/2.2/papers/brakmo-tcpbpf-talk.pdf

This kernel extension has been used to implement several TCP options using eBPF:

• https://inl.info.ucl.ac.be/publications/beyond-socket-options-making-linux-tcp-stack-truly-extensible.html
• https://authors.elsevier.com/c/1bgi1_3CGf3~Ze

Martin Lau has recently pushed a similar approach in the Linux kernel that allows to implement TCP options and TCP congestion control schemes using only eBPF:
https://linuxplumbersconf.org/event/7/contributions/687/attachments/537/1262/BPF_network_tcp-cc-hdr-sk-stg_LPC_2020.pdf

This solution is focussed on the Linux TCP stack, but it demonstrates that it is possible to dynamically extend TCP implementations and could contribute to our extensibility goal.

[tfpauly]

Thanks, @obonaventure! This is a good point that implementation design and openness ends up contributing a lot to practical protocol extensions. I think this goes beyond just saying that we need to actively use extensions, as use-it-or-lose suggests, but brings up the fact that there are impediments to use that come from deployment models and prominent implementations.

Is there anything we can do in an IETF context to help to encourage more extensibility in this way?