RFC 594

RFC 594: Speedup of Host-IMP Interface ✨

• Network Working Group 🌸
• Request for Comments: 594
• NIC: 20616
• Author: J. Burchfiel, BBN-TENEX
• Date: December 1973
• The header doesn't list any category, and it doesn't say this RFC obsoletes or updates anything. 🎀

I. Introduction 💖

okay so, to let the whole subnet show off its full performance for interprocess communication, the host's IMP interface and the IMP's host interface should run at the highest speed possible. 🚀

Reason one: lower latency. Right now a full-sized message ties up a 100 kb interface for almost 100 Msec. That means short stuff like RFNMs, control messages, and NVT (network virtual terminal) characters gets stuck behind it for 100 Msec. Speeding the host interface up to 300 kilobaud shrinks that wait to 30 Msec. literally so much better 😭

Reason two: buffers get freed up faster. While a message moves, the IMP buffer is being emptied and the host core buffer is being filled, and both stay locked down the whole time. Faster transfer means buffers get disposed of way quicker, so you need far fewer of them to carry the traffic, and each one gets reused way more often. ♻️

Reason three: better error control. Right now a destination IMP sends an RFNM after transmitting the first packet of a multipacket message to the destination host. If something goes wrong while the other packets (up to seven) are being pushed into the destination host, the source host never finds out, because it already got a positive acknowledgement in the RFNM. 💀 Waiting to send the RFNM until every packet has made it in would add another 80 Msec. to the round trip message-RFNM time on the current 100 kilobaud interface. A faster interface makes that delayed-RFNM cost much more reasonable, so it becomes practical to get rid of this source of undetected message transmission errors. 🙌

Reason four: more bandwidth. The current interface is limited to 100 kilobaud. A high-speed interface lets hosts talk with a lot more bandwidth, which is essential at a "network-structured" site, where different hosts on the same IMP specialize in different parts of a computation. 🧚

So ngl, any new or retrofitted host interface should be very high speed, and existing ones should be tuned to run at their maximum speed, which is over 300 kilobaud. 🔥

II. Experimental Results 🧪

To back all of this up, the BBN TENEX staff ran an experiment with the BBN IMP group to see how fast the distant interfaces of System A (BBN-TENEX) and System B (BBNB) could actually go. 👑

Here's what they found:

The Host-to-IMP connection is synchronized by a two-way handshake. Its available burst bandwidth is 1 bit/(2225 nsec + 3 nsec/ft.*<cable length>ft). For their cable length, that works out to 310 kilobaud. ✨

The IMP-to-Host connection is synchronized by a four-way handshake. Its available burst bandwidth is 1 bit/(1350 nsec + 6 nsec/ft.*<cable length>ft.), which gives 290 kilobaud for their setup. 🦋

Both System A and System B are now running at this higher interface speed. 💅

Since the propagation delay through a distant host driver-receiver pair is 250 nsec, local host interfaces (<30ft) are expected to be able to run substantially faster than 300 kilobaud. 🌈

They also measured file transfer performance, meaning the CPU time and real time used per megabit of information sent over the network. 📊

This experiment moved one-megabit data files to and from an FTP User process in System B, which was talking to the FTP Server Process in System A. Here are the results:

Operation  Byte Size    Type        Bandwidth       User CPU seconds/
                                                           megabit

Get           8         ASCII       47Kbaud              7.9
Send          8         ASCII       50Kbaud              7.9
Get           32        LocalByte   43Kbaud              1.80
Send          32        LocalByte   38Kbaud              1.70
Get           36        Image       79Kbaud              1.85
Send          36        Image       85Kbaud               .95

The 36-bit bandwidth of around 80Kbaud is a huge glow-up from the typical 25Kbaud they measured before the interface hardware speedup. 🚀 The CPU time use also dropped a bit compared to what RFC #557 by Barry Wessler reported, which shows that system efficiency kept improving between TENEX version 1.31 and TENEX version 1.32. 🎀

So, in conclusion, the BBN-TENEX staff recommends that every host-IMP interface in the network gets sped up to the fastest operation possible. 👑🫶

[This RFC was put into machine readable form for entry] [into the online RFC archives by Alan Whinery, 1/02]