Lecture16-TCPOverview

8/18/2019 Lecture16-TCPOverview

1/12

1

Overview of TCP

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

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

need explicit connection establishment andtermination

► Potentially different RTT

need adaptive timeout mechanism

► Potentially long delay in network

need to be prepared for arrival of very old packets


2/12

2

Overview of TCP

►Potentially different capacity at destination

need to accommodate different amounts of

buffering

►Potentially different network capacity

need to be prepared for network congestion

TCP header

►TCP data is encapsulated in an IP

datagram

►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, 20bytes, 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


3/12

3

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 causes TCP to send the segments?

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


►Recall that IP discards packets after a

packet’s TTL expires

►each TCP packet has a maximumlifetime -- 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


►The Src Port and Dest Port along with the

IP src/dest addresses identify each TCP

connection

►TCP’s demux key is

►Because TCP connections come and go, it

is possible for a connection to have

different incarnations


4/12

4


►The Acknowledgment, SequenceNumber,

AdvertisedWindow fields are all involved in

TCP’s 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


► 6-bit flag field is used to relay informationbetween TCP peers

SYN, FIN -- used for connections

ACK flag set to indicate Acknowledgementfield is valid

URG flag set to indicate Urgent data iscontained

►The RESET flag -- receiver wants to abortthe connection

TCP Connection Establishment

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

Three-way handshake

► 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


5/125

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

TCP state-transition diagram 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


6/126


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


7/127

TCP sliding window

►Receiver cannot acknowledge a byte thathas not been sent

►TCP can’t send a byte application has not

written

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

►NextByteExpected


8/128

TCP sliding window

► On the receive side to avoid buffer overflow:

LastByteRcvd - LastByteRead


9/129

TCP sliding Window Issues

►TCP’s sequence is 32-bits wide

►TCP’s advertised window is 16-bits wide

►This satisfies the sliding window algorithm

requirement

►However, 32-bit sequence number field

can wrap around -- i.e., a packet withsequence # x can be sent and after a

while another packet with sequence # x

can be sent

1632 222 ×>>


► 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


► 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


10/1210


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

►α is selected to smooth EstimatedRTT --

original TCP spec. recommends a setting

between 0.8 and 0.9

SampleRTT)1(TTEstimatedRTTEstimatedR ×−+×= α α


TCP►TimeOut = 2 x EstimatedRTT

Karn/Partridge Algorithm:


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


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


11/1211


TCPDifference = SampleRTT - EstimatedRTTEstimatedRTT = 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

►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

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

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


12/1212

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

Lecture16-TCPOverview

Documents

Transcript of Lecture16-TCPOverview