Mr. Jackson's letter is more than a little disturbing to me, and here's why.
"...the seven layer Open Systems Interconnection model--which defines how devices communicate..." I did not know that the OSI model defined how devices communicate. I thought the OSI model was a model laid on top of any given networking system (combination of hardware, software, protocols, and applications) to help people that are new to it better understand and implement it.
"..."You go to Wal-Mart and buy a telephone for less than $10 and you expect it to work," Gibson said. Yet people usually do not expect the same of their computers. "We don't expect computers to work, we expect them to have a problem."..." This one should speak for it's self. But I guess it does not for everyone. Most computer savvy people that I know *DO* expect their computers to work, all of them. IMHO it is only the masses that have not been told other wise and see shoddy hardware and OSs that have become accustom to the day to day failures. I personally have many systems that have been up and running under load with less than the best hardware and less than the best OS with an uptime that is measured in three digits. I would consider that to be exceptionally reliable for the equipment.
"If a commander expects a system to have a problem, then how could they rely upon it?" Someone had better tell the rest of the military that they are relying upon unreliable systems. What about all the old VAX systems that are controlling ICBMs? When was the last time that one of those failed to do what it was suppose to, be it sit in the silo and wait to launch or launch and hit it's target?
"Gibson cast some of the blame on the packet-based nature of Internet Protocol, which was not designed for foolproof delivery of messages. The protocol cannot guarantee delivery of e-mail, for instance." No IP was not meant to ensure reliability of end to end transmission of data, that is TCP's job. If you are trying to say that email does not make it from his out box to another's in box that is in the SMTP protocol on top of TCP which is on top of IP. Yes there is a LOT of room for improvement in SMTP as it stands today. In the mid to late '70s when the ARPANet was in it's infancy end to end node reliability was one of the highest priorities. The ARPANet was meant to be reliable even with as much as 2/3s of it's infrastructure missing or taken down. The internet, which has been derived from the ARPANet, is quite reliable save for congestion. But wait a minute, we have similar problems on the national power grid, are we going to replace it because of it's problems? Ok, so bandwidth is an issue? Well yes and no. If we are talking military then we can get the size pipes that we need and we will not be transferring mp3s and movies across it in a battle field. Even in a battle field we can use satellite for signal, or point to point wireless technologies that far surpass 802.11. But for the sake of argument let's say that we are stuck at a T-1 (1,572,864 bps raw through put / circa 1,376,256 bps through put via TCP/IP). If every system in the network that needed to communicate had a T-1 and restricted in and out bound traffic to a synchronous 688 kbps then any given system on the network would be able to talk to one other system on the network while still having bandwidth for one system to talk to it. 688 kbps is not bad if you are talking command and control types of interface. Things like terminals that are menu driven, even something along the lines of HTML based interfaces would be more than fast enough. Now say that we need to talk to more than 1 system and listen to 1 system at a time let's adjust the ratios a bit. Let's take it to the extreme and say that I'm going to talk to 1 system at a time with 56 kbps (Yes 56 k, v.90 modem speed.). 56 kbps is still quite sufficient to talk to a command and control system . The only problem with these speeds is that we need to make sure that they are
I call to mind the ARPANet and what it is today.
IMHO this is ludicrous, and here's why.
Mr. Jackson's letter is more than a little disturbing to me, and here's why.
"...the seven layer Open Systems Interconnection model--which defines how devices communicate..." I did not know that the OSI model defined how devices communicate. I thought the OSI model was a model laid on top of any given networking system (combination of hardware, software, protocols, and applications) to help people that are new to it better understand and implement it.
"..."You go to Wal-Mart and buy a telephone for less than $10 and you expect it to work," Gibson said. Yet people usually do not expect the same of their computers. "We don't expect computers to work, we expect them to have a problem."..." This one should speak for it's self. But I guess it does not for everyone. Most computer savvy people that I know *DO* expect their computers to work, all of them. IMHO it is only the masses that have not been told other wise and see shoddy hardware and OSs that have become accustom to the day to day failures. I personally have many systems that have been up and running under load with less than the best hardware and less than the best OS with an uptime that is measured in three digits. I would consider that to be exceptionally reliable for the equipment.
"If a commander expects a system to have a problem, then how could they rely upon it?" Someone had better tell the rest of the military that they are relying upon unreliable systems. What about all the old VAX systems that are controlling ICBMs? When was the last time that one of those failed to do what it was suppose to, be it sit in the silo and wait to launch or launch and hit it's target?
"Gibson cast some of the blame on the packet-based nature of Internet Protocol, which was not designed for foolproof delivery of messages. The protocol cannot guarantee delivery of e-mail, for instance." No IP was not meant to ensure reliability of end to end transmission of data, that is TCP's job. If you are trying to say that email does not make it from his out box to another's in box that is in the SMTP protocol on top of TCP which is on top of IP. Yes there is a LOT of room for improvement in SMTP as it stands today. In the mid to late '70s when the ARPANet was in it's infancy end to end node reliability was one of the highest priorities. The ARPANet was meant to be reliable even with as much as 2/3s of it's infrastructure missing or taken down. The internet, which has been derived from the ARPANet, is quite reliable save for congestion. But wait a minute, we have similar problems on the national power grid, are we going to replace it because of it's problems? Ok, so bandwidth is an issue? Well yes and no. If we are talking military then we can get the size pipes that we need and we will not be transferring mp3s and movies across it in a battle field. Even in a battle field we can use satellite for signal, or point to point wireless technologies that far surpass 802.11. But for the sake of argument let's say that we are stuck at a T-1 (1,572,864 bps raw through put / circa 1,376,256 bps through put via TCP/IP). If every system in the network that needed to communicate had a T-1 and restricted in and out bound traffic to a synchronous 688 kbps then any given system on the network would be able to talk to one other system on the network while still having bandwidth for one system to talk to it. 688 kbps is not bad if you are talking command and control types of interface. Things like terminals that are menu driven, even something along the lines of HTML based interfaces would be more than fast enough. Now say that we need to talk to more than 1 system and listen to 1 system at a time let's adjust the ratios a bit. Let's take it to the extreme and say that I'm going to talk to 1 system at a time with 56 kbps (Yes 56 k, v.90 modem speed.). 56 kbps is still quite sufficient to talk to a command and control system . The only problem with these speeds is that we need to make sure that they are