Transportation Layer 2 TCP pointtopoint one sender one

Transportation Layer (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

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 • 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) B A SYN (SEQ =x) ) 1 + x = K C A , y = Q (SE YN S Con. SE Q=x +1, Set ACK =y+ up 1 ) 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 ACK 1. A sends an ACK 2 for the ACK 1, and releases the connection. When B receives the ACK 2, he releases the connection. B A DR 1 K AC Con. close ACK 2 Con. close

Connection close • The problem is the DR and ACK can be lost • What if ACK 2 is lost? • If B does not receive ACK 2, 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 ACK 1. But A is gone. • Different from setting up a connection. When A is up, keeping on resending will generate a reply somehow. B A DR 1 K AC Con. close ACK 2 lost Con. close

Connection close B A • So, three-way handshaking doesn’t work. • Should we ask A to wait until received ACK 3 from B? DR 1 K AC ACK 2 3 K AC Con. close

Connection close • What if ACK 3 is lost? • Adding ACK 4? • 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 DR 1 K AC ACK 2 3 K AC Con. close lost Con. close

Two army problem

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

TCP Seq. #’s and ACKs byte stream “number”of first byte in segment’s data ACKs: Host B Host A Seq. #’s: User types ‘C’ seq # of next byte expected from other side – cumulative ACK host ACKs receipt of echoed ‘C’ Seq=4 2, ACK =79, d ata = ‘ C’ host ACKs receipt of ’ C ‘ ‘C’, echoes ata = d , 3 4 = back ‘C’ ACK , 9 7 = q Se Seq=4 3, ACK =80 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 SYN(J) +1) K(K, J C A / SYN ACK(K+1) DATA(J+1) ACK(J+2) FIN(M) ACK(M +1) ) FIN(N ACK(N+1)

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

Host A timeout 2, 8 by tes da t a 100 X loss = ACK 2, 8 by tes da ta Seq=100 timeout Seq=92 timeout Seq=9 Host A Host B 0 10 = K 120 AC ACK= Seq=9 2, 8 by tes da ta 20 100 lost ACK scenario Seq=9 2, 8 by tes da ta Seq= 100, 2 0 byte s data K=1 C A = ACK time Host B time premature timeout, cumulative ACKs