Summary

  • RFC 935 challenged the case for newly proposed reliable protocols on low-speed asynchronous links. Robinson compared established character-oriented, bit-oriented and count-based approaches with RATP, then recommended character framing, a 16-bit CRC and LAPB control procedures for dial-up PC access.
  • His short-frame calculation began with 13 Thinwire bytes before link framing. Eight added link characters make 21 on the wire; RATP's six make 19. At about 120 transmitted characters a second, those ratios yield roughly 74 versus 82 Thinwire characters a second. Robinson argued that recovery, multiple outstanding frames and existing hardware made those two characters a poor reason to invent another link rule.

The little number with a large invoice

An engineer can make a new protocol look irresistible by choosing the right row in a table. RFC 935 printed such a table and refused to stop there. Robinson was responding to RFC 914's Thinwire discussion and RFC 916's Reliable Asynchronous Transfer Protocol, or RATP. Both faced a real constraint: a personal computer talking to a gateway over a slow asynchronous serial line. A character sent on that line consumed scarce time. The custom proposals were trying to spend less of it on protocol luggage.

Robinson accepted the arithmetic. Start with the minimum 13-byte Thinwire II frame before link framing. Robinson added eight link characters under his public-standard combination, 8/13 or 61 percent of the Thinwire frame; RATP added six, 6/13 or 46 percent. The line therefore sends 21 or 19 characters for each 13-character Thinwire frame. At roughly 120 transmitted characters per second, 120 × 13/21 gives about 74 Thinwire characters per second; 120 × 13/19 gives about 82. Only one of every 13 Thinwire characters is user data in this typing example, which Robinson gives as roughly 5.6 and 6.3 typed characters per second.

Those are calculations for a particular small-frame case. They are also a remarkably narrow prize for adding a separate protocol to every participating machine.

The contest was not between “reliable” and “unreliable”. It was between ways of finding a frame again after the line made a mess of one. Character-oriented framing used markers such as DLE STX and DLE ETX, with an escape rule for marker characters inside data. Bit-oriented procedures used a flag bit pattern and stuffing; ordinary use was synchronous. DDCMP used a count in its header, avoiding escaped delimiters but making a corrupted count a synchronization problem. Robinson pointed out that count-based protocols still needed a way to find the next header when the count was wrong. A low byte count in a clean frame is an incomplete measure of the cost of a dirty line.

The checksum was guarding the conversation

RFC 935's sharper objection concerned error checks. The new proposals used simple additive or XOR checks that software could calculate cheaply. Robinson wanted a 16-bit cyclic redundancy check at the link. TCP and IP already checked their own material, but an error in the link control field could lose or duplicate frames before higher layers repaired anything. He argued that a CRC combined with the different checks above it caught error patterns that two similar additive checks could miss. At 120 characters per second, he estimated software CRC work at roughly five to six instructions per character with a lookup table.

A gateway might also have a serial chip capable of doing that work.

His design borrowed rather than worshipped standards. He proposed transparent character framing with DLE STX … DLE ETX CRC CRC, and LAPB control procedures for sequencing and acknowledgments. Acknowledgments could ride on reverse traffic. Up to seven frames could be outstanding in each direction. An address field made little sense on a single point-to-point line, yet Robinson kept it because the existing standard and its hardware had it. The resulting overhead was eight characters per frame. He explicitly declined to shave a little more by dropping the address or adopting RATP's count framing: the modest saving would break common practice.

The chip argument was an economic argument inside an engineering memo. Manufacturers had reason to support widely used procedures, and such support could lower processing cost on the gateway and eventually the PC. A custom protocol had to earn its byte advantage again in code, debugging, interoperability and equipment supply. RFC 935 never measured the later market for these alternatives; it recorded Robinson's proposed bargain in January 1985.

His postscript made the period visible. Robinson noticed that his proposal resembled a circa-1976 Telenet access-link design, and predicted that X.25 or X.32 access would soon displace the dial-up arrangement under discussion. That forecast is his, not the article's conclusion. The durable question sits earlier in the document: when the savings are two characters per small frame, who pays to make the exception work whenever the line is noisy, the receiver loses its place or another device must speak the same dialect?

Sources