written 8.1 years ago by |
TCP uses multiple timers (at least conceptually) to do its work. The most important of these is the RTO (Retransmission TimeOut). When a segment is sent, a retransmission timer is started. If the segment is acknowledged before the timer expires, the timer is stopped. If, on the other hand, the timer goes off before the acknowledgement comes in, the segment is retransmitted (and the timer OS started again). It is difficult to predict how long should the timeout be.
This problem is much more difficult in the transport layer than in data link protocols such as 802.11. In the latter case, the expected delay is measured in microseconds and is highly predictable (i.e., has a low variance), so the timer can be set to go off just slightly after the acknowledgement is expected, as shown in Fig below. Since acknowledgements are rarely delayed in the data link layer (due to lack of congestion), the absence of an acknowledgement at the expected time generally means either the frame or the acknowledgement has been lost.
![enter image description here](https://i.imgur.com/uvcKY2s.png)
TCP is faced with a radically different environment. The probability density function for the time it takes for a TCP acknowledgement to come back looks more like Fig. (b) than Fig. (a) as shown above. It is larger and more variable. Determining the round-trip time to the destination is tricky. Even when it is known, deciding on the timeout interval is also difficult. If the timeout is set too short, say, T1 in Fig. (b), unnecessary retransmissions will occur, clogging the Internet with useless packets. If it is set too long (e.g., T2), performance will suffer due to the long retransmission delay whenever a packet is lost. Furthermore, the mean and variance of the acknowledgement arrival distribution can change rapidly within a few seconds as congestion builds up or is resolved.
The solution is to use a dynamic algorithm that constantly adapts the timeout interval, based on continuous measurements of network performance. The algorithm generally used by TCP is due to Jacobson (1988) and works as follows. For each connection, TCP maintains a variable, SRTT (Smoothed Round-Trip Time) that is the best current estimate of the round-trip time to the destination in question.
When a segment is sent, a timer is started, both to see how long the acknowledgement takes and also to trigger a retransmission if it takes too long. If the acknowledgement gets back before the timer expires, TCP measures how long the acknowledgement took, say, R. It then updates SRTT according to the formula.
$$SRTT=αSRTT+(1-α)R$$
where α is a smoothing factor that determines how quickly the old values are forgotten. Typically, α = 7/8. This kind of formula is an EWMA (Exponentially Weighted Moving Average) or low-pass filter that discards noise in the samples.
Transactional TCP:
- One of the ways to implement a client server system is to use the remote procedure call (RPC). We could also use UDP if both the request and reply are small enough to fit into single packets. But if these conditions are not satisfied, then UDP is no more an attractive option. The use of conventional TCP also does not prove to be a practical option due to its low efficiency.
- The disadvantage of using RPC is that even under the best working conditions we need nine packets. This number will increase in the worse cases.
- In order to overcome these problems, an experimental TCP variant was developed known as transactional TCP or T/TCP
- T/TCP is very efficient and has only two messages. T/TCP is described in RFCs 1379 and 1644. The T/TCP protocol is illustrated below:
- The first packet from the client consists of a SYN bit, the request and FIN(finished). This means that the client says I want to establish a connection, here is the data and I have finished.
- On receiving the request, the server prepares the reply and chooses how to respond to the clients request. If the reply fits in one packet then its reply is as shown in fig above which says “I acknowledge your FIN, this is my reply and I have finished”.
- The client then acknowledges server’s FIN and terminates the conversation. If reply is longer than 1 packet then the server can send more than one packet before sending the FIN bit.
- T/TCP has a major disadvantage of security problems due to which it has not gained a widespread popularity.
![enter image description here](https://i.imgur.com/pl82Cya.png)