Transport Layer:

Transmission Control Protocol (TCP)

Dr Samayveer Singh
Dept. of Computer Science and
Engineering
National Institute of Technology
Jalandhar, Punjab, India
[email protected]

NITJ 1
 TCP (Transmission Control Protocol) is a reliable, connection-oriented, stream-
TCP Services based, and full-duplex transport layer protocol. It ensures accurate and in-
order delivery of data from one process to another over a network.

Why use TCP?

1. It guarantees delivery (unlike UDP).
2. Ensures order, no duplication, and error recovery.
3. Used in apps where data integrity matters (e.g., web, email, file transfer).

✓ Process-to-Process Communication
✓ Stream Delivery Service Full-Duplex Communication

1. TCP allows simultaneous

✓ Full-Duplex Communication
two-way data transfer.
2. Both hosts can send and
receive data independently at
the same time.

✓ Multiplexing and Demultiplexing Achieved using:

✓ Connection-Oriented Service
1. Separate buffers and
sequence numbers for each
direction.
2. Common in applications like

✓ Reliable Service video conferencing, remote

login, etc.

Feature Description
-----------------------------------------------------------------------------------------------
**Connection-oriented** Requires a handshake before data transfer. 1. Multiplexing: Multiple processes on a host use TCP
**Reliable** Uses ACKs, retransmissions, timers, etc. simultaneously.
**Full-duplex** Data flows in both directions simultaneously.
**Byte-stream** Data sent as a stream, not message-by-message. 2. Demultiplexing: TCP identifies the correct receiving
**Flow control** Uses a **sliding window** to avoid overwhelming receiver. process using port numbers.
**Congestion control** Regulates sending rate based on network congestion.
**Port addressing** Uses source/destination ports for process communication. 3. Each TCP connection is uniquely identified by 4-tuple:

(Source IP, Source Port, Destination IP, Destination Port)

This allows multiple connections between the same hosts
but different apps.
TCP/IP Protocol Suite 2
 Figure 1 TCP/IP protocol suite

Figure 1 shows the relationship of TCP to the other protocols in the TCP/IP
protocol suite. TCP lies between the application layer and the network
layer, and serves as the intermediary between the application programs and
the network operations.

TCP/IP Protocol Suite 3

TCP/IP Protocol Suite 4
 Figure 2 Stream delivery
TCP is a stream-oriented protocol.

1. It treats the data as a continuous stream of bytes, not discrete packets.

This means: Data is read as a flow, not message-by-message.

2. The receiver doesn’t know where one message ends and another begins.
Example:
If sender writes: [Hello][World]
Receiver may get: [He][lloW][orld]

3. Segmentation and reassembly are handled by TCP internally.

TCP/IP Protocol Suite 5

 Figure 3 Sending and receiving buffers

Stream of bytes

TCP/IP Protocol Suite 6

 Figure 4 TCP segments

Segment N Segment 1
H H

TCP/IP Protocol Suite 7

 TCP FEATURES

TCP has several features that are given as

follows.
✓ Numbering System
✓ Flow Control
✓ Error Control
✓ Congestion Control

TCP/IP Protocol Suite 8

 Note

The bytes of data being transferred in

each connection are numbered by TCP.

The numbering starts with an arbitrarily

generated number.

TCP/IP Protocol Suite 9

Example 1
Suppose a TCP connection is transferring a file of 5,000
bytes. The first byte is numbered 10,001. What are the
sequence numbers for each segment if data are sent in five
segments, each carrying 1,000 bytes?

Solution
The following shows the sequence number for each
segment:

TCP/IP Protocol Suite 10

 Note

The value in the sequence number

field of a segment defines the number
assigned to the first data byte
contained in that segment.

TCP/IP Protocol Suite 11

 Note

The value of the acknowledgment field

in a segment defines the number of the
next byte a party expects to receive.

The acknowledgment number is

cumulative.

TCP/IP Protocol Suite 12

 SEGMENT

Before discussing TCP in more detail, let us

discuss the TCP packets themselves. A packet in
TCP is called a segment.

✓ Format
✓ Encapsulation

TCP/IP Protocol Suite 13

 Figure 5 TCP segment format

Indicates the byte number of the first byte in this segment.

Used to maintain order and track lost data.

This field holds the next expected byte from the sender.
Used to acknowledge received data.
Tells the sender how
many bytes it can send
Used for flow control.
before waiting for an ACK.

Calculated over: (control flags)

1. TCP header
2. Data Valid only if URG flag is set.
3. Pseudo header (from IP: Source IP, Destination IP, Protocol, TCP length) Indicates end of urgent data.

Options make header longer than 20 bytes,

hence padded to maintain alignment.

TCP/IP Protocol Suite 14

 Figure 6 Control field

(start connection)

TCP/IP Protocol Suite 15

 Figure 7 Pseudoheader added to the TCP segment

TCP/IP Protocol Suite 16

 Note

The use of the checksum in TCP is

mandatory.

TCP/IP Protocol Suite 17

 Figure 8 Encapsulation

TCP Application-layer data

header

IP
header

Frame
header

TCP payload
IP payload
Data-link layer payload

TCP/IP Protocol Suite 18

 A TCP CONNECTION

• TCP is connection-oriented. It establishes a virtual path

between the source and destination.
• All of the segments belonging to a message are sent
over this virtual path.
• You may wonder how TCP, which uses the services of
IP, a connectionless protocol, can be connection-
oriented.
• TCP uses the services of IP to deliver individual
segments to the receiver, but it controls the connection
itself.
• If a segment is lost or corrupted, it is retransmitted.

TCP/IP Protocol Suite 19

 Figure 9 Connection establishment using three-way handshake

Passive Open
Initial Sequence No. (choosen randomly by the client) means the server is
set to wait (listen)
seq: 8000 for connection
requests from
clients, rather than
UAPRS F 15000 (server’s
initiating them.

ISN)
SYN
seq: 15000 8001 (client’s
ISN + 1)
ack: 8001
nd: 5000
rwnd = 5000
U A P R S F rw (receiver
window size =
SYN + ACK buffer space)
seq: 8000
ack: 15001
UAPRS F
rwnd: 10000
ACK

TCP/IP Protocol Suite 20

 Note

A SYN segment cannot carry data, but it

consumes one sequence number.

TCP/IP Protocol Suite 21

 Note

A SYN + ACK segment cannot carry

data, but does consume one
sequence number.

TCP/IP Protocol Suite 22

 Note

An ACK segment, if carrying no data,

consumes no sequence number.

TCP/IP Protocol Suite 23

 Figure 10 Data Transfer

seq:Byte number of first byte

in this segment

ack:Next byte expected by

receiver

Connection Termination

TCP/IP Protocol Suite

no new data sent (pure ACK)
24
 Figure 11 Connection termination using three-way handshake

TCP/IP Protocol Suite 25

 Note

The FIN segment consumes one

sequence number if it does
not carry data.

TCP/IP Protocol Suite 26

 Note

The FIN + ACK segment consumes one

sequence number if it does
not carry data.

TCP/IP Protocol Suite 27

 Figure 12 Half-Close

TCP/IP Protocol Suite 28

 Fig 15 Time-line diagram for connection establishment and half-close termination

TCP/IP Protocol Suite 29

 Figure 17 Time line for a common scenario

Steps taken by server in

CLOSE-WAIT:

1. Inform the application layer:

The server's TCP informs the
application process that the
client has finished sending
data (signaled by the received
FIN).

2. Send remaining data in the

buffer/queue (if any):
Before closing the
connection, the server must
send any pending data it still
has in its send buffer to the
client. This ensures no data is
lost.

3. Send EOF (End-of-File):

After all queued data is sent,
the server sends its own FIN
to indicate it has no more
data to send — this acts as
an EOF marker (used in
file/data transfers to indicate
completion).

TCP/IP Protocol Suite 30

 Figure 18 Simultaneous open

TCP/IP Protocol Suite 31

 Figure 19 Simultaneous close

Each end now waits

in the TIME-WAIT
state for 2MSL
(Maximum Segment
Lifetime).

This waiting ensures

that the final ACK is
not lost and allows
retransmissions if
needed.

TCP/IP Protocol Suite 32

 Figure 19 Simultaneous close

1. Both sides initiate the close process.

2. Each sends a FIN, enters FIN-WAIT-1.
3. Both receive FIN, respond with ACK, enter CLOSING.
4. Then enter TIME-WAIT, start 2MSL timer.
5. Finally, both move to the CLOSED state.

TCP/IP Protocol Suite 33

 Figure 20 Denying a connection

TCP/IP Protocol Suite 34

 Figure 21 Aborting a connection

TCP/IP Protocol Suite 35

 WINDOWS IN TCP

TCP uses two windows (send window and receive

window) for each direction of data transfer, which
means four windows for a bidirectional
communication.
To make the discussion simple, we make an
assumption that communication is only
unidirectional; the bidirectional communication
can be inferred using two unidirectional
communications with piggybacking.

TCP/IP Protocol Suite 36

 Figure 22 Send window in TCP

TCP/IP Protocol Suite 37

 Figure 23 Receive window in TCP

TCP/IP Protocol Suite 38

 FLOW CONTROL

✓ In flow control balances the rate a producer creates data with the
rate a consumer can use the data.
✓ TCP separates flow control from error control. In this section, we
discuss flow control, ignoring error control.
✓ We temporarily assume that the logical channel between the
sending and receiving TCP is error-free.
✓ Figure shows unidirectional data transfer between a sender and a
receiver; bidirectional data transfer can be deduced from
unidirectional one.

✓ Opening and Closing Windows

✓ Shrinking of Windows
✓ Silly Window Syndrome

TCP/IP Protocol Suite 39

 Figure 24 Data flow and flow control feedbacks in TCP

Messages Flow control

are pushed
1 5 3 Messages
feedback are pulled

2
Segements are pushed
4
Flow control feedback

TCP/IP Protocol Suite 40

 Figure 25 An example of flow control: Opening and Closing Windows

TCP/IP Protocol Suite 41

 TCP mandates that the window must never shrink once advertised. The sender relies on that
Example 15.2 range being valid until a new larger window is advertised.

• Next figure shows the reason for the mandate in window shrinking.
• Part a of the figure shows values of last acknowledgment and rwnd.
• Part b shows the situation in which the sender has sent bytes 206 to
214.
• Bytes 206 to 209 are acknowledged and purged. The new
advertisement, however, defines the new value of rwnd as 4, in which
210 + 4 < 206 + 12 (new ackno+rwnd >= last ackno+rwnd).
• When the send window shrinks, it creates a problem: byte 214 which
has been already sent is outside the window.
• The relation discussed before forces the receiver to maintain the
right-hand wall of the window to be as shown in part a because the
receiver does not know which of the bytes 210 to 217 has already
been sent.
• One way to prevent this situation is to let the receiver postpone its
feedback until enough buffer locations are available in its window.
• In other words, the receiver should wait until more bytes are
consumed by its process. Once a window is advertised, the receiver cannot shrink it (i.e., it cannot reduce the
allowed byte range).

TCP/IP Protocol Suite 42

 Figure 26 Example 2
If the receiver runs low on buffer:

1. Don't advertise a smaller window.

2. Instead, wait to acknowledge more data until the buffer is cleared and more space is available.
3. This avoids confusion and ensures reliable communication.

TCP/IP Protocol Suite 43

 Silly Window Syndrome is a problem in TCP communication where very
Silly Window Syndrome small segments of data are repeatedly sent or advertised, leading to
inefficient use of network resources and poor throughput.

Silly Window Syndrome is a problem that arises due to poor implementation of TCP.
It degrades the TCP performance and makes the data transmission extremely
inefficient. The problem is called so because:

1. It causes the sender window size to shrink to a silly value.

2. The window size shrinks to such an extent that the data being transmitted is
smaller than TCP Header.
Why Is It a Problem?

What are the causes? 1. Causes low throughput.

2. Wastes network bandwidth.
The two major causes of this syndrome are as follows: 3. Increases packet processing
overhead.
4. Results in congestion in the
network.
1. Sender window transmitting one byte of data repeatedly.

2. Receiver window accepting one byte of data repeatedly.

TCP/IP Protocol Suite 44

Silly Window Syndrome

Cause-1: Sender window transmitting one byte of data repeatedly –

Suppose only one byte of data is generated by an application. The poor
implementation of TCP leads to transmit this small segment of data. Every time
the application generates a byte of data, the window transmits it. This makes the
transmission process slow and inefficient. The problem is solved by Nagle’s
algorithm.

Nagle’s algorithm suggests:

1. Sender should send only the first byte on receiving one byte data from the
application.
2. Sender should buffer all the rest bytes until the outstanding byte gets
acknowledged.
3. In other words, sender should wait for 1 RTT (Round Trip Time).

After receiving the acknowledgement, sender should send the buffered data in one
TCP segment. Then, sender should buffer the data again until the previously sent
data gets acknowledged. Only send the next segment when:
You receive an ACK, or
You have a maximum segment size (MSS) worth of data.
TCP/IP Protocol Suite 45
Silly Window Syndrome
Cause-2: Receiver window accepting one byte of data repeatedly –
Suppose consider the case when the receiver is unable to process all the
incoming data.
In such a case, the receiver will advertise a small window size. The
process continues and the window size becomes smaller and smaller. A
stage arrives when it repeatedly advertises window size of 1 byte. This
makes receiving process slow and inefficient. The solution to this problem
is Clark’s Solution.

Clark’s solution suggests:

1. Receiver should not send a window update for 1 byte.

2. Receiver should wait until it has a decent amount of space available.

3. Receiver should then advertise that window size to the sender.

TCP/IP Protocol Suite 46

 ERROR CONTROL

TCP is a reliable transport layer protocol. This

means that an application program that
delivers a stream of data to TCP relies on TCP
to deliver the entire stream to the application
program on the other end in order, without
error, and without any part lost or duplicated.

Error control in TCP is achieved through the

use of three tools: checksum,
acknowledgment, and time-out.

TCP/IP Protocol Suite 47

 Note

ACK segments do not consume

sequence numbers and
are not acknowledged.

TCP/IP Protocol Suite 48

 Note

Data may arrive out of order and be

temporarily stored by the receiving TCP,
but TCP guarantees that no out-of-order
data are delivered to the process.

TCP/IP Protocol Suite 49

 Note

TCP can be best modeled as a

Selective Repeat protocol.

TCP/IP Protocol Suite 50

 Figure 29 Normal operation

TCP/IP Protocol Suite 51

 Figure 30 Lost segment

TCP/IP Protocol Suite 52

 Note

The receiver TCP delivers only ordered

data to the process.

TCP/IP Protocol Suite 53

 Figure 31 Fast retransmission

TCP/IP Protocol Suite 54

 Figure 32 Lost acknowledgment

TCP/IP Protocol Suite 55

 Figure 33 Lost acknowledgment corrected by resending a segment

TCP/IP Protocol Suite 56

 Note

Lost acknowledgments may create

deadlock if they are not
properly handled.

TCP/IP Protocol Suite 57

 9 CONGESTION CONTROL

➢ Congestion control in TCP is based on both open

loop and closed-loop mechanisms.

➢ TCP uses a congestion window and a congestion

policy that avoid congestion and detect and
alleviate congestion after it has occurred.
Congestion occurs when too many packets are

✓ Congestion Window present in the network, leading to:

Buffer overflows,

✓ Congestion Policy
Packet drops,
Retransmissions,
Increased delays.

It mainly affects router queues and links, not

just the sender/receiver.

TCP/IP Protocol Suite 58

 Figure 34 Slow start, exponential increase

Used at the beginning of a connection or

after a timeout.

Starts with a congestion window (cwnd)

of 1 MSS (Maximum Segment Size).

Grows exponentially:

Each ACK received --> cwnd += 1 MSS

So cwnd doubles every RTT.

TCP/IP Protocol Suite 59

 Note

In the slow start algorithm, the size of

the congestion window increases
exponentially until it reaches a
threshold.

TCP/IP Protocol Suite 60

 Figure 35 Congestion avoidance, additive increase

Congestion Avoidance

When cwnd >= ssthresh

(slow start threshold), TCP
enters congestion
avoidance.

Linear growth:

cwnd += (1 MSS) per RTT

Slower growth helps avoid

congestion once network is
near capacity.

TCP/IP Protocol Suite 61

 Note

In the congestion avoidance algorithm

the size of the congestion window
increases additively until
congestion is detected.

TCP/IP Protocol Suite 62

 Figure 15.36 TCP Congestion policy summary

TCP/IP Protocol Suite 63

 Figure 37 Congestion example

TCP/IP Protocol Suite 64

 TCP TIMERS

Most TCP implementations use at least four timers

to perform its operation smoothly.

TCP/IP Protocol Suite 65

 Figure 38 TCP timers

TCP/IP Protocol Suite 66

 Retransmission Timer

✓ When TCP sends a segment the timer starts and

stops when the acknowledgment is received.

✓ TCP uses retransmission timeout (RTO) to

retransmit lost segments.

✓ If the timer expires timeout occurs and the segment

is retransmitted.
Purpose:
Ensures reliable delivery by retransmitting a segment if an ACK is not received in time.

How is it calculated?

Based on Estimated Round-Trip Time (RTT):

EstimatedRTT = average of recent RTTs
Deviation (DevRTT) = variance in RTT
TimeoutInterval = EstimatedRTT + 4 × DevRTT

TCP/IP Protocol Suite

Adapts to network conditions — increases if the network is congested. 67
 Persistent Timer-

❖ TCP uses a persistent timer to deal with a zero-widow-size deadlock

situation.
❖ It keeps the window size information flowing even if the other end closes its
receiver window.

Consider the following situation-

✓ Sender receives an acknowledgment from the receiver with zero
window size.
✓ This indicates the sender to wait.
✓ Later, receiver updates the window size and sends the segment with the
update to the sender.
✓ This segment gets lost.
✓ Now, both sender and receiver keeps waiting for each other to do
something.
✓ To deal with such a situation, TCP uses a persistent timer.

TCP/IP Protocol Suite 68

 Solution by Persistent Timer-

❖ Sender starts the persistent timer on receiving an ACK from the receiver with
a zero window size.
❖ When persistent timer goes off, sender sends a special segment to the
receiver.
❖ This special segment is called as probe segment and contains only 1 byte of
new data.
❖ Response sent by the receiver to the probe segment gives the updated
window size.
❖ If the updated window size is non-zero, it means data can be sent now.
❖ If the updated window size is still zero, the persistent timer is set again and
the cycle repeats.

TCP/IP Protocol Suite 69

 Keep Alive Timer-

❖ TCP uses a keep alive timer to prevent long idle TCP connections.

✓ Each time server hears from the client, it resets the keep alive timer to 2
hours.
✓ If server does not hear from the client for 2 hours, it sends 10 probe
segments to the client.
✓ These probe segments are sent at a gap of 75 seconds.
✓ If server receives no response after sending 10 probe segments,
it assumes that the client is down.
✓ Then, server terminates the connection automatically.

TCP/IP Protocol Suite 70

 Time Wait Timer-

❖ TCP uses a time wait timer during connection termination.

✓ Sender starts the time wait timer after sending the ACK for the second
FIN segment.
✓ It allows to resend the final acknowledgement if it gets lost.
✓ It prevents the just closed port from reopening again quickly to some
other application.
✓ It ensures that all the segments heading towards the just closed port are
discarded.
✓ The value of time wait timer is usually set to twice the lifetime of a TCP
segment.
Purpose:
Ensures all duplicate segments are flushed from the network before fully closing a connection.

TCP waits 2MSL (Maximum Segment Lifetime) to be sure that:

1. All packets are gone from the network.
2. The other side has received the last ACK.

Avoids confusion if new connections reuse the same IP/port

TCP/IP Protocol Suite 71