19 Datagrams and Packet Structure
19.1 Start With the Packet Budget
Every datagram has a size, a set of headers, and a path that may or may not tolerate fragmentation. Constrained IoT links make this visible: a payload that looks small in code can become too large after security, addressing, and adaptation headers are added.
Use the packet as an accounting record. If you can explain where each byte goes, you can predict when a message fits, fragments, or should be redesigned before field devices start dropping it.
Overview: Datagrams Make Packets Self-Contained
A datagram is a self-contained network packet. It carries enough delivery metadata for the network to forward it independently, plus the payload that the application actually wants to move.
For IoT systems, this model is practical because devices usually send short bursts: a temperature reading, a command, a status report, or a small acknowledgement. The network does not reserve a dedicated circuit for each device. It forwards each packet when the packet appears.
Header
The header identifies where the packet came from, where it should go, which protocol should process it next, how long it is, and what checks protect the packet from obvious corruption.
Payload
The payload is the data handed down from the layer above. For an IoT device, that might be a binary sensor reading, a CoAP message, a firmware block, or an application command.
Best effort
IP forwarding is best effort. A packet can be delayed, duplicated, dropped, or delivered out of order. Reliability, ordering, and retries belong in the transport or application design.
The important design habit is to treat packet structure as a contract. Every byte spent on headers, options, security tags, or fragmentation is a byte that cannot be used for application data on the same frame.
That contract is also what lets engineers reason from a packet capture. A source address explains who claimed to send the packet, a destination address explains the intended next delivery target, a protocol or next-header field explains which parser should receive the payload, and length fields set the boundary between real payload and stray bytes. Routers normally need only the forwarding fields, while endpoints need the full chain of fields to hand the right bytes to UDP, TCP, CoAP, MQTT-SN, or custom device logic. When a datagram is malformed, duplicated, or larger than the path can carry cleanly, those same fields become the first evidence for debugging.
Practitioner: Budget the Packet Before Release
When you design or debug an IoT datagram, start with the packet budget. The useful payload must fit inside the smallest link on the path after every lower layer has added its own headers and trailers.
A useful budget is written as a byte ledger, not as a vague warning about overhead. Start with the link limit, then subtract the link header and trailer, security material, adaptation headers, the network header, the transport header, and any application envelope. For example, IEEE 802.15.4 gives constrained stacks a small frame budget, while IPv6 has a 40-byte base header and UDP adds 8 bytes before application data. 6LoWPAN header compression can recover space, but only when addresses, prefixes, and flow fields match the compression rules. The release question is therefore concrete: what is the largest normal message that still fits after the real deployed stack has wrapped it?
| Design check | What to decide | Why it matters |
|---|---|---|
| Payload size | How many application bytes are sent per message? | Small messages can spend more bytes on protocol overhead than on useful data. |
| Path MTU | What is the smallest frame size on the complete route? | A packet larger than the path allows must be fragmented or rejected. |
| Header stack | Which transport, network, security, adaptation, and link headers are present? | UDP, IPv6, 6LoWPAN compression, MAC security, and link trailers all consume frame space. |
| Recovery model | Who retransmits when one packet or fragment is lost? | IP fragmentation is all-or-nothing at reassembly; application chunks can often retry only the missing block. |
Keep control payloads compact
Use binary fields, concise identifiers, and stable schemas for frequent telemetry. Verbose JSON can be reasonable at gateways, but it is often expensive on small radio frames.
Avoid accidental fragmentation
Check payload size after security and adaptation headers are added. If a message is near the path limit, split it deliberately at the application layer.
Log the fields that matter
Record length, protocol, source, destination, sequence or message ID, and checksum outcome. These fields explain most packet parsing and forwarding failures.
Under the Hood: Parsers Trust Fields Only After Checks
Under the hood, datagram handling is a parsing pipeline. Each layer reads the fields it owns, verifies enough structure to trust the next step, then passes the remaining payload upward or forwards the packet onward.
Fragmentation changes this pipeline. The receiver cannot deliver the original network-layer payload until all required fragments arrive and pass reassembly checks. That is why constrained IoT protocols often prefer smaller application chunks over one large datagram.
Robust parsers treat every length, flag, and next-header value as untrusted input until it has been checked against the bytes actually present. A declared length that exceeds the captured frame, a header chain that points past the payload, or a fragment offset that overlaps an earlier fragment should be rejected before the application sees the data. Diagnostics also depend on where the packet was captured. A checksum failure near the radio points toward corruption or framing trouble; a checksum warning on a host capture can be a hardware-offload artifact; a clean packet at the gateway but not at the service points toward forwarding, NAT, firewall, or application demultiplexing behavior.
| Failure signal | Likely cause | Engineering response |
|---|---|---|
| Length mismatch | Parser disagreement, truncation, or malformed packet | Reject the packet and log observed length versus declared length. |
| Hop limit expired | Routing loop or route churn | Inspect route advertisements, default gateways, and recent topology changes. |
| Repeated fragment timeout | Large payload on a lossy or congested constrained link | Reduce payload size, lower send rate, or move to application block transfer. |
| Checksum failure | Corruption, wrong offload assumptions, or malformed encapsulation | Verify capture point, hardware offload settings, and byte-order handling. |
19.2 Summary
Datagrams are the packet unit that makes packet-switched IoT networking practical. A datagram carries delivery metadata in its header and useful application data in its payload. Each layer wraps the payload it receives, so the final frame on the wire includes transport, network, adaptation, security, and link overhead.
For IoT systems, packet structure is a design constraint. Small payloads can be dominated by headers, and oversized payloads can trigger fragmentation on constrained links. Reliable designs size messages against the smallest path MTU, keep frequent telemetry compact, and add application-level sequence or message identifiers when loss, duplication, or ordering must be detected.
19.3 Key Takeaway
Datagrams make each packet independently forwardable, but they do not make delivery reliable. Budget every header byte, avoid routine fragmentation, and make the application explicit about ordering, retries, and message identity.
19.4 See Also
- Data Representation in Networks - How bits, bytes, encodings, and compact payloads become datagram content
- Encapsulation & PDUs - How protocol layers wrap payloads into progressively larger units
- Packet Switching & Performance - How routers forward datagrams and how queues affect delay and loss
- IPv4 Addressing Fundamentals - How address fields support forwarding decisions inside datagram headers