What would happen if we didn't use TCP or UDP?
20 comments
·February 25, 2025pkkm
jeroenhd
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
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.
nly
It gets worse in practice. Congestional control algorithms on the internet need to play nice with TCP Cubic regardless of how good they are.
valorzard
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
> why QUIC exists when SCTP does
Because QUIC uses UDP, which is supported by most/all intermediate routing equipment.
nly
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.
noam_k
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!)
saurik
WebRTC runs SCTP over DTLS over UDP.
nubinetwork
I thought the point was that they wanted to use something that didn't exist yet (either in RL use or in RFC form)...
megadata
> I'm running my client on Saudi Arabia
I'm impressed that any mystery IP traffic got out of SA.
globular-toast
What you want is a packet socket:
sock_raw = socket(AF_PACKET , SOCK_RAW , htons(ETH_P_ALL));
ay
To second this and expand on the reasons behind:
The way the NATs (network address translators) are sharing the scarce public IPv4 addresses is by multiplexing on the transport level fields (ports in case of TCP/UDP and IDs or inner packet transport level fields in case of ICMP).
Since they are unaware of your protocol, they get into a “special case mode”, which on a naive translator might consume a whole IP address (so you would really make a network admin with a few of those, because you exhaust all their available addresses :-) ; but on the carrier grade NAT there are safeguards against it and the packets are just dropped.
geokon
This is outside my area of expertise.. so naiive question.. but ports aren't tied to the protocol .. right? If you open a raw socket, it's still on some associated port number. NAT traversal multiplexes ports.. so why would that preclude using any arbitrary protocol?
tsimionescu
Ports are very much a concept of the transport layer. They are a very useful concept, so they are used in all major transport-layer protocols, but they are not necessary in a theoretical sense (though a transport layer protocol without them would only allow a single stream of traffic between any two machines, or at least IPs). But TCP port 22 is a completely different thing than UDP port 22, and they are both completely different from SCTP port 22. To prevent confusion, IANA typically assigns the same port number for a protocol on both TCP and UDP (e.g. DNS over TCP uses TCP port 53, just like DNS over UDP uses UDP port 53; and QUIC uses UDP port 443, just like HTTPS uses TCP port 443).
When a machine receives a packet, after the Ethernet and IP layers have made sure the packet is addressed to this machine, the very next thing that happens is checking what transport layer implementation should receive the packet - and this is done based on the "transport" bits in the IP header. If the packet is, say, TCP, then the TCP layer starts reading its own header and finds out the port number, and proceeds from there.
nlitened
Ports are part of TCP and UDP, not IP, as far as I can tell. So ports are tied to the protocol
withinboredom
Ports are tied to the protocol. IP layer doesn’t have ports (it’s in the name).
Hawzen
That's very interesting!
I'll try out IPv6
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.