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

71–80 of 83 posts

Re: QUIC and the end of TCP sockets

#71

Post by tptacek »

IgorPartola wrote: post #60
tptacek wrote: post #58

Earlier quoted context omitted.

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

Stifled how? You want SCTP? Allocate a UDP port for it. You still haven't explained what the problem is.

Re: QUIC and the end of TCP sockets

#72

Post by Hydraulix989 »

jabiko wrote: post #14
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.

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.

It's an eight byte penalty for things needed for QUIC anyways.

Re: QUIC and the end of TCP sockets

#73

Post by toast0 »

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.

It's not nice that pmtud breaks when ICMP isn't available, but sensible probing can do pretty well. Of course, barely anybody probes and they may not be sensible if they do.

Imagine at the beginning of a connection, sending a burst of packets, you could send (ignoring tcp timestamps because it makes the math hard, PAWS is a waste of bytes for most flows, and etc) [0,1460); [1400, 2800), ...

If you get an ack of the first packet, great. If not, you resend it as a 1400 byte payload and probe again in a future burst. Maybe even premptively resend the first packet as a 1400 byte segment after a short delay. Anyway, have enough failed large packets and probe smaller. Probe bigger again every so often if the connection stays open for a meaningful amount of time.

Re: QUIC and the end of TCP sockets

#74

Post by toast0 »

lxgr wrote: post #22
bayindirh wrote: post #13

Earlier quoted context omitted.

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

Fairness at the bottleneck is what matters.

I think the hope is that OS developers will continue to generally pursue (tcp) congestion control that is at least reasonably fair. But if it's under the control of app developers, there's less of a track record of doing the right thing.

Congestion management at bottlenecks is very hard at the bottleneck. If a 40gbps port is congested, the routers on that port almost certainly do not have the ability to do any sort of fair queue management. So everyone has to play nice.

It is not terribly hard for an app developer to get millions of installs; it's a lot harder for an app developer to get millions of patched kernels.

That said, if the whole deal with quic is google wanted userspace congestion control, which is understandable, I don't see why they didn't just do that. It's not like they don't control a large amount of servers with a ton of traffic, and they also control the OS (to some degree) on a large amount of clients. http/2 multiplexing would still be as obviously flawed as it was on release. You'd still have head of line blocking on http/2, but with the right settings, you can just have multiple tcp connections... TLS 1.3 0-RTT and maybe tcp fast open could get round trip counts reduced when appropriate. With proper congestion control, you could share the congestion context for multiple connectjons tk the same peer. QUIC would still have the upper hand with the ability to selectively not retry on unacknowledged data, but I don't know how often that's really used.

Re: QUIC and the end of TCP sockets

#76

Post by IgorPartola »

tptacek wrote: post #71
IgorPartola wrote: post #60

Earlier quoted context omitted.

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

Stifled how? You want SCTP? Allocate a UDP port for it. You still haven't explained what the problem is.

OK let’s put it this way: what is the point of IP being able to carry protocols other than ICMP, TCP, and UDP? For that matter why doN’t TCP and ICMP run on top of UDP?

Re: QUIC and the end of TCP sockets

#77

Post by tptacek »

IgorPartola wrote: post #76
tptacek wrote: post #71

Earlier quoted context omitted.

Stifled how? You want SCTP? Allocate a UDP port for it. You still haven't explained what the problem is.

OK let’s put it this way: what is the point of IP being able to carry protocols other than ICMP, TCP, and UDP? For that matter why doN’t TCP and ICMP run on top of UDP?

There isn't one! TCP running on top of UDP would have been a reasonable design. TCP/IP is full of warts like this. The URG pointer. The conflicting length fields.

The fact of ICMP not being itself a UDP protocol caused major problems for systems programmers, because it meant that OS kernels all "owned" ICMP, provided only a baroque sockopt programming interface to like 5% if it, and required userland programs to hold suser privileges to do any real ICMP work. Awful design. And ICMP is slow-pathed by routers, because it isn't UDP.

UDP literally doesn't do anything but multiplex raw IP. Unless you're actually worried about the 8 bytes the header takes up, there's no reason, none at all, to slide a new IP protocol anywhere but on top of UDP. Again: that's why UDP was designed in the first place. You can go look this up! David Reed still talks about it!

Re: QUIC and the end of TCP sockets

#78

Post by Hydraulix989 »

tptacek wrote: post #63
jlokier wrote: post #45

Earlier quoted context omitted.

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.

Finally some sense in this thread.

Re: QUIC and the end of TCP sockets

#79

Post by mdhb »

tptacek wrote: post #77
IgorPartola wrote: post #76

Earlier quoted context omitted.

OK let’s put it this way: what is the point of IP being able to carry protocols other than ICMP, TCP, and UDP? For that matter why doN’t TCP and ICMP run on top of UDP?

There isn't one! TCP running on top of UDP would have been a reasonable design. TCP/IP is full of warts like this. The URG pointer. The conflicting length fields. The fact of ICMP not being itself a UDP protocol caused major problems for systems programmers, because it meant that OS kernels all "owned" ICMP, provided only a baroque sockopt programming interface to like 5% if it, and required userland programs to hold…

Isn’t WebTransport more or less TCP (reimagined I guess but it’s key functionality and set of capabilities) running on UDP while also able to play well with the web’s security model.

Re: QUIC and the end of TCP sockets

#80

Post by ashtakeaway »

garganzol wrote: post #18
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".

Really glad NextDNS blocked my click.
Post reply on HN