Every protocol we've examined in this module—QUIC, RTP, TFTP—shares a common characteristic: they build sophisticated functionality on UDP's minimal foundation. This isn't coincidence; it's deliberate engineering choice.

UDP is not just a simple transport protocol—it's a protocol development platform. Its minimalism provides a clean slate upon which architects can implement exactly the semantics their application requires, without fighting against assumptions embedded in TCP's design.

This page explores the art and science of building protocols on UDP: when to choose UDP, what you must implement yourself, and the architectural patterns that successful UDP-based protocols share.

The decision to build on UDP rather than TCP is consequential—it means accepting responsibility for reliability, ordering, and congestion control. This decision should never be taken lightly, but there are clear scenarios where UDP is the right choice.

Legitimate Reasons to Choose UDP:

The Build vs. Buy Decision:

Before designing a custom UDP protocol, consider:

1. Can you use an existing UDP-based protocol?

   • RTP for real-time media
   • QUIC for reliable streams with migration
   • DTLS for encrypted UDP datagrams
   • CoAP for constrained IoT devices

2. Is the implementation cost justified?

   • Custom reliability requires significant testing
   • Congestion control must be fair to other traffic
   • Security must be designed in, not added later

3. Do you have the expertise?

   • Networking protocol design is subtle
   • Edge cases and failure modes are numerous
   • Security vulnerabilities often hide in protocol layers

Understanding UDP's minimal feature set is essential—everything not provided must be implemented in your protocol layer.

The Implementation Burden:

Let's estimate the complexity of implementing TCP-like services:

This is why "just use UDP" for new protocols is often naive—reliable, robust implementation requires substantial engineering effort.

Certain patterns recur across UDP-based protocols. Understanding these building blocks provides a toolkit for protocol design.

1. Packet Identification and Sequencing:

Most UDP protocols need to identify and order packets:

+----------+----------+------------------+
| Magic    | Version  |   Sequence #     |
| (2 bytes)| (2 bytes)|    (4 bytes)     |
+----------+----------+------------------+
| Timestamp (optional) |  Flags/Type     |
|     (8 bytes)        |    (2 bytes)    |
+----------+-----------+-----------------+
|              Payload                   |
+----------------------------------------+

Why These Fields:

• Magic number: Identifies your protocol, rejects stray packets
• Version: Enables protocol evolution
• Sequence number: Detects loss, enables ordering
• Timestamp: Enables RTT measurement, jitter calculation
• Type/Flags: Distinguishes packet types (data, control, ack)

2. Connection States:

Even connectionless UDP protocols often need connection-like semantics:

3. Reliability Mechanisms:

If reliability is needed, choose an appropriate mechanism:

Stop-and-Wait (TFTP style):

• Send one packet, wait for ACK
• Simple, low throughput
• Good for: constrained systems, low bandwidth

Go-Back-N:

• Window of outstanding packets
• Loss triggers retransmission of all subsequent packets
• Simpler than selective repeat, wastes bandwidth on loss

Selective Repeat:

• Window of outstanding packets
• Only lost packets retransmitted
• More complex, more efficient
• Used by: QUIC, most modern protocols

Negative Acknowledgment (NACK):

• Receiver explicitly requests missing packets
• Reduces ACK traffic
• Used by: multicast protocols, video streaming

This section is critical. Any UDP-based protocol that sends significant traffic MUST implement congestion control. The internet's stability depends on endpoints backing off when congestion occurs.

Why Congestion Control is Mandatory:

Without congestion control:

• Your protocol floods the network during congestion
• Other applications (TCP) back off, you don't
• You consume unfair bandwidth share
• Network collapse becomes possible
• You may be blocked by ISPs or enterprises

Congestion Control Approaches for UDP:

1. TCP-Friendly Rate Control (TFRC):

• Adjusts sending rate to match what TCP would achieve
• Smoother rate than TCP's sawtooth
• Good for streaming applications
• Requires RTT and loss rate estimation

2. Implementing TCP Congestion Control:

• CUBIC, BBR, or other TCP algorithms
• QUIC uses this approach
• Most complex but most fair

3. Application-Limited Flows:

• If application sends slowly (e.g., DNS queries)
• Congestion control may not be needed
• Rule of thumb: <10 Kbps average rarely needs CC

4. Receiver-Driven:

• Receiver reports acceptable rate
• Sender limits transmission to that rate
• Used in some streaming protocols

Minimum Congestion Control Implementation:

For a simple UDP protocol, at minimum implement:

1. Rate limiting: Never exceed configured maximum rate
2. Backoff on loss: Reduce rate when packets are lost
3. Slow start: Begin transmission slowly, increase gradually
4. RTT awareness: Adjust timeouts based on measured RTT

# Simplified congestion control pseudocode
send_rate = initial_rate
loss_count = 0

def on_packet_lost():
    global send_rate, loss_count
    loss_count += 1
    send_rate = send_rate * 0.5  # Multiplicative decrease

def on_ack_received():
    global send_rate, loss_count
    loss_count = 0
    send_rate = min(send_rate + mss, max_rate)  # Additive increase

UDP's simplicity creates security challenges that must be addressed at the protocol layer.

UDP Security Vulnerabilities:

Security Implementation Options:

1. DTLS (Datagram Transport Layer Security):

• TLS for UDP datagrams
• Provides encryption, authentication, integrity
• Handles packet loss and reordering
• Used by: WebRTC, VPN protocols

2. QUIC's Integrated Approach:

• Encryption built into protocol (TLS 1.3)
• Connection IDs prevent spoofing
• All control information authenticated

3. Custom Security Layer:

• Protocol-specific encryption
• May use established primitives (AES-GCM, ChaCha20-Poly1305)
• Requires careful design to avoid subtle flaws

Preventing Amplification Attacks:

UDP servers are vulnerable to being used as amplifiers in DDoS attacks. Mitigations:

1. Response Size Limiting: Ensure response isn't larger than request
2. Client Puzzles: Require computational work before large responses
3. Address Validation: Verify source address before expensive operations
4. Rate Limiting: Limit responses per source address
5. Handshake First: Require connection establishment before data

NAT (Network Address Translation) complicates UDP protocol design. Unlike TCP, where connections have natural state, UDP's statelessness requires explicit handling.

NAT Behavior with UDP:

When a UDP packet travels through NAT:

1. NAT creates a binding (private IP:port → public IP:port)
2. Return traffic matching the binding is forwarded
3. Binding expires after inactivity (30s to 5min typical)
4. Without keepalives, NAT binding expires

NAT Traversal Techniques:

1. UDP Hole Punching:

• Both peers send to each other simultaneously
• NAT creates binding for outgoing packet
• Incoming packet from peer matches binding
• Requires coordination via external server

2. STUN (Session Traversal Utilities for NAT):

• Client sends to STUN server
• Server responds with client's public IP:port
• Client uses this for hole punching

3. TURN (Traversal Using Relays around NAT):

• When direct connection fails (symmetric NAT)
• Relay server forwards traffic
• Higher latency, but always works

4. ICE (Interactive Connectivity Establishment):

• Combines STUN, TURN, and direct
• Tests all candidates, selects best path
• Used by WebRTC, VoIP

NAT Keepalives:

UDP protocols must send periodic traffic to keep NAT bindings alive:

• Recommended interval: 15-30 seconds
• Even empty packets work
• Failure to keepalive causes abrupt connection loss

Successful UDP protocols share common design patterns that address recurring challenges.

Pattern 1: Magic Number Prefix

Start every packet with a fixed magic number:

• Immediate rejection of non-protocol traffic
• Helps debugging (filter by magic in Wireshark)
• Prevents injection from other applications

const PROTOCOL_MAGIC = 0x51555856; // "QUXV" in ASCII

Pattern 2: Version Field Early

Include version early in header:

• Enables protocol evolution
• Receivers can dispatch to version-specific handlers
• Graceful handling of version mismatch

Pattern 3: Length Fields for Extensibility

Include explicit length fields:

• Receivers can skip unknown extensions
• Forward compatibility without breaking parsers
• TLV (Type-Length-Value) encoding is common

Pattern 4: Idempotent Operations

Design requests to be safely repeatable:

• Retransmissions don't cause duplicate effects
• Essential for reliability without complexity
• Use request IDs to deduplicate

Pattern 5: Graceful Degradation

Handle partial failures gracefully:

• Continue with reduced functionality when possible
• Clear error signaling to application layer
• Timeout and retry rather than immediate failure

Building protocols on UDP is a powerful technique that enables specialized functionality impossible with TCP. However, this power comes with significant responsibility—you must implement everything TCP provides for free.

What's Next:

We'll conclude this module by examining how UDP-based protocols fit into the modern internet—the trends driving adoption, the applications pushing boundaries, and where UDP protocols are heading in the future.