5.4. Timers

There are three timers associated with this protocol. Their purpose will now be briefly discussed as will the actions taken when a timer expires. The particular nature these timeouts take and the methods by which they are set is the responsibility of the protocol implementation.

5.4.1. User Timeout

For practical implementation reasons it is desirable to have a user controllable timeout associated with the successful opening of a connection, successful acknowledgment of data, and successful closing of a connection. Consider the situations in which a connection is so noisy that no data gets through, or a connection is physically cut. Without an overriding timeout these situations would result in unbounded retransmissions.

When this timeout expires the user is informed "Error: Connection aborted due to user timeout.", all queues are flushed, the TCB is deleted, and the CLOSED state is entered.

5.4.2. Retransmission Timeout

This timer ensures that any packet sent for which the SN is significant is acknowledged. When such a packet is sent it is placed in a retransmission queue and the retransmission timer is begun. If an acknowledgment has not arrived within the timer's period then the packet is retransmitted and the timer is restarted. If the acknowledgment does arrive in time then the timer is stopped and the packet is removed from the retransmission queue. The next packet with a significant SN may now be sent.

This timeout is expected to operate in conjunction with a counter which keeps track of the number of times a packet has been retransmitted. Normally an upper limit is set on retransmissions. If that limit is exceeded then the connection is aborted. This event is similar to the user timeout. The user is informed "Error: Connection aborted due to retransmission failure", all queues are flushed, the TCB is deleted, and the CLOSED state is entered.

5.4.3. TIME-WAIT Timeout

This timeout is used to catch any FIN packets which might be retransmitted from the other end of a connection in response to a dropped acknowledgment packet. The timeout period should be at least as long as 2*SRTT. After this timeout expires the other end of the connection is assumed to be closed, the TCB is deleted, and this end enters the CLOSED state also.

6. Data Error Handling

This chapter discusses in detail the types of data errors an established connection may encounter. These are distinct from protocol errors discussed above. In order of discussion these are:

- Framing Errors

- Missing SYNCH pattern

- Unacknowledged packets

- Bad packets

- Duplicate packets

- Outside flow control

- Packets that are too large

- Packets that are too small

6.1. Framing Errors

The RS-232 specification provides framing only for an individual octet. Link level protocols for computer networking normally provide framing for each packet. The SYNCH pattern provides a boundary for the beginning of a packet. No similar pattern was chosen to mark the end and completely frame the packet.

Any bit pattern can appear in the data portion of a packet. For any particular pattern to reliably mark the end of a packet that terminating pattern cannot be allowed to appear in the data. This is usually accomplished by the sender altering any occurrence of the terminating pattern in the data so that it is both no longer recognizable as that pattern and also restorable upon receipt. Both the sender and the receiver are required by this technique to examine all the data. In the absence of a protocol chip to perform this function, it is a source of some overhead.

6.1.1. Synthetic Framing

In the absence of framing, the end of the packet must be synthetically determined. The start of a packet is indicated by the SYNCH pattern. The expected end of a packet can now only be determined by examining the LENGTH octet of the header. It is important to know whether or not the LENGTH data can be trusted. This is accomplished by employing a one octet header checksum to cover the first two octets following the SYNCH pattern. If the header passes the checksum test and neither the SYN, FIN, RST, nor SO flag bits were set then LENGTH is trusted and the number of octets expected beyond the header is LENGTH+2. (For those packets in which any of the above flag bits are set the packet length is fixed and includes only a header portion.)

If the header fails the checksum test we are in some difficulty. The length is incorrect so it may be too small or too large. To recover from this error do the following. Beginning immediately after the SYNCH pattern rescan looking for the next SYNCH pattern. Throw away all octets until a SYNCH is seen and then attempt to reinterpret it as a packet. The sender's retransmission timeout guarantees that a new copy of the packet will be transmitted. This ensures that in discarding the initial SYNCH pattern, the SYNCH pattern from the beginning of the retransmitted packet will eventually be seen.

6.1.2. Costs of Synthetic Framing

This framing strategy causes no overhead unless data errors occur in the packet. This is presumed to be a low probability occurrence. In addition it removes the overhead of both sender and receiver passing over the data to process any termination pattern which might appear in the data.

The worst case behavior would require a packet header to fail its checksum, a new SYNCH pattern to appear in the next few octets, that header failing its checksum, etc., until the SYNCH pattern of the retransmitted packet were finally seen. Consistently bad behavior of this type indicates an extremely noisy communications link.

6.2. Missing SYNCH Pattern

Any valid packet must begin with the SYNCH pattern. Any receiver must discard all input octets until the SYNCH pattern is seen. The data which immediately follows a SYNCH pattern is interpreted as a packet. The header checksum test is applied, then LENGTH+2 octets are read, the data checksum test is applied, etc.