II. A Brief Survey of Some Asynchronous Link Protocols

II.1. DDCMP

DDCMP, Copyright (c) 1978 Digital Equipment Corporation [DDCMP 78], is a reliable point-to-point and multi-point transmission protocol is used by many of that manufacturer's computers. DDCMP does provide reliable asynchronous two way data transmission.

Some of the decisions taken in the design of DDCMP reflect its orientation toward multi-point data links. This leads to headers which are substantially longer than needed for two way point-to-point communications.

DDCMP allows as many as 255 outstanding unacknowledged messages. DDCMP does specifically mention that a particular end of a connection may choose to limit the send queue to one outstanding unacknowledged message. It also allows sending a stream of outstanding unacknowledged packets. Unless all RS-232 implementations of DDCMP were limited to a single outstanding packet, the collision with existing flow control restrictions could lead to very low thruput. (DDCMP is assumed to have control over the link driver. Dealing with various differing flow control mechanisms is not a consideration.)

DDCMP uses a CRC polynomial for data protection which is difficult to calculate for many machines without special hardware [TCP Checksum 78]. Many Digital Equipment computers have such hardware.

DDCMP does not provide the receiver with the ability to restrict incoming packet size. It is true that all the higher level protocols built on top of DDCMP could separately negotiate packet size. But this burden would then be moved away from the link level where it properly resides.

Generally, a full implementation of DDCMP is too complex for consideration. If one were to implement 'part' of the protocol then issues of compatibility with already existing implementations on other computers are raised.

II.2. MODEM Protocol

This is a protocol in common use amongst microcomputers. The description here comes from

MODEM/XMODEM Protocol Explained by Kelly Smith, CP/M-Net "SYSOP" January 8,1980

.... Data is sent in 128-byte sequentially numbered blocks, with a single checksum byte appended to the end of each block. As the receiving computer acquires the incoming data, it performs its own checksum and upon each completion of a block, it compares its checksum result with that of the sending computers. If the receiving computer matches the checksum of the sending computer, it transmits an ACK (ASCII code protocol character for ACKNOWLEDGE (06 Hex, Control-F)) back to the sending computer. The ACK therefore means "all's well on this end, send some more...".

The sending computer will transmit an "initial NAK" (ASCII protocol character for NEGATIVE ACKNOWLEDGE (15 Hex, Control-U))...or, "that wasn't quite right, please send again". Due to the asynchronous nature of the initial "hook-up" between the two computers, the receiving computer will "time-out" looking for data, and send the NAK as the "cue" for the sending computer to begin transmission. The sending computer knows that the receiving computer will "time-out", and uses this fact to "get in sync"... The sending computer responds to the "initial NAK" with a SOH (ASCII code protocol character for START OF HEADING (01 Hex, Control-A)), sends the first block number, sends the 1's complement of the block number, sends 128 bytes of 8 bit data, and finally a checksum, where the checksum is calculated by summing the SOH, the block number, the block number 1's complement, and the 128 bytes of data.

Receiving Computer:

---/NAK/------------------------/ACK/------------------ 15H 06H

Sending Computer:

---/SOH/BLK#/BLK#/DATA/CSUM/---/SOH/BLK#/BLK#/DATA/etc. 01H 01H FEH 8bit 8bit 01H 02H FDH 8bit ....

This process continues, with the next 128 bytes. If the block was ACK'ed by the receiving computer, and then the next sequential block number and its 1's complement, etc. ....

As can be seen from this partial description the MODEM protocol is unidirectional, data can only pass from the sender to the receiver in a stream. In order for data to flow simultaneously in the other direction another connection over another RS-232 line would be required.

In addition this protocol is restricted to a fixed 128 octet packet size. Many front-end concentrators are unable to service such large incoming packets. It has been observed many times that the concentrator of a busy DECsystem-20 can invoke flow control on input at 1200 baud for packets as small as 64 characters.

II.3. KERMIT System

The KERMIT system, Copyright (c) 1981 Columbia University, is a file transfer environment developed recently. It has implementations which run on DECsystem-20, IBM 370 VM/CMS, 8080 CP/M based systems, and the IBM PC among others.

KERMIT combines both the reliable transfer and file transfer into a single package. Extension to other applications and higher level protocols would be possible but the boundary between the reliable transfer and application layers is very indistinct. It violates the layering design strategy the Internet employs.

There is a limitation of transmission to the restricted printable ASCII set for certain computers but not for others. This leads to confusion. KERMIT allows both restricted ASCII and 8-bit transmission.

The KERMIT protocol does have a method of setting MDL at connection initiation. It is limited to a smaller maximum packet size, 96 as opposed to 261 octets. Kermit originally used a checksumming algorithm limited to six bits. This is considered to provide too low a level of error detection capability for data packets. Kermit now allows two other checksumming algorithms in addition to the original. There must be a negotiation between sender and receiver regarding which algorithm to use.

The KERMIT protocol does not appear to make provision for both sides of a connection attempting an active open simultaneously. One side must be an initial "sending Kermit" and the other a "receiving Kermit". The code published as a KERMIT implementation

guide cannot recover from simultaneous active opens, it immediately ABORTs. This reflects a bias towards unidirectional data flow.

The KERMIT packet type (similar to RATP control flags) specifies whether an ACK/NAK is contained in the packet, or data, etc. These are mutually exclusive and piggybacking an ACK on a data packet is not possible. This can be a source of overhead. In addition KERMIT restricts the sender to a single outstanding unacknowledged packet as does RATP. It allocates an entire byte to the sequence number which is unnecessary.

On the subject of error recovery, the size of a packet is contained in the second byte of the packet and is not protected by a header checksum. If the length field was in error due to noise on the link, it could be longer than the correct packet size. The code published as the KERMIT implementation guide relies upon the detection of the <SOH> character anywhere in a packet to indicate the beginning of a packet header. It re-SYNCHs using this technique. This is only possible if binary data in a packet is quoted. If full eight bit data is transmitted it does not appear that the KERMIT protocol rescans for a new MARK (SYNCH) character within the bad packet data just consumed. It will under these circumstances throw away the retransmitted packet or portions thereof. Re-SYNCHing under such conditions is problematical.

REFERENCES

[Cohen 81]

Cohen, D. On Holy Wars and a Plea for Peace. IEEE Computer, October, 1981.

[DDCMP 78]

DDCMP AA-D599A-TC edition, Digital Equipment Corporation, 1978. Version 4.0.

[IP 81]

Postel, J. DOD Standard Internet Protocol [RFC-791] Defense Advanced Research Projects Agency, 1981.

[TCP 81]

Postel, J. Transmission Control Protocol [RFC-793] Defense Advanced Research Projects Agency, 1981.

[TCP Checksum 78]

Plummer, W. W. TCP Checksum Function Design. Technical Report, Bolt Beranek and Newman, Inc., 1978.

EDITORS NOTES

This memo was prepared in essentially this form in June 1983, and set aside. Distribution at this time is prompted by the the "Thinwire" proposal described in RFC-914.