3 ms·

SCTP had already solved the problem that QUIC proposes to solve. Google of all companies has the influence to properly implement and accommodate other L4 protoc

SCTP had already solved the problem that QUIC proposes to solve. Google of all companies has the influence to properly implement and accommodate other L4 protocols. QUIC seems like doubling down on a hack and breaks the elegance of OSI model.

tepmoc 2y ago
SCTP still have some donwsides it has to resolve https://http3-explained.haxx.se/en/why-quic/why-tcpudp#why-not-sctp-over-udp https://http3-explained.haxx.se/en/why-quic/why-tcpudp#why-n... Plus we need happy eyeballs for transport if SCTP run over IP and not encapuslated https://datatracker.ietf.org/doc/html/draft-grinnemo-taps-he https://datatracker.ietf.org/doc/html/draft-grinnemo-taps-he But IPv4 pretty much non-workable since most end-users behind NAT and there no known implementation to work around that.
kmeisthax 2y ago
The OSI model? We're in the world where TCP/IP won. OSI is a hilariously inelegant model that doesn't map to actual network protocols in practice. To wit: where exactly is the "presentation layer" or "session layer" in modern networking standards? IP didn't originally have layering. It was added early on, so they could separate out the parts of the protocol for routing packets (IP) and the parts for assembling data streams (TCP). Then they could permit alternate protocols besides TCP. That's very roughly OSI L3 and L4, so people assumed layering was ideologically adopted across the Internet stack, rather than something that's used pragmatically. Speaking of pragmatism, not everyone wants to throw out all their old networking equipment just to get routers that won't mangle unknown transports. Some particularly paranoid network admin greybeards remember, say, the "ping of death", and would much rather have routers that deliberately filter out anything other than well-formed TCP and UDP streams. Google is not going to get them to change their minds; hell, IPv6 barely got those people to turn on ICMP again. To make matters worse, Windows does not ship SCTP support. If you want to send or receive SCTP packets you either use raw sockets and run as admin (yikes), or you ship a custom network driver to enable unprivileged SCTP. The latter is less of a nightmare but you still have to watch out for conflicts, I presume you can only have one kind of SCTP driver installed at a time. e.g. if Google SCTP is installed, then you switch to Firefox, it'll only work with Mozilla SCTP and you'll have weird conflicts. Seems like a rather invasive modification to the system to make. The alternative is to tunnel SCTP over another transport protocol that can be sent by normal user software, with no privileged operations or system modification required. i.e. UDP. Except, this is 2010, we actually care about encryption now. TLS is built for streams, and tunneling TLS inside of multiple SCTP substreams would be a pain in the ass. So we bundle that in with our SCTP-in-UDP protocol and, OOPS, it turns out that's what QUIC is. I suppose they could have used DTLS in between SCTP and UDP. Then you'd have extra layers, and layers are elegant.

tepmoc 2y ago

SCTP still have some donwsides it has to resolve https://http3-explained.haxx.se/en/why-quic/why-tcpudp#why-not-sctp-over-udp https://http3-explained.haxx.se/en/why-quic/why-tcpudp#why-n... Plus we need happy eyeballs for transport if SCTP run over IP and not encapuslated https://datatracker.ietf.org/doc/html/draft-grinnemo-taps-he https://datatracker.ietf.org/doc/html/draft-grinnemo-taps-he But IPv4 pretty much non-workable since most end-users behind NAT and there no known implementation to work around that.

kmeisthax 2y ago

The OSI model? We're in the world where TCP/IP won. OSI is a hilariously inelegant model that doesn't map to actual network protocols in practice. To wit: where exactly is the "presentation layer" or "session layer" in modern networking standards? IP didn't originally have layering. It was added early on, so they could separate out the parts of the protocol for routing packets (IP) and the parts for assembling data streams (TCP). Then they could permit alternate protocols besides TCP. That's very roughly OSI L3 and L4, so people assumed layering was ideologically adopted across the Internet stack, rather than something that's used pragmatically. Speaking of pragmatism, not everyone wants to throw out all their old networking equipment just to get routers that won't mangle unknown transports. Some particularly paranoid network admin greybeards remember, say, the "ping of death", and would much rather have routers that deliberately filter out anything other than well-formed TCP and UDP streams. Google is not going to get them to change their minds; hell, IPv6 barely got those people to turn on ICMP again. To make matters worse, Windows does not ship SCTP support. If you want to send or receive SCTP packets you either use raw sockets and run as admin (yikes), or you ship a custom network driver to enable unprivileged SCTP. The latter is less of a nightmare but you still have to watch out for conflicts, I presume you can only have one kind of SCTP driver installed at a time. e.g. if Google SCTP is installed, then you switch to Firefox, it'll only work with Mozilla SCTP and you'll have weird conflicts. Seems like a rather invasive modification to the system to make. The alternative is to tunnel SCTP over another transport protocol that can be sent by normal user software, with no privileged operations or system modification required. i.e. UDP. Except, this is 2010, we actually care about encryption now. TLS is built for streams, and tunneling TLS inside of multiple SCTP substreams would be a pain in the ass. So we bundle that in with our SCTP-in-UDP protocol and, OOPS, it turns out that's what QUIC is. I suppose they could have used DTLS in between SCTP and UDP. Then you'd have extra layers, and layers are elegant.