Transmission Control Protocol (TCP)

• Reliable, in-order unicast delivery between 2 processes
• congestion control (throttle sender when network overloaded)
• flow control (sender won’t overwhelm receiver)
• connection-oriented ($\Rightarrow$ connection set-up, stateful)
• does not provide: timing, minimum throughput guarantee, security

TCP Feature Summary

• Provides a completely reliable (no data duplication or loss), connection-oriented, full duplex byte stream transport service that allows two application processes to form a connection, send data either direction, and then terminate the connection

Non-trivial because the underlying IP service can lose, re-order, corrupt, delay, fragment, duplicate packets.

• TCP provides 3 main functionalities:
  • 1. Reliable data transfer (see chapter 2, pipelined retransmission mechanism with two twists: smart acknowledgement management and adaptive window size)
  • 2. Congestion control
  • 3. Flow Control
• TCP is connection-oriented: need to create and close a logical connection, to maintain state

TCP segment structure

TCP reliable data transfer (rdt):

• TCP creates rdt service on top of IP’s unreliable service
  • pipelined segments
  • cumulative acks
  • single retransmission timer
• retransmissions triggered by:
  • timeout events
  • duplicate acks
  • no NACK

Note

Let’s initially consider simplified TCP sender:

• ignore duplicate acks
• ignore flow control, congestion control (the window size is fixed)

TCP sequence number:

• byte stream “number” of first byte in segment’s data

TCP Acknowledgement:

• seq # of next byte expected from other side
• cumulative ACK

How receiver handles out-of-order segments?

TCP spec doesn’t say, - up to implementor

TCP round trip time, timeout

How to set TCP timeout value?

• longer than RTT, but RTT varies!
• too short: premature timeout, unnecessary retransmissions
• too long: slow reaction to segment loss

How to estimate RTT?

• SampleRTT: measured time from segment transmission until ACK receipt
  • ignore retransmissions, cumulatively ACKed segments so quite rough…
• SampleRTT will vary, want estimated RTT “smoother”
  • average several recent measurements, not just current SampleRTT
• In many TCP implementations the minimum value of Timeout is 500 ms due to the clock granularity

• exponential weighted moving average (EWMA)
• influence of past sample decreases exponentially fast
• typical value: $\alpha =0.125$

TCP Sender (simplified)

Event: data received from application

• create segment with seq #
• seq # is byte-stream number of first data byte in segment
• start timer if not already running
  • think of timer as for oldest unACKed segment
  • expiration interval: TimeOutInterval

Event: timeout

• retransmit segment that caused timeout
• restart timer

Event: ACK received

• if ACK acknowledges previously unACKed segments
  • update what is known to be ACKed
  • start timer if there are still unACKed segments

TCP fast retransmit

TCP fast retransmit

if sender receives 4 ACKs for same data (“triple duplicate ACKs”), resend unacked segment with smallest seq #

• likely that unacked segment lost, so don’t wait for timeout

• time-out period often relatively long:
  • long delay before resending lost packet
• detect lost segments via duplicate ACKs.
  • sender often sends many segments back-to-back
  • if segment is lost, there will likely be many duplicate ACKs.

TCP flow control

What happens if network layer delivers data faster than application layer removes data from socket buffers?

Flow control

receiver controls sender, so sender won’t overflow receiver’s buffer by transmitting too much, too fast!

• TCP receiver “advertises” free buffer space in rwnd field in TCP header
  • RcvBuffer size set via socket options (typical default is 4096 bytes)
  • many OS auto adjust RcvBuffer
• sender limits amount of unACKed (“in-flight”) data to received rwnd
• Under normal conditions, receive buffer will not overflow

TCP connection management

before exchanging data, sender/receiver “handshake”:

• agree to establish connection (each knowing the other willing to establish connection)
• agree on connection parameters (e.g., starting seq #s)

Agreeing to establish a connection

Will 2-way handshake always work in network?

• variable delays
• retransmitted messages (e.g. req_conn(x)) due to message loss
• message reordering
• can’t “see” other side

TCP’s Startup/Shutdown Solution:

• Uses three-message exchange
• Known as 3-way handshake
• Necessary and sufficient for
  • Unambiguous, reliable startup
  • Unambiguous, graceful shutdown
• SYN used for startup
• FIN used for shutdown

Closing a TCP connection

• client server each close their side of connection
  • send TCP segment with FIN bit = 1.
• respond to received FIN with ACK
  • on receiving FIN, ACK can be combined with own FIN
• simultaneous FIN exchanges can be handled