Live data from Hacker News

Protocol Wars

en.wikipedia.org

101–110 of 121 posts

Re: Protocol Wars

#101

Earlier quoted context omitted.

I think the factor you're missing is that the WiFi and 5G connections may have substantially different latencies to the other person. Going from a lower-latency to a higher-latency connection will always involve audio dropping out and video pausing. And in the opposite direction, it's preferable to skip over a few frames in order to reduce latency, rather than maintain higher latency. I wonder if you don't see this w…

Video conferencing has latency in the 300ms - 1000ms range[1]. The actual network component of that is pretty small. And video conferencing software already has logic for time stretching/compression to handle variable latency - typically they'll speed up or slow down gaps between words and sentences. [1]: https://www.mdpi.com/2076-3417/12/24/12884

Actually no -- things like FaceTime are more like 90 ms, while other common products like Zoom and Meet are around 150-200. These are minimums with somebody in your own city. This is actually from my own testing in the past, where FaceTime was the clear winner, since Apple seems to care a lot about latency and its software is custom written for its own hardware.

But networks absolutely can add major latency, have you never had a slow Zoom call? It's because of congestion building up and radio interference, not Zoom's software. That's what leads to things like 1,000 ms latency, which makes back and forth conversation very difficult. Moderate-to-major perceptible latency issues in conversation are always because of the network.

And yes some products do time stretching but that's also what people often call glitches because it's very weird.

Re: Protocol Wars

#102

I wish we could start over and redesign everything from Ethernet up to TLS with the lessons we now understand. So many layers could be merged, security could be so much easier, IP addressing hassles could be unnecessary. But all the stuff that seems obvious now couldn't have been learned without the decades of kind of terrible hackery that is OSI and the associated awful stuff like DNS. I'm not sure what the moral of…

It's really hard to prove anything about some things being different in this space, I'm certain it's not a unilaterally good thing.

Re: Protocol Wars

#103
post #95
post #92

And why is "big endian vs little endian" a thing in computers and networking? Because it's homage to Jonathan Swift. It references an apocryphal war about which end of a hard-boiled egg to lop off; no doubt a much more vicious affair than the Haiti / Dominican spat over the pronunciation of "parsely". Parts of the internet are still stuck in the 1980s, my pet peeve being the DNS resolution protocol which calls on rec…

You may want to talk to operators of DNS servers to find out why DNS is mostly UDP. From a software point of view is hardly matters. UDP has some quirks, TCP has some issues, not a big deal. The big deal for operators is resource consumption and latency. In the vast majority of cases where the UDP reply is not truncated, using UDP is both cheaper and faster.

I have worked for Paul Vixie. (I've met Mockepetris and Liu.) Even Vixie agrees UDP frags were a bad idea for The DNS.

Given the context of where we're discussing this, mind if I ask: Why is UDP so attractive for DNS operators? Is it that it encapsulates the message query / response paradigm so well?

Why isn't encryption of greater concern? How can DoT or DoH be "faster" than UDP? Is it really the protocol or a misattribution of causality actually based on LFNs, buffer bloat, and mis- or mal- construction of the tenet that UDP traffic can be dropped with no consequence (instead of employing traffic shaping, for instance).

Honestly, lay it on me: explain to me about messaging versus pipes using DNS as an example.

Re: Protocol Wars

#104
post #79

Earlier quoted context omitted.

People wanted to change bitfield with version from 4 to 6 and increase amount of bytes in IP address filed. Simple KISS. Instead of that we got fragile, backward incompatible, unnecessarily complex, jack of all trades protocol. And people are surprised that even after decades since the release of IPv6, it is being avoided like a plague.

Consider that NAT64 is able to translate between IPv4 and IPv6 at the packet level. If the protocols were as different as you suggest, this wouldn't be possible.

Doesn't IPv6 remove broadcast, thus removing DHCP and ARP?

I mean, hosts need to be 'dual stack' to support IPv4 and IPv6 together - whereas TheLoafOfBread's proposal would allow support of both with one backward-compatible stack.

Re: Protocol Wars

#105
post #96

Earlier quoted context omitted.

I wonder if we will see more of the network layer move into the application layer, like what I think happened with QUIC. I’m not really a network guy, but the thing I find interesting about QUIC is that it’s upgradable. Normalising regular browser updates was a godsend for the web, while TCP/IP remains hard to upgrade because you still, in 2023, have to upgrade your whole OS. Protocols like TLS that sit outside the O…

The need to upgrade the OS is only a small part of the problem. On the one hand, the fact the TCP is unchanging has led to network cards supporting TCP directly. You can shove a large segment of data in the network card and it will split the data up in TCP segments and transmit them. There are also big content companies that let the kernel do all TLS encryption, in some cases that can also be offloaded to hardware. T…

I disagree.

If there’s a financial incentive (better performance or whatever) then the server side will upgrade; it’s a financial and timing decision with strong motivators.

But the client side problem is 5-6 orders of magnitude larger than the server side problem - and to make things worse, they basically don’t care.

People seem happy enough to upgrade their browser, but upgrading their OS is a big deal. Even I don’t like doing it, and I consider it important.

So I think a reasonable rule of thumb would be, the server side will take care of itself. But if you need your clients to reboot their computer to upgrade the network stack to improve your server performance, well, it ain’t gonna happen.

Re: Protocol Wars

#106
post #2

This was still raging when I was a student. From my recollection I _heard_ a lot more about OSI, but everything I used had something proprietary (e.g. NetWare, Token Ring) or TCP/IP. The people supporting TCP/IP had a head start and out-executed the OSI committees and it wasn’t even funny.

Ha! I had worse, when I was a student (in '90s) I was taught some crazy stuff - OSI model but without a single word about the OSI protocols (like X.224) but with TCP/IP pulled over instead. So I was unironically taught that e.g. TCP is a layer 4 on the OSI model and HTTP is layer 7, etc. As if the model was still alive and relevant somehow.

They were still teaching that one decade ago, maybe never stopped.

Re: Protocol Wars

#107
post #79

Earlier quoted context omitted.

Consider that NAT64 is able to translate between IPv4 and IPv6 at the packet level. If the protocols were as different as you suggest, this wouldn't be possible.

Doesn't IPv6 remove broadcast, thus removing DHCP and ARP? I mean, hosts need to be 'dual stack' to support IPv4 and IPv6 together - whereas TheLoafOfBread's proposal would allow support of both with one backward-compatible stack.

DHCP and ARP use 32-bit addresses, so those protocols had to change regardless.

I would challenge you to find someone who knows the difference between Ethernet broadcast and multicast without looking up the answer. They are very similar mechanisms.

Re: Protocol Wars

#108
post #76

Earlier quoted context omitted.

"Because it works now" is a perfectly good reason, I was more talking about a hypothetical "wave a wand and change all devices overnight" scenario. I think an IPv8(Apparently we skip odd numbers) could be a real practical thing one day though, because a lot of things really do with quite work that well. The classic "it's always DNS" meme seems to be very real, tying TLS to domains instead of IPs impedes anything on L…

> tying TLS to domains instead of IPs impedes anything on LAN, TLS doesn't care what's in the certs, that's an application concern. IP addresses work fine in x.509 certs, but are discouraged because of difficulty of validating that control of the IP will continue through the certificate validity period. But this wouldn't much help for your LAN use case, assuing you're using RFC1918 addresses, because no one can prove…

You can prove control of an IP address if they were longer, and the DeviceGeneratedUniquePart was a hash of the certificate.

If you need to renew, you just get a new IP and tell DNS about it, if you're using fixed IPs and can't easily renew without manual work, you're still better off than no encryption.

Instead of proving control of a domain, you'd be proving that an IP is one of the correct ones for a domain.

Tech is advanced enough now that we don't need to conserve every single bit. What you lose in efficiency, you gain in easily being able to tell what part of the IP corresponds to one customer for antiDDOS ratelimiting and the like.

Source routing would probably be best as an optional feature. But if you had a hierarchy with a part explicitly tied to the region, you could source route to the county level at least or even data center level without needing to reveal the exact destination.

Re: Protocol Wars

#109
post #66

I wish we could start over and redesign everything from Ethernet up to TLS with the lessons we now understand. So many layers could be merged, security could be so much easier, IP addressing hassles could be unnecessary. But all the stuff that seems obvious now couldn't have been learned without the decades of kind of terrible hackery that is OSI and the associated awful stuff like DNS. I'm not sure what the moral of…

you don't understand the power of the Lindy effect. All of the dated infrastructure we have now has ultimately survived the test of time. https://en.wikipedia.org/wiki/Lindy_effect by the way DNS is wonderful.

Lindy is pretty much just natural selection for ideas, right? It doesn't prove they are optimal.

It does seem to suggest that frequently switching protocols all the time like we switch web frameworks would be awful though. The benefits of having any universal standard at all can outweigh the flaws in just about anything, even Ipv4 or in some cases even analog stuff.

Re: Protocol Wars

#110

Earlier quoted context omitted.

I wonder if we will see more of the network layer move into the application layer, like what I think happened with QUIC. I’m not really a network guy, but the thing I find interesting about QUIC is that it’s upgradable. Normalising regular browser updates was a godsend for the web, while TCP/IP remains hard to upgrade because you still, in 2023, have to upgrade your whole OS. Protocols like TLS that sit outside the O…

Or the kernels becomes even less of a monolith on all fronts and more userland-like. Both io_uring and eBPF would allow us to handle more complex tasks inside the kernel, reducing context switch losses yet still allowing the benefits of a upgrade-able structure without having to upgrade the OS or even the kernel itself.

Yeah. It strikes me that the lack of a stable Linux kernel ABI is part of the reason why we can’t easily upgrade bits of it. Upgrading a kernel module would be a good solution (could even be done by applications) but IIUC its infeasible.

But still, it seems conceivable that a networking kernel module could talk exclusively to an adaptor shim that is part of the kernel.

idk, I actually haven’t so much as compiled a kernel since the late 90s, so I’m pretty much talking out the wrong end :)

Post reply on HN