1. U-IV : Transport Control Protocol
Dr. D. P.
Digitally signed by Dr. D. P. Mishra
DN: cn=Dr. D. P. Mishra, o=durg,
Date: 2023.04.29 13:55:38 +05'30'
2. Transport Layer
• Two transport layer protocols supported by the Internet:
The Transport Control Protocol (TCP)
The Unreliable Datagram Protocol (UDP)
4. Transport Protocols
• Lowest level end-to-end
Header generated by sender is
interpreted only by the
Routers view transport header
as part of the payload
• Port numbers are 16-bit integers (0 65,535)
• Servers use well know ports, 0-1023 are privileged
• Clients use ephemeral (short-lived) ports
• Internet Assigned Numbers Authority (IANA) maintains a list of
port number assignment
• Well-known ports (0-1023) controlled and assigned by IANA
• Registered ports (1024-49151) IANA registers and lists use of
ports as a convenience (49151 is ¾ of 65536)
• Dynamic ports (49152-65535) ephemeral ports
• For well-known port numbers, see /etc/services on a UNIX or Linux
Transmission Control Protocol
• TCP must perform typical transport layer functions:
• Segmentation breaks message into packets
• End-to-end error control since IP is an unreliable Service
• End-to-end flow control to avoid buffer overflow
• Multiplexing and demultiplexing sessions
• TCP is [originally described in RFC 793, 1981]
• Connection-oriented virtual circuit
• Stream-oriented users exchange streams of data
• Full duplex concurrent transfers can take place in both
• Buffered TCP accepts data and transmits when appropriate
(can be overridden with “push”)
11. TCP Segment /Frame Format
Options (0 or more 32-bit words)
Checksum Urgent Pointer
Source Port Destination Port
Acknowledgement number HL reserved Code Window
12. TCP Frame Fields
• Source & Destination Ports
16 bit port identifiers for each packet
• Sequence number
The packet’s unique sequence ID
• Acknowledgement number
The sequence number of the next packet expected by the
13. TCP Frame Fields (cont’d)
• Window size
Specifies how many bytes may be sent after the first
Checksums the TCP header and IP address fields
• Urgent Pointer
Points to urgent data in the TCP data field
14. TCP Frame Fields (cont’d)
• Header bits
URG = Urgent pointer field in use
ACK = Indicates whether frame contains acknowledgement
PSH = Data has been “pushed”. It should be delivered to
higher layers right away.
RST = Indicates that the connection should be reset
SYN = Used to establish connections
FIN = Used to release a connection
17. TCP Retransmission
• When a packet remains unacknowledged for a period of
time, TCP assumes it is lost and retransmits it.
• TCP tries to calculate the round trip time (RTT) for a
packet and its acknowledgement.
• From the RTT, TCP can guess how long it should wait
before timing out.
20. Round Trip Time (RTT)
RTT = Time for packet to arrive at destination
Time for ACK to return from destination
Time for data to arrive
Time for ACK to return
22. Problem with RTT Calculation
• Sender doesn’t send next packet until he’s sure receiver received previous packet
• The packet/Ack sequence enables reliability
• Sequence numbers help avoid problem of duplicate packets
• Problem: keeping the pipe full
1.5Mbps link x 45ms RTT = 67.5Kb (8KB)
1KB frames implies 1/8th link utilization
Buffering on Sender and
• Sender needs to buffer data so that if data is lost, it can be resent
• Receiver needs to buffer data so that if data is received out of order, it
can be held until all packets are received
• How can we prevent sender overflowing receiver’s buffer?
Receiver tells sender its buffer size during connection setup
• How can we ensure reliability in pipelined transmissions?
Send all N unACKed packets when a loss is signaled
Only send specifically unACKed packets
A bit trickier to implement
Another Pipelining Possibility:
Concurrent Logical Channels
• Multiplex 8 logical channels over a single link
• Run stop-and-wait on each logical channel
• Maintain three state bits per channel
current sequence number out
next sequence number in
• Header: 3-bit channel num, 1-bit sequence num
same as sliding window protocol
• Separates reliability from order
Stop & wait sequence numbers
• Simple sequence numbers enable the client to discard duplicate copies of the
• Stop & wait allows one outstanding frame, requires two distinct sequence
Sliding Window Summary
• Sliding window is best known algorithm in networking
• First role is to enable reliable delivery of packets
Timeouts and acknowledgements
• Second role is to enable in order delivery of packets
Receiver doesn’t pass data up to app until it has packets in order
• Third role is to enable flow control
Prevents server from overflowing receiver’s buffer
31. TCP Performance
• Silly Window Syndrome
Sender generates data quickly
Receiver reads incoming data one octet at a time
32. TCP Performance (cont)
• Silly Window Syndrome
Each ACK advertises a small amount of space
Each segment carries a small amount of data
Poor use of network bandwidth
Unnecessary computational overhead
33. TCP Performance (cont)
• Avoiding Silly Window Syndrome
Use heuristics at sender to avoid transmitting a small
amount of data in each segment
Use heuristics at receiver to avoid sending small
• Receive-side silly window avoidance
Monitor receive window size
Delay advertising an increase until a “significant”
increase is possible
“Significant” = min(half the window, maximum segment size)
34. Receive-Side Silly Window
Receive 6 octets, send ACK 7 with window advisement of 0
Application reads one octet
Application reads one octet
Application reads one octet
Send window advisement of 3, receive 3 octets
35. Receive-Side Silly Window
• Two approaches:
Receiver can ACK received octets but does not advertise
an increase in its window until the increase is
Receiver can not send ACKs when the window is not
large enough to advertise
36. Send-Side Silly
• Goal: avoid sending small segments
• Application can generate data in small blocks
• TCP must collect data sent by application into a
single large segment (clump) for transmission
• TCP must delay sending a segment until it
contains a reasonable amount of data
• How long should TCP wait before transmitting
37. Send-Side Silly Window Avoidance
The Nagle Algorithm:
Application generates data to be sent over a connection
that has already transmitted some data
If all previous transmissions have been acknowledged send
the data immediately
If any ACKs are still pending do not transmit until:
Maximum segment size is reached, or
An ACK arrives
• Self-clocking - does not compute delays
• Applies even if the application requests a push
38. TCP Summary
• Provides reliable stream delivery service
Out-of-band for urgent data
• Makes efficient use of the network
End-to-end flow control
Acknowledgment and retransmission
39. Flow control refers to a set of procedures used to
restrict the amount of data that the sender can
send before waiting for acknowledgment.
40. Error control is based on automatic repeat
request, which is the retransmission of data.
41. The protocols are normally implemented in
software by using one of the common
Selective Repeat ARQ
42. • It is the simplest flow and error control mechanism .
• A transmitter sends a frame then stops and waits for an
Stop-and-Wait ARQ has the following features:
• The sending device keeps a copy of the sent frame
transmitted until it receives an acknowledgment( ACK)
• The sender starts a timer when it sends a frame.
• If an ACK is not received within an allocated time
period, the sender resends it
• Both frames and acknowledgment (ACK) are numbered
alternately 0 and 1( two sequence number only)
• This numbering allows for identification of frames in
case of duplicate transmission
Stop & Wait
43. • The acknowledgment number defines the number of next expected
frame. (frame 0 received ACK 1 is sent)
• A damage or lost frame treated by the same manner by the
• If the receiver detects an error in the received frame, or receives
a frame out of order it simply discards the frame
• The receiver send only positive ACK for frames received safe; it
is silent about the frames damage or lost.
• The sender has a control variable Sthat holds the number of most
recently sent frame (0 or 1). The receiver has control variable R,
that holds the number of the next frame expected (0,or 1)
Stop & Wait
44. Cases of Operations:
1. Normal operation
2. The frame is lost
3. The Acknowledgment (ACK) is
4. The Ack is delayed
Stop and Wait ARQ
45. The sender will not
send the next frame
until it is sure that the
current one is correctly
Sequence number is
necessary to check for
46. • A damage or lost frame
treated by the same
manner by the receiver.
• No NACK when frame is
corrupted / duplicate
Stop and Wait Lost or damaged frame
51. • Is a method to combine a data frame with an acknowledgment.
• It can save bandwidth because data frame and an ACK frame can combined
into just one frame
52. • After each frame sent the host must wait for
• inefficient use of bandwidth
• To improve efficiency ACK should be sent after
• Alternatives: Sliding Window protocol
• Go-back-N ARQ
• Selective Repeat ARQ
53. Pipelining: A task is begun before the previous task
• There is no pipelining in stop and wait ARQ
because we need to wait for a frame to reach the
destination and be acknowledged before the next
frame can be sent
• Pipelining improves the efficiency of the
54. Sliding window protocols apply Pipelining :
Selective Repeat ARQ
• Sliding window protocols improve the efficiency
• Multiple frames should be in transition while waiting
for ACK. Let more than one frame to be outstanding.
• Outstanding frames: frames sent but not
• We can send up to W frames and keep a copy of these
frames(outstanding) until the ACKs arrive.
• This procedures requires additional feature to be
added :sliding window
Sliding window protocol
56. Go_Back _N ARQ
Sender sliding window
If m = 3; sequence
numbers = 8 and window
57. Receiver sliding window
The receive window is an abstract concept defining
an imaginary box of size 1 with one single variable
The window slides when a correct frame has arrived;
sliding occurs one slot at a time.
Go_Back _N ARQ
58. control variables
S: hold the sequence number of the recently sent frame
SF: holds sequence number of the first frame in the
SL: holds the sequence number of the last frame
R: sequence number of the frame expected to received
Outstanding frames: frames sent but
60. In Go-Back-N ARQ we use one timer for the first outstanding
The receiver sends a positive ACK if a frame has arrived
safe and in order.
if a frame is damaged or out of order ,the receiver is silent
and will discard all subsequent frames
When the timer of an unacknowledged frame at the sender
site is expired , the sender goes back and resend all frames
, beginning with the one with expired timer.( that is why the
protocol is called Go-Back-N ARQ)
The receiver doesn't have to acknowledge each frame
received . It can send cumulative Ack for several frame
61. Go-Back-N ARQ
Example: The sender has sent frame 6 , and timer expires
for frame 3( frame 3 has not been acknowledge); the sender
goes back and resends frames 3, 4,5 and 6
65. Go-Back-N ARQ
Bidirectional transmission : piggybacking
• As Stop-and-Wait we can use piggybacking to improve the
efficiency of bidirectional transmission .
• Each direction needs both a sender window and a receiver
67. Selective Repeat ARQ
Go-Back-N ARQ is inefficient of a noisy link.
• In a noisy link frames have higher probability of damage ,
which means the resending of multiple frames.
• This resending consumes the bandwidth and slow down the
• Selective Repeat ARQ protocol : resent only the damage frame
• It defines a negative Acknowledgment (NAK) that report the
sequence number of a damaged frame before the timer expires
• It is more efficient for noisy link, but the processing at the
receiver is more complex
70. Selective Repeat ARQ
At the receiver site we need to distinguish between the
acceptance of a frame and its delivery to the network layer
. At the second arrival , frame 2 arrives and is stored and
marked , but it can not be delivered because frame 1 is
missing . At the next arrival , frame 3 arrives and is marked
and stored , but still none of the frames can be delivered .
Only at the last arrival , when finally a copy of frame 1
arrives , can frames 1 , 2 , and 3 be delivered to the
network layer. There are two conditions for the delivery of
frames to the network layer: First , a set of consecutive
frames must have arrived. Second, the set starts from the
beginning of the window .
71. Selective Repeat ARQ
The next point is about the ACKs . Notice that only two ACKs
are sent here. The first one acknowledges only the first frame;
the second one acknowledges three frames. In Selective
Repeat, ACKs are sent when data are delivered to the network
layer. If the data belonging to n frames are delivered in one
shot , only one ACK is sent for all of them.
72. In Selective Repeat ARQ, the size of In the
sender and receiver window must be at
most one-half of 2m.
75. TCP State Machine
• TCP uses a Finite State Machine, kept by each side of a connection,
to keep track of what state a connection is in.
• State transitions reflect inherent races that can happen in the
network, e.g., two FIN's passing each other in the network.
• Certain things can go wrong along the way, i.e., packets can be
dropped or corrupted.
• In fact, machine is not perfect; certain problems can arise not
anticipated in the original RFC.
• This is where timers will come in, which we will discuss more later.
78. TCP State Machine: Connection Establishment
send SYN + ACK
receive SYN & ACK
• CLOSED: more implied than actual,
i.e., no connection
• LISTEN: willing to receive connections
• SYN-SENT: sent a SYN, waiting for
• SYN-RECEIVED: received a SYN,
waiting for an ACK of our SYN
• ESTABLISHED: connection ready for
79. TCP State Machine:
• FIN-WAIT-1: we closed first, waiting
for ACK of our FIN (active close)
• FIN-WAIT-2: we closed first, other side
has ACKED our FIN, but not yet
• CLOSING: other side closed before it
received our FIN
• TIME-WAIT: we closed, other side
closed, got ACK of our FIN
• CLOSE-WAIT: other side sent FIN
first, not us (passive close)
• LAST-ACK: other side sent FIN, then
we did, now waiting for ACK
80. U-IV Transport Control Protocol
State Transition Diagram 3/4
CLOSED There is no connection.
LISTEN The server is waiting for calls from the client.
SYN-SENT A connection request is sent; waiting for acknowledgment.
SYN-RCVD A connection request is received.
ESTABLISHED Connection is established.
The application has requested the closing of the
FIN-WAIT-2 The other side has accepted the closing of the connection.
TIME-WAIT Waiting for retransmitted segments to die.
CLOSE-WAIT The server is waiting for the application to close.
LAST-ACK The server is waiting for the last acknowledgment.
Can use netstat command to see some TCP states
81. Summary: TCP Protocol
• Protocol provides reliability in face of complex
• Tries to trade off efficiency with being "good
• Vast majority of bytes transferred on Internet today
Peer-to-peer (Napster, Gnutella, FreeNet, KaZaa)
83. Leaky Bucket Algorithm
• Suppose we have a bucket in which we are pouring water in a
random order but we have to get water at fixed rate , for this we will
make a hole at the bottom of the bucket.
• It will ensure that water coming out is in a some fixed rate .
• And also if bucket will full we will stop pouring in it.
• The input rate can vary, but the output rate remains constant.
• Similarly, in networking, a technique called leaky bucket can
smooth out bursty traffic.
• Bursty chunks are stored in the bucket and sent out at an average
84. Leaky Bucket Algorithm
• In the figure, we assume that the network has committed a bandwidth of 3 Mbps for a host.
• The use of the leaky bucket shapes the input traffic to make it conform to this commitment.
• A simple leaky bucket algorithm can be implemented using FIFO queue.
• A FIFO queue holds the packets.
85. Working Steps Leaky Bucket
• When the host has to send a
packet , packet is thrown in
• Bucket leaks at constant rate.
• Bursty traffic is converted into
uniform traffic by leaky bucket.
• In practice bucket is a finite
queue outputs at finite rate.
86. Token Bucket Algorithm
• In this leaky bucket holds tokens
generated at regular intervals of time.
• Bucket has maximum capacity.
• If there is a ready packet , a token is
removed from Bucket and packet is send.
• If there is a no token in bucket, packet
can not be send.
• If bucket is full in token Bucket , token are discarded not packets. While in leaky
bucket , packets are discarded.
• Token Bucket can send Large bursts at faster rate while leaky bucket always sends
packets at constant rate.
88. Karns’ Algorithm
• The retransmission ambiguity problem occurs when a sender has
retransmitted a packet and receives an acknowledgement (ACK)
for the data.
• The sender cannot be certain whether the ACK received was for the
original (presumed lost) packet or for the resent packet.
• If receiver is acknowledging (ACK) the original packet, the RTT sample
is significantly longer than the current SRTT value.
• If the receiver is acknowledging (ACK) the retransmitted packet, RTT is
likely closer to the current SRTT value and the original packet or ACK
• The first part of Karn's Algorithm states that when there is
retransmission ambiguity, RTT measurements are ignored
instead of being incorporated into SRTT to avoid skewing SRTT
89. Karns’ Algorithm (1)
• Improve accuracy of the RTT measurement.
– RTT measurement with packet loss
• Duration A: use the most recent retransmission for RTT measurement.
• Duration B: use the original transmission for RTT measurement.
– Which duration is suitable for RTT measurement?
– example 1:
• We should use "duration A" as RTT in this case.
– But, this assumption is not always correct
90. Karns’ Algorithm (2)
• RTT measurement with packet loss
– example 2:
• We cannot use "duration A" as RTT in this case!
• So, what should we do?
91. Karns’ Algorithm (3)
– Rule 1: Ignore measured RTT for retransmitted packets.
• Remove ambiguity from RTT measurements.
– Rule 2: RTO should be doubled after retransmission.
• This is called "Exponential Back-off"
92. Karns’ Algorithm (4)
Why is Rule 2 necessary?
– When RTO is smaller than Real RTT..
• If only Rule 1 is applied, TCP will use A as RTO forever.
• All packets will be retransmitted.
– No RTT measurement happens.
93. Another Problem with RTT Calculation
• RTT measurements can sometimes fluctuate severely
smoothed RTT (SRTT) is not a good reflection of round-trip
time in these cases
• Solution: Use Jacobson/Karels algorithm:
Error =RTT - SRTT
SRTT ==SRTT + (a Error)
Dev ==Dev + h(|Error| - Dev)
Timeout = SRTT+ (b Dev)
94. Jacobson/Karels Algorithm
Example Initial SRTT = 1.50, Dev = 0
a = 0.125, d = 0.25, b = 4.0
RTT Meas. SRTT
1.5 s = 1.50
1.0 s = 1.44
2.2 s = 1.54
1.0 s = 1.47
0.8 s = 1.39
Error = RTT - SRTT
SRTT = SRTT + (a Error)
Dev = Dev + [d (|Error| - Dev)]
Timeout = SRTT + (b Dev)
• UDP does not provide:
Flow or error control
Guaranteed in-order packet delivery
• UDP is almost a “null” transport layer
97. Why UDP?
• No connection needs to be set up
• Throughput may be higher because UDP packets are easier
to process, especially at the source
• The user doesn’t care if the data is transmitted reliably
• The user wants to implement his or her own transport
98. UDP Characteristics
• End-to-End: an application sends/receives data to/from another
• Connectionless: Application does not need to preestablish
communication before sending data; application does not need to
terminate communication when finished.
• Message-oriented: application sends/receives individual messages
(UDP datagram), not packets.
• Best-effort: same best-effort delivery semantics as IP, i.e. message can
be lost, duplicated, and corrupted.
• Arbitrary interaction: application communicates with many or one
• Operating system independent: identifying application does not
depend on O/S.
99. UDP Frame Format
Source Port Destination Port
UDP length UDP checksum (optional)
• Source Port - 16 bit port number
• Destination Port - 16 bit port number
• Length (of UDP header + data) - 16 bit count of octets
• UDP checksum - 16 bit field. if 0, then there is no checksum, else it is a
checksum over a pseudo header + UDP data area
Need 4 pieces of info: local host (IP addr), local process (port #), remote host (IP
addr), remote process (port #).
Local process port # can be just about any number (between 0 and 65,535), but
remote process port # has to be fixed, otherwise who would know what it is?
101. UDP versus IP
• UDP (User Datagram Protocol) creates a transport layer connection
between two processes.
• The port number identifies the process, or running application
• So using the port number, UDP directs the packet to the correct
• UDP does little else.
No flow control.
No ack of received packets.
Only error control is if a checksum error is detected, it quietly drops the
102. UDP versus IP
• UDP is a connectionless, unreliable transport protocol.
• It does not add anything to the services of IP except for
providing process-to-process communication, instead of
• Advantages : - Minimal overhead; faster
• UDP works well with apps that have their own error and
• Works well with multicasting, SNMP, and RIP.
104. Well Known TCP/UDP Ports
Port # Protocol Description
21 TCP FTP
22 TCP,UDP SSH
23 TCP Telnet
25 TCP SMTP (Simple Mail Transport Protocol) -
used for e-mail routing between mailservers
80 TCP,UDP HTTP
105. UDP checksum
• Treat segment contents as
sequence of 16-bit integers
• Checksum: 1’s complement of
(1’s complement sum of
• Sender puts checksum value
into UDP checksum field
• Compute checksum of received
• Check if computed checksum
equals checksum field value:
NO - error detected
YES - no error detected. But
maybe errors nonetheless?
More later ….
Goal: detect “errors” (e.g., flipped bits) in transmitted segment
APRIL- MAY 2019 (Compulsory For all)
1(a) What do you mean by encapsulation and de-capsulation in context to TCP operation 2M
(b) Explain the various states of TCP state machine in connection establishment phase and
connection teardown phase
(c) Explain karn’s algorithm 7M
(d) Explain various operations of UDP 7M
APRIL- MAY 2018 (Compulsory For all)
1(a) What do you mean by RTT and RTO, and what is their role ? 2M
Explain three-way handshaking for connection establishment in TCP
(c) Compare Karn’s algorithm with Leaky bucket algorithm 7M
(d) What do you mean by ARQ ? Explain the working of Stop and Wait, Go back N and selective repeat
APRIL- MAY 2017
1(a) Define Socket Address 2M
(b) Compare TCP header with UDP header. List the fields in TCP header that are missing from UDP
header. Give the reason for their absence
(c) What do you mean by send window, Receive window, Shrinking of window and silly window
syndrome in TCP ?
(d) Write and explain token bucket algorithm for congestion control. 7M
APRIL- MAY 2016
1(a) Regulating the amount of data source can send before receiving an acknowledgement from
destination is :
(i) Error control
(ii) Flow Control
(iii) Congestion control
(iv) None of the above
(b) Explain difference between TCP and UDP headers 7M
(c) Explain Sliding window protocol used by TCP for flow control 7M
(d) Write short note on
(i) Leaky bucket algorithm
(ii) Token bucket algorithm