Chapter 5 TCP Handshakes Sliding Window Flow Control

Chapter 5 TCP Handshakes, Sliding Window Flow Control Professor Rick Han University of Colorado at Boulder rhan@cs. colorado. edu Prof. Rick Han, University of Colorado at Boulder

Announcements • Read Sections 5. 1 and 5. 2, skip 5. 3 and 5. 4 • Homework #3 on Web, due March 12 • Solutions to HW #2 and #3 available by March 12 evening • Programming Assignment #2 due Friday March 22 by 11: 59 pm • Midterm March 14 • • Through Chapter 4 Network Layer Excluding 2. 9 (network adaptors), 3. 4 (switching hardware), and 4. 4 (multicast) • Next, more on TCP Prof. Rick Han, University of Colorado at Boulder

Recap of Previous Lecture • UDP: Unreliable Datagram Protocol • • • Transport layer above IP Unreliable best-effort packet delivery service 8 bytes of header • Checksum includes prepended IP pseudo-header • TCP: Transmission Control Protocol • • Reliable in-order (byte stream) service or “pipe” TCP Header: • TCP Connection Setup • • • Sequence #’s in both directions (full-duplex) Flow control window Checksum • Three-way Handshake Prof. Rick Han, University of Colorado at Boulder

Two-Way Handshake pictures courtesy of UMass Amherst Prof. Rick Han, University of Colorado at Boulder

Two-Way Handshake: Failure Prof. Rick Han, University of Colorado at Boulder

Two-Way Handshake W/ Timers Prof. Rick Han, University of Colorado at Boulder

3 -way Handshake: Unique ID’s Server (passive) Client: (active) • Both sender and receiver choose unique ID’s to label their (x, y) connection • x chosen by Sender, y by receiver • Prevents Failure scenario in two-way handshakes w/o Prof. Rick Han, University of timers Colorado at Boulder

3 -way Handshake: Prevents Failure Choose x, Send req_conn(x) Timeout, resend req_conn(x) ACK y, Send data (x+1) Timeout, resend Data(x+1) Req_conn(x) Send “accept connection”, Acc_conn(x, y) Choose y, ACK x Data(x+1, y) Receive data Connection closes Req_conn(x) Send acc_conn, Choose unique y’ Data(x+1, y) Drop data packet from Acc_conn(x, y’) old (x, y) connection, Prof. Rick Han, University of Colorado at Boulder Accept only (x+N, y’)

3 -way Handshake: TCP SYN/ACK TCP Server (passive) TCP Client (active) Both A and B choose Unique ID’s for the connection: x is starting sequence # for A->B, y is starting sequence # for B->A Prof. Rick Han, University of Colorado at Boulder

TCP Client/Server Connection • Server listens passively • Socket(), bind(), listen(), accept() • Socket(), bind(), connect() • • State of connection • Macro: current state in state transition diagram • Micro: RTT, congestion window size, … Buffers: pointers to send and receive buffers • • <source IP, source port, dest IP, dest port> In UDP, socket Prof. buffer Rick Han, named University ofby <dest IP, dest port> • Client conducts active open • TCP maintains a Transmission Control Block (TCB) per connection • Name a connection or TCP session with a 4 -tuple Colorado at Boulder

TCP State Machine: Connection Setup Only CLOSED passive OPEN Appl: CLOSE delete TCB create TCB Appl: CLOSE or timeout delete TCB LISTEN SYN RCVD rcv SYN send SYN ACK rcv ACK of SYN CLOSE Send FIN active OPEN create TCB Send SYN Appl: wants to SEND send SYN rcv SYN snd SYN + ACK Rcv SYN, ACK SYN SENT Send ACK + data ESTAB Prof. Rick Han, University of Colorado at Boulder Courtesy: Srini Seshan

TCP SYN Denial of Service Attack • Malicious client rapidly generates a large number of SYN requests • • • Source IP address is random and forged TCP server creates connection queue of half-open connections, allocates data structure • Run out of data structures for half-open conn. ’s New TCP connections to server can’t be made – Denial of service ! • Solutions: • • • If firewall stops SYN’s from outside, then OK If no firewall, then increase size of connection queue, or timeout more quickly when waiting for ACK from SYN/ACK Han, University of addresses Source filtering. Prof. Rick spoofed IP Colorado at Boulder

Detecting Half-open Connections A TCP connection is half-open if one end has closed or aborted the connection without the knowledge of the other end, e. g. by crash TCP A 1. 2. 3. 4. 5. 6. 7. TCP B (CRASH) CLOSED SYN-SENT <SEQ=400><CTL=SYN> (!!) <SEQ=300><ACK=100><CTL=ACK> SYN-SENT <SEQ=100><CTL=RST> SYN-SENT <SEQ=400><CTL=SYN> Prof. Rick Han, University of Colorado at Boulder (send 300, receive 100) ESTABLISHED (? ? ) ESTABLISHED (Abort!!) CLOSED

TCP Connection Tear-down: two FIN/FIN-ACK’s Sender FIN_WAIT 1 Receiver FIN-ACK FIN_WAIT 2 FIN Half-closed Data write CLOSE_WAIT State (passive) Data ack LAST_ACK state TIME_WAIT FIN-ACK Either server or client can be sender and initiate FIN tear-down Prof. Rick Han, University of Colorado at Boulder

TCP State Machine: Connection Tear-down Only CLOSE send FIN WAIT-1 Rcv ACK FIN WAIT-2 ESTAB CLOSE send FIN rcv FIN send ACK rcv FIN snd ACK CLOSE snd FIN rcv FIN+ACK snd ACK CLOSING LAST-ACK rcv ACK of FIN rcv FIN snd ACK CLOSE WAIT TIME WAIT rcv ACK of FIN Timeout=2*msl delete TCB Prof. Rick Han, University of Colorado at Boulder CLOSED Courtesy: Srini Seshan

Sequence Numbers • Data is viewed as a stream of bytes – Each byte in byte stream is numbered, 32 -bit, wraps around – Initial values selected at start up time • TCP breaks up the byte stream into segments – – Sequence # of a segment is byte-stream # of 1 st byte Variably sized, with Maximum Segment Size (MSS) Segments passed down to IP Segments are retransmitted 13450 14950 segment 13450 16050 segment 14950 17550 segment 16050 Prof. Rick Han, University of Colorado at Boulder

Sequence Numbers (2) • Acknowledgements also have sequence #’s – Cumulative ACK’s list the sequence # of the next byte they’re expecting • if sequence # 13449 has been received, then put 13450 in cumulative ACK • TCP resembles Go-Back N when using cumulative ACK’s – Also, have semi-selective ACK’s • SACK-TCP Prof. Rick Han, University of Colorado at Boulder

Sequence Numbers (3) • Finite Sequence # Wrap-Around – Sequence # space (32 bits) must be greater than twice the window size – satisfied – Sequence #’s must not be wrap around too quickly on high bandwidth Gbps links • This is a problem, so there’s a TCP extension – Advertised window must be greater than typical bandwidth*delay product, to fill pipe • This is a problem, so there’s a TCP extension Prof. Rick Han, University of Colorado at Boulder

Segments • When does a TCP sender know it should send? – When MSS bytes have been accumulated – Application can force sending via PUSH – Periodic timer that forces transmission • What does TCP do with out-of-order segments at receiver? – Could discard – inefficient – Could keep, introducing additional pointers at receiver – TCP doesn’t specify! Prof. Rick Han, University of Colorado at Boulder

TCP Flow Control • TCP is a sliding window protocol – For window size n, can send up to n bytes without receiving an acknowledgement – When the data is acknowledged then the window slides forward • Each ACK advertises receiver’s window size in TCP header – Indicates number of bytes the receiver has space for starting from the highest sequence # of ACK’ed data Prof. Rick Han, University of Colorado at Boulder

Window Flow Control: Send Side Flow control window Advertised by receiver Sent and acked Sent but not acked Last. Byte. ACKed by receiver Not yet sent Last. Byte. Sent Prof. Rick Han, University of Colorado at Boulder Window slides As data is ACK’ed Last. Byte. Written

Window Flow Control: Send Side Packet Received Packet Sent Source Port Dest. Port Sequence Number Acknowledgment HL/Flags Window D. Checksum Urgent Pointer Options. . App write acknowledged sent to be sentoutside window Prof. Rick Han, University of Colorado at Boulder

Window Flow Control: Receive Side Last. Byte. Received Receive buffer ACKed and delivered Acked but not delivered to user Rcvd not acked Flow control window Advertised to sender Last. Byte. Read Next. Byte. Expected Prof. Rick Han, University of Colorado at Boulder Window slides As data is ACK’ed

TCP Persist • Flow control: slow receiver advertises 0 window, stopping a fast sender – Sender cannot send until it receives ACK from receiver advertising window size > 0 – What if this ACK is lost? • Sender waits forever • TCP Persist state – Sender periodically sends 1 byte packets to force a new ACK – Receiver responds with ACK even if it can’t store the packet – Sender no longer waits forever Prof. Rick Han, University of Colorado at Boulder

TCP Adaptive Retransmission • TCP achieves reliability by retransmitting segments after: – A Timeout – Receiving 3 duplicate cumulative ACK’s • Two out-of-order segments arrive at receiver, but lowest unacknowledged segment has yet to arrive • Receiver repeats its highest received cumulative sequence # - hence duplicate cumulative ACK’s • Doesn’t wait for timeout : “fast retransmit” • Choosing the value of the Timeout – If too small, retransmit unnecessarily – If too large, poor throughput – Make this adaptive, to respond to changing congestion Prof. Rick Han, University of delays in Internet Colorado at Boulder

Initial Round-trip Estimator • Round trip times exponentially averaged: – New RTT estimate = a (old RTT estimate) + (1 - a) (new RTT) – Recommended value for a: 0. 8 - 0. 9 • 0. 875 for most TCP’s • Retransmission Timeout RTO = b RTT, where b = 2 – Thought to be large enough to provide enough cushion to prevent spurious retransmissions – …and small enough to keep throughput high – Every timer expires, retransmit segment Prof. Rick Han, University of Colorado at Boulder

RTT Retransmission Ambiguity A B Original trans RTO Sample RTT retrans A Original trans mission X missio B RTO n Sample RTT ACK Prof. Rick Han, University of Colorado at Boulder ACK retrans m ission

Karn/Partridge’s modified RTT Estimator • Basic problem: – If a sender has retransmitted a segment, then ACK for that segment may correspond to any of the retransmissions • Is RTT for first transmission or retransmission? • Solution: – Each time a segment is retransmitted: • Don’t average the RTT estimate with the current RTT sample • Also, Double the RTO – exponential backoff like Ethernet – If a segment has been transmitted only once and ACK’ed • Recalculate RTT estimate Prof. Rick Han, University of Colorado at Boulder

Jacobson/Karel’s Retransmission Timeout • Key observation: – Original smoothed RTT can’t keep up with wide/rapid variations in RTT • Solution: – Base RTO on both the average RTT and variance/standard deviation of RTT estimate – Objectives: • When stddev is large, want RTO to stay above the fray and not timeout too often – i. e. set RTO = Average RTT + N*stddev • When stddev is small, stay close to average Prof. Rick Han, University of RTT Colorado at Boulder

Jacobson/Karel’s Retransmission Timeout (2) Err = current RTT – Ave RTT A Next A = old A + g*Err, g=0. 125 Next Std Dev D = old D + h*(|Err|-old D), h=0. 25 RTO = A + 4 * Next D Prof. Rick Han, University of Colorado at Boulder