Selective Reliability

Conventional reliable transport treats every byte as equally important and delay as preferable to loss. That is correct for a file transfer and wrong for anything with a deadline, where a frame, a sample or a position update that arrives after its moment has passed is not merely late — it consumed capacity that the current data needed, and it delayed everything queued behind it.

Selective reliability inverts the default: retransmit what still matters within its deadline, and drop what does not.

Where it applies

• Real-time media. A video frame from four seconds ago cannot be shown; retransmitting it steals uplink from the current frame.
• Location and telemetry streams. A position from four minutes ago has no value in a dispatch decision; the client should send its most recent position rather than a backlog.
• Live metrics and presence. The current value supersedes every earlier one.
• Any pipeline stage whose output has expired before it can be consumed.

Implementation patterns

• Attach a deadline or expiry to each item, so the decision to drop is data-driven rather than heuristic.
• Discard stale items on arrival, not only on send. A server receiving a four-minute-old location update should discard it rather than process it — which is what prevents a reconnect flood from becoming expensive.
• Send the latest, not the backlog. Clients emerging from a coverage gap should send current state rather than flushing everything queued, which is the difference between a recovery and a self-inflicted surge.
• Forward error correction where the round trip is long, so moderate loss is recoverable without any retransmission — trading continuous bandwidth for latency-free recovery.
• Adaptive rate reduction at the source, which addresses the cause rather than the symptom and is usually the highest-leverage control.
• Separate the reliable and unreliable channels explicitly, so control messages that must arrive are not subject to the same policy as data that expires.

Industry example

Live video ingest from consumer uplinks is the clearest case. In-order reliable delivery produces exactly the wrong behaviour: a lost packet stalls everything behind it, and the retransmitted frame arrives too late to be shown while having consumed capacity the current frame needed.

The mature designs use UDP-based transports with application-level selective reliability, latency-sensitive congestion control that does not treat wireless loss as congestion, and adaptive bitrate at the encoder as the primary control.

The same principle appears in mobility platforms, where drivers emerging from a coverage gap must send only their most recent position — and the server discards stale updates on arrival — because thousands of clients flushing queued backlogs simultaneously is both useless and expensive.

Failure scenarios

• Reliable transport used for expiring data, producing head-of-line blocking and stale retransmission.
• Clients flushing backlogs on reconnect, converting a network recovery into a demand surge.
• No expiry on items, so nothing can be dropped safely and the queue grows.
• Dropping control messages along with data because the policy was applied uniformly.
• Unbounded buffering at any stage, which converts a timeliness problem into a memory problem and then into a worthless-data problem.

Trade-offs

Selective reliability gives up completeness, which is unacceptable for anything where every item matters — financial transactions, audit events, orders. It also requires the application to know what has expired, which is domain knowledge the transport cannot supply.

The framing that decides it: is a late item worth more than the capacity it consumes? For file transfer, yes. For anything with a deadline, no — and treating the two the same is why real-time media protocols exist separately from general-purpose reliable transport.

Interview question

"Thousands of mobile clients emerge from a coverage gap simultaneously, each holding several minutes of queued location updates. What should the client send, what should the server do with it, and why?"