Subject: [dtn] bpbis-12 and Bundle Fragmentation - where is total application data unit length ?

From: Loiseau lucien <[email-masked]>
Date: Thu, 10 Jan 2019 18:12:35 +0100

Hi all,

I am implementing bundle fragmentation (5.8) and application data unit
reassembly (5.9) for Terra and it appears that the draft may have some
inconsistencies.

In 5.8 the draft states the following:

. The primary block of each fragment MUST differ from that of the
        fragmented bundle, in that the bundle processing flags of the
        fragment MUST indicate that the bundle is a fragment and both
        fragment offset and total application data unit length must be
        provided.

However it seems that the total application data unit length is no
longer part of the primary block header field since bpbis-07. Should
Total Application Data Unit Length be added back into the primary
block ?

I wonder how the destination can proceed with reassembly without this
field, what was the rational in removing this field or is it a mistake
?

Best Regards,
Lucien.

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Fri, 11 Jan 2019 20:43:43 +0000

Hi, Lucien.  I have gone back through the DTN WG mailing list and all my notes on bpbis, and I cannot find where we agreed to remove the total application data unit length from the primary block header.  (We agreed to remove it from the "Segment ID", but not to remove it altogether from the Primary Block.)  I think its removal was simply a mistake, which we need to remedy in the next edition of the bpbis I-D.

Scott

-----Original Message-----
From: dtn <[email-masked]> On Behalf Of Loiseau lucien
Sent: Thursday, January 10, 2019 9:13 AM
To: [email-masked]
Subject: [dtn] bpbis-12 and Bundle Fragmentation - where is total application data unit length ?

Hi all,

I am implementing bundle fragmentation (5.8) and application data unit reassembly (5.9) for Terra and it appears that the draft may have some inconsistencies.

.. The primary block of each fragment MUST differ from that of the
        fragmented bundle, in that the bundle processing flags of the
        fragment MUST indicate that the bundle is a fragment and both
        fragment offset and total application data unit length must be
        provided.

However it seems that the total application data unit length is no longer part of the primary block header field since bpbis-07. Should Total Application Data Unit Length be added back into the primary block ?

I wonder how the destination can proceed with reassembly without this field, what was the rational in removing this field or is it a mistake ?

Best Regards,
Lucien.

_______________________________________________
dtn mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dtn

---

From: Loiseau lucien <[email-masked]>
Date: Fri, 11 Jan 2019 21:52:49 +0100

Hi Scott,

thanks for your answer!

Since we are talking about fragmentation, it may happen that different
fragments having taken different path in the network and undergo
re-fragmentation may end up overlapping. Right now on a receiver side,
I need to wait for the payload to be parsed in order to compute its
length and so deciding what to do with the fragment. I believe that it
would be very helpful if the primary block would contain the fragment
length as well so as to keep the logic self contained.

Another solution would be that if the flag "Bundle is a fragment" is
set in the primary block, then the bundle MUST include a "Fragment
Information Block" that would contain the fragment offset, fragment
length and total application data unit length so as not to have a
primary block with two many "optional" fields.

What do you think ?

Best Regards,
Lucien

-- 
--
Lucien Loiseau

---

From: "Burleigh, Scott C (312B)" <[email-masked]>
Date: Fri, 11 Jan 2019 21:01:30 +0000

Some time ago we had a "Fragment ID" compound field that was composed of the fragment offset and total application data unit length.  It turned out that the combination of fragment offset and bundle payload length (which is fragment length, by virtue of the fact that the bundle is a fragment) is what is really needed as Fragment ID, so the composite Fragment ID field wasn't needed.  We could combine fragment offset and total application data unit length into a single composite Fragment Information field with two components, if that seemed simpler to operate on.  I'm doubtful that it is really any simpler, but have got no strong feelings either way.

Scott

-----Original Message-----
From: Loiseau lucien <[email-masked]> 
Sent: Friday, January 11, 2019 12:53 PM
To: Burleigh, Scott C (312B) <[email-masked]>
Cc: [email-masked]
Subject: Re: [dtn] bpbis-12 and Bundle Fragmentation - where is total application data unit length ?

Hi Scott,

thanks for your answer!

Since we are talking about fragmentation, it may happen that different fragments having taken different path in the network and undergo re-fragmentation may end up overlapping. Right now on a receiver side, I need to wait for the payload to be parsed in order to compute its length and so deciding what to do with the fragment. I believe that it would be very helpful if the primary block would contain the fragment length as well so as to keep the logic self contained.

Another solution would be that if the flag "Bundle is a fragment" is set in the primary block, then the bundle MUST include a "Fragment Information Block" that would contain the fragment offset, fragment length and total application data unit length so as not to have a primary block with two many "optional" fields.

What do you think ?

Best Regards,
Lucien

--
--
Lucien Loiseau