Transportation Layer

1. Transportation Layer

2. Transportation Layer • Very similar to the data link layer. • 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: • 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. 32 bits source port # dest port # sequence number acknowledgement number head len not used Receive window U A P R S F checksum Urg data pnter Options (variable length) application data (variable length) TCP segment structure 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 08.00.2b.2a.83.62 • Network: want to transfer data to IP host 128.2.222.85 • Transport: which entity you will try to address? • want to talk to one process on host 128.2.222.85. • 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 Handshake B 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. 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 TCP Round Trip Time and Timeout Computer Science, FSU

10. Setting the timeout EstimtedRTT plus “safety margin” Timeout is doubled every time a segment is timeout large variation in EstimatedRTT  larger safety margin 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 Timeout = EstimatedRTT + 4*Deviation Deviation = (1-x)*Deviation + x*|SampleRTT-EstimatedRTT| Computer Science, FSU

11. TCP Timeout

12. client server close FIN ACK close FIN ACK time wait closed 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. 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 This B 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 This B 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 This B 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.