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

61–70 of 83 posts

Re: QUIC and the end of TCP sockets

#61

Post by lxgr »

tuetuopay wrote: post #48
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.…

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.

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.

Re: QUIC and the end of TCP sockets

#62

Post by lxgr »

IgorPartola wrote: post #50
lxgr wrote: post #44

Earlier quoted context omitted.

IPv6 doesn't provide a length header, so that's already 2 bytes arguably necessary for all protocols layered on top of that. Source and destination port just seem like a reasonable baseline for alternate protocols, that's 4 more – leaving just the checksum. (If you're really desperate for space and have integrity provided by your protocol, you can even cram two more bytes in there!) Sure, it would be conceptually nic…

QUIC doesn’t use the UDP length header to designate message length, does it? But my point isn’t even about performance. It is about the fact that NAT and IPv4 address exhaustion and bad firewall practices have killed any innovation of level 4 protocols. Imagine if instead of TCP, SCTP had won the protocol wars in 1980-1990s. Or even better if we had realized that we were going to run out of IPv4 addresses much earlie…

> QUIC doesn’t use the UDP length header to designate message length, does it?

Does it not? Not sure if it's really mandatory, but I believe one rationale for IPv6 getting rid of both its checksum and length fields was that both TCP and UDP duplicate both fields.

Given that QUIC doesn't have its own length field, I would imagine it relies on that of UDP, at least in situations where the lower layer does not provide reliable framing?

> Imagine if instead of TCP, SCTP had won the protocol wars in 1980-1990s. [...] We could have had the opportunity to experiment with different types of transports, baked encryption in at a lower level, etc.

Would we? Instead of TCP, SCTP would have become ossified in the stack all other things being equal (in particular the need for something like NAT due to IPv6 exhaustion), no?

Re: QUIC and the end of TCP sockets

#63

Post by tptacek »

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…

UDP is playing exactly the role it was intended to play. Apart from saving 8 bytes of header and a checksum, what's the advantage to running the protocol directly on top of IP? How is this "ossification"? Again: this was David Reed's original design purpose for UDP! It was exactly for doing shit on top of IP without having to run through TCP's mechanism.

Re: QUIC and the end of TCP sockets

#64

Post by jeffbee »

lxgr wrote: post #56
jeffbee wrote: post #53

Earlier quoted context omitted.

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?

Sure, but the ready appeal of QUIC is that it is in user space by nature, while Linux ties TCP to the kernel. You either need special privileges to run user space TCP on Linux, or you need a different operating system kernel altogether.

Re: QUIC and the end of TCP sockets

#65

Post by tptacek »

IgorPartola wrote: post #52
thadt wrote: post #39

Earlier quoted context omitted.

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

There's going to be encryption either way in any modern protocol, and then the header manipulation stuff is already all done in hardware. It's probably more efficient in UDP than as a direct IP protocol, because UDP is fast-pathed in ways protocols other than 6 and 17 aren't.

Having a diversity of IP protocols isn't a nice thing. The designers of TCP/IP made a protocol specifically for doing the thing you wanted to see SCTP do: it was called UDP.

Re: QUIC and the end of TCP sockets

#66

Post by tptacek »

lxgr wrote: post #42
thadt wrote: post #39

Earlier quoted context omitted.

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?

Good point on there needing to be some application-level addressing anyway. On top of that, I believe the UDP checksum can be omitted as well at least on some OSes (and is arguably not necessary for fully encrypted/authenticated payloads) – leaving really just the two bytes for the "length field".

You can't omit the UDP checksum in IPv6.

Re: QUIC and the end of TCP sockets

#67

Post by cbluth »

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

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

Re: QUIC and the end of TCP sockets

#68

Post by IgorPartola »

tptacek wrote: post #65
IgorPartola wrote: post #52

Earlier quoted context omitted.

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

There's going to be encryption either way in any modern protocol, and then the header manipulation stuff is already all done in hardware. It's probably more efficient in UDP than as a direct IP protocol, because UDP is fast-pathed in ways protocols other than 6 and 17 aren't. Having a diversity of IP protocols isn't a nice thing. The designers of TCP/IP made a protocol specifically for doing the thing you wanted to s…

Why isn’t it a nice thing? And SCTP and UDP clearly provide different semantics. I am fine with experimenting with new protocols on top of UDP because it is simple to do but ultimately I think things like SCTP and QUIC should run directly on top of IP.

Re: QUIC and the end of TCP sockets

#69

Post by KaiserPro »

lxgr wrote: post #23
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…

> since it duplicates the TLS handshake across streams

Depends on your usecase of course. if its something thats only around for a minute, then yeah, but over an hour, makes no difference at all.

QUIC eats more CPU per MB of data than plain TCP/TLS. but that might be solved by more modern offload/kernel optimisations

Re: QUIC and the end of TCP sockets

#70

Post by tptacek »

IgorPartola wrote: post #68
tptacek wrote: post #65

Earlier quoted context omitted.

There's going to be encryption either way in any modern protocol, and then the header manipulation stuff is already all done in hardware. It's probably more efficient in UDP than as a direct IP protocol, because UDP is fast-pathed in ways protocols other than 6 and 17 aren't. Having a diversity of IP protocols isn't a nice thing. The designers of TCP/IP made a protocol specifically for doing the thing you wanted to s…

Why isn’t it a nice thing? And SCTP and UDP clearly provide different semantics. I am fine with experimenting with new protocols on top of UDP because it is simple to do but ultimately I think things like SCTP and QUIC should run directly on top of IP.

No. SCTP provides a superset of UDP's semantics. Every IP protocol does, because UDP doesn't do anything except multiplex raw IP.
Post reply on HN