Transport Layer — TCP & UDP

TCP vs UDP — The Tradeoff

Analogy: - TCP = registered mail with delivery confirmation. Slower, but guaranteed to arrive in order. - UDP = dropping a postcard in a mailbox. Fast and cheap, but no guarantee it arrives.

┌────────────────┬──────────────────────────┬───────────────────────┐
│                │ TCP                      │ UDP                   │
├────────────────┼──────────────────────────┼───────────────────────┤
│ Connection     │ Required (3-way handshake│ None (connectionless) │
│ Reliability    │ Guaranteed delivery      │ Best effort           │
│ Order          │ In-order delivery        │ May arrive out of order│
│ Speed          │ Slower (overhead)        │ Faster                │
│ Header size    │ 20+ bytes                │ 8 bytes               │
│ Use cases      │ HTTP, FTP, email         │ DNS, video streaming  │
└────────────────┴──────────────────────────┴───────────────────────┘

---

TCP 3-Way Handshake — Connection Setup

Client                          Server
  |                               |
  |──── SYN (seq=x) ─────────────→|  "I want to connect, my seq starts at x"
  |                               |
  |←── SYN-ACK (seq=y, ack=x+1) ─|  "OK, my seq is y, I received x"
  |                               |
  |──── ACK (ack=y+1) ───────────→|  "Got it, connection established!"
  |                               |
  [Connection established, data can flow]

Connection termination (4-way):

Client                          Server
  |──── FIN ───────────────────→  |  "I'm done sending"
  |←─── ACK ──────────────────── |  "Acknowledged"
  |←─── FIN ──────────────────── |  "I'm also done sending"
  |──── ACK ───────────────────→  |  "Acknowledged"
  [Connection closed]

---

TCP Flow Control — Receiver Controls the Sender

Problem: What if the sender sends faster than the receiver can process?

Solution: Receiver advertises its buffer space (rwnd) in every ACK.

Sender must keep:  bytes_in_flight ≤ min(cwnd, rwnd)

rwnd = receiver window = available buffer space at receiver
cwnd = congestion window = sender's estimate of network capacity

If receiver advertises rwnd = 0, sender stops.
Zero window probe: sender periodically sends 1-byte probes to check if window reopened.

---

TCP Congestion Control — The Big GATE Topic

Problem: Network can get congested (too many packets). TCP detects and responds.

4 Phases

Phase 1: SLOW START (exponential growth)
  cwnd = 1 MSS initially
  Each ACK received → cwnd += 1 MSS
  Effect: cwnd DOUBLES every RTT (exponential!)
  Stop when: cwnd reaches ssthresh (slow start threshold)

Phase 2: CONGESTION AVOIDANCE (linear growth)
  Each RTT → cwnd += 1 MSS (additive increase)
  Much slower growth — probing for more bandwidth carefully

Phase 3: FAST RETRANSMIT (when 3 duplicate ACKs received)
  3 duplicate ACKs = segment lost but network still working
  Retransmit immediately WITHOUT waiting for timeout

Phase 4: FAST RECOVERY (after fast retransmit)
  ssthresh = cwnd/2
  cwnd = ssthresh + 3 MSS
  Continue congestion avoidance

On Events

Event: TIMEOUT (severe congestion)
  ssthresh = cwnd / 2
  cwnd = 1 MSS
  Enter slow start

Event: 3 DUPLICATE ACKs (mild congestion)
  ssthresh = cwnd / 2
  cwnd = ssthresh   (Tahoe: goto 1; Reno: = ssthresh, stay in congestion avoidance)
  Fast retransmit the lost packet

TCP Tahoe:  always goes to cwnd=1 on loss
TCP Reno:   distinguishes timeout (cwnd=1) vs duplicate ACK (cwnd = ssthresh)

GATE Trace Example:

ssthresh = 8, cwnd starts at 1

RTT 1: cwnd=1 (slow start)
RTT 2: cwnd=2 (doubles)
RTT 3: cwnd=4
RTT 4: cwnd=8 ← reached ssthresh, switch to congestion avoidance
RTT 5: cwnd=9 (+1 per RTT now)
RTT 6: cwnd=10
...
RTT X: timeout occurs at cwnd=12
  ssthresh = 12/2 = 6
  cwnd = 1
  Back to slow start!

---

Port Numbers

Well-known ports (0-1023):   HTTP=80, HTTPS=443, FTP=20/21, SMTP=25, DNS=53, SSH=22
Registered ports (1024-49151)
Dynamic/ephemeral (49152-65535): assigned by OS for client connections

Socket = (IP address, port number) — uniquely identifies one endpoint
Connection = (src_IP, src_port, dst_IP, dst_port) — uniquely identifies one TCP connection

---

Quick Check

Q1. TCP cwnd = 16, ssthresh = 8, 3 duplicate ACKs received. New cwnd and ssthresh (Reno)?

ssthresh = 16/2 = 8
cwnd = ssthresh = 8 (Reno: fast recovery, not back to 1)

Q2. Why does TCP use 3-way handshake instead of 2-way? Answer: 2-way only confirms the client can send to server. The 3rd message (ACK from client) confirms the server can also send to the client — both directions are verified. Also prevents old duplicate connection requests from creating "ghost" connections.

Q3. Video streaming (YouTube) uses UDP or TCP? Why? Answer: UDP (with QUIC or RTSP protocols). Streaming prefers speed over perfect reliability — if one video packet is late, it is better to skip it than to wait. TCP's retransmissions would cause pauses/buffering.