736 TCP Optimizations and QUIC for IoT

Learning Objectives

By the end of this section, you will be able to:

Apply TCP optimization techniques for constrained IoT networks
Understand lightweight TCP implementations for embedded systems
Evaluate QUIC as a modern transport protocol alternative
Calculate and compare protocol overhead for IoT scenarios

736.1 Prerequisites

Before diving into this chapter, you should be familiar with:

Transport Protocol Fundamentals: Understanding TCP characteristics and overhead
Protocol Selection: Knowing when TCP is the right choice

Key Takeaway

In one sentence: When TCP is required, optimizations like connection keep-alive, TCP Fast Open, and lightweight stacks can significantly reduce overhead.

Remember this: QUIC combines UDP’s low latency with TCP’s reliability, potentially offering the best of both worlds for capable IoT devices.

Related Chapters

Prerequisites: - Transport Protocol Fundamentals - TCP/UDP basics - Protocol Selection - When to use TCP

Deep Dives: - Transport Protocols Overview - Index page - Decision Framework - Detailed matrices

736.2 TCP Optimizations for IoT

While UDP is often preferred for IoT, sometimes TCP is necessary. Several optimizations exist to reduce overhead.

736.2.1 TCP Connection Keep-Alive

Problem: TCP handshake overhead for every message

Solution: Keep connection open for multiple transmissions

Trade-off: Memory for connection state vs power for repeated handshakes

Best for: Devices transmitting frequently (e.g., every minute)

Without Keep-Alive (connect per message):
  Message 1: Handshake (78 bytes) + Data + Teardown (104 bytes)
  Message 2: Handshake (78 bytes) + Data + Teardown (104 bytes)
  ...
  Overhead per message: 182+ bytes

With Keep-Alive:
  Initial: Handshake (78 bytes)
  Message 1: Data + ACK (62 bytes)
  Message 2: Data + ACK (62 bytes)
  ...
  Periodic keep-alive: 26 bytes every 60-120 seconds
  Overhead per message: 62+ bytes (66% reduction)

736.2.2 TCP Fast Open (TFO)

RFC 7413: Allows data in SYN packet (reduces handshake to 1-RTT)

Standard TCP:

Client -> Server: SYN
Server -> Client: SYN-ACK
Client -> Server: ACK + Data (first data after 1.5 RTT)

TCP Fast Open:

Client -> Server: SYN + Cookie + Data (data in first packet!)
Server -> Client: SYN-ACK + Data
Total: 1 RTT for first data

Benefits: - Faster connection establishment - Reduced latency for short connections - Saves one round trip

Limitations: - Not widely deployed in IoT yet - Requires TFO cookie from previous connection - Server must support TFO

736.2.3 Lightweight TCP Implementations

Implementation	Code Size	Features	Best For
uIP	4-10 KB	Minimal TCP/IP	8-bit MCUs, extremely constrained
lwIP	40-100 KB	Full-featured, configurable	32-bit MCUs, more RAM
PicoTCP	50-150 KB	Modular, POSIX-like	Linux-like environments
Linux TCP	~500 KB	Full featured	Gateways, edge devices

uIP (Micro IP): - Single packet at a time (no send/receive windows) - No support for urgent data - Simple retransmission (fixed timeout) - Fits in 4 KB code, 1-2 KB RAM

lwIP (Lightweight IP): - Configurable features (enable/disable as needed) - Supports multiple connections - Full TCP with windows, selective ACK - Common in ESP32, STM32 projects

736.2.4 Application-Level Optimizations

MQTT Keep-Alive: Maintain TCP connection with periodic pings - Keep-alive interval: 60-120 seconds typical - Prevents NAT timeout - Detects dead connections

HTTP Persistent Connections: HTTP/1.1 connection reuse - Single TCP connection for multiple requests - Eliminates handshake per request

CoAP over TCP: RFC 8323, combines CoAP efficiency with TCP reliability - For networks where UDP is problematic (firewalls, NAT) - Maintains CoAP’s lightweight message format

736.3 QUIC Protocol for IoT

Deep Dive: QUIC Protocol for IoT Applications

QUIC (Quick UDP Internet Connections) is a modern transport protocol originally developed by Google and now standardized as RFC 9000. While TCP and UDP dominate IoT today, QUIC offers compelling advantages for next-generation IoT applications.

736.3.1 What is QUIC?

QUIC is a UDP-based transport protocol that combines TCP’s reliability with UDP’s low latency, while integrating TLS 1.3 encryption:

Traditional Stack:           QUIC Stack:
+------------------+        +------------------+
|   Application    |        |   Application    |
+------------------+        +------------------+
|       TLS        |        |                  |
+------------------+        |      QUIC        |
|       TCP        |        |  (includes TLS)  |
+------------------+        +------------------+
|       IP         |        |       UDP        |
+------------------+        +------------------+
                            |       IP         |
                            +------------------+

736.3.2 Key Features Relevant to IoT

1. 0-RTT Connection Resumption

For repeated connections (common in IoT telemetry), QUIC can send application data immediately:

First Connection:                  Subsequent Connections:
Client          Server            Client              Server
  |                |                |                    |
  |--- ClientHello -->              |--- 0-RTT Data ---> |
  |<-- ServerHello ---|             |<-- Response -------|
  |--- Finished ----->              |                    |
  |<-- Finished ------|             Total: 0 RTT
  |--- Data --------->
  Total: 1 RTT (vs TCP+TLS: 3 RTT)

IoT Impact: Battery-powered sensors can save 2 round trips (100-500ms) per connection, reducing radio-on time by 30-60%.

2. Multiplexed Streams Without Head-of-Line Blocking

QUIC allows multiple independent streams. Unlike TCP, packet loss on one stream doesn’t block others:

TCP with HTTP/2:                    QUIC:
Stream 1: [Pkt1][Pkt2][----]       Stream 1: [Pkt1][Pkt2][----]  <- Waiting
Stream 2: [Pkt3][Pkt4][ BLOCKED ]  Stream 2: [Pkt3][Pkt4][Pkt5]  <- Continues!
Stream 3: [Pkt5][ BLOCKED ]        Stream 3: [Pkt6][Pkt7]        <- Continues!

Lost Pkt2 blocks ALL streams       Lost Pkt2 only affects Stream 1

IoT Impact: A gateway multiplexing data from 10 sensors can continue sending data for 9 sensors even if one sensor’s packet is lost.

3. Connection Migration

QUIC connections are identified by Connection ID, not IP:port. Connections survive address changes:

Before Network Switch:              After:
192.168.1.50:54321 -> Server       10.0.0.75:42000 -> Server
Connection ID: 0xABCD              Connection ID: 0xABCD (same!)
                                   Connection continues without reset!

IoT Impact: Mobile sensors (vehicles, wearables) can switch between Wi-Fi and cellular without losing connection.

4. Built-in Encryption (Always On)

QUIC mandates TLS 1.3 encryption with no fallback to plaintext:

QUIC Packet Structure:
+------------------+------------------+------------------+
|   Header (clear) |  Payload (encrypted)                |
|  Conn ID, PN     |  Stream Data, ACKs, Control        |
+------------------+------------------+------------------+
                   ^
                   Everything here is authenticated and encrypted

IoT Impact: Eliminates the separate DTLS handshake overhead while providing equivalent security.

736.3.3 QUIC vs TCP/UDP for IoT: Comparison

Metric	TCP+TLS	UDP+DTLS	QUIC
Initial handshake	3 RTT	2-3 RTT	1 RTT
Resumed connection	1-2 RTT	1 RTT	0 RTT
Header overhead	20-60 + 25 bytes	8 + 13 bytes	16-25 bytes
Packet loss impact	All streams blocked	Application handles	Per-stream only
Network migration	Connection drops	Application handles	Transparent
Encryption	Optional (TLS)	Optional (DTLS)	Mandatory

736.3.4 Implementation Considerations

Memory Requirements:

Lightweight TCP stack (uIP):     4-10 KB code, 1-2 KB RAM per connection
Lightweight UDP:                 2-4 KB code, minimal RAM
QUIC (minimal):                  50-100 KB code, 10-20 KB RAM per connection
QUIC (full featured):            200-500 KB code, 50-100 KB RAM per connection

When QUIC Makes Sense for IoT: - Devices with >= 256 KB flash, >= 64 KB RAM (ESP32, RPi, gateways) - High-latency networks (satellite, cellular with 100ms+ RTT) - Mobile devices that switch networks frequently - Multiplexed traffic patterns (gateway aggregating sensors) - Always-encrypted requirements (healthcare, finance)

When to Stick with TCP/UDP: - Severely constrained devices (< 64 KB RAM) - Static networks with low latency (< 20 ms RTT) - Simple telemetry patterns (single sensor, infrequent reports) - Legacy system integration requirements

736.3.5 Energy Analysis: QUIC vs TCP+TLS

Scenario: Sensor sending 100-byte reading every 60 seconds over 100ms RTT network

TCP+TLS (new connection each time):
Handshake: 3 RTT x 100ms = 300ms active
Data transfer: 1 RTT = 100ms active
Total per reading: 400ms radio time
Daily (1440 readings): 576 seconds active

QUIC (0-RTT resumption):
Data transfer: 0 RTT (piggybacked on first packet)
Response: 1 RTT = 100ms active
Total per reading: 100ms radio time
Daily (1440 readings): 144 seconds active

Energy savings: 75% reduction in radio-on time!

736.3.6 Migration Strategy

Phase 1: QUIC for gateway-to-cloud (immediate benefit)
Phase 2: QUIC for capable edge devices
Phase 3: CoAP-over-QUIC for constrained devices (when mature)

736.4 Knowledge Check

Quiz: TCP Optimizations

Question: TCP’s congestion control (slow start, congestion avoidance) is designed for internet traffic. How does this affect IoT over cellular (NB-IoT, LTE-M)?

Explanation: TCP slow start is problematic for IoT:

TCP slow start begins with small congestion window (1-2 packets), requiring multiple round trips to ramp up. For small IoT payloads (single packet), transmission finishes before window grows.

Problem for 100-byte sensor reading: - TCP slow start: Send 1 segment, wait for ACK (100-200ms cellular RTT) - Total time: ~500ms for 100 bytes - Radio stays in high-power state entire time

Cellular radio states (NB-IoT): - RRC Connected: High power (~200 mW) - RRC Idle: Low power (~10 mW) - Transition Idle -> Connected: 1-2 seconds

Result: TCP slow start keeps radio active longer, wasting battery. UDP sends immediately and returns to idle.

Question: TCP requires 3-way handshake before data transmission. For a sensor sending a single 50-byte message, approximately how many total packets and bytes are transmitted?

Explanation: Full TCP transaction for small message:

Connection Establishment:
- SYN: 40-60 bytes
- SYN-ACK: 40-60 bytes
- ACK (can carry data): 40 + 50 = 90 bytes
Data Acknowledgment:
- ACK: 40 bytes
Connection Termination:
- FIN: 40 bytes
- FIN-ACK (combined): 40 bytes

Total: 6-7 packets, ~280-330 bytes

Compare to UDP: Single datagram = 50 + 8 + 20 = 78 bytes

TCP uses 3.6x more bytes for same 50-byte payload!

736.5 Summary

Key Takeaways

TCP Optimizations: - Connection Keep-Alive: Amortize handshake over multiple messages - TCP Fast Open: Data in SYN packet (1 RTT instead of 1.5) - Lightweight Stacks: uIP (4-10 KB), lwIP (40-100 KB) - Application Batching: Combine multiple readings before send

QUIC Benefits: - 0-RTT resumption: Data in first packet for repeat connections - No head-of-line blocking: Streams independent - Connection migration: Survives IP address changes - Built-in encryption: TLS 1.3 mandatory

When to Optimize TCP vs Switch to UDP: - TCP optimization worthwhile for: frequent transmissions, reliable network - Switch to UDP for: infrequent transmissions, lossy network, battery critical

Memory Requirements: - uIP: 4-10 KB code, 1-2 KB RAM - lwIP: 40-100 KB code, configurable RAM - QUIC: 50-500 KB code, 10-100 KB RAM

736.6 What’s Next?

Continue to Transport Protocol Decision Framework to explore detailed decision matrices, comprehensive quizzes, and common pitfalls to avoid.