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

11–20 of 83 posts

Re: QUIC and the end of TCP sockets

#11

Post by jauntywundrkind »

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…

There's a fairly far a long draft for replacing webrtc's SCTP with QUIC for doing p2p work. It doesn't seem to have any of these challenges, seems to be perfectly viable there for connecting peers. https://github.com/w3c/p2p-webtransport

Alas alas, basically stalled out, afaik no implementation. I wish Microsoft (the spec author) or someone would pick this back up.

Re: QUIC and the end of TCP sockets

#12

Post by Hydraulix989 »

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.

Not sure I follow. QUIC is just UDP with an extra header in the opaque payload. To a firewall, it looks just like UDP.

Re: QUIC and the end of TCP sockets

#13

Post by bayindirh »

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 sharing of limited resources among many processes which requests/needs it", and the OS can do system-wide, per socket congestion control without any effort because of the vantage point it has over networking layer.

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.

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

Re: QUIC and the end of TCP sockets

#14

Post by jabiko »

Hydraulix989 wrote: post #12
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.

Not sure I follow. QUIC is just UDP with an extra header in the opaque payload. To a firewall, it looks just like UDP.

That's the point he is making. QUIC has to be based on UDP because the networking stack is ossified enough to not allow the addition of any new Layer 4 protocol. It's not a huge drawback though.

Re: QUIC and the end of TCP sockets

#15

Post by p_l »

Hydraulix989 wrote: post #12
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.

Not sure I follow. QUIC is just UDP with an extra header in the opaque payload. To a firewall, it looks just like UDP.

It exists partially because of ossification of protocols that killed SCTP.

As in, we wouldn't have to implement it on top of UDP

Re: QUIC and the end of TCP sockets

#16

Post by sedawkgrep »

Hydraulix989 wrote: post #12
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.

Not sure I follow. QUIC is just UDP with an extra header in the opaque payload. To a firewall, it looks just like UDP.

I think they’re saying that due to how firewalls are deployed, everything end up either being built on tcp or udp, instead of using existing (or building new) layer four protocols more suited to solving the problem like sctp, et al.

I’m not sure I agree though, because many firewalls already pass other protocols today, like GRE, IPSEC, etc.

Re: QUIC and the end of TCP sockets

#17

Post by tptacek »

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.

Re: QUIC and the end of TCP sockets

#18

Post by garganzol »

jklowden wrote: post #6

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

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

Re: QUIC and the end of TCP sockets

#19

Post by bayindirh »

lxgr wrote: post #4
nickysielicki wrote: post #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. 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.

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?

Re: QUIC and the end of TCP sockets

#20

Post by lxgr »

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?

> 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 responsivity without compromising on fairness, as e.g. BBR has shown.

Post reply on HN