Transportation Layer (2)

1. Transportation Layer (2)

2. 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

3. 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)

4. 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

5. TCP connection set up • The initial sequence number is picked based on the clock • The clock ticks every 4 us

6. TCP Connection Management: establish a connection • 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 sender, receiver establish “connection” before exchanging data segments • initialize TCP variables: • seq. #s • buffers, flow control info • client: connection initiator • server: contacted by client

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

8. 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.

9. TCP connection close B A • 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. DR ACK1 Con. close ACK2 Con. close

10. Connection close B A • 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. DR ACK1 Con. close ACK2 lost Con. close

11. Connection close B A • So, three-way handshaking doesn’t work. • Should we ask A to wait until received ACK3 from B? DR ACK1 ACK2 Con. close ACK3 Con. close

12. Connection close B A • 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. DR ACK1 ACK2 Con. close ACK3 lost Con. close

13. Two army problem

14. 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()

15. Host B Host A User types ‘C’ Seq=42, ACK=79, data = ‘C’ host ACKs receipt of ‘C’, echoes back ‘C’ Seq=79, ACK=43, data = ‘C’ host ACKs receipt of echoed ‘C’ Seq=43, ACK=80 time simple telnet scenario TCP Seq. #’s and ACKs • Seq. #’s: • byte stream “number”of first byte in segment’s data • ACKs: • seq # of next byte expected from other side • cumulative ACK

16. TCP SYN/FIN Sequence # • TCP SYN/FIN packets consume one sequence number • For simplification, seq # counts pkts numbers • In reality, it is byte counts server client SYN(J) SYN/ACK(K,J+1) ACK(K+1) DATA(J+1) ACK(J+2) FIN(M) ACK(M+1) FIN(N) ACK(N+1)

17. 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

18. Host A Host B Seq=92, 8 bytes data ACK=100 timeout X loss Seq=92, 8 bytes data ACK=100 time time lost ACK scenario Host A Host B Seq=92, 8 bytes data Seq=100, 20 bytes data Seq=92 timeout ACK=100 ACK=120 Seq=100 timeout Seq=92, 8 bytes data ACK=120 premature timeout, cumulative ACKs