%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#16A085', 'secondaryColor': '#E67E22', 'tertiaryColor': '#7F8C8D', 'fontSize': '14px'}}}%%
flowchart TB
subgraph TCP["TCP: Connection-Oriented"]
TCP1["3-Way Handshake<br/>(SYN, SYN-ACK, ACK)"]
TCP2["Data Transfer<br/>with ACKs"]
TCP3["Flow Control<br/>(Sliding Window)"]
TCP4["Congestion Control<br/>(Slow Start, AIMD)"]
TCP5["Connection Teardown<br/>(FIN, FIN-ACK)"]
TCP1 --> TCP2 --> TCP3 --> TCP4 --> TCP5
end
subgraph UDP["UDP: Connectionless"]
UDP1["No Handshake"]
UDP2["Fire-and-Forget<br/>Data Transfer"]
UDP3["No Flow Control"]
UDP4["No Congestion Control"]
UDP5["No Connection State"]
UDP1 -.-> UDP2 -.-> UDP3 -.-> UDP4 -.-> UDP5
end
subgraph COMPARE["Key Differences"]
C1["Overhead: TCP 20-60B vs UDP 8B"]
C2["Latency: TCP variable vs UDP predictable"]
C3["State: TCP 1KB+ vs UDP stateless"]
C4["Energy: TCP 5-10× vs UDP baseline"]
end
TCP --> COMPARE
UDP --> COMPARE
style TCP fill:#2C3E50,stroke:#16A085,stroke-width:3px,color:#fff
style UDP fill:#16A085,stroke:#2C3E50,stroke-width:3px,color:#fff
style COMPARE fill:#E67E22,stroke:#2C3E50,stroke-width:2px,color:#fff
style TCP1 fill:#34495E,stroke:#16A085,stroke-width:1px,color:#fff
style TCP2 fill:#34495E,stroke:#16A085,stroke-width:1px,color:#fff
style TCP3 fill:#34495E,stroke:#16A085,stroke-width:1px,color:#fff
style TCP4 fill:#34495E,stroke:#16A085,stroke-width:1px,color:#fff
style TCP5 fill:#34495E,stroke:#16A085,stroke-width:1px,color:#fff
style UDP1 fill:#1ABC9C,stroke:#2C3E50,stroke-width:1px,color:#fff
style UDP2 fill:#1ABC9C,stroke:#2C3E50,stroke-width:1px,color:#fff
style UDP3 fill:#1ABC9C,stroke:#2C3E50,stroke-width:1px,color:#fff
style UDP4 fill:#1ABC9C,stroke:#2C3E50,stroke-width:1px,color:#fff
style UDP5 fill:#1ABC9C,stroke:#2C3E50,stroke-width:1px,color:#fff
style C1 fill:#F39C12,stroke:#2C3E50,stroke-width:1px,color:#000
style C2 fill:#F39C12,stroke:#2C3E50,stroke-width:1px,color:#000
style C3 fill:#F39C12,stroke:#2C3E50,stroke-width:1px,color:#000
style C4 fill:#F39C12,stroke:#2C3E50,stroke-width:1px,color:#000
755 Transport Review: Protocol Selection and Trade-offs
755.1 Learning Objectives
By the end of this chapter, you will be able to:
- Summarize TCP and UDP: Understand key characteristics and IoT use cases
- Apply selection criteria: Choose protocols based on reliability, latency, power, and security
- Analyze trade-offs: Evaluate TCP retransmission vs UDP application-layer retry
- Compare architectures: Understand connection-oriented vs connectionless design
755.2 Prerequisites
Required Chapters:
- Transport Fundamentals - TCP/UDP basics
- Transport Optimizations - IoT adaptations
Estimated Time: 30 minutes
755.3 Key Takeaways
UDP (User Datagram Protocol):
- Connectionless, unreliable, lightweight
- 8-byte header, minimal overhead
- Best for: Real-time, periodic data, power-constrained
- IoT uses: CoAP, MQTT-SN, telemetry, streaming
TCP (Transmission Control Protocol):
- Connection-oriented, reliable, ordered delivery
- 20-60 byte header, connection overhead
- Best for: Critical data, firmware updates, ordered delivery
- IoT uses: MQTT, HTTP, configuration, file transfer
DTLS (Datagram Transport Layer Security):
- Secure UDP: Encryption + authentication for datagrams
- Based on TLS, adapted for unreliable transport
- Overhead: 13+ bytes per record, handshake cost
- Best for: Secure CoAP (CoAPS), secure real-time
- IoT uses: CoAP over DTLS, secure telemetry
Selection Criteria:
- Reliability: TCP if critical, UDP if tolerable loss
- Latency: UDP for real-time, TCP if not time-sensitive
- Power: UDP more efficient (no connection state, ACKs)
- Security: DTLS for UDP, TLS for TCP
- Overhead: UDP 8 bytes, TCP 20-60 bytes
- Application: CoAP (UDP), MQTT (TCP)
Best Practices:
- Use UDP for telemetry, real-time, power-constrained
- Use TCP for firmware, configuration, critical commands
- Add DTLS for security on UDP
- Keep TCP connections alive for frequent transmissions
- Application-level reliability (CoAP confirmable) on UDP
Transport protocol selection significantly impacts IoT system performance, power consumption, and reliability. Choose based on application requirements, not protocol popularity.
755.4 Protocol Trade-off Analysis
These tradeoff cards summarize key design decisions when selecting transport protocols for IoT deployments.
Option A (TCP Automatic Retransmission): TCP retransmits lost segments automatically with exponential backoff (RTO starts at 1s, doubles up to 64s). Retransmission is blind - all unacked data resent even if application no longer needs it. Head-of-line blocking: new data waits behind lost segment. Typical retransmission adds 200ms-2s latency per lost packet in IoT networks with 100ms RTT.
Option B (UDP with CoAP Confirmable): Application controls retry policy. CoAP default: 2s, 4s, 8s, 16s exponential backoff (4 retries max). Selective retry: only critical messages use Confirmable (CON), routine telemetry uses Non-confirmable (NON). No head-of-line blocking: new messages bypass old losses. Message deduplication via Message ID prevents duplicate processing.
Decision Factors: Choose TCP when every byte must arrive in order (file transfers, firmware), when retransmission logic complexity should be avoided, or when using TCP-only protocols (MQTT, HTTP). Choose UDP+CoAP when stale data has no value (sensor telemetry replaced by next reading), when selective reliability needed (critical alerts CON, routine data NON), or when head-of-line blocking is unacceptable (real-time control). Measured impact: In 10% loss network, TCP adds 2-5s latency due to blocking; CoAP CON adds 0.3s average with no blocking.
Option A (TCP Congestion Control): Implements slow start (exponential growth from 1 MSS), congestion avoidance (linear growth), and fast retransmit/recovery. Bandwidth ramps up over 10-20 RTT to reach link capacity. Fair to other TCP flows. Backs off on packet loss: halves congestion window. On lossy wireless (5% loss), throughput can be 10-50% of link capacity due to loss-triggered backoff.
Option B (UDP Best-Effort): No congestion control - sends at application rate. Full link utilization from first packet. Unfair to TCP flows (can starve them). No backoff on loss. Application must implement rate limiting to avoid overwhelming network. Risk: UDP flood can congest gateway, affecting all devices.
Decision Factors: Choose TCP when sharing network with other flows (fairness matters), when sustained throughput needed (large transfers), or when network congestion is a concern (cellular networks charge for retransmissions). Choose UDP when real-time timing matters more than fairness (voice/video), when bursts are small and infrequent (sensor telemetry every 5 min = no congestion concern), or when link is dedicated (point-to-point radio). For IoT: UDP is safe for low-rate sensors (<1 msg/sec); implement application-level rate limiting for higher rates to prevent self-congestion.
755.5 TCP vs UDP Architecture Comparison
TCP vs UDP architectural comparison showing connection-oriented TCP with handshakes, flow control, and congestion management versus connectionless UDP with minimal overhead. TCP provides reliability through 5-stage connection lifecycle (handshake, data with ACKs, flow control, congestion control, teardown) consuming 20-60 byte headers and 1KB+ state memory. UDP offers fire-and-forget delivery with 8-byte headers, no connection state, and predictable latency. Key trade-offs: TCP overhead 5-10× higher energy cost but guaranteed delivery; UDP baseline energy with application-layer reliability needed. IoT applications choose TCP for firmware updates and critical commands, UDP for telemetry and real-time streaming.
This variant shows the same TCP vs UDP differences from a resource consumption perspective - emphasizing what each protocol costs in terms of energy, memory, and time.
%% fig-alt: "TCP vs UDP resource cost comparison: TCP costs 5-10x energy (radio active during handshakes), 1KB+ memory (connection state), and 100+ ms latency (three-way handshake). UDP costs 1x baseline energy (fire-and-forget), near-zero memory (stateless), and minimal latency (immediate send). Shows why UDP is preferred for battery-powered IoT sensors."
%%{init: {'theme': 'base', 'themeVariables': { 'primaryColor': '#2C3E50', 'primaryTextColor': '#fff', 'primaryBorderColor': '#16A085', 'lineColor': '#E67E22', 'secondaryColor': '#16A085', 'tertiaryColor': '#7F8C8D', 'fontSize': '11px'}}}%%
flowchart LR
subgraph COSTS["Resource Costs per Transmission"]
direction TB
subgraph TCP_COST["TCP"]
T_E["Energy<br/>5-10×"]
T_M["Memory<br/>1KB+"]
T_L["Latency<br/>100+ms"]
end
subgraph UDP_COST["UDP"]
U_E["Energy<br/>1× baseline"]
U_M["Memory<br/>~0"]
U_L["Latency<br/>~1ms"]
end
end
subgraph IMPACT["IoT Impact"]
direction TB
TCP_IMP["Battery: months<br/>Nodes: hundreds<br/>Response: variable"]
UDP_IMP["Battery: years<br/>Nodes: thousands<br/>Response: instant"]
end
TCP_COST --> TCP_IMP
UDP_COST --> UDP_IMP
style T_E fill:#e74c3c,stroke:#c0392b,color:#fff
style T_M fill:#e74c3c,stroke:#c0392b,color:#fff
style T_L fill:#e74c3c,stroke:#c0392b,color:#fff
style U_E fill:#16A085,stroke:#2C3E50,color:#fff
style U_M fill:#16A085,stroke:#2C3E50,color:#fff
style U_L fill:#16A085,stroke:#2C3E50,color:#fff
style TCP_IMP fill:#E67E22,stroke:#2C3E50,color:#fff
style UDP_IMP fill:#2C3E50,stroke:#16A085,color:#fff
Key Insight: For battery-powered IoT, think of TCP as a “premium service” - you pay 5-10× energy cost for guaranteed delivery. UDP is “economy class” - minimal cost, but you handle reliability yourself. Choose based on whether the reliability premium is worth the battery life trade-off.
755.6 Summary
Protocol selection is a critical IoT design decision:
- UDP provides minimal overhead (8 bytes), predictable latency, and stateless operation - ideal for frequent sensor telemetry
- TCP guarantees reliable, ordered delivery at the cost of connection overhead and variable latency - essential for firmware and critical commands
- DTLS adds security to UDP with manageable overhead when session resumption is used
- Trade-off analysis should consider reliability requirements, latency sensitivity, power constraints, and security needs
755.7 What’s Next
Continue exploring transport protocol analysis:
- Transport Review: Overhead Analysis: Detailed packet overhead and battery life calculations
- Transport Review: DTLS Security: DTLS architecture and IoT security patterns
- Transport Review: Knowledge Check: Quiz questions to test your understanding