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

51–60 of 83 posts

Re: QUIC and the end of TCP sockets

#51

Post by IgorPartola »

sedawkgrep wrote: post #16
Hydraulix989 wrote: post #12

Earlier quoted context omitted.

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.

That is exactly my point, thank you for clarifying. And yes IPSEC had started forcing people to open up their firewalls. If I had my way though it would be the other way around: all IP protocol numbers except those specifically deemed obsolete or insecure should be allowed, including a range for user defined custom protocols. We really painted ourselves into a corner of 6s and 17s.

Re: QUIC and the end of TCP sockets

#52

Post by IgorPartola »

thadt wrote: post #39
mtoner23 wrote: post #28

Earlier quoted context omitted.

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

Yeah? It's an eight byte header. The OS needs something to tag IP packets to get them delivered to the correct application. So you're thinking maybe a four byte header for 50% savings here?

So we have a checksum of the IP header, a checksum of the UDP header and a port number, an application level stream ID or message ID or whatever the application transport protocol is using, and finally almost certainly an even higher level message ID such as a URI. And that’s before you introduce encryption into it with all that overhead. A level 4 protocol providing full integrity verification, encryption, multi homing, multiplexing, out of band control, and control over transmission reliability would be amazing. But the only way you can experiment with these things is if you use UDP and ports. We take the concept of ports for granted but if you think of ICMP or some other L4 protocols that isn’t the only way to identify the sending and receiving application.

If we just allowed all L4 protocol numbers through and ditched NAT we could have nice things. Or we could kick it up two layers to use QUIC for what SCTP could have been.

Re: QUIC and the end of TCP sockets

#53

Post by jeffbee »

lxgr wrote: post #26
jeffbee wrote: post #24

Earlier quoted context omitted.

"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"?

I mean when your application sends on a socket, the kernel may also send and receive traffic for another task while it's in the syscall, just for funsies, and this is true even if your applications are containerized and you believe their CPU cores are dedicated to the container.

Re: QUIC and the end of TCP sockets

#54

Post by IgorPartola »

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.

UDP introduced ports. Ports are not always the best abstraction for specifying which application is talking to which other application. They are finite.

I am very aware of what you can do with UDP, I have done some very fun work trying to minimize bandwidth usage on crappy mobile connections by using and abusing it. But I think at the end of the day it is an engineering crutch.

If we insisted on properly supporting a diverse set of L4 protocols years ago we wouldn’t have wound up with NAT and slow adoption of IPv6. Address exhaustion would have been a real pressing issue. Instead you can’t even ping a server behind a NAT and firewalls run out of memory trying to manage stateful connections.

UDP is a pretty elegant design for what it is but it is barely good enough to allow us some room to make things work. Ultimately it did limit us more than it enabled us.

Re: QUIC and the end of TCP sockets

#55

Post by IgorPartola »

jlokier wrote: post #45
Hydraulix989 wrote: post #12

Earlier quoted context omitted.

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

Their point is that's a sad design choice, caused by firewalls forcing QUIC to take a first-class TCP-like internet protocol and wrap it with encrypted headers inside UDP for the sole purpose of preventing firewalls from blocking it or making it break in myriad subtle ways. Even QUICs unencrypted header parts are designed to be difficult for intermediate network equipment to track and modify, because of their history…

Couldn’t have said it better myself.

Re: QUIC and the end of TCP sockets

#56

Post by lxgr »

jeffbee wrote: post #53
lxgr wrote: post #26

Earlier quoted context omitted.

What do you mean by "other applications"?

I mean when your application sends on a socket, the kernel may also send and receive traffic for another task while it's in the syscall, just for funsies, and this is true even if your applications are containerized and you believe their CPU cores are dedicated to the container.

Ah, but that's an OS implementation problem, not one with TCP or QUIC, no?

Re: QUIC and the end of TCP sockets

#57

Post by supertrope »

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.

IPSec originally ran on raw IP. These days it has to be tunneled in UDP due to TCP or UDP only ossification.

PMTUD breaks when ICMP is blocked.

The same argument can be made that everything but HTTP being blocked is not a problem because everything can be transported on top of HTTP.

Re: QUIC and the end of TCP sockets

#58

Post by tptacek »

IgorPartola wrote: post #54
tptacek wrote: post #17

Earlier quoted context omitted.

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.

UDP introduced ports. Ports are not always the best abstraction for specifying which application is talking to which other application. They are finite. I am very aware of what you can do with UDP, I have done some very fun work trying to minimize bandwidth usage on crappy mobile connections by using and abusing it. But I think at the end of the day it is an engineering crutch. If we insisted on properly supporting a…

Ports are just a multiplexing device, the same as the IP protocol number. Besides the tiny number of bytes in the UDP header, what's the practical difference?

Re: QUIC and the end of TCP sockets

#59

Post by tptacek »

supertrope wrote: post #57
tptacek wrote: post #17

Earlier quoted context omitted.

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.

IPSec originally ran on raw IP. These days it has to be tunneled in UDP due to TCP or UDP only ossification. PMTUD breaks when ICMP is blocked. The same argument can be made that everything but HTTP being blocked is not a problem because everything can be transported on top of HTTP.

The same argument is made about HTTP. But at least in the HTTP case, you can point to protocol behavior the middle-layer protocol is enforcing on you. You can't do that with UDP; UDP is just IP, with some ports, and a checksum.

Re: QUIC and the end of TCP sockets

#60

Post by IgorPartola »

tptacek wrote: post #58
IgorPartola wrote: post #54

Earlier quoted context omitted.

UDP introduced ports. Ports are not always the best abstraction for specifying which application is talking to which other application. They are finite. I am very aware of what you can do with UDP, I have done some very fun work trying to minimize bandwidth usage on crappy mobile connections by using and abusing it. But I think at the end of the day it is an engineering crutch. If we insisted on properly supporting a…

Ports are just a multiplexing device, the same as the IP protocol number. Besides the tiny number of bytes in the UDP header, what's the practical difference?

Negligible to none as of now. But take a look at this comment below: https://news.ycombinator.com/item?id=45528837

And I agree: it stifled what could have been a much nicer to work with set of protocols and who knows what could have been created had we not just said "well there is always UDP if you want to do your own thing".

Post reply on HN