First off, the IMP to host interface was a parallel hardware interface. Each type of computer attached to an IMP had to have a custom-designed interface unit that connected to the computer's own I/O system. The effect was that the IMP appeared to each host computer as a reliable I/O device. Here's the description of the interface unit for the DEC PDP-11.[1]
There were several models of IMPs. There was even a distributed, redundant IMP, called PLURIBUS. That was a strange machine built out of 16 Lockheed SUE minicomputers, with partially shared memory. BBN put that together. That was the beginning of network switches bigger than one CPU, but that idea was not used again until the era of big Internet routers about 15 years later.
Links between IMPs had both reliability and flow control. No packet was sent until a receiving buffer was available. So no packets were dropped due to congestion. Not at the link level, and not at the end to end level.
Congestion problems manifested themselves as the network stalling. This was a problem in the early days, but was gradually fixed. There was a fragmentation and reassembly system, which could result in overcommitting buffers. Once someone locked up the entire ARPANET in reassembly lockup by sending a pattern of messages that caused buffer fragmentation.
The obsession with buffer space came from the high cost of memory at the time. It was generally thought that congestion management was about not running out of buffer space. Now we know better. See "bufferbloat".
The IMP to IMP system was trusted within itself. So protocol bugs in the IMP to IMP protocol could cause multiple connections or multiple IMPs to fail.
One of the reasons that IP is unreliable is because that prevents trouble on one stream from messing up other streams.
In exchange for less reliability per stream, you get better reliability for the whole system.
The physical layer as described in report 1822 is bit-serial, but uses synchronous clocking scheme without fixed baud-rate reminiscent of parallel SCSI's REQ/ACK. It is a weird scheme for serial links, but it has the clear advantage that it adapts to cable length automatically (but runs at significantly smaller bitrate that could be supported by the cable, which probably was not exactly an issue in 70's).
In fact the whole report 1822 deals mostly in bits (the messages on the IMP-host interface can have arbitrary bit lengths). Obviously this was done in order to support architectures with weird word sizes (eg. 36bit PDP-10).
Bit-serial but multi-conductor cable. The 6 pairs, ground and if I count correctly two single-ended status lines make more sense than 30-pair Cisco serial cables or 34-pair HSSI of the 90's…
First off, the IMP to host interface was a parallel hardware interface. Each type of computer attached to an IMP had to have a custom-designed interface unit that connected to the computer's own I/O system. The effect was that the IMP appeared to each host computer as a reliable I/O device. Here's the description of the interface unit for the DEC PDP-11.[1]
There were several models of IMPs. There was even a distributed, redundant IMP, called PLURIBUS. That was a strange machine built out of 16 Lockheed SUE minicomputers, with partially shared memory. BBN put that together. That was the beginning of network switches bigger than one CPU, but that idea was not used again until the era of big Internet routers about 15 years later.
Links between IMPs had both reliability and flow control. No packet was sent until a receiving buffer was available. So no packets were dropped due to congestion. Not at the link level, and not at the end to end level.
Congestion problems manifested themselves as the network stalling. This was a problem in the early days, but was gradually fixed. There was a fragmentation and reassembly system, which could result in overcommitting buffers. Once someone locked up the entire ARPANET in reassembly lockup by sending a pattern of messages that caused buffer fragmentation.
The obsession with buffer space came from the high cost of memory at the time. It was generally thought that congestion management was about not running out of buffer space. Now we know better. See "bufferbloat".
The IMP to IMP system was trusted within itself. So protocol bugs in the IMP to IMP protocol could cause multiple connections or multiple IMPs to fail.
One of the reasons that IP is unreliable is because that prevents trouble on one stream from messing up other streams. In exchange for less reliability per stream, you get better reliability for the whole system.
[1] http://www.bitsavers.org/pdf/dec/unibus/IMP11-B_Arpanet_Inte...