TCP : Fundamentals of Computer Networks Bill Nace

Transcription

1 TCP : Fundamentals of Computer Networks Bill Nace Material from Computer Networking: A Top Down Approach, 6 th edition. J.F. Kurose and K.W. Ross

2 Administrivia Lab #1 due now! Reminder: Paper Review for next lecture Jacobson88 Grades are posted as they are graded This may mean a friend has their grades before you 2

3 Last Lecture Reliable Data Transfer Tools Checksum Receiver Feedback Retransmission Timer Sequence Number Window / Pipelining 3

4 traceroute Connection-oriented Transport: TCP Segment Structure Connection Management Reliable Data Transfer 4

5 TCP Overview Point-to-point One sender, one receiver Reliable Segments delivered in-order without loss In-order byte stream No message / record boundaries Pipelined Sliding-window type control algorithm 5

6 TCP Overview Full duplex data bi-directional data flow in the same connection Connection-oriented handshaking (exchange of control messages) initializes sender & receiver state before data exchange 6

7 application writes data application reads data socket socket TCP send buffer TCP receive buffer segment segment Both sides have buffers Lots of Producer-Consumer coordination problems to overcome

8 Transmission Control Flow Control Sender will not overwhelm receiver Congestion Control Various algorithms employed to limit sending of segments Don t want to overwhelm the network 8

9 traceroute Connection-oriented Transport: TCP Segment Structure Connection Management Reliable Data Transfer 9

10 Format 32 bits source port # destination port # sequence # Port numbers like UDP 16-bit, some are "well-known" not same as UDP hdr len not used checksum acknowledgement # flags receive window urgent data pointer options (variable length) application data (variable length) 10

11 Format Seq# and Ack# counted by bytes of data, not segments Seq: number of the first byte in this segment Ack: number of the NEXT expected byte Acks are cumulative hdr len source port # destination port # not used checksum sequence # acknowledgement # flags 32 bits receive window urgent data pointer options (variable length) application data (variable length) 11

12 Flag Field Header Length (4 bits) # words (32-bit) Usually 5 (20 bytes) Can be longer with options hdr len 32 bits source port # destination port # sequence # acknowledgement # not flags receive window used checksum urgent data pointer options (variable length) Hdr Len Not Used URG ACK PSH RST SYN FIN application data (variable length) 12

13 Flag Field ACK: Segment acknowledges receipt of another segment (i.e. ack seq# is good) Setup and teardown signals SYN: Synchronize seq# FIN: No more data from sender RST: Reset connection URG ACK PSH RST SYN FIN Rarely used PSH: Push the data to app-layer immediately URG: Urgent data, indicated by Urgent Data Pointer 13

14 Format 32 bits source port # destination port # sequence # Receive window #bytes receiver is willing to accept For flow-control hdr len not used checksum acknowledgement # flags receive window urgent data pointer options (variable length) application data (variable length) 14

15 Format Checksum Same as UDP Urgent data pointer Offset in data field Options Time stamps Window scaling factors Negotiating MSS hdr len source port # destination port # not used checksum sequence # acknowledgement # flags 32 bits receive window urgent data pointer options (variable length) application data (variable length) 15

16 Format Application Data Size limited by MSS MSS=Maximum Segment Size Despite name, MSS is most app data that can be carried MTU (Max Trans Unit) of lower level generally drives MSS App data + TCP header + IP overhead must fit in MTU MSS is often 1460, 536 or 512 bytes hdr len source port # destination port # not used checksum sequence # acknowledgement # flags 32 bits receive window urgent data pointer options (variable length) application data (variable length) 16

17 Question Huge file of L bytes, MSS of 1200 bytes, TCP sequence number field of 4 bytes What is the maximum value of L such that TCP sequence numbers are not reused? Kind of a trick question TCP sequence number is based on number of bytes, not segments MSS is irrelevant Sequence number field is 32-bits, but all sequence number arithmetic is modulo 2 32 so a theoretical file of L = bytes is possible 17

18 traceroute Connection-oriented Transport: TCP Segment Structure Connection Management Reliable Data Transfer 18

19 TCP Connection Management Why connection establishment? TCP sender, receiver setup state before exchanging data segments Initialize TCP variables: seq#s buffers, flow control info (RcvWindow) Why connection teardown? Free up state 19

20 Three-way Handshake Step 1: client sends TCP SYN segment to server specifies initial seq# client server holds no data connection request Step 2: server responds with SYNACK segment server allocates buffers specifies initial seq# acknowledge SYN = 1 seq=client_isn SYN=1 seq=server_isn, ACK=1 ack=client_isn + 1 SYN=0, seq=client_isn + 1 ACK=1 ack=server_isn + 1 connection granted Step 3: Client replies with ACK may contain data

21 Question TCP specification requires each side of a connection to select an initial starting sequence number at random 1. Why? Let s say TCP does not exchange initial sequence numbers, and just use 0 as the starting point. What can happen? An earlier incarnation of the same connection can interfere with a later one 1Not exactly, but it's complicated. Let's pretend it is random. 21

22 Go Away, Dude If a host receives a TCP SYN segment to a closed port, it responds with a RST segment UDP sends a special ICMP packet in this situation 22

23 Closing a Connection client Step 1: Client sends TCP FIN segment to server close server Step 2: Server receives FIN, responds with ACK FIN Closes connection Sends FIN ACK FIN closing Recall: Connection is bidirectional, needs to be shut down from each side timed wait closed ACK closed

24 Closing a Connection client Step 3: client receives FIN, replies with ACK Client enters timed wait close FIN server Will respond to FIN with ACK 240 seconds (2x max time a segment can exist in internet) ACK FIN closing Step 4: server receives ACK, closes connection timed wait closed ACK closed

25 Question client close server FIN Why does client enter timed wait state before closed, even after receiving FIN from server? ACK FIN closing timed wait closed ACK closed

26 Answer What happens if ACK from the client is lost, and the client does not wait? close client FIN server Client may open the same connection again (same pair of port #s) Receives FIN from earlier incarnation of connection Immediately initiate closing of the later incarnation closed open? ACK SYN X ACK FIN FIN closing closing

27 traceroute Connection-oriented Transport: TCP Segment Structure Connection Management Reliable Data Transfer 27

28 TCP RDT TCP creates RDT service on top of IP s unreliable service Pipelined segments Cumulative acks Retransmission timer Retransmissions are triggered by: timeout events duplicate acks Initially, we consider simplified TCP sender: ignore duplicate acks ignore flow control, congestion control assume RTT is estimated somehow

29 TCP Seq# and ACKs Sequence numbers: byte stream number of first byte in segment s data ACKs: seq # of next byte expected from other side cumulative ACK acknowledges bytes up to the first missing byte in the stream User types 'C' host ACKs receipt of echoed 'C' client server Seq=19, ACK=87, data = 'C' Seq=87, ACK=20, data = 'C' Seq=20, ACK=88 host ACKs receipt of 'C' echoes 'C' piggybacked with data, if possible

30 TCP Sender Events Data received from app: Create segment seq# is byte-stream number of first data byte in segment Send, if allowed by congestion & flow-control start timer if not already running (think of timer as for oldest unacked segment) expiration interval: TimeOutInterval Timeout: retransmit segment that caused timeout restart timer ACK received: If acknowledges previously unacked segments update what is known to be ACKed start timer if there are outstanding segments

31 Retransmission Scenarios client Lost ACK timeout SendBase =100 server Seq=92, 8 data bytes X ACK=100 Seq=92, 8 data bytes ACK=100 What does server do when it gets the retransmitted segment? Discard it! Expected seq# is 100. Since 92 < 100 it knows this is duplicate data

32 Retransmission Scenarios client Premature Timeout server Seq=92 timeout Seq=92 timeout Seq=92, 8 data bytes Seq=100, 20 data bytes ACK=100 ACK=120 Seq=92, 8 data bytes ACK=120 Will client retransmit 2nd segment (Seq=100)? No! ACK=120 arrives before the timeout

33 Retransmission Scenarios client Lost ACK Seq=92 timeout server Seq=92, 8 data bytes X Seq=100, 20 data bytes ACK=100 ACK=120 Host hasn t received ACK for first segment, so why doesn t it retransmit? ACK=120 is cumulative, which means everything up to byte 120 has been received (including 92)

34 ACK Generation Event at receiver Arrival of in-order segment with expected seq#. All data up to seq# already ACKed Arrival of in-order segment with expected seq#. One other segment has ACK pending Arrival of out-of-order segment higher than expected seq#. Gap detected Arrival of segment that partially or completely fills gap Receiver Action Delayed ACK. Wait up to 500ms for next segment. If no next segment, send ACK Immediately send single cumulative ACK for both inorder segments Immediately send duplicate ACK, indicating seq# of next expected byte Immediately send ACK, provided that segment starts at lower end of gap 34

35 Fast Retransmit Time-out period often relatively long: Long delay before resending lost segment Detect lost segments via duplicate ACKs Sender often sends many segments backto-back If segment is lost, there will likely be many duplicate ACKs If sender receives 3 duplicate ACKs, it supposes that segment after ACKed data was lost: Fast retransmit: resend segment before timer expires

36 Scenario client Fast Retransmission Seq=92, 8 data bytes server Seq=92 timeout Seq=100, 20 data Seq=120, 15 data Seq=135, 6 data Seq=141, 16 data X ACK=100 ACK=100 (1st Dup) ACK=100 (2nd Dup) ACK=100 (3rd Dup) Sender doesn t have to wait for a timeout to notice probable loss of seq=100 segment Sort of a NACK Seq=100, 20 data bytes ACK=157

37 Why 3? Why 3 duplicate ACKs? Why not do fast retransmit after the first duplicate ACK for a segment is received? If n+1 and n+2 (or n+3) are just reordered, then waiting for 2 duplicate ACKs will not retrigger retransmission Voodoo constant n n+1 n+2 client Seq=100, 20 data bytes server Seq=92, 8 data bytes ACK=100 ACK=120 ACK=100

38 Lesson Objectives Now, you should be able to: describe the requirements and features of TCP describe the segment format of TCP calculate MSS from the relationship of MTU, Network and Transport header sizes 38

39 You should be able to: describe the operations behind establishing and tearing-down a TCP connection describe the operation of sender and receiver in reliably transferring data across the TCP connection. This description should include events occurring at the sender (including fast retransmission optimizations) and receiver, as well as scenarios whereby error conditions are overcome