No way of knowing if a Bundle Message is repeated on receiver side

[climoge]

Hello.

A Bundle Message does not have a Transfer Number field, so a Receiver can't determine if a received Bundle Message is new or is a repeated one.

Also, we can't slide the Transfer Window because of that, that's a problem :
In the RFC draft it's stated that we can at most have the Transfer Window size number of simultaneous transfers. But we can send an infinite amount of Bundle Messages because of the lack of an associated Transfer Number.

Or do I miss something ?

[ricktaylor]

Hi, and thanks for reading the draft so closely — this is a very natural question coming from a bidirectional, reliable CL like TCPCLv4.

The framing to keep in mind is that BTP-U is unidirectional and unreliable by design (§Handling Link-layer PDU Loss): there's no return path, so there are no acknowledgements and no "sliding window" in the TCP flow-control/reliability sense, and deliberately repeating Messages is a feature, not something the receiver must detect and reject. With that, the two concerns resolve as follows.

1. A Bundle Message is a complete bundle, deliberately with no Transfer Number. §Segmentation and Transfers says: "if a complete Bundle can fit in the next Link-layer PDU, then the Bundle SHOULD be transferred without segmentation, see the Bundle Message." The Bundle Message (type 2) accordingly carries only the bundle itself — its content "MUST be a valid Bundle" — and has no Transfer Number field, unlike the Transfer Segment / Transfer End / Transfer Cancel Messages, which all carry one. A Transfer Number exists solely to reassemble a segmented bundle and to scope its in-progress reassembly state; a single-message bundle has nothing to reassemble, so no identifier is required. This isn't an omission — it's the draft saying a whole-bundle transfer needs no transfer context.

2. The Transfer Window bounds concurrent in-progress segmented Transfers, not the bundle rate. Per §Transfer Window it's "the maximum number of Transfers that can be simultaneously in progress" — a cap on how many reassembly contexts a receiver holds open at once, and it slides off the Transfer Numbers carried in the segment-bearing Messages. A Bundle Message isn't a Transfer, carries no Transfer Number, and opens no reassembly state, so it occupies no window slot. That's exactly why you can send any number of Bundle Messages without touching the window: they're a stream of complete, stateless bundles. The "infinite Bundle Messages vs. finite window" comparison is really comparing two different things — stateless complete-bundle delivery versus the bounded set of concurrent segmented reassemblies, which is the only thing the window limits.

On new vs. repeated: for a complete bundle that's the Bundle Protocol's job, not the CL's, and it's well-defined. RFC 9171 identifies every bundle unambiguously by its source node ID and creation timestamp (and, for a fragment, the fragment offset and total ADU length), so duplicate detection is unambiguous and handled by the BPA. Because the link is one-way and lossy, a sender may intentionally repeat a Bundle Message for robustness (see §Repetition of Bundle Segments); the receiving CL simply hands each complete bundle up, and the BPA discards any duplicate by that identity. BTP-U only defines optional duplicate suppression within an in-progress Transfer (a receiver MAY ignore a Message it already holds); it deliberately doesn't deduplicate whole bundles, precisely because RFC 9171 already does.

So the receiver needs no Transfer Number on a Bundle Message, and there's no window accounting that any number of Bundle Messages could overflow.

Hope that helps?

[climoge]

Hi,

Thank you, it helps a lot !
I spoke to the person I’m working with on the draft about this issue I had and they said to me that the Bundle Protocol can handle deduplication.
I'm solely focused on implementing the BTPU draft so I'm lacking a better understanding of the whole protocol.
Sorry for bothering you with beginner questions.

I've almost finished a first implementation draft of the BTPU in Rust with a C FFI, I will share it when it's done.

[ricktaylor]

Hi, No bother at all, I'm very happy to answer questions! We would be interested in seeing your BTPU implementation as we have one in progress for Hardy as well, and some interop testing would be great! ricktaylor/hardy#529 On 24 Jun 2026 13:32, climoge ***@***.***> wrote: [https://avatars.githubusercontent.com/u/14925745?s=20&v=4]climoge left a comment (ricktaylor/btpu#4)<#4 (comment)> Hi, Thank you, it helps a lot ! I spoke to the person I’m working with on the draft about this issue I had and they said to me that the Bundle Protocol can handle deduplication. I'm solely focused on implementing the BTPU draft so I'm lacking a better understanding of the whole protocol. Sorry for bothering you with beginner questions. I've almost finished a first implementation draft of the BTPU in Rust with a C FFI, I will share it when it's done. — Reply to this email directly, view it on GitHub<#4?email_source=notifications&email_token=AAGBVIKD43CCS6HWC7UHM2D5BOYHJA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZYHA2TEOBUGMYKM4TFMFZW63VMON2GC5DFL5RWQYLOM5S2KZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-4788528430>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AAGBVIIV5NF7QZ3BDPJHSXD5BOYHJAVCNFSNUABFKJSXA33TNF2G64TZHM4TCNRVGU3DKNRTHNEXG43VMU5TINRVGY4TANZTHA42C5QC>. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS<https://github.com/notifications/mobile/ios/AAGBVIJBDUOCC46WWIWDXPT5BOYHJA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZYHA2TEOBUGMYKM4TFMFZW63VMON2GC5DFL5RWQYLOM5S2KZLWMVXHJKTGN5XXIZLSL5UW64Y> and Android<https://github.com/notifications/mobile/android/AAGBVIIJBXWVBLCPFJ664ND5BOYHJA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTINZYHA2TEOBUGMYKM4TFMFZW63VMON2GC5DFL5RWQYLOM5S2KZLWMVXHJLTGN5XXIZLSL5QW4ZDSN5UWI>. Download it today! You are receiving this because you modified the open/close state.Message ID: ***@***.***>