TCP - Transmission Control Protocol

* IP/UDP have some problems:
    * Unreliable
    * No flow control
    * Enforced message boundaries (?)

* TCP is a layer atop IP repairing most of these

* (First of two lectures)

TCP Design Principles

* Provide the illusion of a "connection" by
  hiding message boundaries

* Provide reliability by ARQ

* Provide flow control by ARQ
  * Use windowing to make this efficient

TCP Endpoints

* Like UDP: <IP, Port>
  * A TCP connection is uniquely identified by its (two)
    endpoints
  
* TCP is bidirectional
  * A TCP connection inherently sets up a path in each
    direction
  * The protocol ties the packets flowing in opposite
    directions tightly together

* Typically, "server" ports are given "known" numbers,
  whereas "client ports" are chosen by the OS

Evolution of TCP

* TCP has scaled wildly
  * Over time
  * Across application domains

* TCP was not (sufficiently) carefully
  specified or designed: "mass of kludges"

* Lots of historical detritus

General TCP Flow

* Connection is established (next week)

* Each side starts sending "segments" of data

* As data is successfully received, it is ACKed
  * ACK packets are usually "piggybacked" on
    returning data

* ACKs contain a "window"
  * A sender must not send data beyond what the window
    allows

How TCP Copes With Problems

* Lost data: If an ACK for sent data is not received by
  expected time, it is sent again (ARQ)

* Clogged host: If the receiver needs time or space
  to process data, it allows the window to close

Engineering Tradeoffs: Throughput, Latency, Efficiency

* Ideally, TCP would send data immediately when the
  application requests it (and it would be processed
  immediately when received)

* In real life, immediate transmission leads to problems:
  * Bad packet efficiency for tiny packets
  * Impossible when receiver is swamped

* Tradeoffs were different in 1980 than they are today

Delayed ACK

* Instead of trying to ACK data as it is received, hold
  the ACK
  * To piggyback on returning data
  * To subsume with subsequent ACK

* Obviously cannot delay ACKs too long, or host will
  gratuitously retransmit data
  * Timeouts suck, but there we are

Nagling

* Avoid tinygrams by reverting to stop-and-wait; only
  send a tinygram when all outstanding data has been ACKed

* Trades throughput for latency
  * Probably not what is wanted on interactive connections
  * Can (and sometimes should) be disabled per-connection

Message Boundaries

* Two basic approaches
  * TCP connection per message (HTTP)
    * Simple
    * High network overhead
    * Low OS overhead (?)
  * Re-frame using escape protocol or inner protocol

* May choose to use SCTP or RTP instead of TCP

TCP By Default

* When in doubt, you should be using TCP from your
  applications
  * Many years of engineering
  * What the network expects and is optimized for

* Think hard before "starting over" building reliable
  flow-controlled protocols

* UDP when you don't need reliability or flow-control
  * e.g. PSAS telemetry data