1. Transportation Layer

2. Transportation Layer Very similar to the data link layer. differences:
two hosts connected by a link or two hosts connected by a network
differences:
When two hosts are connected by a link, packets will not reorder or duplicate (if the sender sends only once). In addition, packets will either get to the receiver or get lost.
When two hosts are connected by a network, packets can be duplicated, delayed, lost, reordered.
Implication: The problems to be addressed in the transport layer are very similar to those in the data link layer. However, the solutions may be more complex.

3. Problems The problem is that network can delay, reorder, lose packets
Time-out/retransmission introduces duplicates of data, acknowledgement, connect, close packets
Worst case scenario: consider this bank transaction example
(a) setup connection
(b) transfer $100
(c) close connection
all messages are delayed and replayed.

4. TCP point-to-point: full duplex data: reliable, in-order byte steam:
one sender, one receiver
reliable, in-order byte steam:
no “message boundaries”
pipelined:
TCP congestion and flow control set window size
send & receive buffers
full duplex data:
bi-directional data flow in same connection
MSS: maximum segment size
connection-oriented:
handshaking (exchange of control msgs) init’s sender, receiver state before data exchange
flow controlled:
sender will not overwhelm receiver

5. TCP segment structure source port # dest port # application data
32 bits
application
data
(variable length)
sequence number
acknowledgement number
Receive window
Urg data pnter
checksum F S R P A U
head
len
not
used
Options (variable length)
URG: urgent data
(generally not used)
counting
by bytes
of data
(not segments!)
ACK: ACK #
valid
PSH: push data now
(generally not used)
# bytes
rcvr willing
to accept
RST, SYN, FIN:
connection estab
(setup, teardown
commands)
Internet
checksum
(as in UDP)

6. Port number
Link: want to transfer data to Ethernet card b.2a.83.62
Network: want to transfer data to IP host
Transport: which entity you will try to address?
want to talk to one process on host
what to do use? process ID? how many bits? What would be the problem when using the pid as transport layer identifier?
Abstraction: port number

7. TCP Connection Setup – Three-Way HandshakeB A
Connection initiator (the client)
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)
SYN (SEQ=x)
SYN (SEQ=y, ACK=x+1)
Con.
Set up
SEQ=x+1, ACK=y+1)
Con.
Set up

8. Choosing Unique Identifier
On packet arrival: is it real or old?
New connection request/release or an old one? Remember that there is no restriction on reusing the port number.
Unique ID for each TPDU
Choose an identifier for each TPDU such that it is impossible for other TPDU currently in the network associated with this host to have the same identifier.
Pick a random seq#

9. TCP Round Trip Time and Timeout
Q: how to set TCP timeout value?
longer than RTT
note: RTT will vary
too short: premature timeout
unnecessary retransmissions
too long: slow reaction to segment loss
Q: how to estimate RTT?
SampleRTT: measured time from segment transmission until ACK receipt
ignore retransmissions, cumulatively ACKed segments
SampleRTT will vary, want estimated RTT “smoother”
use several recent measurements, not just current SampleRTT
Zhenhai Duan
Computer Science, FSU

10. TCP Round Trip Time and Timeout
EstimatedRTT = (1-x)*EstimatedRTT + x*SampleRTT
Exponential weighted moving average
influence of given sample decreases exponentially fast
typical value of x: 0.1
Setting the timeout
EstimtedRTT plus “safety margin”
Timeout is doubled every time a segment is timeout
large variation in EstimatedRTT  larger safety margin
Timeout = EstimatedRTT + 4*Deviation
Deviation = (1-x)*Deviation +
x*|SampleRTT-EstimatedRTT|
Zhenhai Duan
Computer Science, FSU

11. TCP Timeout

12. TCP Connection Management: close a connection
Modified three-way handshake:
client closes socket:
Step 1: client end system sends TCP FIN control segment to server
Step 2: server receives FIN, replies with ACK. Sends FIN.
client
FIN
server
ACK
close
closed
time wait
closed
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.
Socket programming interface
close() vs shutdown()

13. Why TCP Closes Connection Like ThisB A
Saying goodbye is difficult!
Consider A sending file to B. When A gets the last ACK for data, A sends FIN.
Can A quit at this time? No, because B does not know that A knows that B got all data. So, B might keep sending the last data ACK.
FIN

14. Why TCP Closes Connection Like ThisB A
B ACK this FIN by sending ACKFIN. Can B quit at this time? No, because B does not know whether ACKFIN got through or not. If not, A does not know that B knows that A knows that B got all the data. If A is not sure about this, A might keep on sending FIN.
FIN
ACKFIN

15. Why TCP Closes Connection Like ThisB A
So A sends ACKACKFIN. Can A quit at this time? Still no, because … (too long, you get it).
The point is, if you have reason to send the last ACK, you have just as good reason to send last + 1 ACK, because the only way to make sure that the last ACK is received is to receive the ACK for that ACK, and you have to send an ACK to ACK that ACK because the other side is waiting for it.
Conclusion: No protocol can make sure of graceful close of connection. So have to use timeout. If to use timeout, better use it earlier than later.
FIN
ACKFIN
ACKACKFIN

16. TCP connection close
Now, A enters the TIMEWAIT state because it is not sure its ACKACKFIN will be received or not. If not, he assumes that B will retransmit ACKFIN. If he does not receive ACKFIN for TIMEWAIT, he assumes that its ACKACKFIN got through and quit. However, it could happen that all the ACKACKFINs were lost. It could also happen that All B’s retransmit of ACKFIN were lost. So there is a (very slight) chance that B did not receive the final ACKACKFIN.
The approach adopted by TCP at least makes sure that A is sure that B receives FIN (A must receive ACKFIN.)
So TCP is still reliable for data transfer, because both sides know that the data has been transferred correctly in order.