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

141–150 of 246 posts

Re: QUIC is now RFC 9000

#141

Post by Sean-Der »

Orphis wrote: post #138
zozbot234 wrote: post #117

Earlier quoted context omitted.

> The “ossification” that QUIC deals with is primarily about internet routers who decide to dig into their IP packets. Being 'opaque' to the network is not a foolproof choice, since it also makes stuff like NAT, congestion control and QoS a lot less robust. By exposing connection identifiers to the network, SCTP gains a lot of flexibility wrt. such scenarios compared to QUIC.

It doesn't matter if SCTP has good features if no one is willing to implement quality libraries for it. The protocol exists for a while and only one general purpose library exists for it that's widely used. And it's not without a lot of flaws and limitations. There are good reasons no one wants to invest in it, and I'm sure they did consider it.

I am sure there are even more implementations that I am not aware of.

* https://github.com/pion/sctp

* https://github.com/aiortc/aiortc/blob/main/src/aiortc/rtcsct...

* https://source.chromium.org/chromium/chromium/src/+/main:thi...

* https://github.com/sctplab/usrsctp

People don't make these decisions for technical reasons only. Career wise it is a bad choice to spend your time working on pre-existing technologies. You don't become a distinguished engineer by iterating on existing technologies. You become one by being the creator of something new.

I think QUIC is great and does a good job solving the problems it was designed to solve. It is disingenuous to pretend these decisions were made only for technical reasons.

Re: QUIC is now RFC 9000

#142

Post by lovemenot »

Narishma wrote: post #131
alblue wrote: post #81

Earlier quoted context omitted.

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

I think some versions of Windows 3.x did come with a TCP/IP stack, though it wasn't installed by default even with networking. You had to explicitly install it.

windows for workgroups 3.11

iirc

Re: QUIC is now RFC 9000

#143

Post by jjoonathan »

zozbot234 wrote: post #117
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…

> The “ossification” that QUIC deals with is primarily about internet routers who decide to dig into their IP packets. Being 'opaque' to the network is not a foolproof choice, since it also makes stuff like NAT, congestion control and QoS a lot less robust. By exposing connection identifiers to the network, SCTP gains a lot of flexibility wrt. such scenarios compared to QUIC.

> it also makes stuff like NAT, congestion control and QoS a lot less robust

That's a feature, not a bug. NAT is cancer. It killed the open internet by enabling a particular lazy form of "security" that forced everyone to hand control of their most important data to cloud services.

QoS is worse but has less fallout due to less deployment.

Re: QUIC is now RFC 9000

#144

Post by ksec »

jjoonathan wrote: post #143
zozbot234 wrote: post #117

Earlier quoted context omitted.

> The “ossification” that QUIC deals with is primarily about internet routers who decide to dig into their IP packets. Being 'opaque' to the network is not a foolproof choice, since it also makes stuff like NAT, congestion control and QoS a lot less robust. By exposing connection identifiers to the network, SCTP gains a lot of flexibility wrt. such scenarios compared to QUIC.

> it also makes stuff like NAT, congestion control and QoS a lot less robust That's a feature, not a bug. NAT is cancer. It killed the open internet by enabling a particular lazy form of "security" that forced everyone to hand control of their most important data to cloud services. QoS is worse but has less fallout due to less deployment.

>NAT is cancer. It killed the open internet by enabling a particular lazy form of "security" that forced everyone to hand control of their most important data to cloud services.

Sorry I dont follow. What Cloud Services?

Re: QUIC is now RFC 9000

#145

Post by Hikikomori »

salawat wrote: post #128
zozbot234 wrote: post #117

Earlier quoted context omitted.

> The “ossification” that QUIC deals with is primarily about internet routers who decide to dig into their IP packets. Being 'opaque' to the network is not a foolproof choice, since it also makes stuff like NAT, congestion control and QoS a lot less robust. By exposing connection identifiers to the network, SCTP gains a lot of flexibility wrt. such scenarios compared to QUIC.

I'm happy whenever anyone brings up SCTP. Such a maligned protocol. Congestion control and QoS, however, are a loser's game. If you're running into realistic issues meeting demand due to statistical multiplexing breaking down to the point you must rely on caring about the internal state of traffic streams, you should have thrown more link hardware at the problem long ago. Many dumb pipes > fewer smarter pipes. >NAT O…

QoS has its uses, and you don't have to look any deeper than TCP/UDP headers for it to be good enough. It allows VOIP/IPTV services to continue working under DDoS conditions for example (ISP level).

Re: QUIC is now RFC 9000

#146

Post by unethical_ban »

Orphis wrote: post #138
zozbot234 wrote: post #117

Earlier quoted context omitted.

> The “ossification” that QUIC deals with is primarily about internet routers who decide to dig into their IP packets. Being 'opaque' to the network is not a foolproof choice, since it also makes stuff like NAT, congestion control and QoS a lot less robust. By exposing connection identifiers to the network, SCTP gains a lot of flexibility wrt. such scenarios compared to QUIC.

It doesn't matter if SCTP has good features if no one is willing to implement quality libraries for it. The protocol exists for a while and only one general purpose library exists for it that's widely used. And it's not without a lot of flaws and limitations. There are good reasons no one wants to invest in it, and I'm sure they did consider it.

If Google has a chance to use an industry standard or use their clout to create a new standard, you get one guess at what they're going to do.

Re: QUIC is now RFC 9000

#147

Post by unethical_ban »

yangl1996 wrote: post #44
wmf wrote: post #37

Earlier quoted context omitted.

I think from their perspective the (Windows and Android) kernel is what causes ossification so moving transport into the app, along with encryption, solves it.

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…

Most enterprise security vendors at the moment are advising their customers to block QUIC at the perimeter to force fallback to HTTPS so their TLS decryption can function.

There are valid, ethical reasons for an organization to want to see unencrypted network traffic at their perimeter, and until that problem is solved, you better not go QUIC-only if you are in the business to make money.

Re: QUIC is now RFC 9000

#148

Post by slrz »

MichaelMoser123 wrote: post #102
gotbeans wrote: post #93

Earlier quoted context omitted.

> forced ?? why shouldn't quick be able to use a udp socket?

you can do that, if you can to accept the overhead of a system call per outgoing/incoming frame.

You can always use sendmmsg(2), writev(2) or other iovec-based APIs.

Re: QUIC is now RFC 9000

#149

Post by mchusma »

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.

I actually believe it's their AI gap filling approach that may account for better perceived handoffs there. It was introduced on duo, and was supposed to hit meet sometime.

Re: QUIC is now RFC 9000

#150

Post by TrueDuality »

qwertox wrote: post #136

Will "Unreliable Datagrams" in QUIC support some sort of TLS?

Sure does. The protocol only transfers authenticated encrypted data by design which is slightly different in than how TLS behaves but with the same ultimate outcome (your traffic is encrypted).
Post reply on HN