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

["Clark, Gilbert J. (GRC-LCA0)" <[e-mail]>]

What about e.g. an index field in the primary block that includes an array of both the offset and type of each canonical block included within that particular bundle?

The ability to index directly to specific canonical blocks without needing to walk the bundle to find them at all would be nice.  It would also be useful to reduce the variance in processing time where e.g. a policy does need to be applied to a canonical block that comes later in a bundle.

-Gilbert

The views expressed in this mail reflect the opinions of the author.  They are, therefore, not intended to reflect official positions of NASA or the U.S. Government.
 
On 5/30/18, 4:36 PM, "dtn on behalf of Felix Walter" <[e-mail] on behalf of [e-mail]> wrote:

    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
    
    
    _______________________________________________
    dtn mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/dtn