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

71–80 of 116 posts

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

#71

Post by WorldMaker »

Imustaskforhelp wrote: post #47
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.

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 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.

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

#72

Post by 0x457 »

kstrauser wrote: post #66
api wrote: post #55

Earlier quoted context omitted.

Let's say your ISP gives you a /64. Now you have to use V6 NAT... or assign a /96 internally. SLAAC won't let you do that. That, among other things, is a problem. SLAAC is too limited. You can use DHCPv6 but then you can't use Android because Android, and I think they're alone here, stubbornly and dogmatically refuses to implement it. I guess you could go around and statically assign V6 IPs to Android devices, or run…

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?

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

#73

Post by 0x457 »

valorzard wrote: post #4
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 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…

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.

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

#74

Post by tsimionescu »

capitainenemo wrote: post #63
tsimionescu wrote: post #17

Earlier quoted context omitted.

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.

It's also about user privacy with ISPs as well as anti-censorship. https://www.cloudflare.com/learning/dns/dns-over-tls/

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.

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

#75

Post by WorldMaker »

elcritch wrote: post #35
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…

At some point it seems like we just need to start passing laws requiring (major) internet services to provide all services on IPv6. Routers could then intercept ipv4 only devices and their dns locally and translate it to ipv6. Still lame that in 2024 major services like Steam and Quest basically require IPv4. I want to be able to use the internet without silly things like exhausting a network admins ipv4s.

At least cell phone networks through their standards processes have pushed most consumer networks and consumer hardware to be IPv6 by default ("by only option" in many cases with DNS64 and NAT64 filling in the gaps).

The real pressure we need are to corporate networks. Too many of them think they can use 10.0.0.0/8 forever. Too many of them own giant chunks of public IPv4 space and think they are immune to the address exhaustion. At least the prices for IPv4 addresses are going up at major clouds like AWS and Hetzner. But it still seems too slow of a price rise to hit enough bottom lines that major corporations are feeling the pressure yet.

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

#76

Post by ddejohn »

sema4hacker wrote: post #68

I think a more interesting question is: what if internet protocols and routing equipment were designed from scratch today? Besides much larger packets, I'm guessing something basic in the style of UDP would be chosen to replace HTTP to simplify query-response lookups, a much simpler streaming protocol would be chosen to replace TCP and support all the video playing going on, and those two protocols would more efficie…

There have been a few of these types of discussions on HN -- search phrases like "internet from scratch" -- really fun reading.

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

#77

Post by zrm »

kstrauser wrote: post #66
api wrote: post #55

Earlier quoted context omitted.

Let's say your ISP gives you a /64. Now you have to use V6 NAT... or assign a /96 internally. SLAAC won't let you do that. That, among other things, is a problem. SLAAC is too limited. You can use DHCPv6 but then you can't use Android because Android, and I think they're alone here, stubbornly and dogmatically refuses to implement it. I guess you could go around and statically assign V6 IPs to Android devices, or run…

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.

Users have poor leverage over ISPs. A lot of them still don't support IPv6 out of unmitigated laziness. If they provide it but violate the standard there isn't much you can do about it, so what the standard is really doing is preventing you from mitigating it.

The standard requiring an entire /64 for SLAAC is also just a poor design.

Suppose your ISP is doing the right thing and giving you at least a /56. You have a complex network with your own subnets and you're not sure how many you'll need in the future, but the spec says you only have to give each one a /64 and that seems like plenty, so the person setting up the network does that. Time passes and you get devices in various subnets with fixed addresses you need to stay fixed. Then you want to hook up a VM host or anything else that wants to further subdivide the address space, but the spec says you can't even though there are still scads of addresses. And for what, so they can use EUI-64 which in practice is only 48 bits anyway and is effectively deprecated because it's a privacy fail?

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

#78

Post by MisterTea »

kjs3 wrote: post #60
MisterTea wrote: post #49

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…

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

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

#79

Post by immibis »

globular-toast wrote: post #3

What you want is a packet socket: sock_raw = socket(AF_PACKET , SOCK_RAW , htons(ETH_P_ALL)); IP networks should forward anything, but NAT is a major problem. Would be interesting to try with IPv6.

This gives you a raw Ethernet socket. For a raw IP socket, use AF_INET,SOCK_RAW,0.

A raw Ethernet socket sends packets at the Ethernet level while a raw IP socket sends packets at the IP level. If you want to play on your local network you want Ethernet (maybe). If you want to send weird packets across the Internet you probably want IP, so that you don't have to waste effort doing route lookups and MAC address lookups and your code will still work on non-Ethernet networks, including VPNs.

There are some protocols that run on top of Ethernet but Internet-compatible protocols all run on IP by definition.

This comment was delayed several hours due to HN rate limiting.

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

#80

Post by nickburns »

tsimionescu wrote: post #74
capitainenemo wrote: post #63

Earlier quoted context omitted.

It's also about user privacy with ISPs as well as anti-censorship. https://www.cloudflare.com/learning/dns/dns-over-tls/

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.

Security through obscurity is not the same as actual concealment. That DoH is specced to operate over port TCP/443 makes it no more or less efficacious than DoT over TCP/853 with regard to avoiding censorship. I.e., they're both encrypted.

Many LAN operators conclude that the pragmatic impossiblility of blocking DoH is a net-negative for both network security and censorship avoidance.

Post reply on HN