Transportation Layer (2)
TCP
• point-to-point:
• full duplex data:
– one sender, one receiver
– bi-directional data flow in same
connection
– MSS: maximum segment size
• reliable, in-order byte steam:
– no “message boundaries”
• connection-oriented:
• pipelined:
– TCP congestion and flow control set
window size
• send & receive buffers
– handshaking (exchange of
control msgs) init’s sender,
receiver state before data
exchange
• flow controlled:
socket
door
application
writes data
application
reads data
TCP
send buffer
TCP
receive buffer
segment
socket
door
– sender will not overwhelm
receiver
TCP segment
structure
32 bits
URG: urgent data
(generally not used)
ACK: ACK #
valid
PSH: push data now
(generally not used)
RST, SYN, FIN:
connection estab
(setup, teardown
commands)
Internet
checksum
(as in UDP)
source port #
dest port #
sequence number
acknowledgement number
head not
UA P R S F
len used
checksum
Receive window
Urg data pnter
Options (variable length)
application
data
(variable length)
counting
by bytes
of data
(not segments!)
# bytes
rcvr willing
to accept
TCP Connection Setup – Three-Way
Handshake
A
• Connection initiator (the client)
B
– Chooses unique seqno x and sends
req-conn(x)
• Connection respondent (the
server)
– Upon receiving req-conn(x)
• Chooses its own unique identifier, y
• Sends ack-conn(y,x+1)
• Upon receiving ack-conn(y,x+1),
client responds
– With ack-conn(x+1,y+1)
Con.
Set
up
Con.
Set
up
TCP connection set up
• The initial sequence number is picked based
on the clock
• The clock ticks every 4 us
TCP Connection Management: establish a connection
TCP sender, receiver establish
“connection” before exchanging
data segments
• initialize TCP variables:
– seq. #s
– buffers, flow control info
• client: connection initiator
• server: contacted by client
Three-way handshake:
Step 1: client end system sends TCP SYN
control segment to server
– specifies initial seq #
Step 2: server end system receives SYN,
replies with SYNACK control segment
– ACKs received SYN
– allocates buffers
– specifies server  receiver
initial seq. #
Step 3: client replies with an ACK
segment
TCP connection set up
• When setting up the connection, a connection
is considered set up by B when B is sure that
(0) B knows about the connection (1) A knows
about the connection and (2) A knows that B
is about to open the connection. Similar does
A.
TCP Connection Close
• How about the close of connections?
• Can we achieve: When closing the connection, a
connection is considered closed by B when B is sure that
(0) B knows about the closing (1) A knows about the
closing and (2) A knows that B is about to close the
connection. Similar does A.
TCP connection close
• Three way handshake: A
sends disconnection
request (DR) to B. B
replies with an ACK1. A
sends an ACK2 for the
ACK1, and releases the
connection. When B
receives the ACK2, he
releases the connection.
A
B
Con.
close
Con.
close
Connection close
• The problem is the DR and
ACK can be lost
• What if ACK2 is lost?
• If B does not receive ACK2,
he won’t release the
connection, because he is
not sure whether A knows
he is about to close the
connection. He will keep on
resending ACK1. But A is
gone.
• Different from setting up a
connection. When A is up,
keeping on resending will
generate a reply somehow.
B
A
Con.
close
lost
Con.
close
Connection close
A
• So, three-way
handshaking doesn’t
work.
• Should we ask A to wait
until received ACK3 from
B?
B
Con.
close
Con.
close
Connection close
• What if ACK3 is lost?
• Adding ACK4?
• Apparently this can go
on and on forever. The
net effect is, neither of A
and B can release the
connection, if they want
to release the
connection gracefully.
B
A
Con.
close
Con.
close
lost
Two army problem
TCP Connection Management: close a connection
client
Modified three-way handshake:
client closes socket:
server
close
Step 1: client end system sends TCP FIN
close
control segment to server
ACK. Sends FIN.
Step 3: client receives FIN, replies
with ACK.
Enters “time wait” - will respond with
ACK to received FINs
Step 4: server, receives ACK.
Connection closed.
time wait
Step 2: server receives FIN, replies with
closed
closed
• Socket programming interface
 close() vs shutdown()
TCP Seq. #’s and ACKs
Host A
Seq. #’s:
byte stream “number”of first
byte in segment’s data
ACKs:
User
types
‘C’
seq # of next byte expected
from other side
– cumulative ACK
host ACKs
receipt
of echoed
‘C’
Host B
host ACKs
receipt of
‘C’, echoes
back ‘C’
time
simple telnet scenario
TCP SYN/FIN Sequence #
•
•
•
TCP SYN/FIN packets consume one sequence number
For simplification, seq # counts pkts numbers
In reality, it is byte counts
client
server
Data transmission
• Theoretically, for every packet sent for which the
sender expects an ACK,
– A timer is started
• What is the timeout duration?
– When timer expires, this packet retransmitted
– This applies to both data packets and control packets
SYN and FIN
– Note that ACK is cumulative
• Receiver
– Accept out-of-order packets
– Respond by acking last pkt received in order
time
Host A
Host B
X
loss
lost ACK scenario
Host B
Seq=100 timeout
Seq=92 timeout
timeout
Host A
time
premature timeout,
cumulative ACKs