Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What would happen if we didn't use TCP or UDP?

github.com

Post reply on HN
Print view View original

41–50 of 116 posts

Re: What would happen if we didn't use TCP or UDP?

#41

Post by immibis »

pkkm wrote: post #2

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.

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)

Re: What would happen if we didn't use TCP or UDP?

#42

Post by immibis »

noam_k wrote: post #6
15155 wrote: post #5

Earlier quoted context omitted.

> why QUIC exists when SCTP does Because QUIC uses UDP, which is supported by most/all intermediate routing equipment.

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!)

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.

Re: What would happen if we didn't use TCP or UDP?

#43

Post by nesarkvechnep »

jeroenhd wrote: post #9
pkkm wrote: post #2

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.

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

As with most of the network stack, *BSD implementation is the reference implementation.

Re: What would happen if we didn't use TCP or UDP?

#44

Post by LinuxBender »

What would happen if we didn't use TCP or UDP?

One would have a hard time communicating with anyone. The internet has standardized around TCP and UDP. There are too many devices in most paths that will not be able to handle other protocols. Replacing all the hardware on the internet would take even longer than deprecating IPv4 in my pessimistic opinion. To get around this there would have to be some significant gains of the new protocol that would warrant big expenses in every corporation and government and all the hardware manufacturers would all have to agree on implementing support and further agree on interpretation of the new RFC.

Re: What would happen if we didn't use TCP or UDP?

#45

Post by Hikikomori »

geokon wrote: post #13
ay wrote: post #11

Earlier quoted context omitted.

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…

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?

IP has no ports, it has a protocol field, TCP, UDP, IPsec and other layer 4 protocols have their own protocol number. NAT (PAT really) uses TCP and UDP ports to connect what can be considered separate connections, ie a connection on the inside and a connection on the outside, these connections don't even have the same source/destination ports as connection state tracking is what connects these separate connections.

The socket API has different types of sockets, typically you use stream (TCP) or dgram (UDP), but you can also get a completely raw socket where you need to construct your own ethernet and IP headers, or create your own replacement of IP protocol. So socket does not mean only TCP/UDP or something with ports, unix sockets are another example of this.

Re: What would happen if we didn't use TCP or UDP?

#46

Post by geokon »

tsimionescu wrote: post #19
geokon wrote: post #13

Earlier quoted context omitted.

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?

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

> But TCP port 22 is a completely different thing than UDP port 22

OH woah woah. Okay that's the root of my confusion then. Nevermind. I thought the OS network stack exposes ports and packets come on to ports

Nevermind then :)

Re: What would happen if we didn't use TCP or UDP?

#47

Post by Imustaskforhelp »

15155 wrote: post #5
valorzard wrote: post #4

Earlier quoted context omitted.

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…

> why QUIC exists when SCTP does Because QUIC uses UDP, which is supported by most/all intermediate routing equipment.

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

Re: What would happen if we didn't use TCP or UDP?

#49

Post by MisterTea »

There's also Bell Labs IL - Internet Link - used to speed up 9P links for Plan 9 over LANs. https://doc.cat-v.org/plan_9/4th_edition/papers/il/

And this brings me to why I love networking on Plan 9. First off the dial string, net!address!service, passes the network along with the address and service port letting you easily switch protocols as needed. e.g. a program could listen on IL port 666 using the dial string il!*!666 and the client dials il!10.1.1.1!666. Second, that lets you dial and listen on any protocol from any program. If one wanted to use raw Ethernet you use the dial string ether0!aabbccddeeff. If I wanted to add a protocol like quic or a dead one like ipx/spx I just need to mount it to /net and keep the semantics the same as other services in net and any program can dial that protocol - ezpz user space networking stacks. Powerful abstraction.

Re: What would happen if we didn't use TCP or UDP?

#50

Post by mrbluecoat »

LinuxBender wrote: post #44

What would happen if we didn't use TCP or UDP? One would have a hard time communicating with anyone. The internet has standardized around TCP and UDP. There are too many devices in most paths that will not be able to handle other protocols. Replacing all the hardware on the internet would take even longer than deprecating IPv4 in my pessimistic opinion. To get around this there would have to be some significant gains…

Agreed. This statement sums up the obvious:

> Granted, the server was just two hops away from the client, and it didn't have to pass through the scary sea of the internet

Post reply on HN