Live data from Hacker News

Protocol Wars

en.wikipedia.org

81–90 of 121 posts

Re: Protocol Wars

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

Re: Protocol Wars

#82

In the mid-1980s, I took the OSI course. That's a bunch of time I'll never get back. That was nothing, though, compared to the X.400 course...

OSI concepts are still important, even if none of the layers map to a specific set of protocols and things are blurry near layer 1 and 2. For example, the fact that presentation and application are separate layers, and that compression/encryption are better in their own layer (presentation) rather than totally integrated in the application.

> For example, the fact that presentation and application are separate layers, and that compression/encryption are better in their own layer (presentation) rather than totally integrated in the application.

CRIME attack enters the chat

Compression is not better in its own layer. See the CRIME attack on TLS compression.

Encryption is better at as low an end-to-end layer as possible so that we can have a hope that we can off-load the work to hardware.

Re: Protocol Wars

#83

Earlier quoted context omitted.

Yeah. Top-down vs. agile. Cathedral vs. bazaar. "The right thing" vs "worse is better". And, as you said, the agile/bazaar/worse-is-better camp totally out-executed the top-down/cathedral/do-it-right approach, to the point that OSI is only a theoretical model at this point, and TCP/IP is running in everything from supercomputers to washing machines. Another one of the "well-done in theory, but left in the dust by rea…

As someone who participated at the periphery of the IETF, I resent the association with the ‘whatever goes as long as it only takes two weeks’ software planning movement. They did understand their limitations, and had a huge focus on practicality (running code), but otherwise they really did try to do the right thing. And aside from some obvious warts, I think they did an amazing job

I never said what you're resenting, nor meant to imply it.

But IETF, with their emphasis on practicality, on "rough consensus and running code", was far more on the agile end of the spectrum than OSI was. IETF would recognize a problem, have an RFC, and have working implementations before OSI had done anything. This meant that if you wanted something, your first chance to get it (often by years) was on the IETF road, not on the OSI road. Repeat that a bunch of times and the people who could benefit from new things all moved to the IETF standards.

Re: Protocol Wars

#85
IMO, the worst thing to come out of OSI was the use of numbers for referring to layers. It seems obfuscationist to say "layer 2" or "layer 3" but those seem to have lodged themselves into the industry. For those who only occasionally deal with network stacks "link layer" "internet layer" and "transport layer" are far more mnemonic.

Re: Protocol Wars

#86

Earlier quoted context omitted.

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

It 100% could be. Changes you'd need are: * Android lets an application talk over both wifi and 5G at the same time . * Android exposes information about signal strength on a per packet basis, so that the application can decide at some point that too many packets are too close to not being received, so it's time to send data over 5G in addition. It should also expose data about packet retransmissions at the physical…

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 with cell phones because the latency is generally identical, or if it's just less noticeable with audio than with video? I guess I'd also wonder if cell towers really do hand off without glitches, since there always seem to be glitches when you're driving, but you don't have the slightest idea whether they're from tall buildings or interference or Bluetooth or handoffs or what, or even on your end or the other person's end.

Re: Protocol Wars

#87

In the mid-1980s, I took the OSI course. That's a bunch of time I'll never get back. That was nothing, though, compared to the X.400 course...

OSI concepts are still important, even if none of the layers map to a specific set of protocols and things are blurry near layer 1 and 2. For example, the fact that presentation and application are separate layers, and that compression/encryption are better in their own layer (presentation) rather than totally integrated in the application.

The OSI presentation layer has nothing to do with compression nor encryption. The top three layers of OSI were much more about modelling mainframe terminal applications than anything modern.

Re: Protocol Wars

#88

Earlier quoted context omitted.

It 100% could be. Changes you'd need are: * Android lets an application talk over both wifi and 5G at the same time . * Android exposes information about signal strength on a per packet basis, so that the application can decide at some point that too many packets are too close to not being received, so it's time to send data over 5G in addition. It should also expose data about packet retransmissions at the physical…

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

Re: Protocol Wars

#89

Earlier quoted context omitted.

So.... which will come first, "the year of IPv6" or "the year of linux desktop"? :)

I know you are joking but I don't get the longevity of this joke. I've been running Debian with XFCE for more than 12 years, on PCs custom-built and branded, and on laptops both of enterprise quality and retail junk. Heck, our entire B2B commerce business runs the same setup, with far fewer (read: zero) issues compared to when we were using Windows 98, 98SE, XP SP3, 7, Vista, and 10, at which point we declined Micros…

This. I guess one of the main obstacles for the general Linux adoption is the lack of hardware with it preinstalled in the ordinary stores.

Re: Protocol Wars

#90
post #74
post #53

Earlier quoted context omitted.

> that's never going to be a seamless transition. Why not? It is not obvious to me why a seamless transition is impossible? Isn't the whole point of TCP that individual packets can take different paths over different networks and when they reach the destination they can be sequenced? Why should changing the network disrupt the individual packets from traveling independently?

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.
Post reply on HN