14 Protocol Overhead and Packet Budgets

14.1 Start With One Packet Budget

This section: Start With One Packet Budget — Imagine sending a two-byte temperature reading from a small sensor.

Imagine sending a two-byte temperature reading from a small sensor. The useful reading may be smaller than the labels and checks wrapped around it. A payload is the useful data carried by a message. A protocol is a set of rules for exchanging messages. A gateway is a bridge between a local device network and a wider system.

Start with the payload size. Add every header, security record, reply, retry, and split frame used on the real path. Compare the full totals, not one header name. Then test a lost frame, a small radio limit, and many sensors reporting together. The cheapest packet may still fail if it cannot recover or arrive safely.

Use a byte ledger for one message. Write the useful data first. Add the local link fields. Add the network and transport fields. Add security. Add the application wrapper. Add any split-frame cost. Count replies and retries. Convert the total to airtime on the chosen link. Repeat the ledger for the other option. Keep the same useful data and delivery need in both rows.

Also check the empty case. Some systems spend energy on setup even when no useful data moves. Measure a normal hour and a bad-link hour before choosing the cheaper path.

This small budget assumes known message sizes and link behavior. Real traffic changes with security, errors, and control messages. The Practitioner section builds complete packet budgets. Under the Hood derives capacity, fragmentation, and energy costs.

Overhead analysis starts with one payload and the headers it must carry through the real stack. Separate payload bytes, transport headers, security records, fragmentation, acknowledgements, and control traffic before comparing protocols. The packet budget then shows which cost is measured, which is assumed, and which deployment limit could change the answer.

14.2 Overview: Overhead Analysis Starts With A Message Budget

This section: Overview: Overhead Analysis Starts With A Message Budget — Protocol overhead analysis asks how much traffic a useful application message creates after every required wrapper, acknowledgement, retry, security field, gateway handoff, and maintenance message is included.

Protocol overhead analysis asks how much traffic a useful application message creates after every required wrapper, acknowledgement, retry, security field, gateway handoff, and maintenance message is included. It is not a contest to find the smallest header in isolation.

The useful unit is a bounded flow: one message shape, one path, one receiver behavior, and one link or gateway constraint. A packet budget is accepted only when it separates payload bytes from wrapper bytes and names the evidence behind each count.

For example, a greenhouse alarm may carry only a compact sensor value, a timestamp, and an alarm code, but the deployed path still needs application typing, transport endpoints, network addressing, link framing, and usually security or integrity fields. If the review says "12 bytes of data" while the radio sends several times that amount after wrappers and acknowledgements, the energy, airtime, and reliability decision is being made from the wrong denominator.

The overview question is therefore practical: what traffic must the path carry for one useful receiver action? A status sample, an acknowledged alarm, and a periodic keepalive can each have a different answer. The record should name the message, the expected cadence, the required reply behavior, and the boundary where a small payload change would force another review.

To see why header size cannot be judged in isolation, compare the same small payload across the stacks in Figure 14.1. The visual establishes the denominator for the packet-budget decisions that follow.

+

Read Figure 14.1 from the useful sensor payload outward through transport and network wrappers, then compare the TCP/TLS/MQTT case with UDP/IPv6 and the compressed 6LoWPAN path. Finally place each total against the 127-byte IEEE 802.15.4 frame. The comparison shows how wrapper choices can dominate a small measurement and why the chapter evaluates complete message paths rather than protocol names.

The figure’s 2–8-byte compressed bar is an illustration of compressed IPv6 fields alone, not a complete UDP/6LoWPAN packet. A UDP datagram still needs its transport fields: eight uncompressed bytes, or a separately documented 6LoWPAN UDP next-header encoding under RFC 6282. Link framing and security also remain outside that bar. Do not compare its 12–18-byte total directly with the complete 58-byte UDP/IPv6 network packet without adding the omitted fields.

Overview Knowledge Check

14.3 Practitioner Pattern: Build The Packet Budget Before Comparing Protocols

This section: Practitioner Pattern: Build The Packet Budget Before Comparing Protocols — A practical overhead review uses the same payload and the same evidence categories for every candidate.

A practical overhead review uses the same payload and the same evidence categories for every candidate. That prevents a common mistake: measuring one path with a real trace while judging another path from a rough memory of its header size.

Start with a packet budget, then check whether the complete message still fits the link and adaptation boundary. Fragmentation changes more than byte count; it can add state, retries, queue pressure, and a harder failure mode for constrained devices.

Use a small ledger before selecting a protocol. In the example below, the useful value is 12 bytes, but the transmitted packet budget also includes application typing, transport endpoints, network routing, and link framing. The exact numbers are illustrative for that budget, not universal protocol constants. The decision point is the ratio and the boundary: if a schema change doubles the payload or a security profile adds another tag, the earlier frame-fit result may no longer apply.

The general comparison now needs a concrete byte ledger. Inspect Figure 14.2 to see how one temperature reading changes when the same useful data is carried by different protocol stacks.

+

In Figure 14.2, start with the 17-byte application message, then read each stack row by separating payload from headers. Compare the resulting efficiency only after confirming that the payload is held constant. This sequence connects the illustrative arithmetic to the review method: every candidate must use the same message definition before its airtime or energy consequence can be compared.

Byte efficiency is not the only outcome; crossing a frame limit changes the failure mode. Figure 14.3 shows the decision point that must be checked after the packet budget is complete.

+

Trace Figure 14.3 from the assembled message to the frame-fit check. A single-frame pass preserves the simpler path, while an oversize message splits into fragments and exposes retry, reassembly, and loss state before reaching a redesign or retest decision. The route turns the preceding byte ledger into an operational gate instead of treating fragmentation as a harmless arithmetic detail.

Practitioner Knowledge Check

14.4 Under The Hood: The Evidence Record Separates Measurements From Assumptions

This section: Under The Hood: The Evidence Record Separates Measurements From Assumptions — The hardest part of overhead analysis is not arithmetic.

The hardest part of overhead analysis is not arithmetic. It is preserving the source and confidence of each claim. A measured packet trace, an implementation log, a standards-derived estimate, and a design assumption should not be treated as the same kind of evidence.

The record also needs an owner and a retest trigger. If the payload shape, gateway boundary, security profile, link frame, retry policy, or receiver behavior changes, the earlier overhead conclusion may no longer apply.

A useful evidence record keeps a byte ledger beside the observation source. Payload size might come from the application schema, transport bytes from a packet capture, security bytes from the enabled library mode, and retry behavior from a gateway log under a lossy test. Labelling those sources matters because the next reviewer can see what is measured, what is derived, and what still needs confirmation on the deployed path.

Fragmentation is the classic place where assumptions hide. Once a protected message is split, the receiver needs enough state to reassemble it, the sender may need retry or timeout behavior, and losing any required fragment can lose the useful message. The overhead record should therefore capture both the single-message byte budget and the failure behavior at the gate, not just the nominal header sum.

Control traffic deserves the same treatment. An acknowledged alarm, a sleepy-node poll, a route-maintenance exchange, and a gateway translation can each add packets that are invisible in a one-packet comparison. If those packets occur only during join, reboot, or link loss, the record should say so. That prevents a steady-state trace from being reused as proof for recovery behavior.

The final overhead conclusion must distinguish observed bytes from estimates and open assumptions. Inspect Figure 14.4 to audit that distinction before accepting the worked total.

+

Read Figure 14.4 by first locating the measured, derived, and assumed entries, then follow the worked payload-plus-wrapper calculation to the frame boundary. Finish at the decision limit and retest trigger. The diagram connects the numbers back to their provenance, so a later schema, security, gateway, or link change reopens exactly the evidence it invalidates.

Under-The-Hood Knowledge Check

14.5 Count the Whole Reading before Comparing Header Sizes

This section: Count the Whole Reading before Comparing Header Sizes — Use the chapter’s uncompressed example: 10 useful bytes plus an 8-byte UDP header and a 40-byte IPv6 header.

Use the chapter’s uncompressed example: 10 useful bytes plus an 8-byte UDP header and a 40-byte IPv6 header. The network-layer packet is 58 bytes. Its header overhead is 48 bytes, so useful content is 10 divided by 58, or about 17.2% of that packet. This analysis has not yet counted link headers, link security or frame-check bytes.

Suppose the radio’s frame limit is 127 bytes. Subtracting 58 gives 69 bytes of apparent headroom, but that is not all available to the application because the link wrapper must also fit. The protocol ledger should reserve each actual field before deciding whether fragmentation is needed. Compression can change the wrapper size only under the contexts and options that the path really supports.

In the evidence-record figure, the 2–8-byte compressed value is likewise only a conditional network-header illustration. Keep the UDP header (or its explicitly measured RFC 6282 compressed form) and the actual 802.15.4 link/security bytes in the complete on-air ledger.

Read Figure 14.4 from measured, derived and assumed entries into the payload-plus-wrapper total. The labels prevent an estimate from being reported as a captured packet length. Keep the same analysis boundary when comparing another transport; otherwise a protected packet can be unfairly compared with an unprotected header sketch.

Now assume one reading requires two transmissions after a lost attempt, each carrying the same 58-byte packet at this layer. The overhead analysis now counts 116 bytes sent for one useful 10-byte reading, before additional control traffic. The retry overhead is visible even though the packet’s individual header size did not change.

Predict whether batching two readings always halves energy per sample. It may share some protocol overhead, but a larger packet can change airtime or cross a fragmentation boundary. The energy analysis needs the actual radio setting and success behaviour. Next, add a security handshake to every exchange. Overhead from setup can dominate the compact reading even when its individual data-packet header remains unchanged.

This module’s transport comparison depends on a complete workload ledger: payload, wrappers, setup, acknowledgements, retries and fragmentation. Record both normal and failed exchanges with their observation points. The resulting overhead calculation can guide a design change without pretending that fewer application bytes automatically mean a cheaper or more reliable radio transaction.

14.6 Summary

This section: Summary — Protocol overhead analysis turns byte counts into a reviewable transport decision.

Protocol overhead analysis turns byte counts into a reviewable transport decision. Start with one message path, build a packet budget, add control traffic and retry behavior, check fragmentation risk, compare candidates with the same evidence categories, and record the decision with a clear retest trigger.

14.7 Key Takeaway

This section: Key Takeaway

14.8 See Also

This section: See Also