Dexter said:
@Hadi
I really don’t understand why Google pushed this protocol so hard, especially since SCTP has existed for years and does the same job.
This is similar to why people wrap protocols in HTTP: it’s because IT departments and router makers treat anything outside of TCP/UDP and HTTP (with a few exceptions) like they’re not worth using. They block other ports and refuse to support other protocols.
@Kai
IT departments are usually the problem, especially with UDP blocks. Those can change more easily than core internet infrastructure. If they don’t change, they’ll have to deal with the consequences. Meanwhile, if it can go beyond just a few UDP ports, it could help everyone.
@Kai
Good thing SCTP supports UDP encapsulation natively.
Dexter said:
@Hadi
I really don’t understand why Google pushed this protocol so hard, especially since SCTP has existed for years and does the same job.
QUIC uses 0-1 RTT, while SCTP over DTLS takes 4. For high latency cases, QUIC should perform way better.
@Wynn
There’s no reason you couldn’t include all necessary TLS details in the first packet. SCTP is built to be extendable, and all current flags in the initial packet are unused. Making a flag to show initial TLS is simple. If the ACK response misses that flag, you know you’re talking to a system that doesn’t support or want to provide encryption.
@Dexter
An RFC was actually published this week to extend SCTP and use those flags to optionally skip checksum verification, which is helpful when SCTP is layered above another protocol like DTLS that does its own checks.
Dexter said:
@Hadi
I really don’t understand why Google pushed this protocol so hard, especially since SCTP has existed for years and does the same job.
Because so many ISPs and modems block SCTP, it practically becomes unfeasible. SCTP really shines on private WANs like the ones telecoms use.
@Hollis
It can also encapsulate in UDP, so really, it can work almost everywhere where UDP does.
Dexter said:
@Hollis
It can also encapsulate in UDP, so really, it can work almost everywhere where UDP does.
But then we face the same problem of hardware offloading not being supported, plus we lose the benefit of being implemented in user space, which allows faster improvements.
@Hollis
User space SCTP is available for all major OS now.
Quick updates and protocol upgrades are listed in the RFC as reasons for encapsulation. Your driver would manage that automatically: it tries SCTP first, then falls back on UDP.
Hardware offloading for SCTP is not too bad since UDP encapsulation can handle packet sizes close to 2^16 bytes. Even if using 10 Gbps (for the few users and servers that can manage this), you’d still deal with around 152k checksum checks a second, which is manageable for modern CPUs, especially next to the 6.6 million checksum tests for Ethernet frames.
Plus, NIC firmware can be upgraded, so it’s easy to roll out hardware offloading features later.
@Hollis
Google has the means to encourage vendors to sort this problem.
Imagine putting a “network health indicator” in the Chrome title bar that only shows 100% if SCTP over IPv6 operates with minimal buffer delays and uses a public address, etc.
@Eli
You’re right. Most telcos use 8-year-old firmware in their routers. No one is fixing much.
Hollis said:
@Eli
Google could pressure vendors to fix this.
That’s a completely unrealistic expectation.
Sure, one person at YouTube managed to drive IE6 into the ground in just a couple of years with an unofficial warning banner.
It wouldn’t be instant nor universal, but Google could certainly encourage 90% of devices blocking SCTP to allow it over a few years through subtle nudges.
And yes, that assumes there is a common understanding that handling protocols with a hardware whitelist is bad design. Any ISP doing that should be fined for misleadingly claiming to provide “internet access”.
Hollis said:
@Eli
Google could pressure vendors to fix this.
That’s a completely unrealistic expectation.
Looks like it worked to get Apple to adopt RCS…
Hollis said:
@Eli
Google could pressure vendors to fix this.
That’s a completely unrealistic expectation.
Looks like it worked to get Apple to adopt RCS…
That was just a software change and it still took years. Google has zero chance of convincing ISPs, especially with their tight profit margins, to replace all modems and redo or fix their entire network systems.
@Hollis
The same pressure up the supply chain can lead to updates down the line.
Uma said:
@Hollis
The same pressure up the supply chain can lead to updates down the line.
No way, the manufacturer has moved on by now, and many modems aren’t even made to be remotely updated, plus if it is possible, they’ll charge a lot of money to implement it.
Hollis said:
@Eli
Google could pressure vendors to fix this.
That’s a completely unrealistic expectation.
Looks like it worked to get Apple to adopt RCS…
Apple only adopted RCS because the EU demanded it. They didn’t want anything to do with RCS because it’s not secure. If the EU demanded SCTP, then sure we’d have it, but it’s not as good as QUIC in terms of initial latency.