COMP 431 Internet Services & Protocols Transport Layer Protocols & Services Outline The Transport Layer Reliable data delivery & flow control in TCP Jasleen Kaur Fundamental transport layer services» Multiplexing/Demultiplexing» Error detection» Reliable data delivery» Pipelining» Flow control Logical end-to-end» Congestion control transport application transport network data link physical home network regional ISP network data link physical network data link physical March 28, 2019 Internet transport protocols» UDP» TCP Institutional network application transport network data link physical 1 2
TCP Overview TCP is TCP Segment Structure Header and payload format Point-to-point, full-duplex» Bi-directional data flow within a connection Reliable, in-order byte stream» No message boundaries Connection-oriented» Handshaking initializes sender and receiver state before data exchange Pipelined» Congestion and flow control determine window size» Each endpoint has two buffers: a send and receive buffer Application writes data TCP send buffer socket door segments Application reads data TCP receive buffer RFCs: 793, 1122, 1323, 2018, 2581 Congestion controlled» Internet would cease to function without this! Flow controlled» Sender and receiver have synchronized windows to ensure receiver is not overwhelmed Urgent data ( URG ) ACK number is valid Push data now ( PSH ) Connection establishment and teardown commands ( RST, SYN, FIN ) Same checksum as in UDP 32 bits source port # dest port # sequence number head len acknowledgement number not used UAP R S F rcvr window size checksum ptr urgent data Options (variable length) Application data (variable length) s of data sent/received are numbered (not segments) Number of bytes the receiver is willing to accept payload MSS (Maximum Segment Size) 3 4
TCP Sequence Numbers and ACKs Telnet example TCP Reliable Data Transfer (RDT) Sequence numbers:» stream index of the first byte in the segment s payload ACKs:» Sequence number of next byte expected from the other side» ACKs are cumulative How does receiver handle out-of-order segments?» TCP spec doesn t say, it s up to the implementor User types C time host ACKs receipt of echoed C Host A Host B host ACKs receipt of C, echoes back C TCP creates RDT service on top of IP s unreliable service Pipelined segments Cumulative ACKs TCP uses single retransmission timer Retransmissions are triggered by:» timeout events» duplicate ACKs Initially consider simplified TCP sender:» ignore flow control, congestion control (they determine the window size dynamically) 5 6
Sender s state machine (simplified!) Simplified sender TCP_send(data) create segment udt_send(segment nextseqnum) start_timer receive ACK for segment y update timers advance the window to y retransmit y if third duplicate ACK sequence ACK ed Sliding window unack ed Usable but unsent Not usable timeout for segment y udt_send(segment y) start timer wait for event TCP retransmits segments if:» An expected ACK times out» 3 duplicate ACKs for a segment are received SendBase Comment: SendBase 1 = last cumulatively ACKed byte NextSeqNum Example: SendBase-1 = 71; ACK= 73, so the receiver wants 73+ ACK > SendBase, so new data (SeqNum = 72) is ACKed 7 8
Simplified sender s state machine Simplified sender s state machine Sliding window Sliding window 1 st sequence ACK ed unack ed Unsent and eligible Unsent and ineligible 1 st sequence ACK ed unack ed Unsent and eligible Unsent and ineligible send base sendbase = initial_sequence number nextseqnum = initial_sequence number loop (forever) { switch(event) event: data received from application above event: timer timeout for segment with sequence number y event: ACK received with value y } next sequence number create TCP segment with sequence number nextseqnum start timer for segment with nextseqnum pass segment to IP nextseqnum = nextseqnum + length(data) retransmit segment with sequence number y ( segment y ) compute new timeout interval for segment y restart timer for segment y 9 send base next sequence number if (y > sendbase) { /* Cumulative ACK of all data up to y */ cancel timers for segments with sequence numbers y sendbase = initial_sequence sendbase number := y nextseqnum = initial_sequence } number else if ( y == sendbase) { /* A duplicate ACK */ loop (forever) { increment number of duplicate ACKs received switch(event) if (number of duplicate ACKS received == 3) event: data received from application { /* Fast retransmit */ above resend segment with sequence number sendbase event: timer timeout for segment restart with timer for segment sendbase sequence number y } event: ACK received with } value y } 10
Retransmission examples Retransmission examples Host A Host B Host A Host B Host A Host B Host A Host B timeout X Seq=100 timeout Seq=92 timeout timeout X Seq=100 timeout Seq=92 timeout time time Lost ACK scenario Premature timeout 11 Cumulative ACKs potentially avoid retransmissions Premature timeout 12
Setting the ACK timer How large should the ACK timeout value be?» Too short: Premature timeouts result in unnecessary retransmissions» Too long: Slow reaction to loss results in poor performance because the sender s windows stops advancing Timer should be longer than the RTT, but how do we estimate RTT?» Measure the time from segment transmission until receipt of ACK ( SampleRTT ) Ignore retransmissions Measure only one segment s RTT at a time» SampleRTT will vary, so we compute an average RTT based on several recent RTT samples Estimating round-trip-time EstimatedRTT = (1-x)*EstimatedRTT + x*samplertt Timeout = EstimatedRTT + 4*Deviation Deviation = (1-x)*Deviation + x* SampleRTT-EstimatedRTT The estimated RTT is an exponential weighted moving average (EWMA)» Computes a smooth average» Influence of a given sample decreases exponentially fast E n = x*s n + x(1-x)s n-1 + x(1-x) 2 S n-2 + + x(1-x) i S n-i +» Ty p i cal v alu e o f x is 0.125 Timeout is EstimtedRTT plus safety margin Large variation in EstimatedRTT results in a larger safety margin 13 14
Example RTT Estimate (smoothed) Fast Retransmit RTT (milliseconds) RTT: gaia.cs.umass.edu to fantasia.eurecom.fr 350 300 250 200 150 100 1 8 15 22 29 36 43 50 57 64 71 78 85 92 99 106 time (seconnds) Time-out period often relatively long:» long delay before resending lost packet» timer granularity ~ 10-200 ms» minimum RTO ~ 200-1200 ms Detect lost segments via duplicate ACKs.» Sender often sends many segments back-to-back» If a segment is lost, there will likely be many duplicate ACKs (one for each segment that arrives safely) If sender receives 3 ACKs for the same data, it assumes that the segment after ACKed data was lost:» fast retransmit: resend segment before timer expires» Why wait for 3? SampleRTT Estimated RTT 15 16
ACK generation rules [RFC 1122, RFC 2581] TCP Flow Control Receiver Window control Event TCP Receiver action 1 sequence st Receiver s buffer (RcvBuffer) In-order segment arrival, no gaps, all previous data already ACKed Delayed ACK. Wait 200 ms (up to 500 ms allowed) for next segment. If no segment received, send ACK Delivered to application Received, ACKed, not delivered Acceptable but not received Not expected, not received In-order segment arrival, no gaps, one delayed ACK pending Out-of-order segment arrival (higher than expected sequence number) Gap detected Arrival of segment that partially or completely fills gap Immediately send single cumulative ACK Send duplicate ACK, indicating sequence number of next expected byte Immediate ACK if segment starts at lower end of gap Receiver s window (RcvWindow) Flow control is the problem of ensuring the receiver is not overwhelmed» The receiver can become overwhelmed if the application reads too slow or the sender transmits too fast The receiver s window represents its remaining buffer capacity The window advances as the application reads received data 17 18
TCP Flow Control Window control TCP Flow Control Window control 1 sequence st Receiver s buffer (RcvBuffer) sequence 1st RcvBuffer Delivered to application Received, ACKed, not delivered Acceptable but not received Not expected, not received Delivered to application Received, ACKed, not delivered Acceptable but not received Not expected, not received The receiver explicitly informs the sender of the amount of free buffer space in RcvBuffer» RcvWindow field in TCP segment The sender keeps the amount of transmitted, unacked data less than most recently received RcvWindow dest port sequence number ack number source port head not len used flags checksum Receiver s window TCP options receiver window size urgent data Application data Read Rcvd RcvWindow The goal is to ensure: Rcvd - Read RcvBuffer Sender is sent: RcvWindow = RcvBuffer - (Rcvd-Read) 19 20
TCP Flow Control Sender Window control TCP Connection Management The three-way handshake sequence 1st ACKed ACKed Sent not ACKed Sender s buffer Eligible to be sent Ineligible Application blocked from sending Client client socket socket socket socket Server welcoming socket connection socket The sender ensures: RcvWindow Sent - ACKed RcvWindow TCP endpoints establish a connection before exchanging data segments» client: connection initiator clientsocket = socket(afnet, SOCK_STREAM) clientsocket.connect(servername, serverport)» server: contacted by client connectionsocket, addr = serversocket.accept() 21 22
TCP Connection Management The three-way handshake Client sends SYN segment to server» The SYN specifies the client s initial sequence number» The ACK number in the SYN will be 0 source port # dest port # sequence number head len acknowledgement number not used checksum UAP R S F rcvr window size ptr urgent data Options (variable length) Application data (variable length) TCP Connection Management The three-way handshake Client sends SYN segment to server» The SYN specifies the client s initial sequence number Server receives SYN, replies with SYN+ACK segment» ACKs received SYN» Allocates buffers» Specifies server s initial sequence number client server 23 Third segment may be an ACK only or an ACK+data 24
TCP Connection Management Closing a connection TCP Connection Management Client/Server lifecycles Client sends FIN segment to server Server receives FIN, replies with ACK» Server closes connection, sends FIN Client receives FIN, replies with ACK Client enters timed wait state» Client will ACK any received FIN client server close() Timed Wait Connection closed close() receive FIN send ACK receive FIN send ACK Wait 30 seconds Timed Wait FIN Wait 2 receive ACK send nothing Closed receive SYN+ACK send ACK FIN Wait 1 connect() send SYN SYN Sent close() send FIN receive ACK send nothing close() send FIN ACK Close Wait receive FIN send ACK Closed receive SYN send SYN & ACK Established Established Server creates listen socket Listen SYN Received receive ACK send nothing TCP client lifecycle TCP server lifecycle 25 26