Summary

  • RFC 3366 treated link-layer ARQ persistence as a bounded decision about how much time a link spends recovering a frame before giving up—not as a free increase in reliability.
  • A retry can help one transport flow while adding cumulative delay, jitter or blocking for other traffic; frame acknowledgement still does not prove timely application delivery.

A frame is not the whole packet

The story begins below IP. Automatic Repeat reQuest, or ARQ, detects a missing or corrupted link frame and tries again. Depending on the link, a frame may carry a fragment of an IP packet, an entire packet, or pieces from more than one. The link's acknowledgement answers a narrow question: was this frame accepted under that link protocol? It does not certify that an end-to-end packet reached its destination or that an application could still use it.

RFC 3366, published as Best Current Practice 62, asked designers to take that boundary seriously. Its authors were not specifying one radio protocol or prescribing one retry count. They were explaining how a link-specific repair loop interacts with the Internet traffic above it.

The retry budget spends shared time

The document calls the willingness to retry “persistence.” A design may allow a fixed number of attempts, or let timers and link-failure procedures determine when retransmission stops. An attempt count is not a clock: propagation, shared-medium backoff, queueing, frame size and processing all affect how much time elapses.

That makes reliability conditional. A local link can often react faster than TCP's end-to-end control loop and repair a channel error before the sender retransmits. Yet the recovered frame may arrive after enough delay to change the transport's timer behavior. If the link holds packets in order, later complete packets can wait behind one frame still being retried. On a shared channel, retries can also consume airtime needed by other nodes.

Perfect persistence makes the contrast plain: keep trying indefinitely, and do not report the link packet as lost while the receiver might still accept it. That can be useful for a transfer whose purpose is reliable delivery. Across multiple links, however, repeated recovery can duplicate work already provided end to end; it cannot guarantee the same reliability as transport at the endpoints. For streaming or other time-sensitive UDP traffic, a late packet may be less useful than a missing one.

What the link can safely know

It is tempting to assign long persistence to traffic that “looks reliable” and short persistence to everything else. RFC 3366 explains why observation is not enough. A link may see congestion-control behavior without knowing the application's deadline or whether it values complete delivery over timeliness. Port numbers can be misleading or remapped; tunnels combine different flows; encrypted payloads limit inspection; and a service marking may be overwritten or have only local meaning.

The advice is therefore conditional. If a designer can distinguish service classes safely, different retry behavior may help. If not, all flows inherit the same link behavior. For a link unable to classify them, the BCP generally favors low persistence: recover some frames, but do not let one unfinished packet hold the queue indefinitely. The document also keeps the counterexample: high persistence can help a TCP flow under some variable-error or post-outage conditions. There is no universal best setting.

RFC 3819, the broader subnetwork-design BCP published in 2004, widened the picture to a three-way tension among loss, mean delay and delay variation. That later guidance reinforces flexibility; it does not turn the 2002 example of two to five retries into a modern rule or a measurement of what networks deploy.

The receipt stays local

RFC 3366's durable lesson is about evidence as much as performance. A frame ACK records one local event. A packet leaving the link, a transport accepting data, and an application receiving it in time are later events, each needing its own evidence. A retry may reduce channel-error loss while worsening jitter, delaying congestion feedback or spending time other flows needed.

The link designer chooses a local budget; the path accumulates its consequences. Without knowing the rest of the path or the application's freshness requirement, a device cannot turn “more attempts” into a promise of better service. BCP 62 asked link designers to make that uncertainty part of the design, not to hide it beneath a reliability label.

Sources

Lu Heng did not author RFC 3366. These essays are disclosed as analytical lenses on the difference between a recommendation, running implementation, configured behavior and observed outcome.