9 Transport Selection

In 60 Seconds

Transport protocol selection depends on three key questions: Can you tolerate data loss? Is the device battery-powered? Does it transmit frequently? This chapter provides scenario-based selection guidance, comparing TCP, UDP, and DTLS across reliability, latency, power consumption, and security requirements, with overhead and power calculations for real-world IoT deployments.

Key Concepts

Selection Criteria Hierarchy: 1) Device constraints (RAM/CPU limits protocol options), 2) Network type (cellular → UDP preferred, Ethernet → TCP viable), 3) Data criticality (commands → reliable, telemetry → best-effort), 4) Security requirements (internet-facing → TLS/DTLS mandatory), 5) Ecosystem (existing platform → use its native protocol)
CoAP vs MQTT Decision: CoAP: request-response model, ideal for polling and actuator control, UDP-based, constrained device native; MQTT: publish-subscribe, ideal for fan-out telemetry, TCP-based, broker required; not either/or — common to use both in the same system
Data Freshness vs Completeness Trade-off: For fresh data (real-time state), UDP delivers newest reading; for complete data (billing, compliance), TCP ensures no gaps; define which matters more before selecting protocol
Protocol Overhead Budget: Calculate maximum affordable overhead: data_plan_limit / messages_per_month = max_bytes_per_message; if overhead_fraction > 30%, choose lower-overhead protocol
Interoperability Requirement: Standard protocols (CoAP, MQTT, HTTP) maximize ecosystem compatibility; proprietary protocols optimize performance but limit integration options; default to standards unless performance requirements demand proprietary
Real-Time vs Store-and-Forward: Real-time (events must arrive in <1 s) → TCP with keepalive or UDP with low timeout; store-and-forward (hours of delay acceptable) → MQTT with persistence, NB-IoT/PSM duty cycle
Development Cost Factor: MQTT has rich broker ecosystems (EMQX, HiveMQ, Mosquitto) and client libraries for all platforms; CoAP has fewer turnkey solutions; raw TCP/UDP requires most custom development; factor development cost into selection
Protocol Negotiation: Some IoT platforms support multiple protocols and negotiate based on device capability; LPWAN platforms often support both CoAP (constrained) and MQTT (gateway) with automatic selection

Learning Objectives

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

Choose and justify the most appropriate transport protocol for a given IoT scenario
Apply a systematic decision framework based on reliability, latency, power, and security constraints
Analyze real-world IoT deployments and distinguish when UDP, TCP, DTLS, or hybrid approaches are warranted
Calculate packet overhead and battery life to evaluate the power impact of protocol choice
Design a multi-protocol communication strategy for a heterogeneous IoT system

For Beginners: Transport Protocol Selection

Choosing a transport protocol means balancing competing needs: reliability vs speed, simplicity vs features, and resource usage vs security. This chapter helps you navigate those trade-offs for IoT devices, where every byte of overhead and every millisecond of delay can affect battery life and user experience.

Sensor Squad: The Decision Flowchart!

“Choosing a transport protocol is like picking the right vehicle for a trip,” said Max the Microcontroller. “A sports car is fast but carries little cargo. A truck carries everything but uses more fuel. You pick based on what you need.”

“Start with three questions,” explained Sammy the Sensor. “First: can I tolerate lost data? If no, lean toward TCP. Second: am I battery-powered? If yes, lean toward UDP. Third: do I transmit frequently? If yes, UDP’s lower overhead adds up to massive energy savings.”

“Security adds another dimension,” said Lila the LED. “If you need encryption over UDP, use DTLS. If you need encryption over TCP, use TLS. DTLS adds less overhead than TLS because UDP packets are independent — you do not need to maintain stream state.”

“Each scenario has a clear winner,” concluded Bella the Battery. “Industrial control: TCP for reliability. Environmental monitoring: UDP for battery life. Medical wearable: DTLS for secure telemetry. Video surveillance: UDP for real-time streaming. There is no one-size-fits-all answer.”

9.1 Prerequisites

Before diving into this chapter, you should be able to identify and explain:

Transport Protocol Fundamentals: Understanding TCP vs UDP characteristics and trade-offs
DTLS Security: Understanding when security is needed and DTLS overhead

Key Takeaway

In one sentence: Protocol selection depends on your specific requirements — there is no universal “best” protocol.

Remember this: Ask three questions: (1) Can I tolerate loss? (2) Am I battery-powered? (3) Do I transmit frequently? The answers guide your choice.

9.2 How It Works: The Selection Decision Process

Protocol selection isn’t arbitrary—it follows a systematic evaluation of requirements:

Step 1: Identify Data Criticality

Critical data (firmware, commands, financial): Loss = system failure → TCP required
Important data (sensor readings for control): Loss = degraded service → UDP + app-layer ACK
Informational data (periodic telemetry): Loss = acceptable gap → UDP

Step 2: Evaluate Latency Sensitivity

Real-time (<100 ms): TCP retransmit delays unacceptable → UDP
Interactive (<500 ms): TCP acceptable if low loss → Either
Batch (>1 second): Latency irrelevant → TCP fine

Step 3: Assess Power Constraints

Battery-powered (multi-year life target): Every byte matters → UDP preferred
Energy-harvesting: Intermittent power → UDP (no connection state to lose)
Mains-powered: Power unlimited → TCP acceptable

Step 4: Security Requirements

No security: Use plain UDP or TCP
Security required + UDP: Add DTLS 1.2 (~29 bytes overhead per record: 13B header + 8B nonce + 8B auth tag with AES-128-CCM)
Security required + TCP: Add TLS 1.2 (~29-53 bytes overhead per record depending on cipher suite; AES-GCM ~29B, AES-CBC + HMAC-SHA256 up to 53B)

Step 5: Transmission Pattern Analysis

Frequent (<1 min intervals): UDP critical (handshake overhead dominates)
Moderate (1-10 min): UDP preferred but TCP acceptable
Infrequent (>10 min): Either works (sleep current dominates)

Decision Formula:

IF (data_loss == UNACCEPTABLE) THEN
  TCP
ELSE IF (latency < 100ms) OR (battery_powered AND interval < 5min) THEN
  UDP + optional_app_layer_reliability
ELSE IF (security == REQUIRED AND latency_sensitive) THEN
  UDP + DTLS
ELSE
  TCP + TLS (default safe choice)
END

Why This Works:

Hierarchy of constraints: Data loss tolerance is binary (accept/reject), power is continuous (optimize)
Interactions: TCP + frequent transmissions + battery = failure mode (up to 13× more radio on-time per reading)
Security cost: DTLS overhead (~29B with AES-128-CCM) is similar to TLS overhead (~29-53B depending on cipher); both are manageable for typical IoT payloads

Common Pitfalls:

Choosing UDP for critical commands without app-layer ACK → silent failures
Choosing TCP for high-frequency telemetry without keep-alive → connection storm
Ignoring NAT timeout (TCP dies silently after 2-4 min idle, UDP changes ports)

9.3 Protocol Selection Decision Tree

Decision tree flowchart starting with 'Can you tolerate data loss?' branching left to TCP (reliable, ordered delivery) and right to UDP. The UDP branch further splits on 'Need real-time or battery-efficient?' leading to plain UDP or UDP+DTLS when security is required. Leaf nodes show TCP, TCP+TLS, UDP, UDP+DTLS, and UDP+CoAP outcomes. — Figure 9.1: Transport protocol selection decision tree based on reliability, real-time, and security requirements

Decision tree for selecting transport protocol based on reliability, real-time, and security requirements

Alternative View: TCP vs UDP Decision Flowchart

This variant presents the transport protocol selection through a decision-tree lens — useful for engineers choosing between TCP and UDP based on specific IoT application requirements.

Figure 9.2: Decision flowchart for selecting TCP, UDP, or CoAP based on IoT application requirements

9.4 Selection Criteria

Decision Guide

Use TCP when:

Reliability is critical: Firmware updates, configuration
Data must be ordered: Sequential commands, file transfers
Data loss unacceptable: Financial transactions, critical commands
Network is reliable: Wired connections, stable Wi-Fi
Power not a constraint: Mains-powered devices

Use UDP when:

Low latency required: Real-time monitoring, video streaming
Periodic data: Sensor readings every N seconds
Data loss tolerable: Occasional reading loss OK
Broadcast/multicast needed: One-to-many communication
Power constrained: Battery-powered sensors
Overhead matters: 6LoWPAN, constrained networks

Consider hybrid approach:

UDP for telemetry (sensor data)
TCP for critical ops (firmware, config)
Application-level reliability on UDP (CoAP confirmable messages)

9.5 Example Scenarios

9.5.1 Scenario 1: Temperature Sensor (Battery-Powered)

Analysis

Requirements:

Reports temperature every 5 minutes
Battery-powered (must last years)
Occasional reading loss acceptable
Low latency preferred

Protocol Selection: UDP (with CoAP)

Reasoning:

Low overhead: 8-byte UDP header
Low power: No connection state, no ACKs
Loss tolerable: Missing one reading OK (next reading in 5 min)
CoAP: Application-level confirmable messages if needed

Power Impact (802.15.4 at 250 kbps, 6LoWPAN compressed headers): - UDP: ~1 ms radio on time per reading (24 bytes total) - TCP: ~13 ms (244 bytes: handshake + data + teardown) - ~13x lower radio-on time with UDP (see Overhead Calculation Lab for full derivation)

9.5.2 Scenario 2: Firmware Update (Battery or Mains)

Analysis

Requirements:

500 KB firmware image
Must be 100% reliable
Can tolerate latency (not time-critical)
Corrupted firmware = bricked device

Protocol Selection: TCP (with TLS for security)

Reasoning:

Reliability: Cannot tolerate any packet loss
Ordering: Firmware must be received in correct order
Error recovery: Automatic retransmission
Security: TLS prevents malicious firmware injection

Power Impact:

TCP overhead acceptable for infrequent operation (once per month)
Device can stay awake during update (user-initiated)

9.5.3 Scenario 3: Video Surveillance (Mains-Powered)

Analysis

Requirements:

1080p video stream (2-4 Mbps)
Real-time display (< 200 ms latency)
Mains-powered (no battery concern)
Some frame loss acceptable

Protocol Selection: UDP (with RTP/RTSP)

Reasoning:

Low latency: No retransmission delays
Real-time: Predictable latency
Bandwidth: High bitrate requires efficient protocol
Loss tolerable: Missing frame causes brief artifact, not fatal
TCP would cause: Buffering, variable latency (unacceptable for live video)

Security: Can add SRTP with DTLS-SRTP key exchange (RFC 5764) for encrypted video

9.5.4 Scenario 4: Smart Lock (Battery-Powered, Critical)

Analysis

Requirements:

Lock/unlock commands
Must be 100% reliable (security critical)
Battery-powered
Low latency desired (user waiting)

Protocol Selection: UDP + DTLS (with CoAP confirmable)

Reasoning:

Security: DTLS encryption + authentication (prevent spoofing)
Reliability: CoAP confirmable messages (application-level ACK)
Power: UDP more efficient than TCP
Compromise: Slightly higher overhead than plain UDP, but necessary for security

Why not TCP + TLS?

TCP adds connection overhead (3-way handshake)
TLS handshake is heavy
UDP + DTLS with session resumption more efficient

9.6 Overhead Calculation Lab

Lab Activity: Calculate Overhead and Power Consumption

Objective: Compare TCP vs UDP overhead and power impact for IoT sensor

Scenario: Temperature sensor sending 10-byte readings

Device: nRF52840 - TX current: 5 mA - RX current: 5 mA - Sleep current: 5 uA - Data rate: 250 kbps (802.15.4)

9.6.1 Task 1: Calculate Packet Overhead

Payload: 10 bytes (temperature + humidity + battery)

Assumptions:

IPv6 header: 40 bytes (uncompressed) or 6 bytes (6LoWPAN compressed)
Use compressed headers

Click to see solution

UDP Packet:

IPv6 header (compressed): 6 bytes
UDP header: 8 bytes
Payload: 10 bytes
Total: 24 bytes

Overhead: 14 bytes / 24 bytes = 58% overhead
Efficiency: 10 bytes / 24 bytes = 42% efficiency

TCP Packet (data transmission):

IPv6 header (compressed): 6 bytes
TCP header (minimum): 20 bytes
Payload: 10 bytes
Total: 36 bytes

Overhead: 26 bytes / 36 bytes = 72% overhead
Efficiency: 10 bytes / 36 bytes = 28% efficiency

TCP Handshake (before data):

SYN: 6 (IPv6) + 20 (TCP) = 26 bytes
SYN-ACK: 26 bytes
ACK: 26 bytes
Total handshake: 78 bytes

TCP Data + ACK:

Data: 36 bytes (as calculated above)
ACK: 6 (IPv6) + 20 (TCP) = 26 bytes
Total: 62 bytes

TCP Connection Teardown:

FIN: 26 bytes
ACK: 26 bytes
FIN: 26 bytes
ACK: 26 bytes
Total teardown: 104 bytes

Total TCP (one reading):

Handshake: 78 bytes
Data + ACK: 62 bytes
Teardown: 104 bytes
Total: 244 bytes

Comparison:

UDP: 24 bytes total
TCP: 244 bytes total (10x more!)

9.6.2 Task 2: Calculate Radio On Time

Using packet sizes from Task 1, calculate radio on time:

Data rate: 250 kbps = 31.25 KB/s

Click to see solution

UDP (24 bytes):

TX time = 24 bytes / 31.25 KB/s
        = 24 / 31,250 bytes/s
        = 0.768 ms

Total radio on: ~1 ms (including processing)

TCP (full connection, 244 bytes):

TX time = 244 bytes / 31.25 KB/s
        = 244 / 31,250
        = 7.8 ms

RX time (waiting for ACKs): ~5 ms

Total radio on: ~13 ms (TX + RX + processing)

Comparison:

UDP: 1 ms
TCP (full): 13 ms (13x longer)

9.6.3 Task 3: Calculate Battery Life

Sensor reports every 5 minutes. Calculate battery life.

Assumptions:

Radio TX/RX: 5 mA
Sleep: 5 uA
Battery: 2000 mAh
Readings per day: 288

Click to see solution

UDP:

Active time per reading: 1 ms
Active time per day: 288 x 1 ms = 288 ms = 0.288 s

Active power: 5 mA x 0.288 s = 1.44 mA-s = 0.4 uA-h
Sleep power: 5 uA x (86,400 - 0.288) s / 3600 = 119.99 uA-h

Total per day: 0.4 + 120 = 120.4 uA-h = 0.12 mA-h

Battery life: 2000 mAh / 0.12 mAh/day = 16,667 days = 45.7 years

TCP (full connection per reading):

Active time per reading: 13 ms
Active time per day: 288 x 13 ms = 3.744 s

Active power: 5 mA x 3.744 s = 18.72 mA-s = 5.2 uA-h
Sleep power: 5 uA x (86,400 - 3.744) s / 3600 = 119.97 uA-h

Total per day: 5.2 + 120 = 125.2 uA-h = 0.125 mA-h

Battery life: 2000 mAh / 0.125 mAh/day = 16,000 days = 43.8 years

Putting Numbers to It

The duty cycle reveals why protocol choice matters more at higher frequencies. Energy consumption follows:

\[E_{\text{daily}} = (n \times t_{\text{active}} \times I_{\text{active}}) + ((86{,}400 - n \times t_{\text{active}}) \times I_{\text{sleep}})\]

where \(n\) = transmissions/day, \(t_{\text{active}}\) in seconds, currents in µA. The critical frequency where protocol overhead begins to rival sleep current drain is:

\[n_{\text{critical}} = \frac{I_{\text{sleep}} \times 86{,}400}{(t_{\text{TCP}} - t_{\text{UDP}}) \times I_{\text{active}}}\]

For this sensor (all units consistent — currents in µA, times in seconds): \[n_{\text{critical}} = \frac{5\,\mu\text{A} \times 86{,}400\,\text{s}}{(0.013 - 0.001)\,\text{s} \times 5{,}000\,\mu\text{A}} = \frac{432{,}000}{60} = 7{,}200\text{ tx/day (every 12 s)}\]

Above 7,200 messages/day (one every 12 seconds), TCP overhead becomes the dominant battery drain. Below that threshold, sleep current dominates and protocol choice has diminishing impact on battery life.

Key Insight: For infrequent transmission (every 5 min), sleep current dominates. Protocol overhead has minimal impact on battery life (46 years UDP vs 44 years TCP).

However, at 10-second intervals (8,640 tx/day — above the 7,200 tx/day critical threshold):

UDP:  8,640 × 1 ms  = 8.64 s active/day  → 132 µAh/day  → ~41.5 years
TCP:  8,640 × 13 ms = 112.3 s active/day → 276 µAh/day  → ~19.9 years
Reduction: ~52% shorter battery life with TCP

Protocol choice significantly impacts battery life when transmitting more frequently than once every 12 seconds.

Try It: Protocol Overhead and Battery Life Calculator

Adjust the parameters below to see how protocol choice affects packet overhead and battery life for your specific IoT sensor scenario.

Show code

viewof payload = Inputs.range([1, 200], {value: 10, step: 1, label: "Payload size (bytes)"})
viewof interval_sec = Inputs.range([10, 3600], {value: 300, step: 10, label: "Transmission interval (seconds)"})
viewof battery_mAh = Inputs.range([100, 10000], {value: 2000, step: 100, label: "Battery capacity (mAh)"})
viewof I_active_mA = Inputs.range([1, 50], {value: 5, step: 0.5, label: "Radio active current (mA)"})
viewof I_sleep_uA = Inputs.range([1, 100], {value: 5, step: 1, label: "Sleep current (µA)"})

Show code

{
  // Header sizes (6LoWPAN compressed IPv6 per RFC 6282)
  const ipv6 = 6;
  const udp_hdr = 8;
  const tcp_hdr = 20;
  const data_rate_bps = 250000; // 802.15.4 @ 250 kbps

  // Packet sizes
  const udp_total = ipv6 + udp_hdr + payload;
  const tcp_data  = ipv6 + tcp_hdr + payload;
  const tcp_ctrl  = ipv6 + tcp_hdr;  // SYN, SYN-ACK, ACK, FIN each = 26 B (no payload)
  // Full TCP cycle: 3 handshake + (data + ACK) + 4 teardown
  const tcp_total = 3 * tcp_ctrl + tcp_data + tcp_ctrl + 4 * tcp_ctrl;

  // Radio on-time per transmission (seconds)
  const t_udp_s = (udp_total * 8 / data_rate_bps) + 0.0002; // TX + ~0.2 ms processing
  const t_tcp_s = (tcp_total * 8 / data_rate_bps) + 0.005;  // TX + ~5 ms RX/ACK wait

  // Transmissions per day
  const n = 86400 / interval_sec;

  // Battery life calculation (energy in µAh)
  const I_active_uA = I_active_mA * 1000;

  const E_act_udp  = n * t_udp_s * I_active_uA / 3600;
  const E_slp_udp  = I_sleep_uA * (86400 - n * t_udp_s) / 3600;
  const total_udp  = Math.max(E_act_udp + E_slp_udp, 0.001);
  const life_udp   = (battery_mAh * 1000) / total_udp / 365;

  const E_act_tcp  = n * t_tcp_s * I_active_uA / 3600;
  const E_slp_tcp  = I_sleep_uA * Math.max(86400 - n * t_tcp_s, 0) / 3600;
  const total_tcp  = Math.max(E_act_tcp + E_slp_tcp, 0.001);
  const life_tcp   = (battery_mAh * 1000) / total_tcp / 365;

  // Overhead metrics
  const udp_eff    = (payload / udp_total * 100).toFixed(1);
  const tcp_eff    = (payload / tcp_data  * 100).toFixed(1);
  const ratio      = (tcp_total / udp_total).toFixed(1);
  const life_ratio = (life_udp / life_tcp).toFixed(1);

  // Critical interval: n_crit = (I_sleep × 86400) / (Δt × I_active)  [all in µA and seconds]
  const delta_t_s  = t_tcp_s - t_udp_s;
  const n_crit     = (I_sleep_uA * 86400) / (delta_t_s * I_active_uA);
  const crit_interval_s = (86400 / n_crit).toFixed(0);
  const above_threshold = n > n_crit;

  return html`<div style="border-left: 4px solid #3498DB; padding: 16px; background: #f8fafc; border-radius: 4px; font-family: Arial, sans-serif;">
    <h4 style="margin: 0 0 12px; color: #2C3E50;">${payload}-byte payload, every ${interval_sec}s &nbsp;(${n.toFixed(0)} tx/day)</h4>

    <table style="width:100%; border-collapse: collapse; margin-bottom: 16px; font-size: 0.9em;">
      <thead>
        <tr style="background:#2C3E50; color:white;">
          <th style="padding:8px; text-align:left;">Metric</th>
          <th style="padding:8px; text-align:center;">UDP</th>
          <th style="padding:8px; text-align:center;">TCP (full conn.)</th>
        </tr>
      </thead>
      <tbody>
        <tr style="background:#fff;">
          <td style="padding:8px;">Total bytes per cycle</td>
          <td style="padding:8px; text-align:center; color:#16A085; font-weight:bold;">${udp_total} B</td>
          <td style="padding:8px; text-align:center; color:#E74C3C; font-weight:bold;">${tcp_total} B&nbsp;(${ratio}×)</td>
        </tr>
        <tr style="background:#f4f6f8;">
          <td style="padding:8px;">Payload efficiency</td>
          <td style="padding:8px; text-align:center;">${udp_eff}%</td>
          <td style="padding:8px; text-align:center;">${tcp_eff}%</td>
        </tr>
        <tr style="background:#fff;">
          <td style="padding:8px;">Radio on-time per tx</td>
          <td style="padding:8px; text-align:center;">${(t_udp_s * 1000).toFixed(2)} ms</td>
          <td style="padding:8px; text-align:center;">${(t_tcp_s * 1000).toFixed(1)} ms</td>
        </tr>
        <tr style="background:#f4f6f8;">
          <td style="padding:8px;">Active energy / day</td>
          <td style="padding:8px; text-align:center;">${E_act_udp.toFixed(2)} µAh</td>
          <td style="padding:8px; text-align:center;">${E_act_tcp.toFixed(2)} µAh</td>
        </tr>
        <tr style="background:#fff;">
          <td style="padding:8px;">Total energy / day</td>
          <td style="padding:8px; text-align:center;">${total_udp.toFixed(1)} µAh</td>
          <td style="padding:8px; text-align:center;">${total_tcp.toFixed(1)} µAh</td>
        </tr>
        <tr style="background:#E8F8F5;">
          <td style="padding:8px; font-weight:bold;">Estimated battery life</td>
          <td style="padding:8px; text-align:center; color:#16A085; font-weight:bold;">${life_udp.toFixed(1)} years</td>
          <td style="padding:8px; text-align:center; color:#E74C3C; font-weight:bold;">${life_tcp.toFixed(1)} years</td>
        </tr>
      </tbody>
    </table>

    <p style="margin:4px 0; font-size:0.9em; color:#555;">
      <strong style="color:#2C3E50;">Battery life ratio:</strong> UDP lasts <strong>${life_ratio}×</strong> longer than TCP at this rate.
    </p>
    <p style="margin:4px 0; font-size:0.9em; color:${above_threshold ? '#E74C3C' : '#16A085'};">
      <strong>Critical threshold:</strong> every ${crit_interval_s}s (${n_crit.toFixed(0)} tx/day).
      Current rate is <strong>${above_threshold ? 'ABOVE — protocol choice is critical for battery life' : 'below — sleep current dominates; protocol choice has minor impact'}</strong>.
    </p>
  </div>`;
}

9.7 Protocol Selection Quiz

Question: Four IoT Systems

You’re designing four different IoT systems. For each system, select the most appropriate transport protocol (UDP, TCP, UDP+DTLS, TCP+TLS) and justify your choice.

System A: Smart door lock - Battery-powered (2x AA, must last 1 year) - Lock/unlock commands (must be 100% reliable) - Security critical (prevent unauthorized access) - Latency: Interactive (<200 ms) - Frequency: ~10 operations per day

System B: Industrial sensor network - 200 temperature/vibration sensors - Wired Ethernet (power available) - Reports every 1 second - Reliability: Some loss tolerable (0.1% OK) - No security requirement (internal network)

System C: Firmware update service - Over-the-air updates for IoT devices - 500 KB firmware images - Must be 100% reliable (corruption = bricked device) - Security: Prevent malicious firmware - Frequency: Monthly updates

System D: Video surveillance camera - 1080p stream (2-4 Mbps) - Mains-powered - Real-time display required (<100 ms latency) - Security: Encrypt video stream - Some frame loss acceptable

Click to reveal answer

Answer: A->UDP+DTLS, B->UDP, C->TCP+TLS, D->UDP+DTLS

System A: Smart Door Lock -> UDP + DTLS + CoAP Confirmable

DTLS provides encryption and authentication
UDP more power-efficient than TCP for infrequent operations
CoAP Confirmable provides reliability at application layer
Session resumption reduces handshake overhead

System B: Industrial Sensor Network -> UDP (plain)

0.1% loss acceptable for monitoring
200 sensors at 1 Hz = 200 msg/sec (TCP connection overhead wasteful)
Wired Ethernet = reliable medium
Internal network = no security requirement
Consistent latency for real-time monitoring

System C: Firmware Update Service -> TCP + TLS

100% reliability required (corrupted firmware bricks device)
TCP provides automatic segmentation, ordering, retransmission
TLS prevents malicious firmware injection
Monthly updates = TCP overhead acceptable

System D: Video Surveillance Camera -> UDP + DTLS

Real-time <100ms latency = UDP (no retransmission delays)
Frame loss acceptable (minor glitches OK)
DTLS encrypts video stream
TCP head-of-line blocking would cause buffering

Quiz: Application-Layer Reliability

Common Mistake: Forgetting NAT Timeout Impact on Protocol Selection

The Mistake: Choosing UDP or TCP based solely on reliability/latency needs, forgetting that NAT gateways silently drop mappings after idle timeouts, breaking both protocols in different ways.

The Problem:

Typical NAT UDP timeout: 30-60 seconds
Typical NAT TCP timeout: 2-4 minutes
IoT sensor sending readings every 5 minutes

What Happens with UDP:

Scenario: Sensor sends reading every 5 minutes via UDP to cloud

T=0:      Sensor sends UDP packet from 192.168.1.100:54321
          NAT creates mapping: 203.0.113.50:12345 → 192.168.1.100:54321
          Cloud receives packet from 203.0.113.50:12345

T=60s:    NAT idle timeout expires, mapping deleted

T=300s:   Sensor sends next reading from 192.168.1.100:54321
          NAT creates NEW mapping: 203.0.113.50:12346 → 192.168.1.100:54321
          Cloud receives from different port: 203.0.113.50:12346
          Cloud treats as new device, session breaks!

What Happens with TCP (Worse!):

Scenario: Sensor maintains persistent TCP connection

T=0:      TCP connection established through NAT
          Mapping: 203.0.113.50:12345 → 192.168.1.100:54321

T=240s:   NAT TCP timeout (4 min), mapping silently deleted

T=300s:   Sensor sends data on "established" TCP connection
          NAT doesn't recognize connection, drops packet
          Sensor TCP stack waits for ACK... timeout after 1s
          Sensor retransmits with exponential backoff (1s, 2s, 4s)...
          After 3 retries (~7s total), sensor declares connection dead

Result: Connection appears alive to sensor but is dead to NAT

The Fix Options:

For UDP: Accept ephemeral ports OR keep NAT alive

# Option A: Let cloud handle changing ports (stateless)
# Cloud identifies device by payload ID, not source port
message = {
    "device_id": "sensor-12345",  # Don't rely on IP/port
    "timestamp": time.time(),
    "data": reading
}

# Option B: Send NAT keep-alive pings between readings (adds overhead)
while True:
    send_data()
    time.sleep(50)   # Wait 50 s (well under the 60 s NAT UDP timeout)
    send_keepalive_ping()  # Reset NAT timer before it expires
    time.sleep(250)  # Sleep remaining ~250 s to complete 5-minute cycle

For TCP: Use keep-alive SHORTER than NAT timeout

import socket

sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)

# Enable TCP keep-alive
sock.setsockopt(socket.SOL_SOCKET, socket.SO_KEEPALIVE, 1)

# Linux-specific: Set keep-alive timing
sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_KEEPIDLE, 30)   # Start probing after 30s idle
sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_KEEPINTVL, 30)  # Probe every 30s
sock.setsockopt(socket.IPPROTO_TCP, socket.TCP_KEEPCNT, 3)     # 3 probes before declaring dead

# Result: First keep-alive fires at 30s — safely before even a 2-minute NAT timeout

Best Practice Decision Matrix:

Transmission Interval	NAT Environment	Protocol Choice	Reason
< 30 seconds	Any	UDP (no keep-alive needed)	Frequent traffic keeps NAT mapping alive naturally
30s - 2 min	Behind NAT	UDP with device ID in payload	NAT timeout not reached between messages
2 min - 4 min	Behind NAT	TCP with keep-alive at 30s	Keep-alive fires before NAT timeout
> 4 minutes	Behind NAT	UDP + CoAP with stateless cloud	Avoid TCP keep-alive battery drain
Any	Direct IP (no NAT)	Choose based on reliability needs	NAT timeout not a factor

Real-World Impact:

Case Study: Smart parking sensors sending occupancy every 5 minutes via TCP without keep-alive

Sensors appeared “online” (TCP established)
No data received after first reading
Root cause: NAT timeout at 4 minutes silently dropped all connections
Fix: Changed to UDP with device ID in payload
Result: 100% data delivery, 20% lower battery consumption (no keep-alive)

Lesson Learned: NAT timeouts are invisible to applications but deadly to IoT deployments. Always test protocol choice through actual NAT devices with realistic intervals, not just on local networks.

🏷️ Label the Diagram

💻 Code Challenge

9.8 Summary

Key Takeaways

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)

The 3-Question Framework:

Can I tolerate loss? YES = UDP, NO = TCP or UDP+App-Layer ACK
Am I battery-powered? YES = prefer UDP, NO = either works
Do I transmit frequently? YES = UDP critical, NO = TCP acceptable

Common Patterns:

Telemetry: UDP + CoAP NON (non-confirmable)
Commands: UDP + CoAP CON or TCP
Firmware: TCP + TLS
Video: UDP + RTP

9.9 Concept Relationships

How Protocol Selection Connects

Builds on:

Transport Protocol Fundamentals - Understanding TCP/UDP characteristics before choosing
DTLS Security - Security overhead considerations

Extends to:

TCP Optimizations - Making your TCP choice more efficient
Decision Framework - Comprehensive decision matrices

Informs Application-Layer Choices:

CoAP Protocol - Application-layer protocol for UDP selections
MQTT Protocol - Requires TCP selection

Real-World Integration:

IoT Architectures - Multi-protocol system designs
Edge Computing - Gateway protocol translation

Common Misconceptions:

“One protocol per system” - Wrong: Different data flows need different protocols (telemetry=UDP, commands=TCP)
“CoAP means UDP required” - Partly wrong: CoAP over TCP (RFC 8323) exists for firewall traversal
“Security means TLS means TCP” - Wrong: DTLS provides equivalent security over UDP

Key Insight: Protocol selection is per-data-flow, not per-system. A smart home hub might use UDP for sensor readings, TCP for door lock commands, and DTLS for motion alerts—all simultaneously.

9.10 See Also

Extended Practice:

Overhead Analysis - Quantifying the byte and power impact of your protocol choice
Transport Selection and Scenarios - Extended real-world examples and edge cases

Application-Layer Implementation:

CoAP Implementation - Building reliable messaging over UDP
MQTT Implementation - Using TCP-based publish/subscribe
Industrial IoT Protocols - Factory automation protocol choices

Standards and Background:

RFC 7252 Section 2: CoAP’s rationale for choosing UDP over TCP
NAT Traversal Techniques - RFC 5128: why NAT timeout affects protocol selection

External Tools:

Eclipse IoT Protocols Comparison - Interactive protocol selector tool
AWS IoT Protocol Support - Cloud platform protocol constraints

9.11 Try It Yourself

Hands-On Exercise: Protocol Selection for Smart Parking

Scenario: Design transport protocols for a 500-space parking garage with three data types.

System Components:

Occupancy sensors (500 units): Detect car presence, report every 30 seconds
Payment terminals (10 units): Process credit card transactions
LED guidance signs (50 units): Display “FULL” or available space count

Your Task: For each component, select TCP or UDP and justify with calculations.

Step 1: Analyze Occupancy Sensors

Data: 4 bytes (sensor ID: 2B, occupied: 1B, battery: 1B)
Frequency: Every 30 seconds
Battery: 2x AA lithium (6,000 mAh), target 5 years
Network: 802.15.4 mesh (250 kbps, 10% packet loss)

Questions:

Calculate bytes per day for UDP vs TCP (include handshake/teardown)
Calculate battery life for each protocol
Is 10% packet loss acceptable for parking occupancy?
Your choice: UDP or TCP? Why?

Click for solution

UDP:

Packet: 4B payload + 8B UDP + 6B IPv6 = 18 bytes
Per day: 2,880 transmissions × 18B = 51,840 bytes
Radio time: 0.6 ms per transmission × 2,880 = 1.7 seconds/day
Battery: ~10 years (sleep current dominates)
10% loss: Acceptable (next reading in 30 seconds, averaged over hour)

TCP:

Packet: 244 bytes (handshake + data + teardown)
Per day: 2,880 × 244B = 702,720 bytes (13.6× more!)
Radio time: 13 ms × 2,880 = 37 seconds/day
Battery: ~6 months (retransmissions in 10% loss network drain battery)
10% loss: TCP retransmit storm, worse battery life

Recommended: UDP - 10% loss acceptable, battery life 20× better, simpler mesh routing

Step 2: Analyze Payment Terminals

Data: 200 bytes (card data, encrypted)
Frequency: 5-10 transactions/hour
Power: Mains-powered
Network: Wired Ethernet
Critical: Transaction loss = revenue loss

Your choice: UDP or TCP? Why?

Click for solution

Recommended: TCP + TLS - Transaction loss unacceptable, low frequency makes overhead irrelevant, mains-powered so no battery concern, TLS provides end-to-end security

Step 3: Analyze LED Signs

Data: 2 bytes (command: 1B, brightness: 1B)
Frequency: Command-driven (10-20 updates/day)
Power: Mains-powered
Network: Wi-Fi
Critical: Wrong display = customer confusion, safety issue

Your choice: UDP or TCP? Why?

Click for solution

Recommended: UDP + CoAP Confirmable - Low latency needed (user sees sign immediately), command must arrive (CoAP CON provides ACK), low frequency makes overhead negligible, Wi-Fi has <1% loss

Challenge: Extend the system with 100 security cameras (1080p, 2 Mbps). What protocol and why?

9.12 What’s Next?

Continue to TCP Optimizations and Implementation to apply techniques for making TCP more efficient in constrained IoT environments.

Next Chapter	Topic	Why Read It
TCP Optimizations	Reducing TCP overhead in constrained networks	Apply the TCP scenarios from this chapter more efficiently
Transport Review: Overhead Analysis	Quantifying byte and power cost of protocol choice	Practice the overhead calculations introduced in the Lab section
CoAP Fundamentals	Application-layer reliability over UDP	Implement the UDP + CoAP CON reliability pattern from Scenario 4
MQTT Fundamentals	TCP-based publish/subscribe for IoT	Assess when MQTT’s QoS levels suit your reliability requirements
Decision Framework	Comprehensive decision matrices for complex systems	Extend the 5-step decision process to multi-protocol architectures
IoT Reference Architectures	System-level protocol integration patterns	Design full IoT stacks that combine UDP, TCP, and gateway translation