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

QUIC is now RFC 9000

fastly.com

Post reply on HN
Print view View original

81–90 of 246 posts

Re: QUIC is now RFC 9000

#81

Post by alblue »

throwawaaarrgh wrote: post #51
jeltz wrote: post #48

Earlier quoted context omitted.

Why can't QUIC be implemented in the Kernel? Just because something can be implemented in user space does not mean that it has to.

Anything can be implemented in a kernel. But unless it's natively supported in other kernels, networks, and systems, that just means that one kernel is easier to work with. The big idea behind TCP/IP is that it's a stack which you can use anywhere and everywhere. Not just any network, but any host. To do that, you need it to be portable and ubiquitous. And there is no protocol above OSI layer 4 that is ubiquitous. By…

> The big idea behind TCP/IP is that it's a stack which you can use anywhere and everywhere

For what its worth, Windows 3.x did not come with a TCP/IP stack installed; it was an optional extra. (In the days before Windows 3.x you had to pay for the TCP/IP stack from your network card vendor as an optional extra.)

It wasn’t until Win95 that the OS came bundled with TCP/IP by default, and you could still install other networking protocols like Novel Netware or AppleTalk.

TCP/IP didn’t become the default stack until late into the ‘90s and the “everywhere by default” wasn’t really true until just before the turn of the millennium.

So while QUIC might be in the “early adopters” space for now, everything started that way once. I have no doubt that by 2030 we will see QUIC as a kernel feature in many major operating systems.

Re: QUIC is now RFC 9000

#82

Post by amelius »

skissane wrote: post #47
throwawaaarrgh wrote: post #35

> The internet transport ecosystem has been ossified for decades now, and QUIC breaks out of this ossification But it's still just a layer on top of UDP, and still implemented at the application, like in the past. So how is the ossification broken? Every app has to implement it itself rather than calling a syscall and letting the OS deal with its complexities (same as for TLS, making fewer apps implement it without a…

> Every app has to implement it itself rather than calling a syscall and letting the OS deal with its complexities (same as for TLS, making fewer apps implement it without a lot of extra work). Which also increases context switching Nowhere does RFC9000 say that it has to be implemented in user-space. A kernel-space implementation of QUIC would be conforming. Any OS kernel project (whether open source or proprietary)…

And why does it have to be handled in the OS, if a library would do just fine and provide more flexibility?

Re: QUIC is now RFC 9000

#83

Post by tester34 »

Ayesh wrote: post #80
tester34 wrote: post #77

if we could magically do not care about compatibility how we could redesign/rewrite internet now in order to make it better? what could've been done better? how better performance could be?

I would start by: - Not allocating giant slices of IPv6/4 space to corporations or government agencies. Everything must be IPv6. - Adding proper authentication to BGP. - Taking off the super powers of CAs - Not piling up standards on DNS. - Killing ICANN because it turned out to be a greedy senseless organization. - HTTPS is the standard, and email servers just follow the auth/encryption just like HTTPS. - Curve/Ed25…

Well, I expected more radical/foundational changes than "upgrade to $modern standards" :P

e.g change TCP to $YOLO PROTOCOL, get rid of OSI for something different

Re: QUIC is now RFC 9000

#84

Post by [deleted] »

amelius wrote: post #82
skissane wrote: post #47

Earlier quoted context omitted.

> Every app has to implement it itself rather than calling a syscall and letting the OS deal with its complexities (same as for TLS, making fewer apps implement it without a lot of extra work). Which also increases context switching Nowhere does RFC9000 say that it has to be implemented in user-space. A kernel-space implementation of QUIC would be conforming. Any OS kernel project (whether open source or proprietary)…

And why does it have to be handled in the OS, if a library would do just fine and provide more flexibility?

[deleted]

Re: QUIC is now RFC 9000

#85

Post by ldng »

ninepoints wrote: post #69

I wish the QUIC design was datagram-first... so many client/server implementations don't implement the datagram extension properly because it's... well an extension, and for most applications, reliable sequencing should be eschewed in favor of client-side reassembly. IMO QUIC was far too influenced by the legacy of how HTTP works when there was an opportunity to leapfrog a generation of bad decisions.

Very much like HTTP 2/3, it solves primarily Google's problems.

Re: QUIC is now RFC 9000

#86

Post by ldng »

rini17 wrote: post #74
MertsA wrote: post #72

Earlier quoted context omitted.

I just really wish Google would have built QUIC on top of SCTP. They had the clout, and opportunity to push for real end-to-end SCTP support across the internet. Tunnel it over UDP for IPv4 and userspace implementations but use native SCTP where possible like over IPv6 before middleboxes abound that only support TCP, UDP, and ICMP. There's too many NAT implementations, firewalls, etc that don't support SCTP on IPv4 b…

They wanted a protocol as opaque to middleboxes as possible. SCTP probably isn't, that was not an issue back when it was created.

What Google wants for itself should be irrelevant to the broader Inter-Network standards.

Re: QUIC is now RFC 9000

#87

Post by touisteur »

amelius wrote: post #82
skissane wrote: post #47

Earlier quoted context omitted.

> Every app has to implement it itself rather than calling a syscall and letting the OS deal with its complexities (same as for TLS, making fewer apps implement it without a lot of extra work). Which also increases context switching Nowhere does RFC9000 say that it has to be implemented in user-space. A kernel-space implementation of QUIC would be conforming. Any OS kernel project (whether open source or proprietary)…

And why does it have to be handled in the OS, if a library would do just fine and provide more flexibility?

Well you know that someone is gonna implement it in ebpf sooner than later.

Re: QUIC is now RFC 9000

#88

Post by ldng »

ec109685 wrote: post #62
ivan4th wrote: post #11

Wake me up when multipath support is included... Till then I prefer TCP b/c I can use MPTCP to utilize all of my rural LTE bandwidth for each single flow (e.g. downloading a file)

It is a shame it’s not more widely deployed. It makes so much sense to be able to seamlessly handle transition from Wifi to Cellular. It feels like Google is supporting some notion of this given Meet has seamless handoff as you leave Wifi.

What ?! You mean they're using this standardisation excuse to gain a competitive advantage with a proprietary extension? Shocking....

Re: QUIC is now RFC 9000

#89

Post by touisteur »

wmf wrote: post #41
DaiPlusPlus wrote: post #39

Earlier quoted context omitted.

You're forgetting the rest of userspace that exists between the application and the kernel. > moving transport into the app, along with encryption, solves it This is only a good idea if the application's development moves faster than both the kernel and the rest of the userspace platform - which is a fine strategy if you're targeting old or obsolete platforms, but probably a bad idea if you're targeting currently-sup…

Let's be honest; we're talking about Chrome here. Chrome auto-updates and Windows (pre-10) did not so bugs will be fixed faster in Chrome. Everybody else is along for the ride.

I agree that for updatability it should be something that can be shutdown, reloaded, restarted as simply and with least risk possible. Now I'm thinking that it'll be easier to checkpoint/restore a quic connection than any other thing based on tcp or hidden in the kernel, so you could even do zero-downtime update.

Re: QUIC is now RFC 9000

#90

Post by MichaelMoser123 »

throwawaaarrgh wrote: post #35

> The internet transport ecosystem has been ossified for decades now, and QUIC breaks out of this ossification But it's still just a layer on top of UDP, and still implemented at the application, like in the past. So how is the ossification broken? Every app has to implement it itself rather than calling a syscall and letting the OS deal with its complexities (same as for TLS, making fewer apps implement it without a…

i think the intent is that normally you would do a lot of syscalls in order to do networking; with QUICK you would currently be forced to do do zero-copy networking and pass the frames to the kernal via pf-ring; things don't become simpler, as the network layers will have to be handled by a user mode library, however they would potentially be much faster.
Post reply on HN