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

151–160 of 246 posts

Re: QUIC is now RFC 9000

#151

Post by Orphis »

Sean-Der wrote: post #141
Orphis wrote: post #138

Earlier quoted context omitted.

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

3 of those are related to DataChannels in WebRTC, which at this point is baked into the standard and can't be replaced by another protocol. The SCTP in DataChannels is quite limited, that subset is reasonable to implement somehow.

Only the last one is really general purpose and has had a lot of security issues as well.

Fun fact: I do work on one of those implementations and with another one, and it's out of necessity rather than a career choice.

Re: QUIC is now RFC 9000

#152

Post by jjoonathan »

ksec wrote: post #144
jjoonathan wrote: post #143

Earlier quoted context omitted.

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

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 port and the program gets hacked, it's your fault, not the program's fault. This is an arbitrary social choice that follows directly from enshrining NAT as a "best practice." Even the term "open port" presupposes that there is something unnatural about plebian computers talking to each other on the open internet! This effectively forces services to be centralized, or at least pushes very strongly in that direction.

Of course, we can quibble: what about video conferencing? What about gaming? They use direct connections! Yes, but they pay an extraordinarily steep complexity and reliability price to obtain them and the solutions still wind up using centralized servers. They are exceptions that prove the rule because they allow us to observe how "stepping out of line" is discouraged. It's an accidental line drawn by monkies rather than an intentional line drawn by lizard people, but it's strongly enforced and society-shaping all the same.

It's totally wild to consider the social and market consequences of NAT, the unassuming lazy and kludgy security hack. It got out of hand and reshaped the internet, the technology market, and society from the ground up! That's hardly even an exaggeration!

Re: QUIC is now RFC 9000

#153

Post by _0w8t »

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.

NAT does not need anything more than port numbers or UDP cannot be used with it.

As for QoS going beyond port number, source IP and rate of packets asks for troubles.

Re: QUIC is now RFC 9000

#154

Post by Orphis »

unethical_ban wrote: post #146
Orphis wrote: post #138

Earlier quoted context omitted.

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.

Having a standard doesn't mean you're not allowed to innovate and create another one.

SCTP dates from RFC2960, first draft was published in 1999. It had enough time to get traction, and it didn't. Why would anyone build something new with it now, knowing that it doesn't answer some of the issues with the current Internet?

Even WebRTC's DataChannels were introduced at the IETF in 2012, that's 9 years ago (although ironically, the RFC just got published in January...).

Re: QUIC is now RFC 9000

#155

Post by fanf2 »

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.

or use sendmmsg(2) and recvmmsg(2)

https://www.man7.org/linux/man-pages/man2/sendmmsg.2.html

Re: QUIC is now RFC 9000

#157

Post by Sean-Der »

Orphis wrote: post #151
Sean-Der wrote: post #141

Earlier quoted context omitted.

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

3 of those are related to DataChannels in WebRTC, which at this point is baked into the standard and can't be replaced by another protocol. The SCTP in DataChannels is quite limited, that subset is reasonable to implement somehow. Only the last one is really general purpose and has had a lot of security issues as well. Fun fact: I do work on one of those implementations and with another one, and it's out of necessity…

I know you understand libusrsctp Florent. I created Pion, I feel prety comfortable with SCTP and WebRTC in general as well.

RtcQuicTransport tried to replace SCTP and it didn't work. It would be possible to replace SCTP if something better was available. SCTP has lots of great stuff like FORWARD-TSN. QUIC didn't offer anything compelling over it. Also would come with a huge cost of making WebRTC larger and losing interop with all the existing clients.

libusrsctp has had security issues, but I don't think the protocol is the problem. The issue is C/C++. QUIC implementations are going to have the same class of bugs. Chrome/libwebrtc has plenty of security issues in other areas besides SCTP. Rust/Go doesn't fix everything, but one less thing to worry about at least.

Re: QUIC is now RFC 9000

#158

Post by westmeal »

fierro wrote: post #54
d110af5ccf wrote: post #49

Earlier quoted context omitted.

> Every app has to implement it itself No? I'll just link against one of the cross platform libraries that implements it, the same as for any other networking protocol. (Ex https://github.com/microsoft/msquic ) Also see: https://github.com/quicwg/base-drafts/wiki/Implementations > same as for TLS, making fewer apps implement it without a lot of extra work ... do you not just link against a relevant networking library…

my guy out here rolling his own TLS implementation

I dont know about you but I implement TLS in x86 assembler for breakfast.

Re: QUIC is now RFC 9000

#159

Post by BlueTemplar »

jjoonathan wrote: post #152
ksec wrote: post #144

Earlier quoted context omitted.

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

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.

Re: QUIC is now RFC 9000

#160

Post by BlueTemplar »

_0w8t wrote: post #153
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.

NAT does not need anything more than port numbers or UDP cannot be used with it. As for QoS going beyond port number, source IP and rate of packets asks for troubles.

I wonder : IPs are considered PI (heh). So does this mean that badly implemented QoS can end up violating RGPD ?
Post reply on HN