Presentation is loading. Please wait.

Presentation is loading. Please wait.

Chapter 5 TCP Handshakes, Sliding Window Flow Control Professor Rick Han University of Colorado at Boulder

Similar presentations


Presentation on theme: "Chapter 5 TCP Handshakes, Sliding Window Flow Control Professor Rick Han University of Colorado at Boulder"— Presentation transcript:

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

2 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

3 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: Sequence #’s in both directions (full-duplex) Flow control window Checksum TCP Connection Setup Three-way Handshake

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

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

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

7 Prof. Rick Han, University of Colorado at Boulder 3-way Handshake: Unique ID’s 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 timers Client: (active) Server (passive)

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

9 Prof. Rick Han, University of Colorado at Boulder 3-way Handshake: TCP SYN/ACK 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 TCP Client (active) TCP Server (passive)

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

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

12 Prof. Rick Han, University of Colorado at Boulder 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 Source filtering of spoofed IP addresses

13 Prof. Rick Han, University of Colorado at Boulder Detecting Half-open Connections 1.(CRASH) 2.CLOSED 3.SYN-SENT  4.(!!)  5.SYN-SENT  6.SYN-SENT 7.SYN-SENT  (send 300, receive 100) ESTABLISHED  (??)  ESTABLISHED  (Abort!!) CLOSED  TCP BTCP A 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

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

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

16 Prof. Rick Han, University of Colorado at Boulder 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 1st byte –Variably sized, with Maximum Segment Size (MSS) –Segments passed down to IP –Segments are retransmitted segment 13450 segment 14950 segment 16050 13450149501605017550

17 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

18 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

19 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!

20 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

21 Prof. Rick Han, University of Colorado at Boulder Window Flow Control: Send Side Sent but not ackedNot yet sent Flow control window Advertised by receiver LastByteSent Sent and acked LastByteACKed by receiver LastByteWritten Window slides As data is ACK’ed

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

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

24 Prof. Rick Han, University of Colorado at Boulder 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

25 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 delays in Internet

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

27 Prof. Rick Han, University of Colorado at Boulder RTT Retransmission Ambiguity AB ACK Sample RTT Original transmission retransmission RTO AB Original transmission retransmission Sample RTT ACK RTO X

28 Prof. Rick Han, University of Colorado at Boulder 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

29 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 RTT

30 Prof. Rick Han, University of 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


Download ppt "Chapter 5 TCP Handshakes, Sliding Window Flow Control Professor Rick Han University of Colorado at Boulder"

Similar presentations


Ads by Google