Chapter 15 PDF

Download as pdf or txt
Download as pdf or txt
You are on page 1of 132

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.

TCP/IP Protocol Suite 2


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.

TCP/IP Protocol Suite 3


15.1 TCP
Chapter
Services
15.2 TCP
Outline Features
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 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.

TCP/IP Protocol Suite 5


Topics Discussed in the Section

✔ Process-to-Process Communication
✔ Stream Delivery Service
✔ Full-Duplex Communication
✔ Multiplexing and Demultiplexing
✔ Connection-Oriented Service
✔ Reliable Service

TCP/IP Protocol Suite 6


Figure 15.1 TCP/IP protocol suite

TCP/IP Protocol Suite 7


TCP/IP Protocol Suite 8
Figure 15.2 Stream delivery

TCP/IP Protocol Suite 9


Figure 15.3 Sending and receiving buffers

TCP/IP Protocol Suite 10


Figure 15.4 TCP segments

TCP/IP Protocol Suite 11


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.

TCP/IP Protocol Suite 12


Topics Discussed in the Section

✔ Numbering System
✔ Flow Control
✔ Error Control
✔ Congestion Control

TCP/IP Protocol Suite 13


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 14


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:

TCP/IP Protocol Suite 15


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 16


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 17


15-3 SEGMENT

Before discussing TCP in more detail, let us


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

TCP/IP Protocol Suite 18


Topics Discussed in the Section

✔ Format
✔ Encapsulation

TCP/IP Protocol Suite 19


Figure 15.5 TCP segment format

TCP/IP Protocol Suite 20


Figure 15.6 Control field

TCP/IP Protocol Suite 21


Figure 15.7 Pseudoheader added to the TCP segment

TCP/IP Protocol Suite 22


Note

The use of the checksum in TCP is


mandatory.

TCP/IP Protocol Suite 23


Figure 15.8 Encapsulation

TCP/IP Protocol Suite 24


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.
TCP/IP Protocol Suite 25
Topics Discussed in the Section

✔ Connection Establishment
✔ Data Transfer
✔ Connection Termination
✔ Connection Reset

TCP/IP Protocol Suite 26


Figure 15.9 Connection establishment using three-way handshake

Means “no data” !


seq: 8001 if piggybacking
TCP/IP Protocol Suite 27
Note

A SYN segment cannot carry data, but it


consumes one sequence number.

TCP/IP Protocol Suite 28


Note

A SYN + ACK segment cannot carry


data, but does consume one
sequence number.

TCP/IP Protocol Suite 29


Note

An ACK segment, if carrying no data,


consumes no sequence number.

TCP/IP Protocol Suite 30


Figure 15.10 Data Transfer

Pushing data
Urgent data

TCP/IP Protocol Suite 31


Figure 15.11 Connection termination using three-way handshake

TCP/IP Protocol Suite 32


Note

The FIN segment consumes one


sequence number if it does
not carry data.

TCP/IP Protocol Suite 33


Note

The FIN + ACK segment consumes one


sequence number if it does
not carry data.

TCP/IP Protocol Suite 34


Figure 15.12 Half-Close

TCP/IP Protocol Suite 35


15-5 STATE TRANSITION DIAGRAM

To keep track of all the different events


happening during connection establishment,
connection termination, and data transfer, TCP
is specified as the finite state machine shown in
Figure 15.13.

TCP/IP Protocol Suite 36


Topics Discussed in the Section

✔ Scenarios

TCP/IP Protocol Suite 37


Figure 15.13 State transition diagram

TCP/IP Protocol Suite 38


Note

The state marked as ESTBLISHED


in the FSM is in fact two different
sets of states that the client
and server undergo to transfer data.

TCP/IP Protocol Suite 39


TCP/IP Protocol Suite 40
Figure 15.14 Transition diagram for connection and half-close termination

TCP/IP Protocol Suite 41


Figure 15.15 Time-line diagram for Figure 15.14

1. Enough time for an ACK to be


lost and a new FIN to arrive. If
during the TIME-WAIT state, a
new FIN arrives, the client
sends a new ACK and restarts
the 2MSL timer
2. To prevent a duplicate segment
from one connection appearing
in the next one, TCP requires
that incarnation cannot take
place unless 2MSL amount of
time has elapsed.
Another solution: the ISN of the
incarnation is greater than the
last seq. # used in the previous
connection.

TCP/IP Protocol Suite 42


Figure 15.16 Transition diagram for a common scenario

TCP/IP Protocol Suite 43


Figure 15.17 Time line for a common scenario

TCP/IP Protocol Suite 44


Figure 15.18 Simultaneous open

TCP/IP Protocol Suite 45


Figure 15.19 Simultaneous close

ex

TCP/IP Protocol Suite 46


Figure 15.20 Denying a connection

TCP/IP Protocol Suite 47


Figure 15.21 Aborting a connection

TCP/IP Protocol Suite 48


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.
TCP/IP Protocol Suite 49
Topics Discussed in the Section

✔ Send Window
✔ Receive Window

TCP/IP Protocol Suite 50


Figure 15.22 Send window in TCP

TCP/IP Protocol Suite 51


Figure 15.23 Receive window in TCP

TCP/IP Protocol Suite 52


15-7 FLOW CONTROL

As discussed in Chapter 13, 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 15.24 shows unidirectional
data transfer between a sender and a receiver;
bidirectional data transfer can be deduced from
unidirectional one as discussed in Chapter 13.
TCP/IP Protocol Suite 53
Topics Discussed in the Section

✔ Opening and Closing Windows


✔ Shrinking of Windows
✔ Silly Window Syndrome

TCP/IP Protocol Suite 54


Figure 15.24 TCP/IP protocol suite

TCP/IP Protocol Suite 55


Figure 15.25 An example of flow control

TCP/IP Protocol Suite 56


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. 57
TCP/IP Protocol Suite
Figure 15.26 Example 15.2

Prevent the shrinking of the send window:


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

210

TCP/IP Protocol Suite 58


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

TCP/IP Protocol Suite 59


Silly Window Syndrome (2)
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

TCP/IP Protocol Suite 60


Silly Window Syndrome (3)
– 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

TCP/IP Protocol Suite 61


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.

TCP/IP Protocol Suite 62


Topics Discussed in the Section

✔ Checksum
✔ Acknowledgment
✔ Retransmission
✔ Out-of-Order Segments
✔ FSMs for Data Transfer in TCP
✔ Some Scenarios

TCP/IP Protocol Suite 63


Note

ACK segments do not consume


sequence numbers and
are not acknowledged.

TCP/IP Protocol Suite 64


Acknowledgement Type
– In the past, TCP used only one type of
acknowledgement: Accumulative
Acknowledgement (ACK), also namely
accumulative positive acknowledgement
– More and more implementations are adding
another type of acknowledgement: Selective
Acknowledgement (SACK), SACK is
implemented as an option at the end of the
TCP header.

TCP/IP Protocol Suite 65


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 66


Note

TCP can be best modeled as a


Selective Repeat protocol.

TCP/IP Protocol Suite 67


Figure 15.27 Simplified FSM for sender site

TCP/IP Protocol Suite 68


Figure 15.28 Simplified FSM for the receiver site

TCP/IP Protocol Suite 69


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

TCP/IP Protocol Suite 70


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.

TCP/IP Protocol Suite 71


Figure 15.29 Normal operation

TCP/IP Protocol Suite 72


Figure 15.30 Lost segment

TCP/IP Protocol Suite 73


Note

The receiver TCP delivers only ordered


data to the process.

TCP/IP Protocol Suite 74


Figure 15.31 Fast retransmission

TCP/IP Protocol Suite 75


Figure 15.32 Lost acknowledgment

TCP/IP Protocol Suite 76


Figure 15.33 Lost acknowledgment corrected by resending a segment

TCP/IP Protocol Suite 77


Note

Lost acknowledgments may create


deadlock if they are not
properly handled.

TCP/IP Protocol Suite 78


15-9 CONGESTION CONTROL

We discussed congestion control in Chapter 13.


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.

TCP/IP Protocol Suite 79


Topics Discussed in the Section

✔ Congestion Window
✔ Congestion Policy

TCP/IP Protocol Suite 80


Figure 15.34 Slow start, exponential increase

TCP/IP Protocol Suite 81


Note

In the slow start algorithm, the size of


the congestion window increases
exponentially until it reaches a
threshold.

TCP/IP Protocol Suite 82


Figure 15.35 Congestion avoidance, additive increase

TCP/IP Protocol Suite 83


Note

In the congestion avoidance algorithm


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

TCP/IP Protocol Suite 84


Figure 15.36 TCP Congestion policy summary

TCP/IP Protocol Suite 85


Figure 15.37 Congestion example

TCP/IP Protocol Suite 86


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

TCP/IP Protocol Suite 87


Topics Discussed in the Section

✔ Retransmission Timer
✔ Persistence Timer
✔ Keepalive Timer
✔ TIME-WAIT Timer

TCP/IP Protocol Suite 88


Figure 15.38 TCP timers

TCP/IP Protocol Suite 89


Note

In TCP, there can be only one RTT


measurement in progress at any time.

Since the segments and their ACKs do not


have a 1-1 relationship

TCP/IP Protocol Suite 90


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|

TCP/IP Protocol Suite 91


Calculation of RTO (2)
• Retransmission Timeout (RTO)
– Original 🡪 Initial value
– After any measurement
🡪 RTO = RTTS + 4RTTD

• Example 10 (page 322)


– α = 1/8
– β = 1/4

TCP/IP Protocol Suite 92


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.

TCP/IP Protocol Suite 93


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.

TCP/IP Protocol Suite 94


Figure 15.39 Example 15.3

TCP/IP Protocol Suite 95


Note

TCP does not consider the RTT of a


retransmitted segment in its
calculation of a new RTO.

TCP/IP Protocol Suite 96


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

TCP/IP Protocol Suite 97


Figure 15.40 Example 15.4

TCP/IP Protocol Suite 98


15-11 OPTIONS

The TCP header can have up to 40 bytes of


optional information. Options convey additional
information to the destination or align other
options. We can define two categories of options:
1-byte options and multiple-byte options. The first
category contains two types of options: end of
option list and no operation. The second category,
in most implementations, contains five types of
options: maximum segment size, window scale
factor, timestamp, SACK-permitted, and SACK (see
Figure 15.41).
TCP/IP Protocol Suite 99
Figure 15.41 Options

TCP/IP Protocol Suite 100


Figure 15.42 End-of-option option

TCP/IP Protocol Suite 101


Note

EOP can be used only once.

TCP/IP Protocol Suite 102


Figure 15.43 No-operation option

TCP/IP Protocol Suite 103


Note

NOP can be used more than once.

TCP/IP Protocol Suite 104


Figure 15.44 Minimum-segment-size option

TCP/IP Protocol Suite 105


Note

The value of MSS is determined during


connection establishment and does
not change during the connection.

TCP/IP Protocol Suite 106


Figure 15.45 Window-scale-factor option

TCP/IP Protocol Suite 107


Note

The value of the window scale factor can


be determined only during connection
establishment; it does not change
during the connection.

TCP/IP Protocol Suite 108


Figure 15.46 Timestamp option

TCP/IP Protocol Suite 109


Note

One application of the timestamp option


is the calculation of round-trip
time (RTT).

TCP/IP Protocol Suite 110


Example 15.5
Figure 15.47 shows an example that calculates the
round-trip time for one end. Everything must be flipped if
we want to calculate the RTT for the other end.

TCP/IP Protocol Suite 111


Figure 15.47 Example 15.5

TCP/IP Protocol Suite 112


Note

The timestamp option can also be used


for PAWS.

TCP/IP Protocol Suite 113


Figure 15.48 SACK

TCP/IP Protocol Suite 114


Example 15.6
Let us see how the SACK option is used to list out-of-order
blocks. In Figure 15.49 an end has received five segments
of data.

TCP/IP Protocol Suite 115


Figure 15.49 Example 15.6

TCP/IP Protocol Suite 116


Example 15.7
Figure 15.50 shows how a duplicate segment can be
detected with a combination of ACK and SACK. In this case,
we have some out-of-order segments (in one block) and
one duplicate segment. To show both out-of-order and
duplicate data, SACK uses the first block, in this case, to
show the duplicate data and other blocks to show
out-of-order data. Note that only the first block can be used
for duplicate data. The natural question is how the sender,
when it receives these ACK and SACK values, knows that
the first block is for duplicate data (compare this example
with the previous example). The answer is that the bytes in
the first block are already acknowledged in the ACK field;
therefore, this block must be a duplicate.

TCP/IP Protocol Suite 117


Figure 15.50 Example 15.7

TCP/IP Protocol Suite 118


Example 15.8
Figure 15.51 shows what happens if one of the segments in
the out-of-order section is also duplicated. In this example,
one of the segments (4001:5000) is duplicated.

The SACK option announces this duplicate data first and
then the out-of-order block. This time, however, the
duplicated block is not yet acknowledged by ACK, but
because it is part of the out-of-order block (4001:5000 is
part of 4001:6000), it is understood by the sender that it
defines the duplicate data.

TCP/IP Protocol Suite 119


Figure 15.51 Example 15.8

TCP/IP Protocol Suite 120


15-12 TCP PACKAGE

The TCP header can have up to 40 bytes of


optional information. Options convey additional
information to the destination or align other
options. We can define two categories of options:
1-byte options and multiple-byte options. The first
category contains two types of options: end of
option list and no operation. The second category,
in most implementations, contains five types of
options: maximum segment size, window scale
factor, timestamp, SACK-permitted, and SACK (see
Figure 15.41).
TCP/IP Protocol Suite 121
Topics Discussed in the Section

✔ Transmission Control Block TCBs


✔ Timers
✔ Main Module
✔ Input Processing Module
✔ Output Processing Module

TCP/IP Protocol Suite 122


Figure 15.52 TCBs

TCP/IP Protocol Suite 123


Figure 15.53 TCP/IP protocol suite

TCP/IP Protocol Suite 124


TCP/IP Protocol Suite 125
TCP/IP Protocol Suite 126
TCP/IP Protocol Suite 127
TCP/IP Protocol Suite 128
TCP/IP Protocol Suite 129
TCP/IP Protocol Suite 130
TCP/IP Protocol Suite 131
TCP/IP Protocol Suite 132

You might also like

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy