Achieving reliable communication
RFC - Unknown
(August 1971; No errata)
||RFC Editor Note
RFC 203 (Unknown)
||Send notices to
Network Working Group R. Kalin
Request for Comments: 203 MIT Lincoln Lab
NIC: 7168 10 August 1971
Achieving Reliable Communication
'This material has not been reviewed for public release and is
intended only for use with the ARPA network. It should not be quoted
or cited in any publication not related to the ARPA network.'
A non-standard protocol, suitable for either second or third level
use, is proposed with the intent of providing error resistant and
highly reliable communication channels. Errors introduced by message
garbling, message loss, and message pickup are considered. Measures
for increasing throughput are also discussed.
AIMS AND LIMITATIONS
It is not our intent to propose the design of a perfect communication
channel, rather it is our contention that in the real world there can
be no perfect channels and that no amount of protocol can insure the
error free transfer of information. Our goal is to explicate the
various types of errors that are possible and to provide for each
techniques of detection and recovery that, at a cost, can be made
arbitrarily good. In this way the mean time between undetected
errors can be made as large as necessary.
ERROR TYPES AND DETECTION
Over a message switching facility, such as the ARPA network, all
transmission errors can be divided into two classes -- those that
result in the loss of an expected message, and those that result in
the picking up of an unexpected message. A single bit inversion can
cause errors of both types. Error detection can therefore be divided
into two components -- one which attempts to determine if the message
just received is appropriate at that time, and another which attempts
to determine if a message has been lost.
The detection of garbled input messages has been adequately covered
by classical coding ( elsewhere, mistakenly termed 'communication' )
theory. Internal message consistency can be determined through the
use parity bits, checksum fields, or any of the various coding
techniques available for adding some measure of redundancy. With
relative simplicity, the likelyhood of an undetected error of this
type can be made small enough so as to become inconsequential.
Kalin [Page 1]
RFC 203 ACHIEVING RELIABLE COMMUNICATION 10 August 1971
Because it is adequately covered elsewhere, no further discussion
shall be given here.
The detection of a message's external consistency, whether or not it
can possibly follow the message that arrived just before it, can also
be straight forward. Sequence numbers, if used, can be easily
checked. A modulo N sequence field will allow detection of up to N-1
successive message losses. If several concurrent links are in use
then sequencing can be maintained for each link. Multi-link single
sequence schemes are more complicated and, although used between IMPs
for transmission of message packets, they shall be ignored here.
The detection by a receiving host of a lost message can not be
determined directly, but rather must be inferred from other
observations. Any automatic correction scheme must be prepared to
handle the possibility of faulty inference. Message loss would
normally be inferred upon the arrival of a message that should follow
the one expected. It might also be inferred by the fact that the
message expected is long overdue.
If a BCH or other error correcting code is used for transmission,
errors detected in a message's internal consistency can sometimes be
corrected by the receiving host. In the event that this is not
possible, the content of the message is of little use because it can
not be relied upon. The only reasonable solution is that of
discarding the message and relying upon the recovery procedures
implemented for lost messages.
Errors of external consistency can also be treated in the same way.
The message can be thrown away and the techniques for recovering lost
messages relied upon. Over a critical channel, a slightly fancier
technique can at times save some retransmissions. If message N is
expected, but message N+1 arrives, there is no need to throw away
message N+1 and then recover two messages, it could be saved, and
only message N retransmitted.
On noisy channels the technique of saving out of sequence messages
can be used to some advantage, especially if recovering from a lost
message requires several messages of overhead. On the ARPA network,
the measured error rate is so low that its advantages are outweighed
by the increase in resident coding.
RECOVERING LOST MESSAGES
The simplest technique I know of for recovering lost can be defined
Show full document text