Chapter%205%20TCP%20Handshakes,%20Sliding%20Window%20Flow%20Control

1
Chapter 5TCP Handshakes, Sliding Window Flow
Control

• Professor Rick Han
• University of Colorado at Boulder
• rhan_at_cs.colorado.edu

2
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
  1159 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
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
Two-Way Handshake
Handshake pictures courtesy of UMass Amherst
5
Two-Way Handshake Failure
6
Two-Way Handshake W/ Timers
7
3-way Handshake Unique IDs
Server (passive)
Client (active)

• Both sender and receiver choose unique IDs to
  label their (x,y) connection
• x chosen by Sender, y by receiver
• Prevents Failure scenario in two-way handshakes
  w/o timers

8
3-way Handshake Prevents Failure
Choose x, Send req_conn(x)
Req_conn(x)
Send accept connection, Choose y, ACK x
Timeout, resend req_conn(x)
Acc_conn(x,y)
ACK y, Send data (x1)
Data(x1,y)
Receive data
Timeout, resend Data(x1)
Connection closes
Req_conn(x)
Send acc_conn, Choose unique y
Data(x1,y)
Drop data packet from old (x,y)
connection, Accept only (xN,y)
Acc_conn(x,y)
9
3-way Handshake TCP SYN/ACK
TCP Server (passive)
TCP Client (active)
Both A and B choose Unique IDs for the
connection x is starting sequence for A-gtB, y
is starting sequence for B-gtA
10
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
• ltsource IP, source port, dest IP, dest portgt
• In UDP, socket buffer named by ltdest IP, dest
  portgt

11
TCP State Machine Connection Setup Only
CLOSED
active OPEN
create TCB Send SYN
passive OPEN
Appl CLOSE
create TCB
delete TCB
Appl CLOSE or timeout
LISTEN
delete TCB
Appl wants to SEND
rcv SYN
SYN SENT
SYN RCVD
send SYN
send SYN ACK
rcv SYN
snd SYN ACK
Rcv SYN, ACK
rcv ACK of SYN
Send ACK data
CLOSE
ESTAB
Send FIN
Courtesy Srini Seshan
12
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 cant be made
  Denial of service !
• Solutions
• If firewall stops SYNs 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
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 B
TCP A

• (CRASH)
• CLOSED
• SYN-SENT ? ltSEQ400gtltCTLSYNgt
• (!!) ? ltSEQ300gtltACK100gtltCTLACKgt
• SYN-SENT ? ltSEQ100gtltCTLRSTgt
• SYN-SENT
• SYN-SENT ? ltSEQ400gtltCTLSYNgt

• (send 300, receive 100)
• ESTABLISHED
• (??)
• ESTABLISHED
• ? (Abort!!)
• CLOSED
• ?

14
TCP Connection Tear-down two FIN/FIN-ACKs
Sender
Receiver
FIN_WAIT1
FIN
FIN-ACK
Half-closed CLOSE_WAIT State (passive)
FIN_WAIT2
Data write
Data ack
LAST_ACK state
FIN
TIME_WAIT
FIN-ACK
Either server or client can be sender and
initiate FIN tear-down
15
TCP State Machine Connection Tear-down Only
CLOSE
ESTAB
send FIN
CLOSE
rcv FIN
send FIN
send ACK
CLOSE WAIT
FIN WAIT-1
rcv FIN
CLOSE
snd ACK
Rcv ACK
snd FIN
rcv FINACK
FIN WAIT-2
CLOSING
LAST-ACK
snd ACK
rcv ACK of FIN
rcv ACK of FIN
TIME WAIT
CLOSED
rcv FIN
Timeout2msl
snd ACK
delete TCB
Courtesy Srini Seshan
16
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

13450
14950
16050
17550
segment 14950
segment 13450
segment 16050
17
Sequence Numbers (2)

• Acknowledgements also have sequence s
• Cumulative ACKs list the sequence of the next
  byte theyre expecting
• if sequence 13449 has been received, then put
  13450 in cumulative ACK
• TCP resembles Go-Back N when using cumulative
  ACKs
• Also, have semi-selective ACKs
• SACK-TCP

18
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 theres a TCP extension
• Advertised window must be greater than typical
  bandwidthdelay product, to fill pipe
• This is a problem, so theres a TCP extension

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

20
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 receivers window size in TCP
  header
• Indicates number of bytes the receiver has space
  for starting from the highest sequence of
  ACKed data

21
Window Flow Control Send Side
Flow control window Advertised by receiver
Window slides As data is ACKed
Sent but not acked
Not yet sent
Sent and acked
LastByteWritten
LastByteSent
LastByteACKed by receiver
22
Window Flow Control Send Side
Packet Received
Packet Sent
Source Port
Dest. Port
Source Port
Dest. Port
Sequence Number
Sequence Number
Acknowledgment
Acknowledgment
HL/Flags
Window
HL/Flags
Window
D. Checksum
Urgent Pointer
D. Checksum
Urgent Pointer
Options..
Options..
App write
acknowledged
sent
to be sent
outside window
23
Window Flow Control Receive Side
LastByteReceived
Receive buffer
Acked but not delivered to user
Rcvd not acked
ACKed and delivered
Window slides As data is ACKed
Flow control window Advertised to sender
LastByteRead
NextByteExpected
24
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 gt 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 cant store
  the packet
• Sender no longer waits forever

25
TCP Adaptive Retransmission

• TCP achieves reliability by retransmitting
  segments after
• A Timeout
• Receiving 3 duplicate cumulative ACKs
• 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 ACKs
• Doesnt 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
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 TCPs
• 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 time timer expires, retransmit segment

27
RTT Retransmission Ambiguity
A
B
Original transmission
X
RTO
Sample RTT
retransmission
ACK
28
Karn/Partridges 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
• Dont 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
  ACKed
• Recalculate RTT estimate

29
Jacobson/Karels Retransmission Timeout

• Key observation
• Original smoothed RTT cant 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 Nstddev
• When stddev is small, stay close to average RTT

30
Jacobson/Karels Retransmission Timeout (2)

• Err current RTT Ave RTT A
• Next A old A gErr, g0.125
• Next Std Dev D old D h(Err-old D), h0.25
• RTO A 4 Next D