Block Airtime and the Retransmission Penalty

Block Airtime and the Retransmission Penalty

Ada re-derives this chapter’s own numbers step by step, at full precision

ADA · CALCULATION AUDIT

Block Airtime and the Retransmission Penalty

The chapter pushes a firmware update to a constrained device over a link that drops 10% of packets, sending it as CoAP blocks with a 200 ms round trip per confirmed block. As 1 KB blocks the 256-block transfer needs about 1.11 tries each and finishes near 57 s; as 512-byte blocks it stretches to roughly 114 s. This audit rebuilds each figure and asks whether that extra minute buys anything but reliability, given that halving the block size only halves the airtime wasted per lost block.

Companion to the chapter CoAP Advanced Features — every number here comes from that chapter.

Try

The chapter pushes a firmware update to a constrained device over a link that drops 10% of packets, sending it as CoAP blocks with a 200 ms round trip per confirmed block. Calculate this case.

Observe

This audit rebuilds each figure and asks whether that extra minute buys anything but reliability, given that halving the block size only halves the airtime wasted per lost block. Check shows this.

Explain

The audit conclusion is narrow but sharp: halving the block size exactly doubles the block count, so the confirmed airtime doubles too -- 113.8 / 56.9 = 2.0. That extra minute buys nothing except reliability, because each lost 512-byte block wastes only half the airtime of a lost 1 KB block. The number to defend in a release is not "block-wise transfer works" but "we acceptedtwice the confirmed airtime to halve the loss exposure per block." Check confirms it.

See the relationship before changing it

The figure reads from left to right. The blue input is packet loss. The middle card names the page’s rule. The green output is expected transfer time. The arrow matters: change the input, apply the rule once, then read the result with its unit.

Walk the arrow. Loss raises the expected try count by 1/(1 - loss).

Derive the baseline in four named moves

1. 1

   Name the input. The chapter baseline is 10 %.

2. 2

   Name the relationship. time = 256 blocks x 0.2 s / (1 - loss)

3. 3

   Substitute with units. 256 x 0.2 / 0.9 = 56.89 s

4. 4

   Read the result. Keep the unit beside the value, then use the result only inside the technical boundary below.

Predict, then change packet loss

Try Predict how expected transfer time responds when packet loss moves. Calculate packet loss; compare expected transfer time with that prediction.

Packet loss

10 %

Chapter baseline

Expected transfer time

Observe Return to 10 %. Recheck expected transfer time with packet loss at its chapter value.

Explain Loss raises the expected try count by 1/(1 - loss).

Check yourself

What should you do before trusting a moved-slider result?

Answer: Predict its direction, apply the displayed relationship, keep the units, and compare the reset value with the chapter’s worked baseline.

What does this small model leave out?

Answer: Only packet loss moves here. The expected transfer time calculation excludes field effects listed below.

Honesty note. The expected transfer time result holds packet loss as the only changing input. It is not a field prediction.

Technical boundaries

The fixed inputs for “Block Airtime and the Retransmission Penalty” omit loss bursts, congestion control, block reordering, server processing, radio-state transitions, or security overhead; “Block Airtime and the Retransmission Penalty” therefore reports only its named fixtures.

Ada: This chapter makes three numeric claims about block-wise transfer on a 10% loss link – that 256 unconfirmed 1 KB blocks almost never arrive, that each confirmed block needs about 1.11 tries, and that switching to 512-byte blocks pushes the transfer to roughly 114 seconds. Let me rebuild each from the chapter’s own inputs: packet-loss rate p = 0.10, a 200 ms round trip per confirmed block, and the block counts stated in the transfer table.

• Unconfirmed 256-block success: (1 - 0.10)^256 = 0.9^256 = 1.9323e-12, which is about 0.0000000002% – effectively never, exactly as the table’s ~0% says.
• Expected transmissions per confirmed block: 1 / (1 - 0.10) = 1 / 0.9 = 1.111111.... The chapter rounds this to 1.11 for readability; I carry the full value.
• 256 confirmed 1 KB blocks: 256 x 0.2 s x 1.111111 = 56.888... s, which rounds to 56.9 s only at the end (the chapter’s rounded 1.11 gives 56.8 s, and the table lists 57 s – the same result).
• 512 confirmed 512-byte blocks: 512 x 0.2 s x 1.111111 = 113.777... s, rounding to 113.8 s (chapter 113.7, table 114 s).

The audit conclusion is narrow but sharp: halving the block size exactly doubles the block count, so the confirmed airtime doubles too – 113.8 / 56.9 = 2.0. That extra minute buys nothing except reliability, because each lost 512-byte block wastes only half the airtime of a lost 1 KB block. The number to defend in a release is not “block-wise transfer works” but “we accepted 114 seconds to hold the per-loss waste to 512 bytes.”

Every number above is taken from the chapter’s own material and re-derived step by step.