Subject: Re: [dtn] AMP comment on TDC encoding duplication

From: Brian Sipos <[email-masked]>
Date: Wed, 6 Apr 2016 18:46:16 +0000

Ed,
Knowing that there is a driving need for the extra sizing data is enough that I have no problem with its presence.

Would there be any benefit to moving all of that 'metadata' into the front of the TDC encoding? Rather than leapfrog iteration through the TDC it would be a sum-of-lengths to jump to specific index. Just a thought, either way I have no issue.
On Apr 6, 2016 12:06 PM, "Birrane, Edward J." <[email-masked]> wrote:

Brian,

  I agree and disagree.

  I agree in the sense that if we set a requirement that all AMP type representations MUST be self-describing in their length, then an additional length field is not necessary.

  I disagree in the sense that the length of an AMP type may be dynamic, requiring some deep processing of the AMP data type to understand where it ends. If we do to encapsulate the AMP data in a BLOB then a "blind" processing agent would be unable to understand where the TDC ends because it could not do deep type inspection on the collection.  Further, it makes it more difficult for an agent to directly jump to "item N" in the collection.

  If we could devise a way to both preserve the ability to jump through the TDC and save space I am all for it. If we need to sacrifice one or the other, I would rather have extra bytes and the ability to more quickly navigate the TDC.

-Ed

---
Edward J. Birrane, III, Ph.D.
Embedded Applications Group Supervisor
Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839
________________________________
From: dtn <[email-masked]> on behalf of Brian Sipos <[email-masked]>
Sent: Wednesday, March 30, 2016 4:53 PM
To: [email-masked]
Subject: [dtn] AMP comment on TDC encoding duplication

This is a comment against "draft-birrane-dtn-amp-02".

These comments are based on my earlier comment about AMP data types being self-terminating (not needing an external size indication to decode typed data).

I believe that the current TDC encoding form has unnecessary duplication of count/size values. In the case of the "types" list at the head of the TDC encoding, the TDC "count" value and the size of the "types" BLOB end up being the exact same value and so the "count" is redundant (and possibly conflicting, if the encoding is malformed) data.

Additionally, the TDC use of a BLOB wrapper around each of the encoded values is duplication of information.
What I mean to say is that a type ID number *and* a data size is redundant, since the type ID itself is sufficient for a "blind" decoder to determine the content of some arbitrary data stream.  All of the encoded values either are fixed-length, or have a size/count embedded in the encoding (TDC, BLOB), or have some end-of-data (e.g. STR, SDNV) indicator.
In this way, the TDC (or similar nested structure) only need to have:
 - A list of the types of contained elements (the number of TDC-wrapped values is implicit in the number of types). The list can be encoded by a BLOB (as in the current spec), so the "count" value just needs to be removed.
 - A concatenated, encoded element data; size of each element is implicit in the type, and any explicit size is redundant.

I only mention this because when dealing with ASN.1 BER it is annoying that there is explicit size at each level, so nested data ends up repeating (large) size-indicating numbers. This causes the overall encoded size to balloon since the encoded sizes themselves grow as log(N) of the size of the data.

---

From: "Birrane, Edward J." <[email-masked]>
Date: Sun, 17 Apr 2016 19:18:10 +0000

Brian,

  There is something nice to having the meta-data up front, but I am unsure it provides any processing benefit. I’m inclined to keep it the way it is, but if we find a need for something different, let’s revisit.

-Ed

---

From: Brian Sipos [mailto:[email-masked]]
Sent: Wednesday, April 06, 2016 2:46 PM
To: Birrane, Edward J.
Cc: [email-masked]
Subject: Re: AMP comment on TDC encoding duplication

Ed,

Would there be any benefit to moving all of that 'metadata' into the front of the TDC encoding? Rather than leapfrog iteration through the TDC it would be a sum-of-lengths to jump to specific index. Just a thought, either way I have no issue.
On Apr 6, 2016 12:06 PM, "Birrane, Edward J." <[email-masked]<mailto:[email-masked]>> wrote:

Brian,

  I agree and disagree.

-Ed

---
Edward J. Birrane, III, Ph.D.
Embedded Applications Group Supervisor
Space Exploration Sector
Johns Hopkins Applied Physics Laboratory
(W) 443-778-7423 / (F) 443-228-3839
________________________________
From: dtn <[email-masked]<mailto:[email-masked]>> on behalf of Brian Sipos <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, March 30, 2016 4:53 PM
To: [email-masked]<mailto:[email-masked]>
Subject: [dtn] AMP comment on TDC encoding duplication