QUIC and the end of TCP sockets
codemia.io
QUIC and the end of TCP sockets
1–10 of 83 posts
Re: QUIC and the end of TCP sockets
#2> Running in user space offers more flexibility for resource management and experimentation.
I stopped reading here. This isn’t really an essential property of QUIC, there’s a lot of good reasons to eventually try to implement this in the kernel.
Re: QUIC and the end of TCP sockets
#3> QUIC’s design intentionally separates the wire protocol from the congestion control algorithm
Is that not the case for TCP as well? Most congestion control algorithms just assign new meanings to existing wire-level flags (e.g. duplicate ACKs), or even only change sender-side behavior.
> QUIC gives* control back to application developers to tailor congestion control to their use case*
That's what it actually does: It moves the congestion control implementation from the OS to user space.
In that sense, it's the same tradeoff as containers vs. regular binaries linking to shared libraries: Great if your applications are updated more often than your OS; not so great if it's the other way around.
Re: QUIC and the end of TCP sockets
#4> Running in user space offers more flexibility for resource management and experimentation. I stopped reading here. This isn’t really an essential property of QUIC, there’s a lot of good reasons to eventually try to implement this in the kernel. https://lwn.net/Articles/1029851/
Maybe not an essential property of QUIC, but definitely one of not using TCP.
Most OSes don't let you send raw TCP segments without superuser privileges, so you can't just bring your own TCP congestion control algorithm in the userspace, unless you also wrap your custom TCP segments in UDP.
Re: QUIC and the end of TCP sockets
#5The obnoxious thing is that overly aggressive firewalls have killed any IP protocols that are not TCP or UDP. Even ICMP is often blocked or partially blocked.
In the mean time we could have had nice things: https://en.wikipedia.org/wiki/Stream_Control_Transmission_Pr...
SCTP would be a fantastic protocol for HTTP/HTTPS. Pipelining, multi homing, multi streaming, oh my.
Re: QUIC and the end of TCP sockets
#6Note well: the claims about TCP come with some evidence, in the form of a graph. The claims for QUIC do not.
Many of the claims are dubious. TCP has "no notion of multiple steams"? What are two sockets, then? What is poll(2)? The onus is on QUIC to explain why it’s better for the application to multiplex the socket than for the kernel to multiplex the device. AFAICT that question is assumed away in a deluge of words.
If the author thinks it’s the "end of TCP sockets", show us the research, the published papers and meticulous detail. Then tell me again why I should eschew the services of TCP and absorb its complexity into my application.
Re: QUIC and the end of TCP sockets
#7QUIC would be the end of the free internet if it ever "took over" but luckily it won't. It's not built to do so, it's only built for corporate use cases.
QUIC implementations do not allow for anyone to connect to anyone else. Instead, because it was built entirely with corporate for-profit uses cases in mind and open-washed through the IETF, the idea of a third party coporation having to authenticate the identity of all connections is baked in. And 99.999% of QUIC libs, and the way they're shipped in clients, cannot even connect to a server without a third party corp first saying they know the end point and allow it. Fine for corporate/profit use cases where security of the monetary transactions is all that matters. Very much less fine for human uses cases where it forces centralization and easy control by our rapidly enshittifying authoritarian governments. QUIC is the antithesis to the concept of the internet and it's robustness and routing around damage.
Re: QUIC and the end of TCP sockets
#8One thing to note is that using HTTP2.0 for anything other than "this is not how to design high throughput protocols" is unfair.
At the time HTTP2.0's multiplexing was known to be bad for anything other than perfect, low latency networks. I hope this was because people had faith in better connectivity, rather than ignorance of how mobile and non-lan traffic worked.
You should probably at least try QUIC now, but you can get past HOL blocking by having multiple TCP streams. Its super cheap, cheaper than QUIC.
Re: QUIC and the end of TCP sockets
#9QUIC would be the end of the free internet if it ever "took over" but luckily it won't. It's not built to do so, it's only built for corporate use cases. QUIC implementations do not allow for anyone to connect to anyone else. Instead, because it was built entirely with corporate for-profit uses cases in mind and open-washed through the IETF, the idea of a third party coporation having to authenticate the identity of…
I guess you are referring to the TLS requirement? I guess I could see how on a more restrictive platform like a phone you could conceivably be prevented from accepting alternate CAs or self signed certificates.
Re: QUIC and the end of TCP sockets
#10The most obnoxious thing about QUIC is I don't need encryption all of the time, actually the majority of the time. Useless overhead.