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.
Protocol Wars
81–90 of 121 posts
Re: Protocol Wars
#82In 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.
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
#83Earlier 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
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
#84Re: Protocol Wars
#85Re: Protocol Wars
#86Earlier 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 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
#87In 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.
Re: Protocol Wars
#88Earlier 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…
Re: Protocol Wars
#89Earlier 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…
Re: Protocol Wars
#90Earlier 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.