[ih] Early use of the "Internet" term (1977)

Sat Jun 15 12:59:59 PDT 2019

802.3 coax Ethernet has limits on the lengths of the cables, the delay through repeaters, and the number of repeaters that ensure overall network latency can’t exceed 232 bits. When collisions occur, colliding nodes switch from sending data to sending a jam signal that fills the slot - 512 bit times - and then do collision recovery. Late collisions (after the 232 bit time latency) can occur, but did so rarely. They’re treated as errors and left to higher level protocols to sort out. Collisions are detected by a voltage drop on the cable that everyone sees, but if somebody misses it they should see the jam signal. 

It’s a pretty reliable system, but collision-free full duplex is better. Full duplex switches permit multiple packets to traverse the switch at the same time as long as they have different destinations, and buffer those with the same destination that overlap. And switches allow operators to assign priorities so that more important bits have a fast lane, just as they did on the IBM Token Ring. 

> On Jun 14, 2019, at 10:15 PM, Gordon Peterson <gep2 at terabites.com> wrote:
> 
> 
> 
> On 6/14/2019 6:12 PM, Richard Bennett wrote:
>> In principle, Ethernet collisions only occurred at during the first few bytes of the frame - the collision window - so it didn’t take long to backoff and recover. But the advent of full duplex in 10BASE-T eliminated collisions. 
> It depends on how long the message is, and how it's routed.  The end of the message can be seen earlier in some places than in others, depending on propagation delays and different routings.  And some collisions may be seen by some network nodes, and not by others.
>> We put positive acknowledgment in Wi-Fi because we predicted one undetected collision per 100 frames or so, owing to the lack of a reliable collision indicator. That appears to have been the right choice. 
> In the case of ARCnet, any given cable is only driven from one end at any given time.  So you never get a "collision" of two data packets colliding on the same cable coming from different ends.
>> 
>>> On Jun 14, 2019, at 5:04 PM, Gordon Peterson <gep2 at terabites.com <mailto:gep2 at terabites.com>> wrote:
>>> 
>>> 
>>> 
>>> On 6/14/2019 4:53 PM, Richard Bennett wrote:
>>>> The fact that ARCnet was essentially a plug-and-play system for converting 3270 terminal clusters - wire and all - into PC clusters was a huge selling point for departmental computing in the mid ‘80s and beyond. With a Novell file & print server, 3270 emulation and file transfer on your PCs, a shared laser printer and a 3270 LAN gateway you were good to go.
>>> Sure!  And that you could just add a hub in your department, and the wire that used to carry the traffic from your (big/expensive) 3270 cluster controller to just ONE terminal could now support a BUNCH of departmental computers!  As many as you needed!  All able to talk together.
>>>> Classic Ethernet’s biggest flaw was its lack of the star topology used for office power, phones, and 3270s.
>>> Basically, ALL classical distribution systems use "interconnected stars" topologies.  Water, electricity, storm sewers, food and product distribution, (yes) telephones, just about everything.  And with linear-bus Ethernet, adding a new drop ANYWHERE on the bus disrupted messages and electrical signals for the ENTIRE bus, until everything re-stabilized.  A map tack or paperclip could short out the whole linear bus, and it could take a LONG time to figure out where the problem was, and get it going again.
>>>> Multi-port transceivers for Cheapernet remedied this, but they were very pricey before 10BASE-T.
>>>> 
>>>> Metcalfe & crew believed active hubs would be bottlenecks, but that idea never made much sense; the active hub just needs to be as fast as each individual node.
>>> It just needs to be as fast as the cable, the total bit rate at the active hub is the same.  And in ARCnet, any given cable is only carrying a single signal in one direction at any given time, and therefore you don't really have electrical signal collisions, and don't have any problems with reflections from taps or the ends of a cable.
>>> 
>>> More important, with ARCnet the originating RIM knows within about 5-10 microseconds of the end of a transmission whether the transmission was received (fully, correctly and completely) by the destination RIM... before the next packet is prepared and sent.  With Ethernet, you have to wait (maybe a LONG time) until higher-level protocols don't receive an expected result (if any).  Packet collisions (if any) can occur elsewhere in an Ethernet network, and may not be seen by the sender (since the collision elsewhere might occur after the sender has stopped sending).
>>> 
>>> ARCnet has the receiving node acknowledging (IMMEDIATELY) whether the received packet was received, fully buffered at the receiving end, with correct parity for each byte received, the correct CRC for the entire packet, and the correct number of bytes expected.  And the originating RIM gets this "positive ACK" before it sends another queued packet, or passes the "invitation to transmit" token on to the next node in the polling list.  So if your higher-level protocol is set so that ANY packet can be safely and simply re-transmitted (as The ARC System's protocols allowed) in case of ANY doubt, it makes it really easy to make a VERY robust and error-tolerant network architecture.
>>> 
>>>> RB 
>>>> 
>>>>> On Jun 14, 2019, at 2:30 PM, Gordon Peterson <gep2 at terabites.com <mailto:gep2 at terabites.com>> wrote:
>>>>> 
>>>>> 
>>>>> On 6/14/2019 3:02 PM, Clem Cole wrote:
>>>>>> 
>>>>>> 
>>>>>> On Fri, Jun 14, 2019 at 3:52 PM Richard Bennett <richard at bennett.com <mailto:richard at bennett.com>> wrote:
>>>>>> The PARC Ethernet that immediately preceded Blue Book was 2.94 Mbps, not 3. The difference is greater than the bandwidth of ARPANET at the time. I think an even earlier prototype was 1 Mbps.
>>>>>> Right... in both cases.   One of the guys (Roger Bates IIRC), even calculated the number of bit of storage in the PARC                                     network >>wires<< at one point.
>>>>> Bob Metcalfe's original "Ether"net was a wired version of the University of Hawaii's "Project Aloha", which was a radio-broadcast network...
>>>>>> 
>>>>>> These were both thin coax systems as thick net was a Blue Book designed-by-committee monstrosity with poor noise modeling.
>>>>>> Amen....
>>>>> Bob Metcalfe told me he was a big fan of the linear bus, even with the problems and vulnerabilities I pointed out (including ringing back from the taps, need to terminate ends, ability to take the whole bus down with a pin or paperclip, etc etc).  I told him that an "interconnected stars" topology was a lot better, but he persisted.... sigh...
>>>>> 
>>>>> I think it's worth noting that basically nobody still runs thick-wire linear bus Ethernet, and Ethernet didn't really get very successful until they finally adopted the ARCnet-style "interconnected stars" cabling topology based on hubs.
>>>>> 
>>>>>> A question for you: Was the ARCnet you are describing from Datapoint, the same technology as the 75 ohm coax ARCnet that was popular with Novell networks in the mid to late 1980s?   
>>>>> Actually it was 93 ohm, RG-62U, BNC connectors, but yes, their "RX-NET" was actually the exact same thing as Datapoint's ARCnet.  They (Datapoint ARC System and Novell RX-NET systems) coexisted nicely on the same ARCnet cable system, too.  ;-)  The wires and cabling and connectors were the same as IBM had used for their 2260 (and 3270 and following) terminals... so most big companies with such networks in place already were cabled for ARCnet.  ;-)   ARCnet is actually very tolerant, I'm told it will even run happily over coat-hanger wire.  ;-)
>>>>>> I remember it was originally less costly than the 'Blue Book' ethernet per port until NS and group came up with 'CheaperNet' (running it across 50 ohm wire thin wire and using BNC connectors). 
>>>>> The bigger advantages of ARCnet over Ethernet have to do with low-level protocols, fault tolerance, error recovery, electrical robustness, and a lot more.
>>>>>> 
>>>>>> 
>>>>>> RB
>>>>>> 
>>>>>>> On Jun 14, 2019, at 6:43 AM, Noel Chiappa <jnc at mercury.lcs.mit.edu <mailto:jnc at mercury.lcs.mit.edu>> wrote:
>>>>>>> 
>>>>>>>> From: Jorge Amodio
>>>>>>> 
>>>>>>>> Thank you so much for your detailed response
>>>>>>> 
>>>>>>> Indeed, it was a fantastic and fascinating glimpse into a too-little-known
>>>>>>> corner of computing history.
>>>>>>> 
>>>>>>> For those who would like to know more, in addition to online sources, I can
>>>>>>> recommend "Datapoint: The Lost Story of the Texans Who Invented the Personal
>>>>>>> Computer Revolution", by Lamont Wood. (I'm not sure if those who were there,
>>>>>>> like Mr. Peterson, would consider it accurate, but it seemed to be to be quite
>>>>>>> good.)
>>>>>>> 
>>>>>>> Typical nugget: the Intel 8008 was not a descendant of the Intel 4004
>>>>>>> (although the production chips did use technology developed for the 4004), as
>>>>>>> commonly thought at one point; rather, it was developed for Datapoint
>>>>>>> (although they wound up building their own CPU out of discrete components).
>>>>>>> The 8008 developed into the 8080, and then the 8086... and I expect many of us
>>>>>>> are reading this on its descendants.
>>>>>>> 
>>>>>>>> I'll follow up on a private message so I don't get the rest of the list
>>>>>>>> bored with details.
>>>>>>> 
>>>>>>> Bored? Never! :-)
>>>>>>> 
>>>>>>> 
>>>>>>>>> On Thu, Jun 13, 2019 at 6:18 PM Gordon Peterson <gep2 at terabites.com <mailto:gep2 at terabites.com>> wrote:
>>>>>>> 
>>>>>>>>> (...and, at the time, Ethernet.... which wasn't a released product yet...
>>>>>>>>> was running at just 2 megabits
>>>>>>> 
>>>>>>> Minor nit - 3.
>>>>>>> 
>>>>>>>>> "Oh, Gordon," my colleagues told me.  "It's a good system, but you're
>>>>>>>>> crazy... big businesses will never give up their mainframes and run their
>>>>>>>>> processing on networks of little computers."
>>>>>>>>> I grinned at them and replied, "You just WATCH!"   :-)
>>>>>>> 
>>>>>>> I suspect many people on this list have had similar experiences! (In my case,
>>>>>>> circa mid-80s, telling my now-wife that one day everyone would have
>>>>>>> email... :-)
>>>>>>> 
>>>>>>> It would be interesting to collect stories about when we got glimpses of the
>>>>>>> future. I am particularly thinking of Craig's story about Swedish train
>>>>>>> timetables; my equivalent was going home to Bermuda at one point and seeing
>>>>>>> URL's painted on commercial vehicles.
>>>>>>> 
>>>>>>>      Noel
>>>>>>> _______
>>>>>>> internet-history mailing list
>>>>>>> internet-history at postel.org <mailto:internet-history at postel.org>
>>>>>>> http://mailman.postel.org/mailman/listinfo/internet-history <http://mailman.postel.org/mailman/listinfo/internet-history>
>>>>>>> Contact list-owner at postel.org <mailto:list-owner at postel.org> for assistance.
>>>>>> 
>>>>>> —
>>>>>> Richard Bennett
>>>>>> High Tech Forum <http://hightechforum.org/> Founder
>>>>>> Ethernet & Wi-Fi standards co-creator
>>>>>> 
>>>>>> Internet Policy Consultant
>>>>>> 
>>>>>> _______
>>>>>> internet-history mailing list
>>>>>> internet-history at postel.org <mailto:internet-history at postel.org>
>>>>>> http://mailman.postel.org/mailman/listinfo/internet-history <http://mailman.postel.org/mailman/listinfo/internet-history>
>>>>>> Contact list-owner at postel.org <mailto:list-owner at postel.org> for assistance.
>>>>>> ᐧ
>>>>> 
>>>>>  <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=icon>	Virus-free. www.avast.com <https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient&utm_term=link>
>>>> —
>>>> Richard Bennett
>>>> High Tech Forum <http://hightechforum.org/> Founder
>>>> Ethernet & Wi-Fi standards co-creator
>>>> 
>>>> Internet Policy Consultant
>>>> 
>> 
>> —
>> Richard Bennett
>> High Tech Forum <http://hightechforum.org/> Founder
>> Ethernet & Wi-Fi standards co-creator
>> 
>> Internet Policy Consultant
>> 

—
Richard Bennett
High Tech Forum <http://hightechforum.org/> Founder
Ethernet & Wi-Fi standards co-creator

Internet Policy Consultant

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://elists.isoc.org/pipermail/internet-history/attachments/20190615/c8ca4f0e/attachment.htm>