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

171–180 of 246 posts

Re: QUIC is now RFC 9000

#171

Post by slowstart »

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

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.

Our QUIC implementation MsQuic can run in both kernel and user mode on Windows. A PAL allows the core protocol logic to be agnostic.

Re: QUIC is now RFC 9000

#172

Post by overgard »

throwawaaarrgh wrote: post #163
cormacrelf wrote: post #64

Earlier quoted context omitted.

The “ossification” that QUIC deals with is primarily about internet routers who decide to dig into their IP packets. https://http3-explained.haxx.se/en/why-quic/why-ossification Many have optimisations around TCP and long-standing TCP characteristics, which they are able to do because the TCP headers are unencrypted. This led to TCP being difficult to improve, because of all the implementations out there making assum…

Ah, the old middleboxes excuse. Changing TCP would break the middleboxes, so instead we'll invent a brand new protocol which is (theoretically) ignored by the middleboxes. The idea being if you slip something in via UDP, nobody will notice, and then you encrypt it so the middleboxes give up on it. This assumes that lack of transparency is the only way forward. I'd argue that IP and TCP ossified not because of transpa…

> Yet we know a transparent, grokable, mungeable, backwards-and-forwards-compatible protocol that plays well with middle boxes is doable: HTTP

Not all traffic is web traffic, maybe not even most of it. There are so many things that would have absolutely wretched performance if you tried to implement them with HTTP instead of TCP. HTTP is way too generic to be truly performant.

Re: QUIC is now RFC 9000

#173

Post by 10000truths »

ikiris wrote: post #166
throwawaaarrgh wrote: post #164

Earlier quoted context omitted.

NAT is literally the only thing stopping every single personal device in the world from being hacked. It may be a kludge, but it's the best kludge in all of technology. And what do you have against QoS? Would it be better if your VoIP calls stuttered every time you loaded a fat web page?

No it isn't, that's basic stateful firewalling. NAT in no way provides security. At all.

Even stateful firewalls don’t protect you from being hacked. Hacks occur when you run untrusted code on your machine. That untrusted code can easily bypass your stateful firewall by initiating a connection to a C&C server.

Re: QUIC is now RFC 9000

#174

Post by slowstart »

jokoon wrote: post #107

I am still wondering, isn't TCP hardware accelerated? Maybe QUIC would also mean the CPU working harder, but I'm not really sure. I would be nice to have a thoughtful conversation about the security implication of QUIC: Wikipedia says packets are encrypted individually. I'm also curious: is QUIC exclusively aimed towards HTTP2 or can it be used for real time applications, like real time gaming or video conferencing?

You may be interested in this: https://techcommunity.microsoft.com/t5/networking-blog/makin.... The gist is that yes QUIC has higher CPU usage but all OS platforms are investing in UDP hardware offloads and optimizations to level the playing field. While the only IETF standard that will come out is HTTP/3, our implementation MsQuic powers both HTTP/3 and SMB proving the general purpose nature of the transport. We are not there yet in terms of an application that's only powered by QUIC because UDP reachability is not 100%, so you need a fallback. Most apps will either use HTTP/3 and fallback to HTTP/2 or use QUIC directly and have to fall back to secure L7 over TCP.

Re: QUIC is now RFC 9000

#175

Post by BlueTemplar »

randomifcpfan wrote: post #61
yangl1996 wrote: post #44

Earlier quoted context omitted.

There are also the "middle boxes" that networking researchers talk a lot about. Such devices sit in the middle of a link and easily become unhappy if the packets transmitted do not fit some (possibly outdated or buggy) predefined scheme. Think of cooperate firewalls with "deep pack inspection" that intelligently shut down connections they do not like. Once all middle box vendors start to assume a certain way that a p…

Yes, exactly. See this lwn article for more discussion of ossification: https://lwn.net/Articles/745590/

> SCTP has been around for years, but middleboxes still do not recognize it and tend to block it. As a result, SCTP cannot be reliably used on the net. Actually deploying a new IP-based protocol, he said, is simply impossible on today's Internet.

Well, IPv6 shows that it's hard, but possible.

Also see how new broadcast "protocols" were forced on TV manufacturers by various governments worldwide.

Re: QUIC is now RFC 9000

#176

Post by 10000truths »

BlueTemplar wrote: post #159
jjoonathan wrote: post #152

Earlier quoted context omitted.

All cloud services. Personal computers and devices are not allowed to talk to each other on the internet. They are only allowed to talk to specially designated servers -- specially designated by virtue of having a public IPv4 and open port. Enforcement happens through liability: if you put data in a cloud service and the cloud service gets hacked, it's the cloud service's fault, but if you run a program on an open po…

Thankfully, this is going away now with IPv6.

Unfortunately not. Most consumer and SOHO routers have reflexive ACLs enabled by default, and your average Joe doesn’t know or care to turn it off.

Re: QUIC is now RFC 9000

#177

Post by fouric »

throwawaaarrgh wrote: post #164
jjoonathan wrote: post #152

Earlier quoted context omitted.

All cloud services. Personal computers and devices are not allowed to talk to each other on the internet. They are only allowed to talk to specially designated servers -- specially designated by virtue of having a public IPv4 and open port. Enforcement happens through liability: if you put data in a cloud service and the cloud service gets hacked, it's the cloud service's fault, but if you run a program on an open po…

NAT is literally the only thing stopping every single personal device in the world from being hacked. It may be a kludge, but it's the best kludge in all of technology. And what do you have against QoS? Would it be better if your VoIP calls stuttered every time you loaded a fat web page?

> NAT is literally the only thing stopping every single personal device in the world from being hacked.

This is so wrong that it must be satire. NAT provides the very most basic protection possible, easily replicated (and surpassed) by every firewall that comes stock with every modern OS, and is completely insufficient (and not even necessary) to prevent personal devices being hacked.

Re: QUIC is now RFC 9000

#178

Post by josefx »

overgard wrote: post #165
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 I think for almost all developers, library support for features is much more relevant than OS support anyway. How many of you are directly writing winsock code? Implementing it on UDP just means that you don't need to update a lot of ancient routers and firmware. I don't see "ossification" being a proble…

> Things haven't changed much at the transport layer because largely it just works.

There is a reason this isn't built on top of TCP, because TCP has so many problems the moment you try to do anything non trivial with it.

UDP on the other hand is kind of redundant since you already have IP packages, so you have a tiny package based protocol on top of a different package based protocol. Also you don't get any ordering information in UDP, which is kind of weird since the IP layer has to handle ordering to deal with package fragmentation, which is a fun feature that some hardware sees as a request to reorder your packages. I may have some PTSD from dealing with "smart" switches and a bit of software that did not expect package reordering issues on a tiny in house network.

Re: QUIC is now RFC 9000

#179

Post by salawat »

jopsen wrote: post #124
capableweb wrote: post #123

Earlier quoted context omitted.

> You'd be super sad if you could not reference a function defined later in a source file. Would you? Most of the environments I'm in requires you to define the thing before you can use it, I'm not that sad about that. In fact, that seems to make a lot more sense than that you can define something after you use it, I'd expect that to lead to a compiler/interpreter error.

So no recursion?

You totally can.

Remember, it's all about tokenizing. You're associating chunks of machine code to tokens that tell the machine where to go to get the actual definition, or where to plop the machine code if statically linking.

Nobody said that RFC numbering implied any sort of temporal order. You are the Linker. Be the Linker.

Re: QUIC is now RFC 9000

#180

Post by salawat »

snuxoll wrote: post #129
vincnetas wrote: post #59

Earlier quoted context omitted.

To be used as 9000 meme it should have been "over 9000" https://en.wikipedia.org/wiki/It%27s_Over_9000 !

As GP’s edit pointed out, it actually is RFC 8999-9002 - so yes, it’s over 9000.

No, that's just a sine-wave centered around 9000 where someone forgot to take instrument precision into account.
Post reply on HN