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

Protocol Wars

en.wikipedia.org

Post reply on HN
Print view View original

91–100 of 121 posts

Re: Protocol Wars

#91

Post by doublepg23 »

TheLoafOfBread wrote: post #14
vmfunction wrote: post #8

Earlier quoted context omitted.

The fact that it takes so long to transition to IPv6 and like many other obstruction to technological/social progress are economic and business gain for a certain small group of people and organisations.

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.

This comes up often. What do you think would happen if you sent a “IPv4+” packet? All the ossified equipment would drop it. So you have to replace all this equipment, ideally _once_ so we ought to make it count.

Re: Protocol Wars

#92

Post by m3047 »

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 recursing resolvers to try TCP after receiving a successful UDP response with TC=1. (Where did this become "only"? When did it become ok not to support TCP?)

Seems like IP works just fine on top of ATM. Maybe the MTU isn't the same as ethernet; too bad.

By the way UDP frags are bad; don't do that. Guess it's not completely transparent afterall and relying on a kludge mechanism as the answer to knowing the terrain (MTU) isn't the One True Way.

TCP is a reliability mechanism built on top of IP. It has enough popularity to have its own protocol designator so that you can't say it's "built on top of UDP". Don't want that mechanism? Don't use it.

Want messaging? Use a datagram protocol; that would be UDP (unless you decide to use your own special protocol ID). It's unreliable? Do something about it. (See where I'm going with this?) Craft your messages so that they fit in a single packet. Invest in some decent networking gear that reports dropped packets and allows traffic shaping. Bonus: get one-to-many and transit-based destination editing.

If you refuse to compromise on your abastraction and are too cheap to afford SDN, create a virtualization layer for your network traffic like everybody before you... it's virtual turtles all the way down or hasn't that occurred to you?

Re: Protocol Wars

#93

Post by m3047 »

moomin wrote: 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.

Not saying that it's strictly how it has to be done but historically in OT environments the choice was more between (Ethernet) CSMA/CD and token ring (not so much Netware, it wanted to do its own thing) on a segment that IP was transiting.

Re: Protocol Wars

#94

Post by ElectricalUnion »

doctor_eval wrote: post #46
eternityforest wrote: post #38

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…

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.

Re: Protocol Wars

#95

Post by phicoh »

m3047 wrote: 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.

Re: Protocol Wars

#96

Post by phicoh »

doctor_eval wrote: post #46
eternityforest wrote: post #38

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…

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.

The big problem for TCP is all the boxes on the internet that understand TCP and don't understand TCP extensions. That could be home routers doing NAT, firewalls, etc. Those boxes are not only hard to upgrade, they also break things. QUIC fixes this by making sure that as much as possible is encrypted.

Some ISPs monitor TCP headers and from retransmissions they can figure out where problems are in the network. QUIC will take that ability away.

So QUIC is a mixed blessing.

Re: Protocol Wars

#97

Post by toast0 »

867-5309 wrote: post #43
londons_explore wrote: post #37

Earlier quoted context omitted.

And yet, even with QUIC and a brand new Google phone on a Google wifi network and a Google Fi cell connection, I still can't walk away from my house and have a video call migrate from wifi to 5G without the audio glitching and dropping frames. All the mobility benefits of QUIC mean nothing when the rest of the software stack isn't designed to let it work.

that's never going to be a seamless transition. the fact the transition happens automatically is a marvel in itself

Never is a long time. QUIC isn't great for this, because while it has IP address flexibility, it's not designed to have multiple paths simultaneously active.

If you design for this use case, you can make it work today; especially since the user is on a video call and only asking for the audio to be glitchless. Sending audio over both wifi and cell is possible and simple and would solve audio at the expense of double the audio bandwidth. More bandwidth efficient methods are left to the reader.

Re: Protocol Wars

#98

Post by grishka »

greyface- wrote: post #16
samwillis wrote: post #3

TCP/IP is so entrenched in everything, literally, it will still be in use when we leave this planet and it gets swallowed up by the sun. The news will report the destruction of Earth and explain that it and its inhabitants longest lasting legacy is TCP/IP, then report that the transition to IPv6 is going well and everyone will be on it soon...

TCP becomes unusable under interplanetary latencies; leaving the planet will force us to transition off of it.

That assumes that the speed of light is an insurmountable speed limit. We can't be 100% sure of that.

But even if it is, TCP can be used with any latency if you configure the timeouts accordingly and maintain a large enough send buffer to allow retransmissions.

Re: Protocol Wars

#99

Post by LaLaLand122 »

doctor_eval wrote: post #46
eternityforest wrote: post #38

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…

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…

> I wonder if we will see more of the network layer move into the application layer, like what I think happened with QUIC.

https://lwn.net/Articles/169961/

Re: Protocol Wars

#100

Post by toast0 »

londons_explore wrote: post #90
dave881 wrote: post #74

Earlier quoted context omitted.

There are several things that make this difficult. Much of the difficulty relates to the device changing it's network address. Seamless transition requires that the application can: - Find the new address; i.e. Cell provider vs. Residential/Business ISP - Associate the new address with the same flow - Duplicate packets and reassemble them, or change to "better" path interface.

On both android and iOS, a regular app can't choose to send packets over both 5G and wifi at the same time. Thats needed to setup a new connection while still using the old one.

I was pretty sure that android and iOS both have apis for apps to choose between 'whatever is best', 'wifi preferred' and 'cellular preferred'?

I don't know the details, but some iOS network apis (Network Kit?) allow you to set a required interface type somehow. https://developer.apple.com/documentation/network/nwparamete...

Post reply on HN