Principles Digital Communication System & Computer Networks (Charles River Media Computer Engineering)

20.4 TRANSMISSION CONTROL PROTOCOL (TCP)

It is the job of transport layer protocol to ensure that the data is delivered to the application layer without any errors. The functions of the transport layer are:

• To check whether the packets are received in sequence or not. If they are not in sequence, they have to be arranged in sequence.

• To check whether each packet is received without errors using the checksum. If packets are received in error, TCP layer has to ask for retransmissions.

• To check whether all packets are received or whether some packets are lost. It may happen that one of the routers may drop a packet (discard it) because its buffer is full, or the router itself may go faulty. If packets are lost, the TCP layer has to inform the other end system to retransmit the packet. Dropping a packet is generally due to congestion on the network.

The TCP layer provides end-to-end reliable transfer of data by taking care of flow control and error control. If packets are received in error, retransmission is requested. If packets are received out of order, they are put in sequence. It appears to the application layer as though everything is fine, but the TCP layer needs to do a lot of work to achieve this.

Sometimes, one system may send the packets very fast, and the router or end system may not be able to receive the packets at that speed. Flow control is done by the transport layer.

It is the job of the transport layer to provide an end-to-end reliable transfer of data even if the underlying IP layer does not provide reliable service. The Transmission Control Protocol (TCP) does all these functions, through flow control and acknowledgements.

20.4.1 Flow Control and Acknowledgements

To provide a reliable transmission, the acknowledgement policy is used. The two protocols for this mechanism are the stop-and-wait protocol and the sliding window protocol. These protocols take care of lost packets, flow control, and error detection.

Stop-and-Wait Protocol

When the source (end system A) sends the first packet to the destination (end system B), B sends an acknowledgment packet. Then A sends the second packet, and B sends the acknowledgement. This is a very simple protocol. But the problem is that if the acknowledgement for a packet is lost, what has to be done? A sends the first packet and then starts a timer. The destination, after receiving the packet, sends an acknowledgement. If the acknowledgement is received before the timer expires, the source sends the next packet and resets the timer. If the packet sent by the source is lost, or if the acknowledgement sent by the destination is lost, the timer will expire, and the source resends the packet.

In stop-and-wait protocol, the source sends a packet and only after the acknowledgement is received from the destination is the next packet sent. This is a simple protocol, but it results in lots of delay, and the bandwidth is not used efficiently.

Figure 20.5: Stop-and-wait protocol.

This protocol is very simple to implement. However, the drawback is that the throughput will be very poor and the channel bandwidth is not used efficiently. For instance, if this protocol is used in a satellite network, A will send a packet, and after one second it will receive the acknowledgment. During that one second, the satellite channel is free, and the channel is not used effectively. A refinement to this protocol is the sliding window protocol.

Sliding Window Protocol

In this protocol, the source sends a certain number of packets without waiting for the acknowledgements. The destination receives the packets and sends an acknowledgement for each packet. The source will have a timer for each packet and keeps track of the unacknowledged packets. If the timer expires for a particular packet and the acknowledgement is not received, that packet will be resent. This way, the throughput on the network can be increased substantially.

There are many options as to when to send the acknowledgement. One option is the window size. If the sliding window size is seven, the source can send up to seven packets without waiting for the acknowledgement. The destination can send an acknowledgement after receiving all seven packets. If the destination has not received packet four, it can send an acknowledgement indicating that up to packet three were received. As shown in Figure 20.6, if B sends ACK three, the source knows that up to packetthree were received correctly, and it sends all the packets from four onwards again. Another option in the sliding window protocol is when to send the acknowledgements. A positive acknowledgment can be sent indicating that up to packet #n all packets are received. Alternatively, a negative acknowledgement may be sent indicating that packet #n is not received.

Figure 20.6: Sliding window protocol.

In sliding window protocol, a certain number of packets (say seven) are sent by the source without waiting for an acknowledgement. The destination can send a single acknowledgement for packet 3 indicating that 3 packets are received. Using this approach, the number of acknowledgements can be reduced, and the throughput can be increased.

The sliding window protocol also addresses flow control. If the destination cannot receive packets, with the speed with which the source sends the packets, the destination can control the packets flow.

Using this simple protocol, TCP layer will take care of flow control error control and tell the source that the packets are being received. We will discuss the details of the IP and TCP layers in the next two chapters.

20.4.2 Congestion Control

On the Internet, many connections get established and closed, so the traffic on the Internet is difficult to predict. If the traffic suddenly goes up, there will be congestion in the network and, as a result, some packets may be discarded by the routers. Every host has to have some discipline in transmitting its packets—there is no point in pushing packets onto the network if there is congestion.

In TCP/IP networks, congestion control is done through an additive-increase, multiplicative-decrease mechanism. To start with, a congestion window size is fixed. If there is congestion, the window size is reduced to half. If the congestion is reduced, the window size is increased by one.

In TCP, congestion control is done through a mechanism called additive increase/multiplicative decrease. A congestion window size is fixed at the beginning of the transmission, such as 16 packets. If there is suddenly congestion, and a packet loss is detected, the TCP reduces the congestion window size to 8. Even then, if a packet loss is detected, the window size is reduced to 4, and then to Z. The decrease is multiplicative.

If the congestion is reduced on the network, and acknowledgements for the packets are being received by the source, for each acknowledgement received, the TCP increases the window size by 1. If 4 was the earlier window size, it becomes 5, then 6 and so on. The increase is additive.

This simple mechanism for flow control ensures that the transmission channel is used effectively.