Like its sister protocol UDP, TCP is a member of the IP family. However, TCP is a reliable, connection- oriented protocol that has capabilities for error detection, error correction, and in-sequence delivery of data streams. Figure 1.103 shows the generic header format of TCP frames.
As in case of UDP, the source and destination ports identify the application on top of the transport layer. Each TCP packet is sent with a unique sequence number that is acknowledged by the receiver after error-free reception of the packet. There is no separate ACK message. Instead the ACK is transmitted using the next available frame in the opposite direction.
The meaning of the other TCP header information elements is as follows:
• Data offset: The length of the TCP header without the data field (payload).
• Flags (8 bits) (aka control bits): These are eight 1-bit flags with the following meaning:
– Congestion Window Reduced (CWR) (1 bit): This flag is set by the sending host to indicate that it received a TCP segment with the ECN-Echo (ECE) flag set and had responded in the congestion control mechanism.
– ECE (1 bit): Value (1) indicates that the TCP peer is ECN capable during three-way handshake, and value (2) that a packet with the congestion experienced flag in the IP header set is received during normal transmission.
– URG (1 bit): This is the URGent pointer field for datagrams with high priority.
– ACK (1 bit): This indicates that the ACK field is significant.
– PSH (1 bit): The push function.
– RST (1 bit): Reset the connection.
– SYN (1 bit): Synchronize sequence numbers.
– FIN (1 bit): No more data from sender. This flag should trigger the TCP FIN procedure to terminate the TCP connection.
• Window (16 bits): This is the size of the receive window, which specifies the number of bytes (beyond the sequence number in the ACK field) that the receiver is currently willing to receive.
• Checksum (16 bits): This 16-bit field is used for error checking of the headerand the payload data.
• Urgent pointer (16 bits): If the URG flag is set, then this 16-bit field is an offset from the sequence number indicating the last urgent data byte.
• Options (variable bits): This is an appendix with optional additional information. The total length of the option field must be a multiple of a 32-bit word and the data offset field adjusted appropriately.
Each TCP connection starts with a so-called three-way handshake, as shown in the first three lines of Figure 1.104.
Figure 1.103 TCP header format.
Figure 1.104 TCP startup for a FTP service.
Firstly, the side that wants to establish a TCP connection sends a TCP SYN message. The sequence number in this SYN message is a random number. The ACK number is always 0, because no received frame needs to be acknowledged.
When the peer entity receives the SYN message it sends back a SYN-ACK including the previous sequence number+1 as the ACK number. The originating party of the connection will do the same to acknowledge the SYN-ACK with the first payload packet to be sent. Starting with this first payload packet, the size of the payload data field is encoded in the sequence number and the SYN-ACK is again acknowledged with its sequence number value+1.
Due to the fact that the initial round-trip time must be calculated on each side of the connection, the TCP startup procedure may take quite a while, especially if there is a long distance or a long chain of network nodes between the endpoints. Based on delay measurement results, it has become common to describe this typical behavior as “TCP slow start.”
TCP detects missing packets on behalf of timer expiry. The initial timer values on both sides of the connection are calculated during the startup procedure as the initial round-trip time. If the expected ACK for a sent packet does not arrive before the timer in the sending entity expires, the previously sent frame is retransmitted as shown in Figure 1.105.
During the ongoing connection the round-trip time on both endpoints of the connection is adjusted multiple times. However, due to outliers in end-to-end latency, it is also possible that duplicated messages are sent in case the receiving entity detects timeout and hence a necessary retransmission, but the expected frame is indeed received – after the retransmission was already sent.
Figure 1.105 TCP retransmission scenarios.
Malfunctions, lost frames, as well as duplicated ACKs have an impact on the network QoS. They slow down the transmission of payload data. Duplicated ACKs are a waste of precious bandwidth on the radio interface and necessary retransmissions increase the payload packet delay.