And the problem here is that I trust my network and I trust my operating system both significantly more than I trust my applications, especially as browsers have transitioned largely to being user-hostile by design.

The primary benefactor of your end-to-end argument is ad networks that also own web browsers.

Hence why this is political, it's about shifting network traffic outside of places users have control.

> and takes control away from the operating system

That's just because QUIC is a new, not yet specified protocol, isn't it?

Kernels will get support eventually. Microsoft is actually already shipping some code. [1]

Browsers will probably switch to OS facilities once they are mature enough and provide a performance benefit.

[1] https://www.windowslatest.com/2018/04/03/microsoft-to-add-su...

It's not abundantly clear that there can be a performance benefit from moving QUIC into the kernel. Indeed, there is no performance benefit from having TCP in the kernel. That's why one of the most common tactics in high-performance networking is to move the TCP stack into userspace.

The end-to-end argument in IP networking evolved in a time (the 1970s and 1980s) when a host could reasonably be considered the endpoint. Now hosts are so big and powerful that it's no longer reasonable to draw the boundary around them. The individual process running on the host is the true endpoint, and having the application in charge of its own network flow control is the natural evolution of things.

> Indeed, there is no performance benefit from having TCP in the kernel. That's why one of the most common tactics in high-performance networking is to move the TCP stack into userspace.

But a userspace network stack only make sense in single purpose devices/servers, because they have to take over the hardware, right?

On a consumer device many applications can use the network concurrently.

QUIC runs on top of UDP anyway, so userspace libraries use OS UDP facilities, but lose the ability to do better cross-application balancing. Hardware TCP offloading also plays a role of course.

You don't have to take over the hardware to do userspace TCP. You only need the ability to put raw datagrams on the wire (Linux RAW socket, for example). You _can_ take over the device with something like DPDK but that's not necessary. As you correctly say, QUIC uses existing OS-level facilities to communicate over UDP, so there is no reason that several processes on a single host cannot use application-level QUIC stacks concurrently.

It's possible to use kernel facilities to route flows to the right application or stack, and then use that stack to process individual connections.

For example, many network cards support creating multiple virtual network devices, and you could hand a whole such device to a userspace process, but only let it see traffic intended for that device.

Or, finer-grained, you could use a filter to steer certain packet flows to a process, while handling others in the kernel.

I do absolutely think there's value in having native QUIC in the kernel, but then, I also think there's value in having native TLS in the kernel; doesn't mean you always want to use it.

> QUIC hides flow control parameters from the network

It's not clear that this is a good thing. You generally want things like network-provided congestion notification+control, and plain vanilla UDP won't be enough for this.

Well, the end-to-end argument is that you are wrong. You never want the network to do anything smart. ECN is fine, and does not require the network to have visibility into flow control parameters.

https://web.mit.edu/Saltzer/www/publications/endtoend/endtoe...