Transmission Control Protocol (TCP)

Chapter 15
Transmission
Control
Protocol
(TCP)
TCP/IP Protocol Suite 1

Copyright © The McGraw-Hill Companies, Inc. Permission required for reproduction or display.
OBJECTIVES:
 To introduce TCP as a protocol that provides reliable stream
delivery service.
 To define TCP features and compare them with UDP features.
 To define the format of a TCP segment and its fields.
 To show how TCP provides a connection-oriented service, and
show the segments exchanged during connection establishment
and connection termination phases.
 To discuss the state transition diagram for TCP and discuss
some scenarios.
 To introduce windows in TCP that are used for flow and error
control.

OBJECTIVES (continued):
 To discuss how TCP implements flow control in which the
receive window controls the size of the send window.
 To discuss error control and FSMs used by TCP during the data
transmission phase.
 To discuss how TCP controls the congestion in the network using
different strategies.
 To list and explain the purpose of each timer in TCP.
 To discuss options in TCP and show how TCP can provide
selective acknowledgment using the SACK option.
 To give a layout and a simplified pseudocode for the TCP
package.

15.1 TCP Services
Chapter
15.2 TCP Features
Outline
15.3 Segment
15.4 A TCP Connection
15.5 State Transition Diagram
15.6 Windows in TCP
15.7 Flow Control
15.8 Error Control
15.9 Congestion Control
15.10 TCP Timers
15.11 Options
TCP/IP Protocol Suite
15.12 TCP Package 4
15-1 TCP SERVICES
Figure 15.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.

Topics Discussed in the Section
 Process-to-Process Communication
 Stream Delivery Service
 Full-Duplex Communication
 Multiplexing and Demultiplexing
 Connection-Oriented Service
 Reliable Service

Figure 15.1 TCP/IP protocol suite

Figure 15.2 Stream delivery

Figure 15.3 Sending and receiving buffers
Stream of bytes

Figure 15.4 TCP segments
Segment N Segment 1
H H

15-2 TCP FEATURES
To provide the services mentioned in the previous

section, TCP has several features that are briefly
summarized in this section and discussed later in
detail.

 Numbering System
 Flow Control
 Error Control
 Congestion Control

Note
The bytes of data being transferred in

each connection are numbered by TCP.
The numbering starts with an arbitrarily

generated number.

Example 15.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:

Note
The value in the sequence number

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

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.

15-3 SEGMENT
Before discussing TCP in more detail, let us discuss the

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

 Format
 Encapsulation

Figure 15.5 TCP segment format

Figure 15.6 Control field

Figure 15.7 Pseudoheader added to the TCP segment

Figure 15.8 Encapsulation
TCP
Application-layer data
header
IP
header
Frame
header
TCP payload
IP payload
Data-link layer payload

15-4 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 then sent over this virtual
path. You may wonder how TCP, which uses the
services of IP, a connectionless protocol, can be
connection-oriented. The point is that a TCP connection
is virtual, not physical. TCP operates at a higher level.
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.
 Connection Establishment
 Data Transfer
 Connection Termination
 Connection Reset

Figure 15.9 Connection establishment using three-way handshake
Passive
Active open
open seq: 8000
UAPRS F
SYN
seq: 15000
Connection ack: 8001
opened nd: 5000
U A P R S F rw
SYN + ACK
seq: 8000
ack: 15001
UAPRS F
rwnd: 10000
ACK
Means “no data” !

Note
A SYN segment cannot carry data, but it

consumes one sequence number.

Note
A SYN + ACK segment cannot carry

data, but does consume one
sequence number.

Note
An ACK segment, if carrying no data,

consumes no sequence number.

Figure 15.10 Data Transfer
seq: 8001
Send
request ack: 15001
UAPRS F
Data Receive
bytes: 8001-9
000
Send seq: 9001

request ack: 15001
UAPRS F
Data Receive
bytes: 9001-1
0000
seq: 15001 Send

ack: 10001 request
Pushing data UAPRS F

Data
17000
bytes: 15001-
Urgent data
seq: 10000
ack: 17001
UAPRS F
rwnd:10000
Connection Termination

Figure 15.11 Connection termination using three-way handshake

Note
The FIN segment consumes one

sequence number if it does
not carry data.

Note
The FIN + ACK segment consumes one

sequence number if it does
not carry data.

Figure 15.12 Half-Close

15-6 WINDOWS IN TCP
Before discussing data transfer in TCP and the issues

such as flow, error, and congestion control, we describe
the windows used 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.

 Send Window
 Receive Window

Figure 15.22 Send window in TCP

Figure 15.23 Receive window in TCP

15-7 FLOW CONTROL
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.

 Opening and Closing Windows
 Shrinking of Windows
 Silly Window Syndrome

Figure 15.24 TCP/IP protocol suite
Messages Flow control

are pushed
1 5 3 Messages
feedback are pulled
2
Segements are pushed
4
Flow control feedback

Figure 15.25 An example of flow control

Example 15.2
Figure 15.26 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.
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.
Figure 15.26 Example 15.2
Prevent the shrinking of the send window:

new ackNo + new rwnd >= last ackNo + last rwnd
210

Silly Window Syndrome (1)
 Sending data in very small segments
1. Syndrome created by the Sender
– Sending application program creates data
slowly (e.g. 1 byte at a time)
– Wait and collect data to send in a larger block
– How long should the sending TCP wait?
– Solution: Nagle’s algorithm
– Nagle’s algorithm takes into account (1) the
speed of the application program that creates
the data, and (2) the speed of the network
that transports the data

 Nagles’s Algorithm
1. The sending TCP sends the first piece of data it
receives from the sending application program even
if it is only 1 byte.
2. After sending the first segment, the sending TCP
accumulates data in the output buffer and waits
until either the receiving TCP sends an
acknowledgment or until enough data has
accumulated to fill a maximum-size segment. At this
time, the sending TCP can send the segment.
3. Step 2 is repeated for the rest of the transmission.

2. Syndrome created by the Receiver
– Receiving application program consumes data
slowly (e.g. 1 byte at a time)
– The receiving TCP announces a window size of
1 byte. The sending TCP sends only 1 byte…
– Solution 1: Clark’s solution
– Sending an ACK but announcing a window size
of zero until there is enough space to
accommodate a segment of max. size or until
half of the buffer is empty

– Solution 2: Delayed Acknowledgement
– The receiver waits until there is decent
amount of space in its incoming buffer before
acknowledging the arrived segments
– The delayed acknowledgement prevents the
sending TCP from sliding its window. It also
reduces traffic.
– Disadvantage: it may force the sender to
retransmit the unacknowledged segments
– To balance: should not be delayed by more
than 500ms

15-8 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.

 Checksum
 Acknowledgment
 Retransmission
 Out-of-Order Segments
Some Scenarios

Rules for Generating ACK (1)
– 1. When one end sends a data segment to the
other end, it must include an ACK. That gives
the next sequence number it expects to
receive. (Piggyback)
– 2. The receiver needs to delay sending (until
another segment arrives or 500ms) an ACK
segment if there is only one outstanding in-
order segment. It prevents ACK segments
from creating extra traffic.
– 3. There should not be more than 2 in-order
unacknowledged segments at any time. It
prevent the unnecessary retransmission

Rules for Generating ACK (2)
– 4. When a segment arrives with an out-of-
order sequence number that is higher than
expected, the receiver immediately sends an
ACK segment announcing the sequence number
of the next expected segment. (for fast
retransmission)
– 5. When a missing segment arrives, the
receiver sends an ACK segment to announce
the next sequence number expected.
– 6. If a duplicate segment arrives, the receiver
immediately sends an ACK.

Figure 15.29 Normal operation

Figure 15.30 Lost segment

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.

Note
The receiver TCP delivers only ordered

data to the process.

Figure 15.31 Fast retransmission

Figure 15.31 Fast retransmission

Figure 15.32 Automatically correct Lost acknowledgment

Figure 15.33 Lost acknowledgment corrected by resending a segment

Figure 15.33 Lost acknowledgment may create deadlock

Note
Lost acknowledgments may create

deadlock if they are not
properly handled.

15-9 CONGESTION CONTROL
TCP uses a congestion window and a congestion policy

that avoid congestion and detect and alleviate congestion
after it has occurred.

 Congestion Window
 Congestion Policy

CONGESTION Window
The sender has two pieces of information: the

receiver-advertised window size and the congestion
window size.
Actual window size = minimum (rwnd, cwnd)

CONGESTION POLICY
 Three phases:
o Slow start
o Congestion avoidance
o Congestion detection
 In the slow start phase, the sender starts with a
slow rate of transmission, but increases the rate
rapidly to reach a threshold.
 When the threshold is reached, the rate of increase
is reduced.

Figure 15.34 Slow start, exponential increase
1
cwnd
RTT
2
cwnd
RTT
4
cwnd
RTT
8
cwnd

Note
In the slow start algorithm, the size of

the congestion window increases
exponentially until it reaches a
threshold.

CONGESTION AVOIDANCE
If we start with the slow start algorithm, the size of

the congestion window increases exponentially.
To avoid congestion before it happens, one must slow

down this exponential growth.
TCP defines another algorithm called congestion

avoidance, which increases the cwnd additively
instead of exponentially.

Figure 15.35 Congestion avoidance, additive increase

Note
In the congestion avoidance algorithm

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

CONGESTION DETECTION:
Multiplicative decrease
 If congestion occurs, the congestion window size
must be decreased.
 The only way a sender can guess that congestion
has occurred is the need to retransmit a segment.
 Retransmission can occur in one of two cases:
 When the RTO timer times out.
 When three duplicate ACKs are received.
 In both cases, the size of the threshold is

dropped to half (multiplicative decrease).

Multiplicative decrease (Cont…)
1. If a time-out occurs, there is a stronger
possibility of congestion; In this case TCP reacts
strongly:
a. It sets the value of the threshold to half
of the current window size.
b. It reduces cwnd back to one segment.
c. It starts the slow start phase again.

Multiplicative decrease (Cont…)
2. If three duplicate ACKs are received, there is a
weaker possibility of congestion; In this case,
TCP has a weaker reaction as shown below:
a. It sets the value of the threshold to half
of the current window size.
b. It sets cwnd to the value of the threshold
c. It starts the congestion avoidance phase.

Figure 15.36 TCP Congestion policy summary

Figure 15.37 Congestion example

15-10 TCP TIMERS
To perform its operation smoothly, most TCP

implementations use at least four timers as shown in
Figure 15.38 (slide 83).

 Retransmission Timer
 Persistence Timer
 Keepalive Timer
 TIME-WAIT Timer

Figure 15.38 TCP timers

Retransmission Timer
To retransmit lost segments, TCP employs one

retransmission timer that handles the
retransmission time-out (RTO), the waiting time
for an acknowledgment of a segment

Round Trip Time (RTT)
To calculate the retransmission time-out (RTO),

we first need to calculate the roundtrip time
(RTT).

Measured Round Trip Time (RTT)
We need to find how long it takes to send a

segment and receive an acknowledgment for it.
This is the measured RTT.
We use the notation RTTM to stand for measured

RTT.

Note
In TCP, there can be only one RTT

measurement in progress at any time.

Smoothed Round Trip Time (RTT)
The measured RTT, RTTM, is likely to change for

each round trip.
The fluctuation is so high in today’s Internet that

a single measurement alone cannot be used for
retransmission time-out purposes
A smoothed RTT, called RTTS, is a weighted

average of RTTM and the previous RTTS
Calculation of RTO (1)
• Smoothed RTT: RTTS
– Original  No value
– After 1st measurement  RTTS = RTTM
– 2nd …  RTTS = (1-)*RTTS + *RTTM

• RTT Deviation : RTTD
– Original  No value
– After 1st measurement  RTTD = 0.5*RTTM
– 2nd …  RTTD = (1-)*RTTD + *|RTTS - RTTM|
The value of β is also implementation-dependent,

but is usually is set to 1/4.

• Retransmission Timeout (RTO)
– Original  Initial value
– After any measurement
 RTO = RTTS + 4RTTD
• Example 10 (page 322)
–  = 1/8
–  = 1/4

Example 15.3
Let us give a hypothetical example. Figure 15.39 shows part of a
connection. The figure shows the connection establishment and
part of the data transfer phases.
1. When the SYN segment is sent, there is no value for RTTM,
RTTS, or RTTD. The value of RTO is set to 6.00 seconds. The
following shows the value of these variable at this moment:
2. When the SYN+ACK segment arrives, RTTM is measured

and is equal to 1.5 seconds.
RTTs = RTTM
RTTD = RTTM * 1/2
RTO = RTTS + 4RTTD


Example 15.3 Continued
3. When the first data segment is sent, a new RTT measurement
starts. No RTT measurement starts for the second data
segment because a measurement is already in progress. The
arrival of the last ACK segment is used to calculate the next
value of RTTM. Although the last ACK segment acknowledges
both data segments (cumulative), its arrival finalizes the value
of RTTM for the first segment. The values of these variables
are now as shown below.
 = 1/8 ,  = 1/4
RTTS = (1-)*RTTS + *RTTM
RTTD = (1-)*RTTD + *|RTTS - RTTM|
RTO = RTTS + 4RTTD


Karn’s Algorithm
Suppose that a segment is not acknowledged during the

retransmission timeout period and is therefore
retransmitted. When the sending TCP receives an
acknowledgment for this segment, it does not know if
the acknowledgment is for the original segment or for
the retransmitted one.
However, if the original segment was lost and the

acknowledgment is for the retransmitted one, the value
of the current RTT must be calculated from the time the
segment was retransmitted.
Karn’s Algorithm Cont….
This ambiguity was solved by Karn.
Do not consider the round-trip time of a retransmitted

segment in the calculation of RTTs.
Do not update the value of RTTs until you send a

segment and receive an acknowledgment without the
need for retransmission.

Note
TCP does not consider the RTT of a

retransmitted segment in its
calculation of a new RTO.

Exponential Backoff
What is the value of RTO if a retransmission occurs?
Most TCP implementations use an exponential backoff

strategy.
The value of RTO is doubled for each retransmission.

So if the segment is retransmitted once, the value is two
times the RTO.
If it is transmitted twice, the value is four times the RTO,

and so on.
Example 15.4
Figure 15.40 is a continuation of the previous example. There is
retransmission and Karn’s algorithm is applied.
The first segment in the figure is sent, but lost. The RTO timer
expires after 4.74 seconds. The segment is retransmitted and the
timer is set to 9.48, twice the previous value of RTO. This time an
ACK is received before the time-out. We wait until we send a new
segment and receive the ACK for it before recalculating the RTO
(Karn’s algorithm).


Persistence Timer
To deal with a zero-window-size advertisement, TCP

needs another timer.
If the receiving TCP announces a window size of zero,
the sending TCP stops transmitting segments until the
receiving TCP sends an ACK segment announcing a
nonzero window size.
This ACK segment can be lost.
Both TCPs might continue to wait for each other forever
(a deadlock).
To correct this deadlock, TCP uses a persistence timer
When zero window size is received.
Persistence Timer Cont…
When the sending TCP receives an acknowledgment

with a window size of zero, it starts a persistence timer.
When the persistence timer goes off, the sending TCP

sends a special segment called a probe. This segment
contains only 1 byte of new data. The probe causes the
receiving TCP to resend the acknowledgment.
The value of the persistence timer is set to the value of

the retransmission time.
If a response is not received from the receiver, another
probe segment
TCP/IP Protocol Suite is sent 98
Keep Alive Timer
A keepalive timer is used to prevent a long idle

connection between two TCPs.
Suppose that a client opens a TCP connection to a
server, transfers some data, and becomes silent.
Perhaps the client has crashed and connection remains
open.
Server has a keepalive timer that is reset when it hears
from client.The time-out is usually 2 hours.
If the server does not hear from the client after 2 hours,
it sends a probe segment. If there is no response after
10 probes, each of which is 75 s apart, it assumes
that the client
TCP/IP Protocol Suite is down and terminates the connection. 99
Time Wait
If the last ACK segment is lost, the server TCP, which

sets a timer for the last FIN, assumes that its FIN is
lost and resends it.
If the client goes to the CLOSED state and closes the
connection, it never receives this resent FIN segment.
Consequently, the server never receives the final ACK.
The server cannot close the connection.
The Time Wait makes the client wait for a duration
that is enough time for an ACK to be lost and a FIN to
arrive.

Transmission Control Protocol (TCP)

Uploaded by

Copyright:

Available Formats

Transmission Control Protocol (TCP)

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Transmission Control Protocol (TCP)

Uploaded by

Copyright:

Available Formats

Chapter 15

TCP/IP Protocol Suite 1

TCP/IP Protocol Suite 2

TCP/IP Protocol Suite 3

Figure 15.1 shows the relationship of TCP to the other

TCP/IP Protocol Suite 5

TCP/IP Protocol Suite 6

TCP/IP Protocol Suite 7

TCP/IP Protocol Suite 8

TCP/IP Protocol Suite 9

TCP/IP Protocol Suite 10

To provide the services mentioned in the previous

TCP/IP Protocol Suite 11

TCP/IP Protocol Suite 12

The bytes of data being transferred in

The numbering starts with an arbitrarily

TCP/IP Protocol Suite 13

TCP/IP Protocol Suite 14

The value in the sequence number

TCP/IP Protocol Suite 15

The value of the acknowledgment field

The acknowledgment number is

TCP/IP Protocol Suite 16

Before discussing TCP in more detail, let us discuss the

TCP/IP Protocol Suite 17

TCP/IP Protocol Suite 18

TCP/IP Protocol Suite 19

TCP/IP Protocol Suite 20

TCP/IP Protocol Suite 21

TCP/IP Protocol Suite 22

TCP/IP Protocol Suite 24

Means “no data” !

TCP/IP Protocol Suite 25

A SYN segment cannot carry data, but it

TCP/IP Protocol Suite 26

A SYN + ACK segment cannot carry

TCP/IP Protocol Suite 27

An ACK segment, if carrying no data,

TCP/IP Protocol Suite 28

Send seq: 9001

seq: 15001 Send

Pushing data UAPRS F

TCP/IP Protocol Suite 29

TCP/IP Protocol Suite 30

The FIN segment consumes one

TCP/IP Protocol Suite 31

The FIN + ACK segment consumes one

TCP/IP Protocol Suite 32

TCP/IP Protocol Suite 33

Before discussing data transfer in TCP and the issues

TCP/IP Protocol Suite 34

TCP/IP Protocol Suite 35

TCP/IP Protocol Suite 36

TCP/IP Protocol Suite 37

Flow control balances the rate a producer creates data

TCP/IP Protocol Suite 38

TCP/IP Protocol Suite 39

Messages Flow control

TCP/IP Protocol Suite 40