TCP-in-UDP Solution (eBPF)

Cool article! L4 stuff is always fun to read about :)

Since TCP-in-UDP seems to be involve implementing end-to-end features over UDP, I feel like a comparison to multipath QUIC might be helpful so that we can understand it better.

My impression from reading about HTTP/3 is that QUIC is just kind of better than TCP in performing a lot of end-to-end functions, like recovery, encryption, error correction, duplicate suppression, congestion control, and delivery acknowledgement, and of course multiplexing the connection. (The advantage of TCP seems like its simpler and more mature, but it's honestly not clear to me where TCP wins and I'd be interested in hearing about the situations in which TCP is better than QUIC.)

So if we're addressing middleboxes screwing with MPTCP by tunneling TCP over UDP, isn't this very similar to what multipath QUIC does? The article seems to argue this is a simpler, lower-overhead solution than VPN tunnels, which I agree, that would seem like the wrong tool for the job, but I can't really tell which of multipath QUIC and MPTCP-over-UDP is simpler; they seem really similar to me and I'd appreciate help differentiating them.

When would one prefer MPTCP-over-UDP over multipath QUIC, and vice versa? How do the two differ in functionality, stability, and ease-of-use?

I know it isn't the intended use case but I wonder how this would perform as a censorship circumvention method. The translation alone may be enough of a change to avoid the pattern matching used by firewalls.

Makes total sense to me. But why hasn't this been done a long time ago? Pretty sure people spotted this earlier in TCP and UDP but this was never implemented?