[HN Gopher] Increasing QUIC and UDP Throughput over Tailscale ___________________________________________________________________ Increasing QUIC and UDP Throughput over Tailscale Author : PaulHoule Score : 59 points Date : 2023-11-20 21:07 UTC (1 hours ago) (HTM) web link (tailscale.com) (TXT) w3m dump (tailscale.com) | imperialdrive wrote: | Y'all are impressive--Kudos! | djha-skin wrote: | This is pretty cool, but I would have liked to see more | benchmarks around phones to servers instead of Linux box to Linux | box. | | UDP and QUIC are most effective serving traffic from phones to | servers, not from Linux box to Linux box. | | Linux boxes are typically either servers or behind a corporate | firewall as e.g user laptops such as the one I use at work. There | are distinct disadvantages to running QUIC in that environment: | | * UDP is often blocked by default by corporate firewalls. | | * Having everything in user space means having to actually update | the user software before getting a security patch deep in the | transport layer. Compared with getting a kernel patch to fix a | TCP vulnerability, which typically happens more often on a Linux | box and is more stable than updating userspace software. | | * TCP throughput in a data center or behind a corporate firewall | is typically fast enough for most needs. | | However, from a phone on a cell tower, QUIC starts to make sense: | | * Having everything in user space means I can update for security | patches every time I update the app, which is much more frequent | than OS updates on for example Android. | | * Having everything over UDP means I can get the usual non head | of line blocking benefits so often touted, with top notch | security as well. | gorkish wrote: | GSO (Generic segmentation offload) is supported for UDP in the | Linux kernel from 4.18 so I would assume these optimizations | should be easily possible for the kernel driver as well and can | take advantage of any drivers that pass the GSO down to the | network hardware too. | | Kinda weird optimization though; I'm not exactly sure why it | works as well as it appears to; I am thinking that the gain may | be far far less noticeable/important at <1gbps. This may be why | there aren't any benchmarks for lower end devices or bandwidth | constrained paths. | | On another front, I wonder would there be any advantage to | encapsulating a native UDP protocol like wireguard in QUIC | frames? Might this result in increased reliability and improved | packet handling from firewalls and middleboxes? | dan-robertson wrote: | Wireguard udp packets are already pretty unstructured. The | first four bytes are 4, 0, 0, 0. They have another 12 bytes of | header and then encrypted data. ___________________________________________________________________ (page generated 2023-11-20 23:00 UTC)