CS3250 Distributed Systems
Lecture 6 -- More on TCP/IP
Delay or Loss of Data Segments
In the left-hand diagram below host 1 sends a data segment containing n octets of data with
sequence number X1 and when this arrives at host 2, an acknowledgement is sent back with
sequence number X+n (assuming all segments with sequence numbers < X have also been
received). In the meantime host 1 might also have transmitted further data segments with
sequence numbers X+n, X+2n and X+3n2. Suppose that segment with sequence numberX+n
is delayed and arrives after those with sequence numbers X+2n and X+3n. On receipt of
segments numbered X+2n and X+3n, host 2 cannot send an acknowledgement (as it hasn't yet
received the segment numbered X+n). When eventually segment X+n arrives, host 2 sends
an acknowledgement with sequence number X+4n to indicate that it now has received all data
octets with sequence numbers < X+4n.
The right-hand diagram shows the sequence of events when a data segment (with sequence
number X+n) is lost, but data segments numbered X+2n and X+3n have been transmitted and
received. Eventually host 1 will time out and resend X+n. When this segment arrives, host 2
can send an acknowledgement with sequence number X+4n as it has now received everything
with sequence numbers < X+4n. Suppose in the meantime host 1 has timed out again and
retransmitted segment X+2n, when this duplicate segment is received by host 2, it is
acknowledged by resending an ACK X+4n (since the original ACK X+4n may have been
lost), but the duplicate segment is discarded.
Host 1
Host 1
Host 2
Host 2
data X
data X+n
data X
*
data X+2n
ACK X+n
data X+n
ACK X+n
data X+3n
data X+2n
data X+3n
Host 1 times out
and resends X+n data X+n
ACK
X+4n
Time
Host 1 times out
and resends X+2n
ACK X+4n
data X+2n
Time
ACK X+4n
duplicate
segment X+2n
acknowledged
but otherwise
ignored
To summarise if a segment is lost or delayed and is not acknowledged with a certain time
interval, it is resent by the sender. If two (or more) duplicate segments are received by
1
Hence it contains octets with sequence numbers X through to X+n–1 inclusive.
We assume for simplicity all segments have a data section of n octets.
© A Barnes, 2005
1
CS3250/L6
2
receiver (due to delay of the original segment or due to loss or delay of its original
acknowledgement), then all duplicates are acknowledged. If duplicate acknowledgements are
received by the sender, then the duplicates are ignored.
Establishing a TCP Connection
A three-way handshake protocol is used to establish a TCP connection. In this the two
hosts must inform each other of their initial sequence numbers. Suppose host 1 wishes to
actively open a connection to host 2. It sends a TCP segment to host 2 with the SYN bit set
and with its initial sequence number X (say). When host 2 (which must be in a passive open
state listening for connections) receives the SYN segment, it replies with a segment with the
SYN bit set and with its initial sequence number Y (say). The ACK bit set is also set and the
acknowledgement number is set to X+1 (recall that the acknowledgement number is lowest
sequence number NOT received). On receipt of the SYN/ACK, host 1 sends back a segment
with the ACK bit set and with the acknowledgement number set to Y+1. Host 1 can then
begin transmitting data segments to host 2 with segment numbers X+1, X+n+1, etc.3. On
receipt of the ACK Y+1 by host 2, the connection is fully established and the sequence
numbers of the two streams of data are synchronised. Host 2 can send data segments to host
1 with sequence numbers Y+1, Y+m+1, etc.4.
The protocol can also handle the exception case when both hosts simultaneously initiate an
active open.
Host 2
Host 1
Host 1
Host 2
SYN X
SYN X
SYN Y
SYN Y/ACK X+1
SYN X/ACK Y+1
SYN Y/ACK X+1
ACK Y+1
Host 1 can
now transmit
data
Host 2 can
now transmit
data
Host 1 can
now transmit
data
Host 2 can
now transmit
data
Time
Normal Active/Passive Open
Simultaneous Active Open
Suppose now that host 2 is not prepared to accept the connection request from host 1. When
it receives the SYN segment, it replies with a segment with the RST and ACK bits set and
with acknowledgement number of X+1. This informs the host that its connection request has
been received and rejected.
3
Assuming host 1 is sending segements with data sections of size n.
Assuming host 2 is sending segements with data sections of size m.
© A Barnes, 2005
2
4
CS3250/L6
The protocol is robust enough to cater for the loss or delay of segments in the handshake
sequence. It does this by using a policy of retransmission if an acknowledgement has not
arrived within a certain time-out interval. If SYN X is resent by host 1 and both are received
by host 2, they are both acknowledged with SYN Y/ACK X+1 (in case the cause of the
resend was the loss of the first SYN/ACK). If host 1 receives both these SYN Y/ACK X+1
then both are acknowledged with ACK Y+1 (in case the cause of the resend was the loss of
the first ACK).
In the diagrams on the next page we show the case when the SYN/ACK from host 2 is lost.
After a certain time host 1 times-out waiting for the SYN/ACK and resends the SYN, host 2
then resends the SYN/ACK and this one gets through and is acknowledged and the
connection is established. Alternatively when the SYN/ACK is lost, it might be host 2 that
times-out waiting for the ACK. It then resends the SYN/ACK and when this arrives host 1
responds with its ACK and when this arrives the connection is established.
The second diagram illustrates what happens if the first SYN/ACK is delayed and host 2
times out waiting for the ACK and resends it SYN/ACK. Both SYN/ACK that arrive at host
1 must be acknowledged.
Host 2
Host 1
Host 2
Host 1
SYN X
SYN X
SYN Y/ACK X+1
SYN Y
*
SYN X
SYN Y/ACK X+1
SYN Y/ACK X+1
ACK Y+1
ACK Y+1
Time
SYN Y/ACK X+1
reacknowledged
ACK Y+1
Duplicate
ACK ignored
SYN/ACK delayed
Host 2 times-out
and retransmits
SYN/ACK
SYN/ACK lost
Host 1 times-out
and retransmits
SYN
Exercise Sketch diagrams of what occurs when
if the SYN and SYN/ACK arrive, but the final ACK is lost or delayed.
an initial SYN is delayed and host 1 times out and resends the SYN
© A Barnes, 2005
3
CS3250/L6
Closing a TCP connection
The orderly close down of a connection is somewhat more complex and requires a four-way
handshake (see diagram overleaf). Suppose host 1 reaches the end of its data sequence
(which we will suppose finishes at octet number X–1) and wishes to close down the
connection. After receiving acknowledgement from host 2 of all its data, it sends a segment
with the FIN bit set and with the sequence number X. On receipt of this FIN signal, host 2
acknowledges the close-down request by sending a segment ACK X+1. This
acknowledgement ACK X+1 prevents repeated resends of FIN X by host 1. On receipt of
this FIN and the sending of ACK X+1, host 2 also informs its application of the close-down
request. The host 2 application may still have data to send back to host 1 and normal data
segments can still be sent to host 1 and must be acknowledged by host 1 in the normal way.
When host 2 reaches the end of its data sequence (which we will suppose finishes at octet
number Y–1) and wishes to complete the close down, it signals this to TCP software which
(after all its data has been acknowledged) sends a segment with FIN set and its final sequence
number Y (say). To complete the close-down handshake sequence host 1 acknowledges the
close down and sends ACK Y+1. Assuming no ACK's or FIN/ACK's are lost, the shutdown
completes and the connection is broken after a suitable time-out interval at each end of the
connection; this time-out interval on shutdown is often called the linger interval.
Like the 3-way handshake to initiate a connection, this 4-way close-down handshake protocol
is also robust. It can handle simultaneous active shutdowns by both hosts. Suppose host 1
sends a FIN X and, at more or less the same time, host 2 sends FIN Y. On receipt of the FIN
X, host 2 now responds with FIN Y / ACK X+1 and on receipt of FIN Y, host 1 now
responds with FIN X / ACK Y+1. The shutdown then completes after a suitable time-out (or
linger) interval (assuming no acknowledgments are lost).
The protocol can also handle loss or delay of the FIN, FIN/ACK or ACK's in the 4-way
handshake. Again unacknowledged FIN's and FIN/ACK's are resent after a suitable time-out
interval and duplicate FIN's or FIN/ACK's are all acknowledged, with duplicate ACK's being
ignored.
The purpose of the linger interval is to allow a reasonable time for delayed FIN, FIN/ACK or
ACK's segments which have been resent, to be received over the current connection. If the
connection were closed immediately after receipt of the FIN/ACK and ACK segments,
delayed and duplicated segments from a terminated connection could be misinterpreted if
another connection with the same source and destination endpoints were set up in the near
future.
In addition to the orderly close-down of a connection described above, it is possible to abort a
connection immediately. In this case the host wishing to abort the connection will send a
segment with the RST flag in the CODE BITS field set.
In the above discussion the host initiating the shut-down (namely host 1) cannot send
segments over the connection once it has sent a segment with FIN set in the code bits field. It
can still receive segments until host 2 sends a segment with the FIN bit set. However, it is
also possible for an application on host 1 to signal to TCP that it does not wish to receive any
further data from host 2, but that it wishes to continue to send segments to host 2. No
indication of this is sent to host 2 (which presumably continues to send segments ). However
when these segments arrive at host 1 TCP does not pass them to the application, but discards
them.
© A Barnes, 2005
4
CS3250/L6
Host 1
Host 1 initiates
close-down
Host 2
FIN X
ACK X+1
inform Host 2 Application of
Close-Down request
Send normal segments with
sequence numbers < Y and
receive acknowledgements
FIN Y/ACK X+1
Host 2 Application
closes connection
ACK Y+1
Time
© A Barnes, 2005
Close Down
complete
5
CS3250/L6