A Transport Layer protocol that provides reliable data transfer and Congestion control.
Features
- Connection-oriented: TCP initialises communication with some preliminary Segments to initialise the parameters that ensure reliable data transfer. This initial phase is called a handshake and because three segments are sent it is referred to as a Three-Way Handshake.
- Full-Duplex Service.
- Point-to-Point Connection.
- Send buffer: TCP does not send data immediately but holds data ready to be sent in a send buffer. These Segments are then sent when TCP finds it optimal considering congestion control.
- Limits the size of segments: the maximum amount of data placed in a segment is limited by the Maximum Segment Size.
- Cumulative Acknowledgement.
- Resend packages on timeout.
- Fast Retransmit.
- Controls Congestion with a Congestion Window.
- Self-clocking: uses Acknowledgements to increase its Congestion Window size.
TCP RFCs do not specify what happens to out-of-order segments, and the decision is up to the implementer of TCP. Two choices are:
- Discard out-of-order segments, as in Go-Back-N.
- Buffer out-of-order segments and wait for the missing bytes to fill the gap, as in Selective Repeat.
Segment Structure

The header of a TCP segment consists of:
- Source port number: 16-bit identifier for the sending Port.
- Destination port number: a 16-bit identifier for the destination Port.
- Sequence number: a 32-bit identifier for the packet. TCP views data as an ordered stream of bytes, which it chops up when it sends it in segments. It thus chooses its sequence numbers as the byte number of the data, that is the first byte in the segment.
- Acknowledgement number: a 32-bit identifier for the acknowledgement. The acknowledgement number is chosen as the next sequence number that is expected to be received.
- Header length: number of 32-bit words in header. This is required since the options field makes TCP headers have variable lengths.
- Flags for explicit congestion:
CWR(Congestion Window Reduced):ECE(Explicit Congestion Notification Echo):
- Flag field: contains 6 bits of flags, which are 1 when flagged:
URG(Urgent): indicating that there is data in the segment that the sender’s upper-layer has marked “urgent”.ACK(Acknowledgement): indicates that the value in the acknowledgement field is valid, i.e. that the segment contains an acknowledgement for a received segment.PSH(Push): indicates to the receiving end that the data should be pushed up to the receiving application immediately without buffering.RST(Reset): indicates that an abrupt termination of the connection is requested, typically used to reset a connection. Used in cases where a Host receives a Segment on a port where it does not accept connections.SYN(Synchronise): indicates that a connection wants to be established. Used in the Three-Way Handshake.FIN(Finish): Indicates that the sender has finished sending data and wants to close the connection. It is the first step in the TCP connection termination process.
- Receive window: number of bytes that a receiver is willing to accept.
- Used for flow control.
- It is set to the amount of spare room in the buffer.
- If the buffer has no spare room and the receive window becomes 0, then TCP requires the other Hosts to keep sending one-byte data to probe for when more room is available to receive data.
- Internet Checksum: field for providing the Checksum.
- Urgent data pointer: 16-bit pointer indicating the location of the last byte of urgent data. Only used if
URGis flagged.
Connection Management
TCP establishes a connection with a Three-Way Handshake.
A client closes a connection by setting the FIN flag and receiving an ACK from the server. The client then waits for the server to send a FIN flag for which the client sends an ACK and after a timeout closes the connection.
The states of a TCP connection of a client can be shown by:

Congestion Control
TCP controls congestion by maintaining a Congestion Window, that is not specified in Segments. The size of this window is dynamic:
- Decrease Congestion Window on lost Segments as this even implies Congestion
- Increase Congestion Window when receiving Acks, as they indicate successful delivery and therefore no Congestion.
These considerations form the basis of the TCP (Reno) congestion-control Algorithm which has three components:
- Slow start
- When a TCP connection begins the size of the Congestion Window
cwndis initialised to 1 MSS. - Afterwards, it increases
cwndby 1 MSS for each ACK, resulting in a doubling of the sending rate for every RTT giving it exponential growth.
- When a TCP connection begins the size of the Congestion Window
- Congestion avoidance
- The Congestion Window is increased by 1 MSS every RTT making the sending rate increase linearly.
- Fast recovery
The algorithm copes with loss by:
- Timeout: slow start is started anew with a
cwndof 1. But first, it saves half the value ofcwndin a state variablessthresh(slow start threshold), which indicates the value ofcwndwhich makes the algorithm go to congestion avoidance. - Three duplicate ACKs are received: the algorithms go to fast recovery.
As TCP Reno results in a linear additive increase in cwnd of 1 MSS per RTT and then a multiplicative decrease (halving) of cwnd on loss it is called an additive-increase, multiplicative-decrease (AIMD) form of Congestion control.
A Congestion control mechanism is said to be fair if the average transmission rate of each connection is an equal share of the link bandwidth.
Other Version of congestion Control
TCP Tahoe
An earlier version of TCP called TCP Tahoe, does not have the fast recovery phase that TCP Reno. This is a very cautious approach and resets cwnd to 1 MSS even when a loss can quickly recovered with the effect of a lower cwnd as shown below:

TCP CUBIC
TCP CUBIC takes another approach and ramps up the sending rate fast until near the value of cwnd where the last loss occurred and then probes cautiously by increasing cwnd very little.
The rate of increase in cwnd is based on the cube of the distance between the current time and which is the time when it is expected that cwnd reaches assuming no loss. This means that when is far from cwnd increases rapidly but does so slowly as approaches . It also means that when is a little greater than cwnd increase slowly, (which is good if the congestion level of the link causing the loss hasn’t changed by much) but as exceeds by a lot, cwnd increases rapidly (which quickly finds the new operating point if the congestion level has changed significantly).

Examples
Successful transmission of ‘C’

Retransmission due to lost acknowledgement

Cumulative acknowledgement avoids retransmission of the first segment
