Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

QUIC and the end of TCP sockets

codemia.io

Post reply on HN
Print view View original

21–30 of 83 posts

Re: QUIC and the end of TCP sockets

#21

Post by fulafel »

IgorPartola wrote: post #5

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

SCTP had some other nails to its coffin too. For example it came from the telco world and so had no end user app buyin and poor dev experience.

Re: QUIC and the end of TCP sockets

#22

Post by lxgr »

bayindirh wrote: post #13
lxgr wrote: post #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: I…

> QUIC gives control back to application developers to tailor congestion control to their use case If I understood modern application development correctly, this interprets as "The developers will import another library which they don't understand and will wreak havoc on other applications' data streams by only optimizing stuff for themselves". Again, if I remember correctly, an OS is "the layer which manages the sha…

> Assuming that every application will do congestion control correctly while not choking everyone else even unintentionally with user space's limited visibility is absurd at worst, and wishful thinking at best.

Why? All practically used variants of TCP achieve fairness at the bottleneck without any central arbiter or explicit view of the upstream congestion situation. Besides, UDP has never had congestion control and has been around for decades.

> The whole ordeal is direct violation with application separation coming with protected mode. [...] The whole ordeal is direct violation with application separation coming with protected mode.

Are you concerned about fairness between applications on the same OS or fairness at the bottleneck, usually upstream from both application and OS/host?

In the former case, the OS always gets the last word, whether you're using TCP or your own homebrew congestion control via UDP, and you can make sure that each application gets the exact same fair egress rate if required. In the latter case, nothing prevents anyone from patching their kernel and running "unfair TCP" today.

Re: QUIC and the end of TCP sockets

#23

Post by lxgr »

KaiserPro wrote: post #8

One 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 c…

> you can get past HOL blocking by having multiple TCP streams. Its super cheap, cheaper than QUIC

And also super inefficient, since it duplicates the TLS handshake across streams and uses more resources in the OS and middleboxes (like them or hate them, they're a thing that might throttle you if you go too crazy with connection-level parallelism).

That's on top of very poor fairness at bottlenecks (which is per TCP stream unless there's separate traffic policing).

Re: QUIC and the end of TCP sockets

#24

Post by jeffbee »

bayindirh wrote: post #19
lxgr wrote: post #4

Earlier quoted context omitted.

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.

Why do the hard work if the same thing can be done by the kernel, or even by the card itself? Drown other applications for your own benefit?

"Drown other applications" is unfortunately exactly what happens when you let the Linux kernel run your TCP stack. Profile your application and you may discover that your CPUs are being spent running the protocol stack on behalf of other applications.

Re: QUIC and the end of TCP sockets

#25

Post by lxgr »

IgorPartola wrote: post #5

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

If you like SCPT, nobody's stopping you from using it today! Just put it in a minimal UDP wrapper.

WebRTC has been doing just that for peer to peer data connections (which need TCP-like semantics while traversing NATs via UDP hole punching).

Re: QUIC and the end of TCP sockets

#26

Post by lxgr »

jeffbee wrote: post #24
bayindirh wrote: post #19

Earlier quoted context omitted.

Why do the hard work if the same thing can be done by the kernel, or even by the card itself? Drown other applications for your own benefit?

"Drown other applications" is unfortunately exactly what happens when you let the Linux kernel run your TCP stack. Profile your application and you may discover that your CPUs are being spent running the protocol stack on behalf of other applications.

What do you mean by "other applications"?

Re: QUIC and the end of TCP sockets

#27

Post by lxgr »

exabrial wrote: post #10

The most obnoxious thing about QUIC is I don't need encryption all of the time, actually the majority of the time. Useless overhead.

Even if you have nothing to hide and don't care about accidental or intentional data modification, the benefit of largely cutting out "clever" middleboxes alone is almost always worth it.

Re: QUIC and the end of TCP sockets

#28

Post by mtoner23 »

tptacek wrote: post #17
IgorPartola wrote: post #5

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

Why would you need another IP protocol besides UDP? Anything you can do directly under an IP header, you can do under a UDP header as well, and the UDP header itself is tiny. Going back to David Reed, this is specifically why UDP exists: as the extension interface to build more non-TCP transport protocols.

Because it's an extra header. Making data transfer that much less efficient and working to make sure that clients can decide it properly

Re: QUIC and the end of TCP sockets

#29

Post by lxgr »

superkuh wrote: post #7

QUIC 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…

Huh, I never knew, I've been using QUIC on my Raspberry Pi's web server for years... Did I unknowingly go corporate!?

Even if you don't want to get a Letsencrypt certificate, you can always use a self-signed one and configure your clients to trust it on first use or entirely ignore it.

SSH also uses "mandatory host keys", if you think about it. It's really not a question of the protocols but rather of common client libraries and tooling.

Re: QUIC and the end of TCP sockets

#30

Post by neilalexander »

lxgr wrote: post #20
bayindirh wrote: post #19

Earlier quoted context omitted.

Why do the hard work if the same thing can be done by the kernel, or even by the card itself? Drown other applications for your own benefit?

> Why do the hard work if the same thing can be done by the kernel, or even by the card itself? How would you swap out the TCP congestion control algorithm in an OS, or even hardware, you don't control? > Drown other applications for your own benefit? Fairness equivalent to classic TCP is a design goal of practically all alternative algorithms, so I'm not sure what you're implying. It's entirely possible to improve r…

> How would you swap out the TCP congestion control algorithm in an OS, or even hardware, you don't control?

On the contrary, introducing their own novel/mysterious/poorly implemented congestion control algorithms is not a thing I want userspace applications doing.

Post reply on HN