Lecture16 TCPOverview

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

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

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

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

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

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!
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
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
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
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
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

Lecture16 TCPOverview

Uploaded by

Copyright:

Available Formats

Lecture16 TCPOverview

Uploaded by

Document Information

Original Description:

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

Lecture16 TCPOverview

Uploaded by

Copyright:

Available Formats

Overview of TCP

Based on sliding window protocol used at data

Potentially different RTT

need explicit connection establishment and

Potentially long delay in network

need to be prepared for arrival of very old packets

different capacity at destination

to accommodate different amounts of

different network capacity

to be prepared for network congestion

normal size of the TCP header is 20

provides a byte-stream service

record markers are inserted by TCP

does not interpret the contents of the

TCP Segment format

mentioned earlier TCP does not

TCP Segment format

grows larger than the maximum

TCP Segment format

that IP discards packets after a

causes TCP to send the segments?

TCP Segment format

Src Port and Dest Port along with the

TCP Segment format

TCP Segment format

flag field is used to relay information

FIN -- used for connections

RESET flag -- receiver wants to abort

TCP Connection Establishment

connection begins with two actions

(caller) does an active open -- party

connection setup is asymmetric

Why the sequence number ACK is one larger than the

should client and server exchange

TCP state-transition diagram

TCP state-transition diagram

states above ESTABLISHED are

TCP state-transition diagram

TCP state-transition diagram

TCP state-transition diagram

Three possible combinations to go from

A connection in TIME_WAIT state cannot move

TCP state-transition diagram

side responds with an ACK to a FIN from

TCP sliding window

guarantees reliable delivery of data

advertises the size of the sliding

TCP sliding window

cannot acknowledge a byte that

TCP sliding window

data has arrived in-order, NextByteExpected

TCP sliding window

TCP sliding window

throttles the sender by

TCP sliding window

On the receive side to avoid buffer overflow:

TCP sliding window

LastByteRcvd - LastByteRead <= MaxRcvBuffer