Summary

  • RFC 914 calculated that a single Telnet character travelled inside a 41-byte TCP/IP packet. At 1200 baud, the authors estimated about 0.3 seconds per packet, or roughly 30 effective baud for one-character traffic under their stated assumptions.
  • Their three Thinwire proposals cut the example to 17 bytes, then 13 bytes, or moved network and transport work to a gateway. The last design promised roughly 900 effective baud in the RFC's estimate while making the gateway the PC's agent for Internet connections.

Imagine buying a bicycle because the railway fare is too high. Then discovering that every time you turn the pedals, you must tow forty filing cabinets. The bicycle is fine; the transaction is ridiculous. In September 1984, David Farber, Gary Delp and Thomas Conte gave that problem a packet diagram. A person typing one character into Telnet could produce a 41-byte TCP/IP packet. The character was one byte of the journey. The rest was the machinery that made the journey intelligible.

Their Thinwire RFC began with a price change. Computing power had entered the $3,000–$10,000 personal-computer range. A computer could now sit in an office, a home or another place far from a fast network attachment. A dedicated 56k line was expensive and slow to arrange; 1200- and 2400-baud telephone modems were available. Put the cheaper computer on the cheaper line, however, and protocol overhead suddenly became visible. At 1200 baud, the RFC calculated about 0.3 seconds to transmit the 41-byte single-character packet. That made the effective character rate about 30 baud. These were line-limited, synchronous-link estimates: interrupts, computation and framing could make the actual time 10–50% worse. A local echo could make some typing feel tolerable, but applications sending each character still had to pay the fare.

The authors proposed three responses. Thinwire I was the cautious one: keep the preceding packet at each end of the link and send instructions for changing it. Offset and count fields said where to substitute bytes. In the Telnet example, a typical update took 17 bytes instead of 41, which the RFC translated to about 70 effective baud. The trick was simple, and so was its weakness. If different kinds of packets shared one remembered template, each could spoil the resemblance that made the next update short. The paper had cut the luggage, but the luggage still needed sorting.

Thinwire II made the sorting explicit. Each TCP connection got a class and a stored template. A bitfield identified changed header fields, and small deltas replaced repeated full-width values. In the paper's example, 41 bytes became 13, equivalent to about 95 effective baud for single-character packets. The link gained room by asking both sides to remember more. The PC needed several templates; the gateway needed connection tables. If their memories diverged, traffic stopped until recovery. The authors called for a reliable serial link and periodic full packets to resynchronize it.

A new protocol that the compressor did not understand would travel in full. Compression had become a contract between two memories.

Thinwire III was the audacious sibling. Why make the personal computer carry the complete network and transport apparatus over the thin line at all? In that design, a central gateway ran the Internet-facing TCP and UDP connections. The PC and gateway exchanged data and control over one reliable, multiplexed serial stream. The RFC estimated average effective throughput in the 900-baud range. That was a very different order of improvement from shaving a few more header bytes. It was also a different shape of network. The gateway opened outward connections as the PC's agent.

The PC could arrange a passive opening at the gateway to provide a service, but an ordinary unsolicited inbound connection could not simply arrive at the PC as though it were a full Internet host.

There is the real choice behind the speed figures. Thinwire I spends fewer bytes and little state. Thinwire II buys a shorter packet with synchronized memory at both ends. Thinwire III buys a much thinner conversation by handing the gateway the job of being the Internet-facing party. The line gets lighter as the far end gets more important. If the gateway is unavailable, overloaded, or unwilling to provide a function, the personal computer's access to that function follows it. The paper did not report a deployed network's outage statistics; it set out the operating roles that would make such dependence possible.

The RFC Editor record places the memo in September 1984 and now labels it Historic. Its authors offered these methods for discussion, not as Internet standards. That makes the arithmetic more interesting, not less: it captures an engineering crossroads before hindsight made one lane look inevitable. A cheap computer and a cheap modem opened the door. The door had a 41-byte hinge. Farber, Delp and Conte asked whether to oil it, rebuild it, or hire a gateway to do the opening.