1. U-IV : Transport Control Protocol
(TCP)
Dr. D. P.
Mishra
Digitally signed by Dr. D. P. Mishra
DN: cn=Dr. D. P. Mishra, o=durg,
ou=BIT, email=dpmishra@bitdurg.
ac.in, c=IN
Date: 2023.04.29 13:55:38 +05'30'

2. Transport Layer
• Two transport layer protocols supported by the Internet:
 Reliable:
 The Transport Control Protocol (TCP)
 Unreliable
 The Unreliable Datagram Protocol (UDP)
U-IV
Transport
Control
Protocol

3. U-IV
Transport
Control
Protocol
Transport Layer

4. Transport Protocols
• Lowest level end-to-end
protocol.
 Header generated by sender is
interpreted only by the
destination
 Routers view transport header
as part of the payload
7
6
5
7
6
5
Transport
IP
Datalink
Physical
Transport
IP
Datalink
Physical
IP
router
2 2
1 1
U-IV
Transport
Control
Protocol

5. U-IV
Transport
Control
Protocol
Scope of Internet & Transport layer

6. TCP UDP
IP
Hardware
Process Layer
Transport Layer
Network Layer
Data-Link Layer
Process Process
ICMP, ARP
&
RARP
U-IV
Transport
Control
Protocol

7. U-IV
Transport
Control
Protocol
Transport Layer Addressing
Addresses
• Data link layer  MAC address
• Network layer  IP address
• Transport layer  Port number (choose among multiple processes
running on destination host)

8. U-IV
Transport
Control
Protocol
Port Numbers
• 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
machine

9. U-IV
Transport
Control
Protocol
Multiplexing and Demultiplexing
Multiplexing
Sender side may have several
processes that need to send
packets (albeit only 1 transport-
layer protocol)
Demultiplexing
At receiver side, after error
checking and header dropping,
transport-layer delivers each
message to appropriate process

10. U-IV
Transport
Control
Protocol
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]
• Reliable
• Connection-oriented  virtual circuit
• Stream-oriented  users exchange streams of data
• Full duplex  concurrent transfers can take place in both
directions
• Buffered  TCP accepts data and transmits when appropriate
(can be overridden with “push”)

11. TCP Segment /Frame Format
Sequence Number
Acknowledgement number
Options (0 or more 32-bit words)
Checksum Urgent Pointer
Window Size
HL
F
I
N
S
Y
N
R
S
T
P
S
H
A
C
K
U
R
G
Data
32 bits
Source Port Destination Port
U-IV
Transport
Control
Protocol
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
receiver
U-IV
Transport
Control
Protocol

13. TCP Frame Fields (cont’d)
• Window size
 Specifies how many bytes may be sent after the first
acknowledged byte
• Checksum
 Checksums the TCP header and IP address fields
• Urgent Pointer
 Points to urgent data in the TCP data field
U-IV
Transport
Control
Protocol

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
U-IV
Transport
Control
Protocol

15. TCP Connection Establishment
• Three-way Handshake
Host A Host B
U-IV
Transport
Control
Protocol

16. TCP Connection Tear-down
• Two double handshakes:
Host A Host B
A->B
torn down
B->A
torn down
U-IV
Transport
Control
Protocol

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.
U-IV
Transport
Control
Protocol

18. U-IV
Transport
Control
Protocol
Acknowledgements & Timeouts
Sender Receiver
Frame
ACK
Timeout
Time
Sender Receiver
Frame
ACK
Timeout
Frame
ACK
Timeout
Sender Receiver
Frame
ACK
Timeout
Frame
ACK
Timeout
Sender Receiver
Frame
Timeout
Frame
ACK
Timeout
(a) (c)
(b) (d)

19. U-IV
Transport
Control
Protocol
Propagation Delay
• Propagation delay is defined as the delay between
transmission and receipt of packets between
hosts.
• Propagation delay can be used to estimate timeout
period

20. Round Trip Time (RTT)
RTT = Time for packet to arrive at destination
+
Time for ACK to return from destination
Network
Time for data to arrive
Time for ACK to return
U-IV
Transport
Control
Protocol

21. RTT Calculation
Receiver
Sender
RTT
0.9 sec
2.2 sec
RTT = 2.2 sec - 0.9 sec. = 1.3 sec
U-IV
Transport
Control
Protocol

22. Problem with RTT Calculation
Receiver
Sender
Sender Timeout
RTT?
RTT?
U-IV
Transport
Control
Protocol

23. U-IV
Transport
Control
Protocol
Stop-and-Wait Process
• 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
• Example
 1.5Mbps link x 45ms RTT = 67.5Kb (8KB)
 1KB frames implies 1/8th link utilization
Sender Receiver

24. U-IV
Transport
Control
Protocol
Solution: Pipelining via Sliding
Window
• Allow multiple outstanding (un-ACKed) frames
• Upper bound on un-ACKed frames, called window
Sender Receiver
Time
…
…

25. U-IV
Transport
Control
Protocol
Buffering on Sender and
Receiver
• 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
 Flow control
• 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?
 Go-Back-N
 Send all N unACKed packets when a loss is signaled
 Inefficient
 Selective repeat
 Only send specifically unACKed packets
 A bit trickier to implement

26. U-IV
Transport
Control
Protocol
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
 channel busy
 current sequence number out
 next sequence number in
• Header: 3-bit channel num, 1-bit sequence num
 4-bits total
 same as sliding window protocol
• Separates reliability from order

27. U-IV
Transport
Control
Protocol
Stop & wait sequence numbers
Sender Receiver
Timeout
Timeout
Sender Receiver
Timeout
Timeout
(c) (d)
Sender Receiver
(e)
• Simple sequence numbers enable the client to discard duplicate copies of the
same frame
• Stop & wait allows one outstanding frame, requires two distinct sequence
numbers

28. Sliding Window Protocol
U-IV
Transport
Control
Protocol

29. U-IV
Transport
Control
Protocol
Sliding Window Example
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
0
1
2
Sender Receiver
A3
3
4
5
6
A4
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14
0 1 2 3 4 5 6 7 8 9 10 11 12 13 14

30. U-IV
Transport
Control
Protocol
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
Sender Receiver
U-IV
Transport
Control
Protocol

32. TCP Performance (cont)
• Silly Window Syndrome
 Each ACK advertises a small amount of space
 Each segment carries a small amount of data
• Problems:
 Poor use of network bandwidth
 Unnecessary computational overhead
U-IV
Transport
Control
Protocol

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
window advisements
• 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)
U-IV
Transport
Control
Protocol

34. Receive-Side Silly Window
Avoidance Example
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
U-IV
Transport
Control
Protocol

35. Receive-Side Silly Window
Avoidance
• Two approaches:
 Receiver can ACK received octets but does not advertise
an increase in its window until the increase is
significant
 Receiver can not send ACKs when the window is not
large enough to advertise
• Advantages/disadvantages?
U-IV
Transport
Control
Protocol

36. Send-Side Silly
Window Avoidance
• 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
data?
U-IV
Transport
Control
Protocol

37. Send-Side Silly Window Avoidance
(cont)
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
U-IV
Transport
Control
Protocol

38. TCP Summary
• Provides reliable stream delivery service
 Full duplex
 Out-of-band for urgent data
• Makes efficient use of the network
 Piggybacking
 Sliding windows
 Efficiency
 End-to-end flow control
 Acknowledgment and retransmission
 Congestion recovery/avoidance
U-IV
Transport
Control
Protocol

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
programming languages.
Stop-and-Wait ARQ
Go-Back-N ARQ
Selective Repeat ARQ
PROTOCOLS
ARQ’s

42. • It is the simplest flow and error control mechanism .
• A transmitter sends a frame then stops and waits for an
acknowledgment.
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
receiver
• 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
lost
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
receive
 Sequence number is
necessary to check for
duplicated frames
Stop-and-Wait ARQ

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

47. • Importance of frame
numbering
Stop and Wait Lost ACK frame

48. In Stop and-Wait ARQ, numbering frames
prevents the retaining of duplicate frames.

49. Importance
of
frame numbering
Stop and Wait
Delayed ACK and lost frame

50. Numbered acknowledgments are needed if an
acknowledgment is delayed and the next frame
is lost.

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
Piggybacking (Bidirectional
transmission)

52. • After each frame sent the host must wait for
an ACK
• inefficient use of bandwidth
• To improve efficiency ACK should be sent after
multiple frames
• Alternatives: Sliding Window protocol
• Go-back-N ARQ
• Selective Repeat ARQ
Stop-and-Wait ARQ

53. Pipelining: A task is begun before the previous task
has ended
• 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
transmission
Pipelining

54. Sliding window protocols apply Pipelining :
Go-Back-N ARQ
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
acknowledged
• 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

55. Sliding window

56. Go_Back _N ARQ
Sender sliding window
If m = 3; sequence
numbers = 8 and window
size =7
Acknowledged frames

57. Receiver sliding window
 The receive window is an abstract concept defining
an imaginary box of size 1 with one single variable
Rn.
 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
window
SL: holds the sequence number of the last frame
R: sequence number of the frame expected to received
Outstanding frames: frames sent but
not acknowledged
Go-Back-N ARQ

59. Go-Back-N ARQ

60. In Go-Back-N ARQ we use one timer for the first outstanding
frame
 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
Go-Back-N ARQ

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

62. Go-Back-N ARQ
Normal operation
 How many frame scan
be transmitted Without
acknowledgment?
 ACK1 is not necessary
if ACK2 is sent:
Cumulative ACK

63. Go-Back-N ARQ
Damage or Lost Frame
Correctly received out of order packets
are not Buffered
What is the disadvantage of this?

64. Go-Back-N ARQ

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
window.

66. Stop-and-Wait ARQ is a special case of Go-
Back-N ARQ in which the size of the send
window is 1
Note

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
transmission .
Solution:
• 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

68. Selective Repeat ARQ

69. Selective Repeat ARQ
m=3
Sequences no=2m =8 :
0,1,2 ,3,4,5,6,7Window
size =2m/2= 8/2=4
Lost Frame

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.
Note

73. Selective Repeat ARQ
m=2

74. TCP State Machine
U-IV
Transport
Control
Protocol

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.
U-IV
Transport
Control
Protocol

76. U-IV
Transport
Control
Protocol
State Transition Diagram
Typical TCP
states visited by
a TCP client

77. U-IV
Transport
Control
Protocol
State Transition Diagram
Typical TCP
states visited
by a TCP
server

78. TCP State Machine: Connection Establishment
ESTABLISHED
SYN_RCVD
SYN_SENT
CLOSED
LISTEN
client application
calls connect()
send SYN
receive SYN
send SYN + ACK
server application
calls listen()
receive SYN & ACK
send ACK
receive ACK
• CLOSED: more implied than actual,
i.e., no connection
• LISTEN: willing to receive connections
(accept call)
• SYN-SENT: sent a SYN, waiting for
SYN-ACK
• SYN-RECEIVED: received a SYN,
waiting for an ACK of our SYN
• ESTABLISHED: connection ready for
data transfer
receive SYN
send ACK
U-IV
Transport
Control
Protocol

79. TCP State Machine:
Connection Teardown
ESTABLISHED
FIN_WAIT_2
TIME_WAIT
FIN_WAIT_1
LAST_ACK
CLOSE_WAIT
CLOSED
wait 2*MSL
(240 seconds)
receive ACK
receive FIN
send ACK
receive ACK
of FIN
close() called
send FIN
receive FIN
send ACK
• 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
FIN'ed
• 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
CLOSING
receive FIN
send ACK
receive ACK
of FIN
close() called
send FIN
U-IV
Transport
Control
Protocol

80. U-IV Transport Control Protocol
State Transition Diagram 3/4
State Description
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.
FIN-WAIT-1
The application has requested the closing of the
connection.
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
network behavior
• Tries to trade off efficiency with being "good
network citizen"
• Vast majority of bytes transferred on Internet today
are TCP-based:
 Web
 Mail
 News
 Peer-to-peer (Napster, Gnutella, FreeNet, KaZaa)
U-IV
Transport
Control
Protocol

82. Leaky bucket & Token bucket Algorithm
U-IV
Transport
Control
Protocol

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
rate.
U-IV
Transport
Control
Protocol

84. Leaky Bucket Algorithm
U-IV
Transport
Control
Protocol
• 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.
• 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.
U-IV
Transport
Control
Protocol

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.
U-IV
Transport
Control
Protocol
Advantages:
• 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.

87. Karn’s Algorithm
U-IV
Transport
Control
Protocol

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
was lost.
• 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
incorrectly
U-IV
Transport
Control
Protocol

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
U-IV
Transport
Control
Protocol

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?
U-IV
Transport
Control
Protocol

91. Karns’ Algorithm (3)
Karn's algorithm
– 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"
U-IV
Transport
Control
Protocol

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.
U-IV
Transport
Control
Protocol

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)
U-IV
Transport
Control
Protocol

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
3.1 s
Error
= 0.0
= -0.50
= +0.76
= -0.54
= -0.67
Dev.
= 0.00
= 0.13
= 0.28
= 0.35
= 0.43
Timeout
= 1.50
= 1.94
= 2.67
= 2.85
= 3.09
Error = RTT - SRTT
SRTT = SRTT + (a  Error)
Dev = Dev + [d  (|Error| - Dev)]
Timeout = SRTT + (b  Dev)
2.0 s
U-IV
Transport
Control
Protocol

95. UDP
U-IV
Transport
Control
Protocol

96. UDP
• UDP does not provide:
 Connection management
 Flow or error control
 Guaranteed in-order packet delivery
• UDP is almost a “null” transport layer
U-IV
Transport
Control
Protocol

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
protocol
U-IV
Transport
Control
Protocol

98. UDP Characteristics
U-IV
Transport
Control
Protocol
• End-to-End: an application sends/receives data to/from another
application.
• 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
other applications.
• Operating system independent: identifying application does not
depend on O/S.

99. UDP Frame Format
32 bits
Source Port Destination Port
UDP length UDP checksum (optional)
Data
U-IV
Transport
Control
Protocol
• 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

100. U-IV
Transport
Control
Protocol
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
program.
• So using the port number, UDP directs the packet to the correct
location.
• 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
packet.
U-IV
Transport
Control
Protocol

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
host-to-host.
• Advantages : - Minimal overhead; faster
• UDP works well with apps that have their own error and
flow control;
• Works well with multicasting, SNMP, and RIP.
U-IV
Transport
Control
Protocol

103. Well-known UDP Port Numbers
U-IV
Transport
Control
Protocol

104. Well Known TCP/UDP Ports
U-IV
Transport
Control
Protocol
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
Sender:
• Treat segment contents as
sequence of 16-bit integers
• Checksum: 1’s complement of
(1’s complement sum of
segment contents)
• Sender puts checksum value
into UDP checksum field
Receiver:
• Compute checksum of received
segment
• 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
U-IV
Transport
Control
Protocol

106. Questions Appeared in University Exam
U-III
Routing
Protocols
-
Unicast
&
Multicast
106

107. U-III
Routing
Protocols
-
Unicast
&
Multicast
107
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
7M
(c) Explain karn’s algorithm 7M
(d) Explain various operations of UDP 7M

108. U-III
Routing
Protocols
-
Unicast
&
Multicast
108
APRIL- MAY 2018 (Compulsory For all)
1(a) What do you mean by RTT and RTO, and what is their role ? 2M
(b)
Explain three-way handshaking for connection establishment in TCP
7M
(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
ARQ
7M

109. U-III
Routing
Protocols
-
Unicast
&
Multicast
109
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
7M
(c) What do you mean by send window, Receive window, Shrinking of window and silly window
syndrome in TCP ?
7M
(d) Write and explain token bucket algorithm for congestion control. 7M

110. U-III
Routing
Protocols
-
Unicast
&
Multicast
110
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
2M
(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
7M

111. U-III
Routing
Protocols
-
Unicast
&
Multicast
111
APRIL- MAY 2015
1(a) Determine the efficiency of sliding window protocol 2M
(b) Explain go back-N and selective repeat ARQ with flow diagram 7M
(c) Explain the header format of TCP and UDP with pseudo headers 7M
(d) Explain the leaky bucket and token bucket algorithm with example 7M