Fiber optics have enabled the transmission of long strings of data in a serial fashion from a driver to a receiver over long distances (typically measured in kilometers) at very high data rates (typically specified in billions of bits per second). This is in contrast to more traditional communication over electrical wires which only allow data to be transmitted for relatively short distances at these high data rates. The distances for communication over wire means is typically in the range of several tens of meters.
Fiber optic data transmission is however inherently noisy in that bit errors in the data are frequent. Error rates of one in a trillion or even one in a billion bits are common. Various checking methods including cyclic redundancy codes are used to detect these errors.
Several methods have been suggested for recovering data that has been transmitted but received with error indications. One method is to employ a high level protocol that keeps track of the time from request to response. Each time a request is sent from one side of the fiber optic link to the other, the sender starts a timer. If a response is not received within a specified time, the sender "assumes" that either the request or the response was lost. The sender then requests status from the other end of the link to determine if the request should be resent.
Another method of recovering data received in error is to package the data into frames and to assign a sequence number to each frame. If a receiver detects a frame with a sequence number that is out of order, it assumes that one or more frames were lost. Using the sequence number of the last correctly received frame, the receiver then requests the lost frames to be retransmitted. This method allows multiple requests and responses to be on the link at the same time, thus improving the utilization.
Still another method of determining the frame in error is to use separate checking fields for the header and the information field. Thus if the information field is in error, the chances are that the header identifying the frame is still error free. Using the frame header information, the detecting end of the link can request the frame to be retransmitted.
With both of the methods described above, it is still possible that a frame is lost and that a request never completes. Sequence numbers require subsequent frames for the detection of the frame in error, and using separate checking fields for the frame header does not guarantee that the frame header itself is not in error. Because of these shortcomings, it is usual practice to time outstanding requests to detect missing responses. These timers detect both the damaged frames and unusually long response times in the system. The values used for these timers are rather large so that normal delays in processing a request do not cause the timers to expire too often. On the other hand, long timers may further delay subsequent recovery actions when the frame cannot be resent.
Thus what is needed is a mechanism by which the delays in the higher level recovery procedures due to long timeouts are avoided when the frame cannot be resent. This is accomplished by using a much shorter timer that spans only the low level recovery action.