@Em0nM4stodon As a user from well back in the day, pre-1990...this space reminds me a great deal of the original EFNet/NSFNet/ARPANet I used to inhabit when I was in college, prior to The September That Never Ended (if anyone picks up on that reference).
The users came from a mostly academic or research-forward corporate background; the powers that be in the corporate world mostly had no conception of what the Internet was, and once they discovered it, still didn't have a real idea how it worked, as it was antithetical to the ethos of capitalism. Thus, the user base exhibited traits associated with enthusiastic engineers and academics: braininess, neophilia, curiosity, imagination. Being geeky and different was celebrated and encouraged. The same mentality you might find at an SF convention, art gallery, museum, or junior/local theater project. Communities were intentional, and there was a sense of reciprocal rights and recognition...a celebration of our global diversity.
Of course, flamewars there were...but overall, there was a nurturing of positive growth within the space.
Ancient history, of course. I am wondering if there is a self-regulation that's involved. When I describe the Fediverse to others, even friends whom I consider intelligent, there seems to be a lack of exact comprehension about what it is I'm talking about. (And among my age cohort, there's also a fatigue with social media in general, which I think is partly a function of age, and partly an accrual of bad experiences on Facebook and other corporatized media.)
When I started my phpBB forum as a general online space, I found the "culture" of such forums to be *radically* different. I described it as the "what's your favorite donut" mentality - everything was facile and superficial, like the scene in the kitchen at an awkward party. It just never took off and I don't have any idea why. (Several people close to me have encouraged me not to delete the forums; if you wish to go there, see my profile and pinned post for the address and registration code.)
#Fediverse #EFNet #ARPANet #NSFNet #phpBB #Forum #SFCon #diversity
#NSFNET
El 31 de octubre de 1985 se crea y pone en funcionamiento la NSFnet (National Science Foundation Network), que vendría siendo a la postre el backbone de la actual internet. En 1991 se vuelve comercial e inicia la revolución de la red conocida como Internet
#retrocomputingmx #nsfnet #internet
The question posed was:
This had to be addressed, with so many people piling on and choosing that the OSI model was replaced by TCP/IP because it worked better and increased in popularity
Nothing could be further from the truth.
tallship wrote the following post Sat, 13 Apr 2024 17:34:29 +0000
Okay I thought I'd share this recent post here on the #Fediverse. To give it some context, it's an answer to a common question, often a misunderstanding (even by many knowledgeable folks) as to just how we got here.
So first, the question, posed HERE.
And my answer follows below:
There's a lot of apples and oranges here. And everyone had a lot of good points made, but your question is simple, and has a very simple answer. I'll endeavor to address that directly, but do need to tend to some of what has already been said.
## Scroll down to the tl;dr for the succinct answer of your question
Ethernet, ARCNET, Token Ring, Thick net (RG-59), Thin net (RG-58 A/U), and UTP (Cat 3, Cat 5, and Cat 6 unshielded twisted pair, Etc.) really have zero bearing on your question insofar as IP is concerned. All of these specifications relate to the definition of technologies that, although are indeed addressed in the OSI model which is indeed very much in use to this day,but are outside the scope of Internet Protocol. I'll come back to this in a minute.
It's quite common to say TCP/IP, but really, it's just IP. For example, we have TCP ports and we have UDP ports in firewalling. i.e., TCP is Transmission Control Protocol and handles the delivery of data in the form of packets. IP handles the routing itself so those messages can arrive to and from the end points. Uniform Data Protocol is another delivery system that does not guarantee arrival but operates on a best effort basis, while TCP is much chattier as it guarantees delivery and retransmission of missed packets - UDP is pretty efficient but in the case of say, a phone call, a packet here and there won't be missed by the human ear.
That's a very simplistic high level-view that will only stand up to the most basic of scrutiny, but this isn't a class on internetworking ;) If you just want to be able to understand conceptually, my definition will suffice.
Networking (LAN) topologies like Token Ring, ARCNET, and Ethernet aren't anywhere in the IP stack, but figure prominently in the OSI stack. I'm not going to go into the details of how these work, or the physical connection methods used like Vampire Taps, Thin net, or twisted pair with RJ-45 terminators, but their relationship will become obvious in a moment.
The OSI model unfolds like so, remember this little mnemonic to keep it straight so you always know:
> People Don't Need To See Paula Abdul
Okay, touched on already, but not really treated, is the description of that little memory aid.
> Physical, Data Link, Network, Transport, Session, Presentation, and Application layers (From bottom to top).
The physical and Data Link layers cover things like the cabling methods described above,and you're probably familiar with MAC Addresses (medium access control) on NICs (network interface controller). These correlate to the first two layers of the OSI stack, namely, the Physical (obvious - you can touch it), and the Data Link layer - how each host's NIC and switches on each LAN segment talk to each other and decide which packets are designated for whom (People Don't).
In software engineering, we're concerned mostly with the Session, Presentation, and Application layers (See Paula Abdul). Detailed explanation of these top three layers is outside the scope of this discussion.
The Beauty of the OSI model is that each layer on one host (or program) talks to exclusively with the same layer of the program or hardware on the other host it is communicating with - or so it believes it is, because, as should be obvious, is has to pass its information down the stack to the next layer below itself, and then when it arrives at the other host, it passes that information back up the stack until it reaches the very top (Abdul) of the stack - the application.
Not all communication involves all of the stacks. At the LAN (Local Area Network) level, we're mostly concerned with the Physical and Data Link layers - we're just trying to get some packet that we aren't concerned about the contents of from one box to another. But that packet probably includes information that goes all the way up the stack.
For instance, NIC #1 has the MAC: 00:b0:d0:63:c2:26 and NIC #2 has a MAC of 00:00:5e:c0:53:af. There's communication between these two NICs over the Ethernet on this LAN segment. One says I have a packet for 00:00:5e:c0:53:af and then two answers and says, "Hey that's me!" Nobody else has that address on the LAN, so they don't answer and stop listening for the payload.
Now for Internet Protocol (IP) and TCP/UDP (Transmission Control Protocol and User Datagram Protocol):
IP corresponds to Layer 3 (Need) - the Network Layer of the **OSI Model.
TCP and UDP correspond to Layer 4 (To) - the Transport Layer of the OSI model.
That covers the entire OSI model and how TCP/IP correspond to it - almost. You're not getting off that easy today.
There's actually a bit of conflation and overlapping there. Just like in real life, it's never that cut and dried. For that, we have the following excellent explanation and drill down thanks to Julia Evans:
- Layer 2 (Don't) corresponds to Ethernet.
- Layer 3 (Need) corresponds to IP.
- Layer 4 (To) corresponds to TCP or UDP (or ICMP etc)
- Layer 7 (Abdul) corresponds to whatever is inside the TCP or UDP packet (for example a DNS query)
You may wish to give her page a gander for just a bit more of a deeper dive.
Now let's talk about what might be a bit of a misconception on the part of some, or at least, a bit of a foggy conflation between that of the specification of the OSI model and a Company called Bolt Beranek & Newman (BBN) a government contractor tasked with developing the IP stack networking code.
The TCP/IP you know and depend upon today wasn't written by them, and to suggest that it was the OSI model that was scrapped instead of BBN's product is a bit of a misunderstanding. As you can see from above, the OSI model is very much alive and well, and factors into your everyday life, encompasses software development and communications, device manufacturing and engineering, as well as routing and delivery of information.
This next part is rather opinionated, and the way that many of us choose to remember our history of UNIX, the ARPANET, the NSFnet, and the Internet:
The IP stack you know and use everyday was fathered by Bill Joy, who arrived at UC Berkeley in (IIRC) 1974), created vi because ed just wasn't cutting it when he wanted a full screen editor to write Berkeley UNIX (BSD), including TCP/IP, and co-founded Sun Microsystems (SunOS / Solaris):
> Bill Joy just didn’t feel like this (the BBN code) was as efficient as he could do if he did it himself. And so Joy just rewrote it. Here the stuff was delivered to him, he said, “That’s a bunch of junk,” and he redid it. There was no debate at all. He just unilaterally redid it.
Because UNIX was hitherto an AT&T product, and because government contracting has always been rife with interminable vacillating and pontificating, BBN never actually managed to produce code for the the IP stack that could really be relied upon. In short, it kinda sucked. Bad.
I highly recommend that you take a look at this excellent resource explaining the OSI model.
# tl;dr:
So! You've decided to scroll down and skip all of the other stuff to get the straight dope on the answer to your question. Here it is:
> What were the major things that caused TCP/IP to become the internet standard protocol?
The ARPANET (and where I worked, what was to become specifically the MILNET portion of that) had a mandate to replace NCP (Network Control Protocol) with IP (Internet Protocol). We did a dry run and literally over two thirds of the Internet (ARPANET) at that time disappeared, because people are lazy, software has bugs, you name it. There were lots of reasons. But that only lasted the better part of a day for the most part.
At that time the ARPANET really only consisted of Universities, big Defense contractors and U.S. Military facilities. Now, if you'll do a bit of digging around, you'll discover that there was really no such thing as NCP - that is, for the most part, what the film industry refers to as a retcon, meaning that we, as an industry, retroactively went back and came up with a way to explain away replacing a protocol that didn't really exist - a backstory, if you will. Sure, there was NCP, it was mostly a kludge of heterogeneous management and communications programs that varied from system to system, site to site, with several commonalities and inconsistencies that were hobbled together with bailing twine, coat hangers, and duct tape (for lack of a better metaphor).
So we really, really, needed something as uniform and ubiquitous as the promise that Internet Protocol would deliver. Because Bill Joy and others had done so much work at UC Berkeley, we actually had 4.1BSD (4.1a) to work with on our DEC machinery. As a junior member of my division, in both age and experience, I was given the task of, let's say throwing the switch on some of our machines, so to speak, when we cut over from the NCP spaghetti and henceforth embraced TCP/IP no matter what, on Flag Day - 01 January 1983.
So you see,the adoption of Internet Protocol was not a de facto occurrence - it was de jure, a government mandate to occur at a specific time on a specific day.
It literally had nothing to do with popularity or some kind of organic adoption, the erroneously described, so-called demise of the OSI model, or any physical network topology.
### DARPA said 01 January 1983 and that's it, and that was it - Flag Day.
Sure, it took a few days for several facilities to come up (anyone not running IP was summarily and unceremoniously cut off from the ARPANET).
And one also needs to consider that it wasn't every machine - we only had some machines that were Internet hosts. We still had a lot of mainframes and mini computers, etc., that were interconnected within our facilities in a hodgepodge or some other fashion. Nowadays we have a tendency to be somewhat incredulous if every device doesn't directly connect over IP to the Internet in some way. That wasn't the case back then - you passed traffic internally, sometimes by unmounting tapes from one machine and mounting them on another.
There was a lot of hand wringing, stress, boatloads of frustration, and concern by people over keeping their jobs all over the world. But that's why and when it happened. Six months later in the UNIX portions of networks we had much greater stability with the release of 4.2BSD, but it wouldn't really be until a few years later Net2 was released that things settled down with the virtually flawless networking stability that we enjoy today.
Enjoy!
#tallship #DARPA #IP #Internet_Protocol #Computer_History #internetworking #Internet #ARPANET #MILNET #NSFnet #Bill_Joy #BBN #UNIX #BSD
⛵
.
What were the major things that caused TCP/IP to become the internet standard protocol?
This had to be addressed, with so many people piling on and choosing that the OSI model was replaced by TCP/IP because it worked better and increased in popularity
Nothing could be further from the truth.
tallship wrote the following post Sat, 13 Apr 2024 17:34:29 +0000
Okay I thought I'd share this recent post here on the #Fediverse. To give it some context, it's an answer to a common question, often a misunderstanding (even by many knowledgeable folks) as to just how we got here.
So first, the question, posed HERE.
And my answer follows below:
There's a lot of apples and oranges here. And everyone had a lot of good points made, but your question is simple, and has a very simple answer. I'll endeavor to address that directly, but do need to tend to some of what has already been said.
## Scroll down to the tl;dr for the succinct answer of your question
Ethernet, ARCNET, Token Ring, Thick net (RG-59), Thin net (RG-58 A/U), and UTP (Cat 3, Cat 5, and Cat 6 unshielded twisted pair, Etc.) really have zero bearing on your question insofar as IP is concerned. All of these specifications relate to the definition of technologies that, although are indeed addressed in the OSI model which is indeed very much in use to this day,but are outside the scope of Internet Protocol. I'll come back to this in a minute.
It's quite common to say TCP/IP, but really, it's just IP. For example, we have TCP ports and we have UDP ports in firewalling. i.e., TCP is Transmission Control Protocol and handles the delivery of data in the form of packets. IP handles the routing itself so those messages can arrive to and from the end points. Uniform Data Protocol is another delivery system that does not guarantee arrival but operates on a best effort basis, while TCP is much chattier as it guarantees delivery and retransmission of missed packets - UDP is pretty efficient but in the case of say, a phone call, a packet here and there won't be missed by the human ear.
That's a very simplistic high level-view that will only stand up to the most basic of scrutiny, but this isn't a class on internetworking ;) If you just want to be able to understand conceptually, my definition will suffice.
Networking (LAN) topologies like Token Ring, ARCNET, and Ethernet aren't anywhere in the IP stack, but figure prominently in the OSI stack. I'm not going to go into the details of how these work, or the physical connection methods used like Vampire Taps, Thin net, or twisted pair with RJ-45 terminators, but their relationship will become obvious in a moment.
The OSI model unfolds like so, remember this little mnemonic to keep it straight so you always know:
> People Don't Need To See Paula Abdul
Okay, touched on already, but not really treated, is the description of that little memory aid.
> Physical, Data Link, Network, Transport, Session, Presentation, and Application layers (From bottom to top).
The physical and Data Link layers cover things like the cabling methods described above,and you're probably familiar with MAC Addresses (medium access control) on NICs (network interface controller). These correlate to the first two layers of the OSI stack, namely, the Physical (obvious - you can touch it), and the Data Link layer - how each host's NIC and switches on each LAN segment talk to each other and decide which packets are designated for whom (People Don't).
In software engineering, we're concerned mostly with the Session, Presentation, and Application layers (See Paula Abdul). Detailed explanation of these top three layers is outside the scope of this discussion.
The Beauty of the OSI model is that each layer on one host (or program) talks to exclusively with the same layer of the program or hardware on the other host it is communicating with - or so it believes it is, because, as should be obvious, is has to pass its information down the stack to the next layer below itself, and then when it arrives at the other host, it passes that information back up the stack until it reaches the very top (Abdul) of the stack - the application.
Not all communication involves all of the stacks. At the LAN (Local Area Network) level, we're mostly concerned with the Physical and Data Link layers - we're just trying to get some packet that we aren't concerned about the contents of from one box to another. But that packet probably includes information that goes all the way up the stack.
For instance, NIC #1 has the MAC: 00:b0:d0:63:c2:26 and NIC #2 has a MAC of 00:00:5e:c0:53:af. There's communication between these two NICs over the Ethernet on this LAN segment. One says I have a packet for 00:00:5e:c0:53:af and then two answers and says, "Hey that's me!" Nobody else has that address on the LAN, so they don't answer and stop listening for the payload.
Now for Internet Protocol (IP) and TCP/UDP (Transmission Control Protocol and User Datagram Protocol):
IP corresponds to Layer 3 (Need) - the Network Layer of the **OSI Model.
TCP and UDP correspond to Layer 4 (To) - the Transport Layer of the OSI model.
That covers the entire OSI model and how TCP/IP correspond to it - almost. You're not getting off that easy today.
There's actually a bit of conflation and overlapping there. Just like in real life, it's never that cut and dried. For that, we have the following excellent explanation and drill down thanks to Julia Evans:
- Layer 2 (Don't) corresponds to Ethernet.
- Layer 3 (Need) corresponds to IP.
- Layer 4 (To) corresponds to TCP or UDP (or ICMP etc)
- Layer 7 (Abdul) corresponds to whatever is inside the TCP or UDP packet (for example a DNS query)
You may wish to give her page a gander for just a bit more of a deeper dive.
Now let's talk about what might be a bit of a misconception on the part of some, or at least, a bit of a foggy conflation between that of the specification of the OSI model and a Company called Bolt Beranek & Newman (BBN) a government contractor tasked with developing the IP stack networking code.
The TCP/IP you know and depend upon today wasn't written by them, and to suggest that it was the OSI model that was scrapped instead of BBN's product is a bit of a misunderstanding. As you can see from above, the OSI model is very much alive and well, and factors into your everyday life, encompasses software development and communications, device manufacturing and engineering, as well as routing and delivery of information.
This next part is rather opinionated, and the way that many of us choose to remember our history of UNIX, the ARPANET, the NSFnet, and the Internet:
The IP stack you know and use everyday was fathered by Bill Joy, who arrived at UC Berkeley in (IIRC) 1974), created vi because ed just wasn't cutting it when he wanted a full screen editor to write Berkeley UNIX (BSD), including TCP/IP, and co-founded Sun Microsystems (SunOS / Solaris):
> Bill Joy just didn’t feel like this (the BBN code) was as efficient as he could do if he did it himself. And so Joy just rewrote it. Here the stuff was delivered to him, he said, “That’s a bunch of junk,” and he redid it. There was no debate at all. He just unilaterally redid it.
Because UNIX was hitherto an AT&T product, and because government contracting has always been rife with interminable vacillating and pontificating, BBN never actually managed to produce code for the the IP stack that could really be relied upon. In short, it kinda sucked. Bad.
I highly recommend that you take a look at this excellent resource explaining the OSI model.
# tl;dr:
So! You've decided to scroll down and skip all of the other stuff to get the straight dope on the answer to your question. Here it is:
> What were the major things that caused TCP/IP to become the internet standard protocol?
The ARPANET (and where I worked, what was to become specifically the MILNET portion of that) had a mandate to replace NCP (Network Control Protocol) with IP (Internet Protocol). We did a dry run and literally over two thirds of the Internet (ARPANET) at that time disappeared, because people are lazy, software has bugs, you name it. There were lots of reasons. But that only lasted the better part of a day for the most part.
At that time the ARPANET really only consisted of Universities, big Defense contractors and U.S. Military facilities. Now, if you'll do a bit of digging around, you'll discover that there was really no such thing as NCP - that is, for the most part, what the film industry refers to as a retcon, meaning that we, as an industry, retroactively went back and came up with a way to explain away replacing a protocol that didn't really exist - a backstory, if you will. Sure, there was NCP, it was mostly a kludge of heterogeneous management and communications programs that varied from system to system, site to site, with several commonalities and inconsistencies that were hobbled together with bailing twine, coat hangers, and duct tape (for lack of a better metaphor).
So we really, really, needed something as uniform and ubiquitous as the promise that Internet Protocol would deliver. Because Bill Joy and others had done so much work at UC Berkeley, we actually had 4.1BSD (4.1a) to work with on our DEC machinery. As a junior member of my division, in both age and experience, I was given the task of, let's say throwing the switch on some of our machines, so to speak, when we cut over from the NCP spaghetti and henceforth embraced TCP/IP no matter what, on Flag Day - 01 January 1983.
So you see,the adoption of Internet Protocol was not a de facto occurrence - it was de jure, a government mandate to occur at a specific time on a specific day.
It literally had nothing to do with popularity or some kind of organic adoption, the erroneously described, so-called demise of the OSI model, or any physical network topology.
### DARPA said 01 January 1983 and that's it, and that was it - Flag Day.
Sure, it took a few days for several facilities to come up (anyone not running IP was summarily and unceremoniously cut off from the ARPANET).
And one also needs to consider that it wasn't every machine - we only had some machines that were Internet hosts. We still had a lot of mainframes and mini computers, etc., that were interconnected within our facilities in a hodgepodge or some other fashion. Nowadays we have a tendency to be somewhat incredulous if every device doesn't directly connect over IP to the Internet in some way. That wasn't the case back then - you passed traffic internally, sometimes by unmounting tapes from one machine and mounting them on another.
There was a lot of hand wringing, stress, boatloads of frustration, and concern by people over keeping their jobs all over the world. But that's why and when it happened. Six months later in the UNIX portions of networks we had much greater stability with the release of 4.2BSD, but it wouldn't really be until a few years later Net2 was released that things settled down with the virtually flawless networking stability that we enjoy today.
Enjoy!
#tallship #DARPA #IP #Internet_Protocol #Computer_History #internetworking #Internet #ARPANET #MILNET #NSFnet #Bill_Joy #BBN #UNIX #BSD
⛵
.
Okay I thought I'd share this recent post here on the #Fediverse. To give it some context, it's an answer to a common question, often a misunderstanding (even by many knowledgeable folks) as to just how we got here.
So first, the question, posed HERE.
And my answer follows below:
There's a lot of apples and oranges here. And everyone had a lot of good points made, but your question is simple, and has a very simple answer. I'll endeavor to address that directly, but do need to tend to some of what has already been said.
## Scroll down to the tl;dr for the succinct answer of your question
Ethernet, ARCNET, Token Ring, Thick net (RG-59), Thin net (RG-58 A/U), and UTP (Cat 3, Cat 5, and Cat 6 unshielded twisted pair, Etc.) really have zero bearing on your question insofar as IP is concerned. All of these specifications relate to the definition of technologies that, although are indeed addressed in the OSI model which is indeed very much in use to this day,but are outside the scope of Internet Protocol. I'll come back to this in a minute.
It's quite common to say TCP/IP, but really, it's just IP. For example, we have TCP ports and we have UDP ports in firewalling. i.e., TCP is Transmission Control Protocol and handles the delivery of data in the form of packets. IP handles the routing itself so those messages can arrive to and from the end points. User Datagram Protocol is another delivery system that does not guarantee arrival but operates on a best effort basis, while TCP is much chattier as it guarantees delivery and retransmission of missed packets - UDP is pretty efficient but in the case of say, a phone call, a packet here and there won't be missed by the human ear.
That's a very simplistic high level-view that will only stand up to the most basic of scrutiny, but this isn't a class on internetworking ;) If you just want to be able to understand conceptually, my definition will suffice.
Networking (LAN) topologies like Token Ring, ARCNET, and Ethernet aren't anywhere in the IP stack, but figure prominently in the OSI stack. I'm not going to go into the details of how these work, or the physical connection methods used like Vampire Taps, Thin net, or twisted pair with RJ-45 terminators, but their relationship will become obvious in a moment.
The OSI model unfolds like so, remember this little mnemonic to keep it straight so you always know:
> People Don't Need To See Paula Abdul
Okay, touched on already, but not really treated, is the description of that little memory aid.
> Physical, Data Link, Network, Transport, Session, Presentation, and Application layers (From bottom to top).
The physical and Data Link layers cover things like the cabling methods described above,and you're probably familiar with MAC Addresses (medium access control) on NICs (network interface controller). These correlate to the first two layers of the OSI stack, namely, the Physical (obvious - you can touch it), and the Data Link layer - how each host's NIC and switches on each LAN segment talk to each other and decide which packets are designated for whom (People Don't).
In software engineering, we're concerned mostly with the Session, Presentation, and Application layers (See Paula Abdul). Detailed explanation of these top three layers is outside the scope of this discussion.
The Beauty of the OSI model is that each layer on one host (or program) talks to exclusively with the same layer of the program or hardware on the other host it is communicating with - or so it believes it is, because, as should be obvious, is has to pass its information down the stack to the next layer below itself, and then when it arrives at the other host, it passes that information back up the stack until it reaches the very top (Abdul) of the stack - the application.
Not all communication involves all of the stacks. At the LAN (Local Area Network) level, we're mostly concerned with the Physical and Data Link layers - we're just trying to get some packet that we aren't concerned about the contents of from one box to another. But that packet probably includes information that goes all the way up the stack.
For instance, NIC #1 has the MAC: 00:b0:d0:63:c2:26 and NIC #2 has a MAC of 00:00:5e:c0:53:af. There's communication between these two NICs over the Ethernet on this LAN segment. One says I have a packet for 00:00:5e:c0:53:af and then two answers and says, "Hey that's me!" Nobody else has that address on the LAN, so they don't answer and stop listening for the payload.
Now for Internet Protocol (IP) and TCP/UDP (Transmission Control Protocol and User Datagram Protocol):
IP corresponds to Layer 3 (Need) - the Network Layer of the **OSI Model.
TCP and UDP correspond to Layer 4 (To) - the Transport Layer of the OSI model.
That covers the entire OSI model and how TCP/IP correspond to it - almost. You're not getting off that easy today.
There's actually a bit of conflation and overlapping there. Just like in real life, it's never that cut and dried. For that, we have the following excellent explanation and drill down thanks to Julia Evans:
- Layer 2 (Don't) corresponds to Ethernet.
- Layer 3 (Need) corresponds to IP.
- Layer 4 (To) corresponds to TCP or UDP (or ICMP etc)
- Layer 7 (Abdul) corresponds to whatever is inside the TCP or UDP packet (for example a DNS query)
You may wish to give her page a gander for just a bit more of a deeper dive.
Now let's talk about what might be a bit of a misconception on the part of some, or at least, a bit of a foggy conflation between that of the specification of the OSI model and a Company called Bolt Beranek & Newman (BBN) a government contractor tasked with developing the IP stack networking code.
The TCP/IP you know and depend upon today wasn't written by them, and to suggest that it was the OSI model that was scrapped instead of BBN's product is a bit of a misunderstanding. As you can see from above, the OSI model is very much alive and well, and factors into your everyday life, encompasses software development and communications, device manufacturing and engineering, as well as routing and delivery of information.
This next part is rather opinionated, and the way that many of us choose to remember our history of UNIX, the ARPANET, the NSFnet, and the Internet:
The IP stack you know and use everyday was fathered by Bill Joy, who arrived at UC Berkeley in (IIRC) 1974), created vi because ed just wasn't cutting it when he wanted a full screen editor to write Berkeley UNIX (BSD), including TCP/IP, and co-founded Sun Microsystems (SunOS / Solaris):
> Bill Joy just didn’t feel like this (the BBN code) was as efficient as he could do if he did it himself. And so Joy just rewrote it. Here the stuff was delivered to him, he said, “That’s a bunch of junk,” and he redid it. There was no debate at all. He just unilaterally redid it.
Because UNIX was hitherto an AT&T product, and because government contracting has always been rife with interminable vacillating and pontificating, BBN never actually managed to produce code for the the IP stack that could really be relied upon. In short, it kinda sucked. Bad.
I highly recommend that you take a look at this excellent resource explaining the OSI model.
# tl;dr:
So! You've decided to scroll down and skip all of the other stuff to get the straight dope on the answer to your question. Here it is:
> What were the major things that caused TCP/IP to become the internet standard protocol?
The ARPANET (and where I worked, what was to become specifically the MILNET portion of that) had a mandate to replace NCP (Network Control Protocol) with IP (Internet Protocol). We did a dry run and literally over two thirds of the Internet (ARPANET) at that time disappeared, because people are lazy, software has bugs, you name it. There were lots of reasons. But that only lasted the better part of a day for the most part.
At that time the ARPANET really only consisted of Universities, big Defense contractors and U.S. Military facilities. Now, if you'll do a bit of digging around, you'll discover that there was really no such thing as NCP - that is, for the most part, what the film industry refers to as a retcon, meaning that we, as an industry, retroactively went back and came up with a way to explain away replacing a protocol that didn't really exist - a backstory, if you will. Sure, there was NCP, it was mostly a kludge of heterogeneous management and communications programs that varied from system to system, site to site, with several commonalities and inconsistencies that were hobbled together with bailing twine, coat hangers, and duct tape (for lack of a better metaphor).
So we really, really, needed something as uniform and ubiquitous as the promise that Internet Protocol would deliver. Because Bill Joy and others had done so much work at UC Berkeley, we actually had 4.1BSD (4.1a) to work with on our DEC machinery. As a junior member of my division, in both age and experience, I was given the task of, let's say throwing the switch on some of our machines, so to speak, when we cut over from the NCP spaghetti and henceforth embraced TCP/IP no matter what, on Flag Day - 01 January 1983.
So you see,the adoption of Internet Protocol was not a de facto occurrence - it was de jure, a government mandate to occur at a specific time on a specific day.
It literally had nothing to do with popularity or some kind of organic adoption, the erroneously described, so-called demise of the OSI model, or any physical network topology.
### DARPA said 01 January 1983 and that's it, and that was it - Flag Day.
Sure, it took a few days for several facilities to come up (anyone not running IP was summarily and unceremoniously cut off from the ARPANET).
And one also needs to consider that it wasn't every machine - we only had some machines that were Internet hosts. We still had a lot of mainframes and mini computers, etc., that were interconnected within our facilities in a hodgepodge or some other fashion. Nowadays we have a tendency to be somewhat incredulous if every device doesn't directly connect over IP to the Internet in some way. That wasn't the case back then - you passed traffic internally, sometimes by unmounting tapes from one machine and mounting them on another.
There was a lot of hand wringing, stress, boatloads of frustration, and concern by people over keeping their jobs all over the world. But that's why and when it happened. Six months later in the UNIX portions of networks we had much greater stability with the release of 4.2BSD, but it wouldn't really be until a few years later Net2 was released that things settled down with the virtually flawless networking stability that we enjoy today.
Enjoy!
#tallship #DARPA #IP #Internet_Protocol #Computer_History #internetworking #Internet #ARPANET #MILNET #NSFnet #Bill_Joy #BBN #UNIX #BSD
⛵
.
Fuckers.
I will always be BT74, going back all the way to NIC.DDN.MIL aka, yet another nom de plume of SRI, or, as was affectionately referred to as, "The NIC".
Back in the mid-80's after we introduced DNS in 1985 (and even before), you could actually call up Jake Feinler directly over the phone for time sensitive issues of a priority nature. She was always able to get things resolved in a matter of hours - sometimes I'd get a call back in a few minutes from an engineer at SRI to confirm that all was well.
according to the man pages, you should still be able to a #WHOIS searches #NIC handles for "NET-...", POCs like my handle above (um... sort of, I'll get to that), etc.
So I should note, that the NIC Handle I've listed above hasn't actually been searchable for quite some time now (at least ten years). but you should still be able to grep for it (coz I've made certain to still listed that way in my registry records). A simple, elegant system that lends well it's usage to humans, is now being cast aside for something less readable and in many ways, relevant, when you're quickly trying to pull a piece of primary data to reach someone responsible for a contact point (PoC), with respect to themselves, their property, or a "Role Account" that is responsible for a resource and shared by perhaps, several individuals.
So, the various contacts in the WHOIS records are variously, Registrant, Admin, Tech, and Billing contacts. In reality (and I've not seen a change in the RFCs on this point, but I don't follow that closely nowadays), the TECH CONTACT is defined as the person or role account responsible for the direct administration of DNS - not neccessarily the same as any other contact role account. ADMIN is important too, but not really as important as the TECH contact. In theory and still many times in practice, a remote sysadmin somewhere needs to get ahold of the DNS administrator to report abuse or some other issue, so a WHOIS is performed and voila! - you have a contact point to help fix a technical situation.
REGISTRANT is the owner of the domain registration, and as such, might legitimately have a reason to pay a privacy bureau to act as a proxy for contacting (to block stalkers, spammers, whatev), and the BILLING contact really has little technical relevance, but unlike the REGISTRANT, is the actual person or role account to interact with when it comes to domain renewals, etc.
So the ADMIN and at the very least, TECH contacts must (or should) be live phone and/or Fax numbers and email addresses that are searchable and reachable by anyone. In reality, however, after #NSI started to become less of a NIC, and shed themselves of the internic.net moniker as they commercialized under pressure from the nascent ICANN in order to have their contract renewed, anyone who registered a domain ended up having the fields to all of the contacts being filled out with the same data as that of the* registration owner/admin*, instead of what it should have been for at least the TECH and ADMIN contacts - you can override these defaults, but most will never bother, and have no idea why there are all these various roles in the records. (/me sighs....).
Okay, so after Jon Postel's untimely passing, the miscreants pretending to be legitimate enough to bootstrap ICANN quickly came to the realization that there's really no such thing as IANA - it was just a pseudonym for Jon, who literally ran pretty much everything we hold sacred today - like, being the RFC editor, and being IANA, managing the AUTH delegations of the #ccTLDs and even the DNS root servers (litterally moved one unilaterally once). So IANA was created by these miscreant folks, like Esther Dyson and Mike Roberts - pretenders provocateur. But I digress.
So now we've got these RIRs (which is a good thing, some better than others, but still). RIPE still uses NIC-HANDLEs, and so does #ARIN.
And as I promised, my NIC-HANDLE, once and always BT74, evolved into BT74-ARIN once that RIR was created. More explanations are in the alt-text accessibility tags for the two attached images.
So I won't go on further with this historical perspective that just sort of quietly was usurped by commercial pressures in the special interest lobby sector, #ICANN, and #WIPO, but anyone who's really interested can check out and read my friend Ellen Rony's book about the #Domain_Wars.
But just for shits and giggles, I've included a couple of screenies attached to this post:
- my current, automatically evolved NIC-HANDLE following the formalization of ARIN, from the ARIN website, and...
- An explanation of the usage of NIC-Handle's from the current man pages of WHOIS.
I hope that helps!
All the best!
#tallship #UNIX #DNS #FOSS #systems_administration #Stanford_Research_Institute #ARPANET #MILNET #NSFNET
⛵
.
@petersuber I vividly remember the early days of the web when it was unclear whether it would matter to average people compared to walled-garden services like #AOL (then #AmericaOnline), #Prodigy, or #CompuServe.
IMHO the web’s early rise depended on two other factors:
• Graphical #browsers like #NCSA #Mosaic on mainstream computer operating systems (1993)
• Decommissioning of the US government-funded #NSFNET backbone, effectively ending restrictions on commercial Internet traffic (1995)
@YusufToropov I think it would be interesting for certain #BigTech companies to try federating, whether via #Mastodon or some other solution. Obviously, the radical #FediAdmins would resist. But I don’t think it’s a zero-sum game any more than it was when the walled-garden services started integrating SMTP for #email, or when the #NSFnet backbone was decommissioned in 1995 and commercial traffic could finally be carried widely without running afoul of their anti-commercial Acceptable Use Policy.
A Day in the Life of the 1989 NSFNET NOC
https://toobnix.org/videos/watch/8a4ec6c4-d0ec-454a-90c9-e8a148840baf
#12Streams 2021 6 – @Internet2 ‘#InternetHistory Webinar: How the US NSFNET Regional Academic Networks Evolved to Become the Global Internet (1985 — 1995)’ #i2online @Internet2 @gricart #SURAnet @EliseGerich #NSFNET Susan Estrada #CERFnet Steve Wolff
On Friday December 31 2021, in the sixth instalment of the Internet Society Livestreaming‘s ‘12 Days of Streams‘ annual highlights, we feature Internet 2's 'Int
WEBCAST TODAY: @Internet2 ‘#InternetHistory Webinar: How the US NSNET Regional Academic Networks Evolved to Become the Global Internet (1985 — 1995)’ #i2online @Internet2 @gricart #SURAnet @EliseGerich #NSFNET Susan Estrada #CERFnet Steve Wolff
Today, Tuesday 14 September 2020, at 13:00 EDT (18:00 UTC) Internet2 hosts an Internet History Webinar: 'How the US NSNET Regional Academic Networks Evolved to Become t
#12Streams 2020 3 – Celebrating #NSFnet, both coming and going! w/ @vgcerf @algore Dennis Jennings @NSF Howard Pfeffer @SullivanISOC @margmartonosi <a href="https://twitter.com/hashtag/internetindependence?f=realtime&src=hash">#internetindependence</a> #iid25 @Edyson @james_a_lewis @rehundt @GaryShapiro @tevslin Andrew Odlyzko
Today, Monday December 28 2020, at 7:00pm EST (00:00 UTC) in the third installment of the
WEBCAST TODAY – #NSFNET 35th Anniversary Celebratory Event @Internet2 @internetsociety @vgcerf @algore Dennis Jennings @NSF Howard Pfeffer @SullivanISOC @margmartonosi
Today, Tuesday 8 December 2020, at 1pm-2:45pm EST (18:00-19:45 UTC) the Internet Society and Internet2 present a NSFNET 35th Anniversary Celebratory Virtual Event. From 1985-1995 the National Science Foundation Network (NSFNET) was a pivotal United Stat
WEBCAST THURS: #InternetIndependenceDay marking 25th anniversary of NSFNET decommissioning w/ @Edyson @james_a_lewis @rehundt @GaryShapiro @tevslin Andrew Odlyzko
On April 30 2020, at 5pm EDT (21:00 UTC) Internet elders will gather to mark the 25th anniversary of the 1995 decommissioning of the NSFNET backbone, following the passage of Al Gore's High Performance Computing Act of 1991. This was the moment that the Intern
Client Info
Server: https://mastodon.social
Version: 2025.04
Repository: https://github.com/cyevgeniy/lmst