This is the 2D network-path counterpart of the 3D OSCORE vs DTLS simulator: same two protocols, same byte and energy accounting, but here the path between sensor and server runs through N adjustable proxy hops so you can see how each protocol's overhead scales with hop count, not just packet loss.
DTLS 1.2 secures the transport hop by hop. Every proxy on the path terminates the DTLS session from its upstream neighbour and opens a fresh one to its downstream neighbour — it has to fully decrypt the record to route the CoAP message, then re-encrypt it. That means a path with H intermediate proxies has H + 1 independently-secured segments, and every segment pays its own handshake (or resumption) cost plus its own ≈29-byte record overhead on every message.
OSCORE secures the CoAP message itself with COSE/AEAD, using an end-to-end Security Context established once via EDHOC. A proxy forwards the object-secured message unchanged — it never decrypts it, so hop count doesn't multiply the overhead. Total cost is one fixed EDHOC setup (~280 B, paid once, not per hop) plus a flat ≈16 B per message, independent of H.
segments = hops + 1
DTLS_total = segments × (handshake_bytes + 29 × messages)
OSCORE_total = 280 + 16 × messages (hop-independent)
handshake_bytes = 1450 (full cert handshake) or 220 (resumption)
Latency (illustrative, constrained-MCU link):
DTLS_latency = segments × (prop_ms + crypto_ms) — every hop pays crypto
OSCORE_latency = segments × prop_ms + 2 × crypto_ms — only the two endpoints pay crypto
Because DTLS's cost is multiplied by segments and OSCORE's is flat, there is a genuine crossover hop count: for a short, resumption-based, low-volume DTLS session on a single hop, DTLS can still transmit fewer total bytes than OSCORE's one-time EDHOC setup — but add proxy hops or send more messages and DTLS's repeated per-segment cost overtakes OSCORE almost immediately. A full-handshake DTLS session is essentially never cheaper, even at zero hops. Move the hop and message sliders and watch the bytes-vs-hops chart's crossover marker shift live.
Real-world relevance: this is exactly why CoAP deployments that route through untrusted intermediary proxies (border routers, cloud brokers) standardise on OSCORE — DTLS's per-hop re-encryption is both a bandwidth/energy cost and a trust problem, since every proxy would need the plaintext to do its job.