[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)