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

81–90 of 116 posts

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

#81

Post by Karrot_Kream »

crims0n wrote: post #28
Karrot_Kream wrote: post #10

Earlier quoted context omitted.

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

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.

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.

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

#82

Post by walth »

WorldMaker wrote: post #71
Imustaskforhelp wrote: post #47

Earlier quoted context omitted.

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…

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

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

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

#83

Post by immibis »

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…

What we can learn from this is that there are networks other than The Internet, and even The Internet can be subdivided into parts that don't really work together.

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

#84

Post by adrianmonk »

geokon wrote: post #46
tsimionescu wrote: post #19

Earlier quoted context omitted.

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

You are partially right, though. The OS network stack does expose and handle ports if you use a protocol that has them.

Networks are built in layers. There's a physical layer underneath IP, then there's IP, and then there's TCP and UDP on top of IP.

The OS network stack has components that handle all of these layers. That's why it's called a stack.

Port numbers are part of the individual protocol (TCP or UDP) because there are a lot of things you can do with networking, and port numbers don't necessarily make sense with all of them.

For example, when you ping another computer, that uses ICMP, and there is no need for ports with ICMP. You're pinging the whole computer, not trying to connect with one of several applications running on it. So ports are not really needed.

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

#85

Post by Karrot_Kream »

jmclnx wrote: post #48

We would all be on UUCP. That was doing similar things before TCP/UDP.

If you're interested in a more "modern" UUCP, there's NNCP [1] (HTTPS ver here [2].) It continues to mostly be a file-transfer protocol with a bit of signaling added on.

[1]: http://www.nncpgo.org/

[2]: https://nncp.mirrors.quux.org/

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

#86

Post by hylaride »

0x457 wrote: post #72
kstrauser wrote: post #66

Earlier quoted context omitted.

Android's right on this one (and I don't own an Android device that I know of, so this isn't me fanboying them). TBH ISPs that hand out /64's shouldn't be allowed to say that they support IPv6 because it's a completely non-standard — not as in "uncommon", but as in "violates the documented standards" - setup.

Wait, what's not standard about /64?

Strictly speaking, it's perfectly standard and you can subdivide it (manually). However, for a variety of reasons subnetting smaller than a /64 is difficult and not supported at all via SLAAC (because the host portion is derived from the MAC which is already 48 bits, plus other overhead). So if you want to split up a /64 from your ISP, you're limited to manual configuration, DHCPv6 (and no android support), or other ways:

https://version6.ru/en/dividing-the-indivisible

If you're just dealing with a single network at home, a /64 is otherwise fine. But there's a reason the recommended handout from ISPs is a /56; the inventors of IPv6 (or more specifically SLAAC) just didn't take into consideration how intransigent big telecoms would be.

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

#87

Post by immibis »

mrbluecoat wrote: post #50
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

Actually the Internet at large is fine with any protocol on top of IP. It's your home router's NAT function that can only handle UDP and TCP. Set it to bridge mode and use your computer as the router (if you need one) and you can send anything from that computer.

If you have CGNAT you're still screwed. Get one of those free ipv6 tunnels.

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

#88

Post by immibis »

kjs3 wrote: post #61
jmclnx wrote: post #48

We would all be on UUCP. That was doing similar things before TCP/UDP.

UUCP was only a couple years before TCP, and isn't really an equivalent (it's fancy file transfer with a little remote command exec sprinkled on in the end) and natively its dialup oriented; it usually requires some other L3 protocol to run over networks. There was a time when IPX/SPX was a contender. Xerox pitched XNS directly at TCP. DECNet/OSI was around. There were a lot of others...lot's of experimenting going o…

UUCP's primary distinction is that it's store-and-forward.

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

#89

Post by kjs3 »

MisterTea wrote: post #78
kjs3 wrote: post #60

Earlier quoted context omitted.

Reminds me a bit of UUCP or AT&T Datakit addressing.

Datakit was in fact one of the early supported networks in Plan 9. You could dial into a 9 machine over datakit, mount an outward facing IP stack over your /net and your on-line: http://man.postnix.pw/plan_9_2e/3/datakit

Interesting, and I suppose not surprising given the source. AT&T kept on with Datakit long after circuit switched data networking became passe.

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

#90

Post by 0x457 »

hylaride wrote: post #86
0x457 wrote: post #72

Earlier quoted context omitted.

Wait, what's not standard about /64?

Strictly speaking, it's perfectly standard and you can subdivide it (manually). However, for a variety of reasons subnetting smaller than a /64 is difficult and not supported at all via SLAAC (because the host portion is derived from the MAC which is already 48 bits, plus other overhead). So if you want to split up a /64 from your ISP, you're limited to manual configuration, DHCPv6 (and no android support), or other…

I understand that, but what I'm replying to says: "TBH ISPs that hand out /64's shouldn't be allowed to say that they support IPv6 because it's a completely non-standard — not as in "uncommon", but as in "violates the documented standards" - setup."
Post reply on HN