8 ms·

You don't need to make up your own for this experiment. There's already a pretty old protocol that's far superior to TCP, but failed to get adoption because of

by pkkm 2y ago

You don't need to make up your own for this experiment. There's already a pretty old protocol that's far superior to TCP, but failed to get adoption because of network hardware dropping everything other than TCP and UDP. It's called SCTP.

nubinetwork 2y ago
I thought the point was that they wanted to use something that didn't exist yet (either in RL use or in RFC form)...
valorzard 2y ago
SCTP is really cool, I first found out about it because it’s the basis for WebRTC data channels. It’s basically reliable UDP, but you can turn off the reliability if you want. Makes me wonder why QUIC exists when SCTP does…
- 15155 2y ago
  > why QUIC exists when SCTP does Because QUIC uses UDP, which is supported by most/all intermediate routing equipment.
  - noam_k 2y ago
    Is this a real issue? SCTP runs over IP, so unless your talking about firewalls and such, the support should be there. Edit: a quick search showed that NAT traversal is an issue (of course!)
    - evrimoztamur 2y ago
      Hole punching is perhaps why UDP is de facto?
    - Karrot_Kream 2y ago
      Yes this is called protocol ossification [1] or ossification for short. Other transport layer protocol rollouts have been stymied by ossification such as MPTCP. QUIC specifically went with UDP to prevent ossification yet if you hang out in networking forums you'll still find netops who want to block QUIC if they can. [1]: https://en.m.wikipedia.org/wiki/Protocol_ossification https://en.m.wikipedia.org/wiki/Protocol_ossification
      - crims0n 2y ago
        Because from an enterprise security perspective, it breaks a lot of tools. You can’t decrypt, IDS/IPS signatures don’t work, and you lose visibility to what is going on in your network.
        Dylan16807 2y ago
        Wrapping everything in UDP breaks the same tools but it's more obnoxious for everyone involved.
        Karrot_Kream 2y ago
        Yes I know why netops want to block QUIC but that just shows the tension between the folks who want to build new functionality and the folks who are in charge of enterprise security. I get it, I've held SRE-like roles in the past myself. When you're in charge of security and maintenance, you have no positive incentive to allow innovation. New functionality gives you nothing. You never get called into a meeting and congratulated for new functionality you help unlock. You only get called in if something goes wrong, and so you have every incentive to monitor, lock down, and steer traffic as best as you can so things don't go wrong on your watch. IMO it's a structural problem that blocks a lot of innovation. The same thing happens when a popular open source project that's author led switches to an external maintainer. When the incentives to block innovation are stronger than the incentives to allow it, you get ossification.
        smaudet 2y ago
        Possibly even SRE shouldn't even exist, not only the structural issues you mention, but... If you approach to security is that only square tiles are allowed because your security framework is a square grid, and points just break your security model, maybe it was never a valid thing to model in the first place. I'm not saying security should not exist, but to use an analogy the approach should be entirely different - we have security guards, less so fences, not because fences don't provide some security, but because the agent can make the proper decision, and a lot of these enterprise models are more akin to fences with a doorman, not an professional with a piece and training...
    - immibis 2y ago
      Every home user is behind a NAT. While you can send any protocol between datacenter servers, IPv4 home users are stuck with TCP or UDP.
  - saurik 2y ago
    WebRTC runs SCTP over DTLS over UDP.
  - nly 2y ago
    The whole point of UDP is to allow alternative protocols to be implemented on top. SCTPs mistake was it wasn't implemented as a userland library on top of UDP to begin with.
  - Imustaskforhelp 2y ago
    I am now genuinely wondering Maybe its me being stupid but why don't we use quic always instead of tcp? I think it has to do with something that I read that tcp can do upto 1000 connections simultaneously no worries and they won't interfere with each other's bandwidth / impact each other , but udp does make it possible for one service being very high to impact other. There was this latest test by anton putra with udp vs tcp and the difference was IIRC negligible. Someone said that he should probably use udp in kernel mode to essentially get insane performance I amnot sure
    - WorldMaker 2y ago
      > Maybe its me being stupid but why don't we use quic always instead of tcp? A big reason is because QUIC is a lot younger than TCP and it will take a while for all the use cases of TCP to decide (if they are actively maintained and looking at possible upgrades) if QUIC is a good option worth testing. QUIC's rollout so far hasn't been entirely without bugs/controversies/quirks/obstacles/challenges. You still see a lot more HTTP/2 than HTTP/3 connections in the current wild and that doesn't seem to be changing near as fast as major providers upgraded HTTP/1.x to HTTP/2. There's still a bunch of languages and contemporary OSes without strong QUIC support. (Just the other day on HN was a binding for Erlang to msquic, IIRC, for a first pass at QUIC support in that language.) Some point soon QUIC might start feeling as rock solid as TCP, but today TCP is (decades of) rock solid and QUIC is still a lot new and a little quirky.
      - walth 2y ago
        Safari on IOS still has a ton lingering HTTP/3 / QUIC bugs. I think it is to the point that if your user base doesn't warrant it, (i.e. you are targeting well connected devices with minimal latency/packetloss) it's not even worth turning HTTP/3 on
      - Imustaskforhelp 2y ago
        so quic just lacks the decades of experience but is a better protocol than tcp overall ? That is kind of nice to know actually. The support will come considering its built on top of UDP. You just need people pushing and google is already pushing it hard . The main problem is quic's support in languages. But support will come.So after reading this comment of yours , I am pretty optimistic about quic overall
  - lttlrck 2y ago
    That's not the reason, SCTP over UDP was already standardized
- tepmoc 2y ago
  https://news.ycombinator.com/item?id=41488416 https://news.ycombinator.com/item?id=41488416
- bdd8f1df777b 2y ago
  Others have mentioned protocol ossification which is indeed the primary reason. A secondary reason is that QUIC fuses TLS so its latency is further reduced by one RTT. For high latency networks, the difference is palpable.
- signa11 2y ago
  > It’s basically reliable UDP, ... more importantly though, it transmits multiple independent streams of message chunks in parallel. similarity with UDP ends at message oriented nature of the protocol. closest equivalent for TCP would be MPTCP I suppose ?
- 0x457 2y ago
  Because pure SCTP can't survive outside your LAN, thanks to everything in-between you and your destination. Why not use SCTP on top of UDP? Well, because one of the main benefits of QUIC is TLS being at its core. SCTP you're talking about runs on top of DTLS on top of UDP. DTLS has issues on its own, but even if it didn't it wouldn't beat QUIC in TTFB.
- ianburrell 2y ago
  SCTP can run over UDP. QUIC is supposed to be faster than SCTP by combining layers and eliminate round trips. Also, QUIC is a stream protocol like TCP. SCTP makes messages explicit. Both have multiplexing which is why seem different.
jeroenhd 2y ago
SCTP is fascinating because it's one of the backbone technologies that makes communication possible for most people on the planet (as the mobile network stack pretty much relies on it), yet it's effectively unsupported on almost every consumer device. If you want to use it, you're probably going to have to ship a userland implementation that needs privileges to open a raw network socket, because kernel implementations are rare (and often slow). We could've had it as a QUIC replacement if it weren't for terrible middleboxes and IPv4 NAT screwing everyone over once again. Hell, NAT wouldn't even have been an issue had SCTP support been widespread before consumer NAT devices started being implemented. It's a prime example of how new network protocols now have to lie and deceive to work over the internet. TLS needs to pretend to be TLS 1.2, QUIC needs to pretend to be an application on top of UDP while reimplementing SCTP and TCP, and even things like secure DNS are now piped over HTTPS just in case a shitty middlebox can't deal with raw TLS.
- tsimionescu 2y ago
  While the gist of your post is spot on, I do feel it should be noted that DoH is preferred over DoT not to protect from middleboxes that don't work properly, but from middleboxes that are actively trying to outright censor encrypted DNS, but can't afford to snoop on/prevent all HTTPS traffic. It's an anti-censorship measure, not a compatibility measure.
  - capitainenemo 2y ago
    It's also about user privacy with ISPs as well as anti-censorship. https://www.cloudflare.com/learning/dns/dns-over-tls/ https://www.cloudflare.com/learning/dns/dns-over-tls/
    - tsimionescu 2y ago
      DoT (DNS over TLS) would have been enough for privacy from your ISP, using a dedicated port. It's only when you want to protect from censorship that you need to hide the (encrypted) DNS traffic among other traffic that can't be easily blocked.
immibis 2y ago
It's actually universal within a certain niche. I think phone networks are doing just about everything over SCTP internally. When SS7 links get replaced they get replaced with something that uses SCTP. Not sure of the details because I don't work there. Related: there's a parallel Internet with a different root of number allocation called GRX/IPX (GPRS Roaming Exchange/Internetwork Packet Exchange)
AnotherGoodName 2y ago
IPX is another that was very common just 20years ago. Many old games only support ipx networking and you need to run an ipx over tcp emulator to play them multiplayer nowadays.
dakra137 2y ago
TCP would be fine if it had the concept of message, in addition to stream. The sender sends a message. It flows to the recipient. The recipient program can specify that a receive receives the entire message, no more and no less, as long as the application's target input buffer is large enough. SCTP does this. A shim on top of TCP socket receive could also do this also, as long as there is a convention to prefix each message with a length field, say 16 bits, with the MSB indicating that the message is incomplete and is continued in the next length delimited segment.

by pkkm 2y ago

nubinetwork 2y ago

I thought the point was that they wanted to use something that didn't exist yet (either in RL use or in RFC form)...

valorzard 2y ago

SCTP is really cool, I first found out about it because it’s the basis for WebRTC data channels. It’s basically reliable UDP, but you can turn off the reliability if you want. Makes me wonder why QUIC exists when SCTP does…

15155 2y ago
> why QUIC exists when SCTP does Because QUIC uses UDP, which is supported by most/all intermediate routing equipment.
- noam_k 2y ago
  Is this a real issue? SCTP runs over IP, so unless your talking about firewalls and such, the support should be there. Edit: a quick search showed that NAT traversal is an issue (of course!)
  - evrimoztamur 2y ago
    Hole punching is perhaps why UDP is de facto?
  - Karrot_Kream 2y ago
    Yes this is called protocol ossification [1] or ossification for short. Other transport layer protocol rollouts have been stymied by ossification such as MPTCP. QUIC specifically went with UDP to prevent ossification yet if you hang out in networking forums you'll still find netops who want to block QUIC if they can. [1]: https://en.m.wikipedia.org/wiki/Protocol_ossification https://en.m.wikipedia.org/wiki/Protocol_ossification
    - crims0n 2y ago
      Because from an enterprise security perspective, it breaks a lot of tools. You can’t decrypt, IDS/IPS signatures don’t work, and you lose visibility to what is going on in your network.
      - Dylan16807 2y ago
        Wrapping everything in UDP breaks the same tools but it's more obnoxious for everyone involved.
      - Karrot_Kream 2y ago
        Yes I know why netops want to block QUIC but that just shows the tension between the folks who want to build new functionality and the folks who are in charge of enterprise security. I get it, I've held SRE-like roles in the past myself. When you're in charge of security and maintenance, you have no positive incentive to allow innovation. New functionality gives you nothing. You never get called into a meeting and congratulated for new functionality you help unlock. You only get called in if something goes wrong, and so you have every incentive to monitor, lock down, and steer traffic as best as you can so things don't go wrong on your watch. IMO it's a structural problem that blocks a lot of innovation. The same thing happens when a popular open source project that's author led switches to an external maintainer. When the incentives to block innovation are stronger than the incentives to allow it, you get ossification.
        smaudet 2y ago
        Possibly even SRE shouldn't even exist, not only the structural issues you mention, but... If you approach to security is that only square tiles are allowed because your security framework is a square grid, and points just break your security model, maybe it was never a valid thing to model in the first place. I'm not saying security should not exist, but to use an analogy the approach should be entirely different - we have security guards, less so fences, not because fences don't provide some security, but because the agent can make the proper decision, and a lot of these enterprise models are more akin to fences with a doorman, not an professional with a piece and training...
  - immibis 2y ago
    Every home user is behind a NAT. While you can send any protocol between datacenter servers, IPv4 home users are stuck with TCP or UDP.
- saurik 2y ago
  WebRTC runs SCTP over DTLS over UDP.
- nly 2y ago
  The whole point of UDP is to allow alternative protocols to be implemented on top. SCTPs mistake was it wasn't implemented as a userland library on top of UDP to begin with.
- Imustaskforhelp 2y ago
  I am now genuinely wondering Maybe its me being stupid but why don't we use quic always instead of tcp? I think it has to do with something that I read that tcp can do upto 1000 connections simultaneously no worries and they won't interfere with each other's bandwidth / impact each other , but udp does make it possible for one service being very high to impact other. There was this latest test by anton putra with udp vs tcp and the difference was IIRC negligible. Someone said that he should probably use udp in kernel mode to essentially get insane performance I amnot sure
  - WorldMaker 2y ago
    > Maybe its me being stupid but why don't we use quic always instead of tcp? A big reason is because QUIC is a lot younger than TCP and it will take a while for all the use cases of TCP to decide (if they are actively maintained and looking at possible upgrades) if QUIC is a good option worth testing. QUIC's rollout so far hasn't been entirely without bugs/controversies/quirks/obstacles/challenges. You still see a lot more HTTP/2 than HTTP/3 connections in the current wild and that doesn't seem to be changing near as fast as major providers upgraded HTTP/1.x to HTTP/2. There's still a bunch of languages and contemporary OSes without strong QUIC support. (Just the other day on HN was a binding for Erlang to msquic, IIRC, for a first pass at QUIC support in that language.) Some point soon QUIC might start feeling as rock solid as TCP, but today TCP is (decades of) rock solid and QUIC is still a lot new and a little quirky.
    - walth 2y ago
      Safari on IOS still has a ton lingering HTTP/3 / QUIC bugs. I think it is to the point that if your user base doesn't warrant it, (i.e. you are targeting well connected devices with minimal latency/packetloss) it's not even worth turning HTTP/3 on
    - Imustaskforhelp 2y ago
      so quic just lacks the decades of experience but is a better protocol than tcp overall ? That is kind of nice to know actually. The support will come considering its built on top of UDP. You just need people pushing and google is already pushing it hard . The main problem is quic's support in languages. But support will come.So after reading this comment of yours , I am pretty optimistic about quic overall
- lttlrck 2y ago
  That's not the reason, SCTP over UDP was already standardized
tepmoc 2y ago
https://news.ycombinator.com/item?id=41488416 https://news.ycombinator.com/item?id=41488416
bdd8f1df777b 2y ago
Others have mentioned protocol ossification which is indeed the primary reason. A secondary reason is that QUIC fuses TLS so its latency is further reduced by one RTT. For high latency networks, the difference is palpable.
signa11 2y ago
> It’s basically reliable UDP, ... more importantly though, it transmits multiple independent streams of message chunks in parallel. similarity with UDP ends at message oriented nature of the protocol. closest equivalent for TCP would be MPTCP I suppose ?
0x457 2y ago
Because pure SCTP can't survive outside your LAN, thanks to everything in-between you and your destination. Why not use SCTP on top of UDP? Well, because one of the main benefits of QUIC is TLS being at its core. SCTP you're talking about runs on top of DTLS on top of UDP. DTLS has issues on its own, but even if it didn't it wouldn't beat QUIC in TTFB.
ianburrell 2y ago
SCTP can run over UDP. QUIC is supposed to be faster than SCTP by combining layers and eliminate round trips. Also, QUIC is a stream protocol like TCP. SCTP makes messages explicit. Both have multiplexing which is why seem different.

jeroenhd 2y ago

SCTP is fascinating because it's one of the backbone technologies that makes communication possible for most people on the planet (as the mobile network stack pretty much relies on it), yet it's effectively unsupported on almost every consumer device. If you want to use it, you're probably going to have to ship a userland implementation that needs privileges to open a raw network socket, because kernel implementations are rare (and often slow). We could've had it as a QUIC replacement if it weren't for terrible middleboxes and IPv4 NAT screwing everyone over once again. Hell, NAT wouldn't even have been an issue had SCTP support been widespread before consumer NAT devices started being implemented. It's a prime example of how new network protocols now have to lie and deceive to work over the internet. TLS needs to pretend to be TLS 1.2, QUIC needs to pretend to be an application on top of UDP while reimplementing SCTP and TCP, and even things like secure DNS are now piped over HTTPS just in case a shitty middlebox can't deal with raw TLS.

tsimionescu 2y ago
While the gist of your post is spot on, I do feel it should be noted that DoH is preferred over DoT not to protect from middleboxes that don't work properly, but from middleboxes that are actively trying to outright censor encrypted DNS, but can't afford to snoop on/prevent all HTTPS traffic. It's an anti-censorship measure, not a compatibility measure.
- capitainenemo 2y ago
  It's also about user privacy with ISPs as well as anti-censorship. https://www.cloudflare.com/learning/dns/dns-over-tls/ https://www.cloudflare.com/learning/dns/dns-over-tls/
  - tsimionescu 2y ago
    DoT (DNS over TLS) would have been enough for privacy from your ISP, using a dedicated port. It's only when you want to protect from censorship that you need to hide the (encrypted) DNS traffic among other traffic that can't be easily blocked.

immibis 2y ago

It's actually universal within a certain niche. I think phone networks are doing just about everything over SCTP internally. When SS7 links get replaced they get replaced with something that uses SCTP. Not sure of the details because I don't work there. Related: there's a parallel Internet with a different root of number allocation called GRX/IPX (GPRS Roaming Exchange/Internetwork Packet Exchange)

AnotherGoodName 2y ago

IPX is another that was very common just 20years ago. Many old games only support ipx networking and you need to run an ipx over tcp emulator to play them multiplayer nowadays.

dakra137 2y ago

TCP would be fine if it had the concept of message, in addition to stream. The sender sends a message. It flows to the recipient. The recipient program can specify that a receive receives the entire message, no more and no less, as long as the application's target input buffer is large enough. SCTP does this. A shim on top of TCP socket receive could also do this also, as long as there is a convention to prefix each message with a length field, say 16 bits, with the MSB indicating that the message is incomplete and is continued in the next length delimited segment.