Re: [dtn] "Block data length" field in BPbis

[Felix Walter <[e-mail]>]

Marc,

yes, for intermediate nodes this requires parsing the complete CBOR
representation for all blocks. It also implies that a full CBOR parser
always has to be used because it is not known in advance which types
will be contained in unknown blocks.

An alternative would be to specify the "block payload" as being a single
CBOR byte string, containing the (serialized) block-specific data.
Though not as nice as having the bundle as a single large CBOR object,
from an implementation perspective, this is probably the simplest
solution. For example, the status blocks would then contain a serialized
CBOR array in the payload field.

Felix

Am 30.05.2018 um 21:37 schrieb Marc Blanchet:
> On 30 May 2018, at 15:10, Felix Walter wrote:
>
>> Scott,
>>
>> great, I think removing the field is the best solution.
>>
>
> much safer to have one single place for authority. However, does that
> require more parsing from the intermediate nodes if they need to
> somewhat parse some blocks for policy decisions for example?
>
> Marc.
>
>> Felix
>>
>> Am 30.05.2018 um 20:54 schrieb Burleigh, Scott C (312B):
>>> Felix, sorry, I am finally replying to this email: you are right
>>> that CBOR representation would provide all of the individual lengths
>>> of the block-type-specific data fields that are summed in the block
>>> data length field, and as such the block data length field is
>>> redundant.  My first impulse on re-reading your email was simply to
>>> revise the definition of "Block data length" as you suggest.  But on
>>> reflection I think it actually makes more sense to remove block data
>>> length from the specification and instead specifically require that
>>> all block-type-specific data fields appear in CBOR representation.
>>>
>>> I want to post version 11 of this specification later today, before
>>> version 10 expires, and at this point I plan to go ahead with
>>> removal of the block data length field.  If anyone has a technical
>>> argument to make in defense of retaining block data length in bpbis,
>>> please speak up this afternoon?
>>>
>>> Scott
>>>
>>> -----Original Message-----
>>> From: dtn <[e-mail]> On Behalf Of Felix Walter
>>> Sent: Friday, March 23, 2018 9:22 AM
>>> To: [e-mail]
>>> Subject: [dtn] "Block data length" field in BPbis
>>>
>>> Hi,
>>>
>>> We just had a short talk with Scott, Ed, and Rick about the "Block
>>> data length" [1] field of the canonical block in BPbis that I would
>>> like to forward to the list. As far as I understand it, this value
>>> is the count of (serialized) bytes still belonging to the block, but
>>> following the length field.
>>>
>>> Because CBOR is used for the block-type-specific data, the length
>>> field by itself is redundant. For example, in the payload block, it
>>> will always be followed by a "CBOR byte string" representing the
>>> payload data. (This contains a length as well.) It needs to be
>>> considered in implementations that all these length fields are
>>> variable-length themselves - however, this turned out to be no big
>>> issue. I also see the point of having the "Block data length"
>>> available to the parser, to be able to skip over the whole block
>>> data of complex extension blocks without even parsing them.
>>>
>>> Are there any further reasons for having the "Block data length"
>>> available which I have missed? Or does anyone have a strong opinion
>>> on whether this should be removed or kept?
>>>
>>> By the way, the language concerning the "Block data length" should
>>> probably be modified slightly as it refers to "[...] the aggregate
>>> length of all remaining fields of the block, i.e., the
>>> block-type-specific data fields.", though, this may (now) be
>>> followed by the CRC checksum.
>>>
>>> Felix
>>>
>>> [1] https://tools.ietf.org/html/draft-ietf-dtn-bpbis-10#section-4.2.3
>>>
>>> _______________________________________________
>>> dtn mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dtn
>>>
>>> _______________________________________________
>>> dtn mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/dtn
>>
>> _______________________________________________
>> dtn mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/dtn
>
> _______________________________________________
> dtn mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/dtn