Get the latest tech news
TCP-in-UDP Solution (eBPF)
The MPTCP protocol is complex, mainly to be able to survive on the Internet where middleboxes such as NATs, firewalls, IDS or proxies can modify parts of the TCP packets. Worst case scenario, an MPTCP connection should fallback to “plain” TCP. Today, such fallbacks are rarer than before – probably because MPTCP has been used since 2013 on millions of Apple smartphones worldwide – but they can still exist, e.g. on some mobile networks using Performance Enhancing Proxies (PEPs) where MPTCP connections are not bypassed. In such cases, a solution to continue benefiting from MPTCP is to tunnel the MPTCP connections. Different solutions exist, but they usually add extra layers, and requires setting a virtual private network (VPN) up with private IP addresses between the client and the server. Here, a simpler solution is presented: TCP-in-UDP. This solution relies on eBPF, doesn’t add extra data per packet, and doesn’t require a virtual private network. Read on to find out more about that!
On paper, the required modifications – protocol, a 16-bit word, and adapt the checksum – are small, and should be easy to do using eBPF with TC ingress and egress hooks. This is an optimisation, because the kernel will often do operations depending on the packet header, and it doesn’t really care about the content of the data, which is usually more for the userspace, or to be forwarded to another network interface. Correct, but even if all hardware offload accelerations are disabled, in egress, the Linux networking stack still has interest to deal with bigger packets internally, and do the segmentation in software at the end.
Or read this on Hacker News
