Overview of TCP

Connection-oriented, byte-stream
sending process writes some number of bytes
TCP breaks into segments and sends via IP
receiving process reads some number of bytes

Overview of TCP

Overview of TCP
Full duplex
Implements both flow and congestion controls
Flow control: keep sender from overrunning
receiver
Congestion control: keep sender from
overrunning network
Flow control is an end-to-end issue and
congestion control is concerned with how hosts
and network interact

Overview of TCP

Based on sliding window protocol used at data

link level, but the situation is very different.
Potentially connects many different hosts

Potentially different RTT

need explicit connection establishment and

termination
need adaptive timeout mechanism

Potentially long delay in network

need to be prepared for arrival of very old packets

Overview of TCP
Potentially

different capacity at destination

need

to accommodate different amounts of

buffering

Potentially
need

TCP header
TCP

data is encapsulated in an IP
datagram

different network capacity

to be prepared for network congestion

The

normal size of the TCP header is 20

bytes, unless options are present

TCP header

TCP services
TCP

provides a byte-stream service

no

record markers are inserted by TCP

if sending application writes 10 bytes, 20
bytes, and 50 bytes --- the receiving
application may receive the 80 bytes in four
reads of 20 bytes
TCP

does not interpret the contents of the

bytes -- ASCII/binary -- same

TCP Segment format

As

mentioned earlier TCP does not

transmit bytes -- although it is a byte
stream based service
Source host buffers enough bytes from the
sending process to fill a reasonably sized
packet
Sends these packets, called segments to
receiver

TCP Segment format

What

segment

grows larger than the maximum

segment size
explicit action by the sending application
trigger by a timer that periodically fires -segment contains as many bytes as are
currently buffered

TCP Segment format

Recall

that IP discards packets after a

packets TTL expires
each TCP packet has a maximum
lifetime -- maximum segment lifetime
(MSL) -- current recommended setting is
120 seconds
This value is not enforced by the IP -- it is
a conservative estimate the TCP makes of
how long a packet might live

causes TCP to send the segments?

TCP Segment format

The

Src Port and Dest Port along with the

IP src/dest addresses identify each TCP
connection
TCPs demux key is
<SrcPort, SrcIPAddr, DestPort,
DestIPAddr>
Because TCP connections come and go, it
is possible for a connection to have
different incarnations

TCP Segment format

The

Acknowledgment, SequenceNumber,
AdvertisedWindow fields are all involved in
TCPs sliding window algorithm
Each data byte has a sequence number
The Sequence Number field contains the #
for the first byte of data
Acknowledgment and AdvertisedWindow
fields carry information about the opposite
flow

TCP Segment format

6-bit

flag field is used to relay information

between TCP peers
SYN,

FIN -- used for connections

flag set to indicate Acknowledgement
field is valid
URG flag set to indicate Urgent data is
contained
ACK

The

RESET flag -- receiver wants to abort

the connection

TCP Connection Establishment

TCP

Three-way handshake

connection begins with two actions

client

(caller) does an active open -- party

wanting to initiate a connection
server (callee) has already done a passive
open -- party willing to accept a connection
Most

connection setup is asymmetric

TCP has an explicit connection setup -both sides should agree on a set of
transmission parameters

Why the sequence number ACK is one larger than the

one sent?
It is the next sequence number expected -- this
implicitly acknowledges all earlier sequence numbers

Three-way handshake
Why

should client and server exchange

starting sequence numbers with each
other?
It should be simpler is each side starts
from 0 -- well known sequence number
Reason: to protect against two
incarnations of a connection reusing the
same sequence numbers too soon

TCP state-transition diagram

TCP state-transition diagram

The

states above ESTABLISHED are

involved in setting up a connection
The states below ESTABLISHED are
involved in terminating a connection
The sliding-window algorithm is hidden in
ESTABLISHED state
all connections start in CLOSED state
Each arc is labeled with a tag of the form
event/action

TCP state-transition diagram

Opening a connection:
server invokes a passive open operation -causing TCP to move to LISTEN state
client does an active open -- send a SYN
segment to server and moves to SYN_SENT
state
when SYN arrives at the server -- server moves
to SYN_RCVD and responds with SYN+ACK
arrival of SYN+ACK at client moves it to
ESTABLISHED -- three way handshake

TCP state-transition diagram

Closing a connection:
application process on both sides of the
connection must independently close its
half of the connection
if one side closes the connection, it has no
more data to send -- will be available to
receive data

TCP state-transition diagram

Three possible combinations to go from

ESTABLISHED to CLOSED
this side closes first: ESTABLISHED -- FIN_WAIT_1 - FIN_WAIT_2 -- TIME_WAIT -- CLOSED
other side closes first: ESTABLISHED -CLOSE_WAIT -- LAST_ACK -- CLOSED
both sides close at the same time: ESTABLISHED -FIN_WAIT_1 -- CLOSING -- TIME_WAIT -- CLOSED

A connection in TIME_WAIT state cannot move

to CLOSED state until it has waited 2*MSL

TCP state-transition diagram

Reason:
local

side responds with an ACK to a FIN from

remote side
in case the ACK is lost, the remote side would
retransmit the FIN again after timeout
if the connection is allowed to move to
CLOSED state -- then there might be another
incarnation of the connection when the FIN for
the earlier connection arrives at the local side
this FIN will close the new incarnation

TCP sliding window

Serves

several purposes:

it

guarantees reliable delivery of data

it ensures data is delivered in order
enforces flow control between sender/receiver
Receiver

advertises the size of the sliding

window -- using the Advertised Window
field in the TCP header
Receiver selects a suitable value so that
its buffer is not overflowed by a fast
sender

TCP sliding window

Receiver

cannot acknowledge a byte that

has not been sent
TCP cant send a byte application has not
written

TCP sliding window

NextByteExpected
if

<= LastByteRcvd + 1

data has arrived in-order, NextByteExpected

points to the byte after LastByteRcvd
if out-of-order arrival, NextBytesExpected
points to the first gap in the data

TCP sliding window

In receiving side:
LastByteRead < NextByteExpected -- byte
cannot be read by the application until it is
received and all preceding bytes are also
received -- NextBytesExpected points to
the byte immediately after the last byte
meeting this criterion

TCP sliding window

Flow control:
sending application is filling its local buffer
receiving application is emptying its buffer
Both buffers have finite size:
MaxSendBuffer

and MaxRcvBuffer

Receiver

throttles the sender by

advertising the window size no larger than
the amount of data it can buffer

TCP sliding window

On the receive side to avoid buffer overflow:

TCP sliding window

LastByteRcvd - LastByteRead <= MaxRcvBuffer

LastByteReceived - LastByteAcked <=

AdvertisedWindow

AdvertisedWindow =
MaxRcvBuffer - (LastByteRcvd - LastByteRead)

This is the amount of free space remaining in the

receive buffer
If the data arrives faster than consumed, this
value decreases with time -- at one time
AdvertisedWindow will be 0 if the receiver falls
behind the sender

On sending side TCP should adhere to the

advertised window it gets from the receiver

EffectiveWindow = AdvertisedWindow (LastByteSent - LastByteAcked)

EffectiveWindow must be greater than 0 before
the sender can send data
Send side must also make sure the local
application does not overflow the send buffer

TCP sliding window

LastByteWritten

- LastByteAcked <=

MaxSendBuffer
if the sending process tries to write y bytes
to TCP and
(LastByteWritten - LastByteAcked) + y >
MaxSendBuffer
TCP blocks
TCP ensures that a slow receiving process
can stop a fast sending process

TCP sliding window

When

advertisedWindow becomes 0 the

sender stops sending data
Because TCP sends a segment only in
response to a received segment -- How
sender know the receiver is ready?
When

receiver advertises a window size of 0,

sender periodically sends a 1 byte segment
this triggers a response -- reports a non-zero
window size
called smart sender/dumb receiver technique

TCP sliding Window Issues

TCPs

sequence is 32-bits wide

TCPs advertised window is 16-bits wide
This satisfies the sliding window algorithm
requirement 232 >> 2 216
However, 32-bit sequence number field
can wrap around -- i.e., a packet with
sequence # x can be sent and after a
while another packet with sequence # x
can be sent

TCP sliding Window Issues

TCP sliding Window Issues

A

packet can survive for MSL time -- 120

seconds
If sequence number wraps around within
120 seconds we have a problem
Sequence # will wrap around if the #s are
consumed very fast -- data is transmitted
very fast
An OC-48 (622Mbps) link can wraparound
sequence #s in 55 seconds

Adaptive Retransmissions in
TCP

Largest

possible data sender could have

in the pipe is determined by the 16-bit
AdvertisedWindow
The advertisedWindow should be large
enough to inject
delay

* bandwidth data into the network

Assuming

a RTT of 100ms for T3 -549Kbytes

16-bit AdvertisedWindow will allow only
64Kbytes!

Adaptive Retransmissions in
TCP
TCP

sets timeout for retransmission as a

function of the estimated RTT
TCP uses an adaptive mechanism to
estimate the RTT
Idea: keep a running average of RTT and
compute timeout as a function of RTT

Adaptive Retransmissions in
TCP
TimeOut

= 2 x EstimatedRTT

Karn/Partridge Algorithm:

EstimatedR TT = EstimatedR TT + (1 ) SampleRTT

is selected to smooth EstimatedRTT -original TCP spec. recommends a setting

between 0.8 and 0.9

Adaptive Retransmissions in
TCP
The

RTT estimation process should not

consider the sampleRTT when a
retransmission occurs
As shown above, precise measurement of
sampleRTT becomes difficult due to the
ambiguity in matching the ACKs with the
transmissions

Adaptive Retransmissions in
TCP
Jacobson/Karels Algorithm
Only the aspect of the algorithm that deals with
timeout and retransmit is discussed here
Main problem with the original scheme
it does not consider the variation of the sampleRTTs
into account
if the variation is small, then EstimatedRTT can be
better trusted
if large variation then, timeout should not be tightly
coupled to EstimatedRTT

10

Adaptive Retransmissions in
TCP

Difference = SampleRTT - EstimatedRTT

EstimatedRTT = EstimatedRTT + ( x
Difference)
Deviation = Deviation + (|Difference| Deviation)
is a fraction between 0 and 1

Timeout = x EstimatedRTT + x Deviation

is typicall 1, is set to 4

TCP Extensions
TCP timeout estimation:
TCP reads the actual system clock and
puts it in the segment header
Receiver echo the timestamp back to the
sender
Sender can estimate the RTT by
subtracting the current time from the
received timestamp

TCP Extensions
Measuring

RTT, sequence number wrap

around, and keeping the pipe full are some
of issues with TCP
Extensions have been proposed to
address these issues

TCP Extensions
Sequence number wrap around:
Two segments with the same sequence
number
Differentiate the two segments by putting
the timestamp value in the option field
Timestamps monotonically increasing;
helps in distinguishing the segments

11

TCP Extensions
Larger Pipe:
AdvertisedWindow may not be sufficient to
fully utilize the pipe -- Delay * bandwidth
product may very large compared to the
AdvertisedWindow
We can use a scaling factor
AdvertisedWindow is left shifted by that
many places before using its contents

12