Summary

  • BTPU can repeat exact copies of transfer messages when a unidirectional link offers no return channel for retransmission requests.
  • A Transfer End message names the last segment index. Only a receiver that has every index from zero through that value can call the local transfer complete; the sender does not learn that fact from BTPU.

A transmitter releases the same luminous fragment several times into a link that cannot answer. The copies may raise confidence, but none looks backward. This is the operating problem addressed by draft-ietf-dtn-btpu-04, a 7 September working-group draft for moving large binary objects—normally BPv7 bundles—over unreliable, frame-based, unidirectional links.

The protocol gives the receiver a precise reassembly rule. Segments share a 32-bit Transfer number and carry increasing Segment Index values. The Transfer End message includes the final segment and its index, N. Completion exists at the receiver only when every segment 0..N is present and the bytes can be concatenated. The result is then handed upward for further processing.

That sequence prevents one ambiguity while preserving several others. Emitting Transfer End does not prove that it arrived. Its arrival does not prove that earlier segments survived. Complete reassembly does not prove that BPv7 parsing, CRC or BPSec processing succeeded. Bundle-layer acceptance does not prove forwarding, endpoint delivery or application acknowledgement. Those are different events with different observers.

BTPU handles loss without pretending to have feedback. A sender may repeat any message in a different link-layer PDU, but a repeat must be an exact copy. Different segments and transfers may receive different repetition counts. Offline analysis, a local reliability class or an out-of-band loss signal may influence the policy. The draft does not assign a universal success probability to three copies, ten copies or any other number.

The sliding Transfer Window is another local control, not a delivery ledger. It bounds the Transfer numbers that remain active, lets a receiver distinguish new values from obsolete values after wrap-around, and discards state that falls behind the window. Its size is configured out of band; the draft recommends 16 while explicitly leaving that value for working-group discussion. A message ignored as too old says what the receiver did with its local state, not whether a sender's earlier business obligation was satisfied.

Repetition also remains separate from link-layer redundancy or erasure coding. Combining those counters into one “reliability” number would hide which mechanism acted and which failure it could observe. The optional Bundle Length Hint is similarly narrow: it supports memory allocation, but an expected length is not received content.

The deployment section states the decisive limit. BTPU is unreliable and has no in-band return path suitable for acknowledgement of transfer success. Any acknowledgement system must use a logically separate path from receiver to sender. The protocol also supplies no congestion control or signalling and must not be placed on a congestible public path unless the link layer supplies the missing control.

BPv7 already distinguishes reception, forwarding, delivery, deletion and application acknowledgement in its own status machinery. Those records may travel later and by another route. BTPU's virtue is narrower: it lets a one-way convergence layer move framed data without inventing a reverse channel. Good operations preserve that honesty.

Sources