[jklowden]

Note 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.

[garganzol]

Manipulative tone of the article title says it all. "The end of".

[ashtakeaway]

Really glad NextDNS blocked my click.

[tuetuopay]

Even the TCP graph is dubious. Cubic being systematically above the link capacity makes me chuckle. Yes bufferbloat can have cubic "hug" a somewhat higher limit, but it still needs to start under the link capacity.

[lxgr]

That's easily explained, in the parts of the x axis missing in the plot it actually goes negative and pays back the borrowed bytes.

[cbluth]

The obvious comparisons are between udp and tcp, and then between quic and ssh, given the notion of "multiple streams"