TCP Implementation Policy Options
The TCP standard provides a precise specification of the protocol to be used between TCP entities. However, certain aspects of the protocol admit several possible implementation options. Although two implementations that choose alternative options will be interoperable, there may be performance implications. The design areas for which options are specified are the following:
Send policy Deliver policy Accept policy Retransmit policy Acknowledge policy. Send policy
In the absence of pushed data and a closed transmission window, a sending TCP entity is free to transmit data at its own convenience. As data are issued by the user, they are buffered in the transmit buffer. TCP may construct a segment for each batch of data provided by its user or it may wait until a certain amount of data accumulates before constructing and sending a segment. The actual policy will depend on performance considerations. If transmissions are infrequent and large, there is low overhead in terms of segment generation and processing. On the other hand, if transmissions are frequent and small, then the system provides quick response.
Deliver policy
In the absence of a PUSH, a receiving TCP entity is free to deliver data to the user at its own convenience. It may deliver data as such in order segment is received or it may buffer data from a number of segments in receive buffer before delivery. The actual policy will depend on performance consideration. If deliveries are infrequent and large, the user may not receive data as promptly as desired. On the other hand, if deliveries are frequent and small, there may be unnecessary processing both in TCP and in the user software, as well as an unnecessary number of operating system interrupts.
Accept policy
When all data segments arrive in order over a TCP connection, TCP places the data in a receive buffer for delivery to the user. It is possible, however, for segments to arrive out of order. In such a case, the receiving TCP entity has two options:
(i) In-order: Accept only segments that arrive in order; any segment that arrives out of order is discarded.
(2) In-window: Accept all segments that are within the receive window.
The in-order policy makes for a simple implementation; but places a burden on the networking facility as the sending TCP must time out and retransmit segments that were successfully received, but discarded because of misordering. Furthermore, if
a single segment is lost in transit, then all subsequent segments must be transmitted once the sending TCP times out on the last segment.
Retransmit policy
TCP maintains a queue of segments that have been sent, but not yet acknowledged. The TCP specification states that TCP will retransmit a segment if it fails to receive an acknowledgement within a given time. A TCP implementation may employ one of the three retransmission strategies:
(1) First-only: Maintain one retransmission timer for the entire queue. If an acknowledgement is received, remove the approximate segment or segments from the queue and reset the timer. If the timer expires, retransmit the segment at the front of the queue and reset the timer.
(2) Batch: Maintain one retransmission timer for the entire queue. If an acknowledgement is received, remove the approximate segment or segments from the queue and reset the timer. If the timer expires, retransmit all segments in the queue and reset the timer.
(3) Individual: Maintain one timer for each segment in the queue. If an acknowledgement is received, remove the approximate segment or segments from the queue and destroy the corresponding timer and timers. If any timer expires, retransmit the corresponding segment individually and reset its timer.
The first-only policy is efficient in terms of traffic generated, because only lost segments (or segments whose ACK was lost) are retransmitted. However, because the timer for the second segment in the queue is not set until the first segment is acknowledged, there can be considerable delays. The individual policy solves this problem at the expense of a more complex implementation. The policy also reduces the likelihood of long delays, but may result in unnecessary retransmissions.
The actual effectiveness of the retransmit policy depends in part on the accept policy of the receiver. If the receiver is using an in-order accept policy then it will discard segments received after a lost segment. This fits best with batch retransmission. If the receiver is using an in-window accept policy, then a first-only or individual retransmission policy is best. Of course, in a mixed network of computers, both accept policies may be in use.
Acknowledge policy
When a data segment arrives that is in sequence, the receiving TCP entity has two options concerning the timing of acknowledgement:
(1) Immediate: When data are accepted, immediately transmit an empty (no data) segment containing the approximate acknowledgement number.
(2) Cumulative:    When data are accepted, record the need for acknowledgement but wait for an outbound segment with data on which to piggyback the acknowledgement. To avoid long delay, set a window timer; if the timer expires before an acknowledgement is sent, transmit an empty segment containing the appropriate acknowledgement number.
The immediate policy is simple and keeps the sending TCP entity fully informed, which limits unnecessary retransmissions. However, this policy results in extra segment transmissions (namely, empty segments used only to ACK). Furthermore, the policy can increase the load on the network. Consider that a TCP entity receives a segment and immediately sends an ACK. Then the data in the segment are released to the application, which expands the receive window, triggering another empty TCP segment to provide additional credit to the sending TCP entity.
Because of the potential overhead of the immediate policy, the cumulative policy is typically used. Recognize, however, that the use of this policy requires more processing at the receiving end and complicates the task of estimating round-trip delay by the sending TCP entity.

How Does TCP Achieve Reliability?
How does TCP achieve reliability? The answer is complex because TCP uses a variety of techniques to handle parts of the problem. One of the most important techniques is retransmission. When TCP sends data, the sender compensates for packet loss by implementing a retransmission scheme. Both sides of a communication participate. When TCP receives data, it sends an acknowledgement back to the sender. Whenever it sends data, TCP starts a timer. If the timer expires before an acknowledgement arrives, the sender retransmits the data. Figure illustrates retransmission.

items on the left correspond to events in a computer sending data, items on the right correspond to events in a computer receiving data, and time goes down the figure. The sender retransmits lost data.
TCP's retransmission scheme is the key to its success; it handles communication across an arbitrary Internet and allows multiple application programs to communicate concurrently. For example, one application can send data across a satellite channel to a computer in another country, while another application sends data across a local arc network to a computer in the next room. TCP must be ready to retransmit any message that is lost on either connection. The question is: how long should TCP wait before retransmitting? Acknowledgements from a computer on a local area network are expected to arrive within a few milliseconds. Waiting too long for such an acknowledgement leaves the network idle and does not maximize throughput. Thus, on a local area network, TCP should not wait a long time before retransmitting. However, retransmitting after a few milliseconds does not work well on a long distance satellite connection because the unnecessary traffic consumes network bandwidth and lowers throughput.
TCP faces a more difficult challenge than distinguishing between local and remote destinations: bursts of datagram’s can cause congestion, and also transmission delays along a given path to change rapidly. In fact, the total time required to send a message and receive an acknowledgement can increase or decrease by an order of magnitude in a few milliseconds.

BACK