Re: [dtn-interest] Comments on RFC 5050

["Burleigh, Scott C (313B)" <[e-mail]>]

Michael, a few comments in-line below.

Scott

-----Original Message-----
From: [e-mail] [mailto:[e-mail]] On Behalf Of Michael Noisternig
Sent: Tuesday, June 18, 2013 2:09 AM
To: [e-mail]
Subject: [dtn-interest] Comments on RFC 5050

Continuing my review (part 2/3) with RFC 5050...

4. Bundle Format:
"At most one of the blocks in the sequence may be a payload block."
Would it be advanteous to allow more payload blocks with different (e.g., security) processing?

>       We've considered this several times but I think we've never seen enough advantage to justify the additional complexity.  It would enable aggregation of multiple application data units into a single bundle, thereby saving the overhead of multiple primary blocks.  However, that aggregation could just as readily - and possibly even more efficiently - be done above BP (in the application, or in the Delay-Tolerant Payload Conditioning layer we're standardizing in CCSDS).  At the same time, supporting multiple payload blocks would seem to make fragmentation and reassembly more complicated.  So it's not an obvious improvement.

4.1. SDNVs:
I am not convinced this is the best solution. Even if we acknowledge that some flexible way to encode variable-length data is needed protocol designers are still faced with the decision whether to directly SDNV-encode some data field or instead SDNV-encode a length field such as to more efficiently carry lengthy data. Why not combine the current SDNV solution with some UTF-8-like encoding, such that the length of the data field is implicitly encoded?

>       Can you describe in more detail the specific alternative you are proposing?  That would give us a basis for comparison, which might answer this question.

The protocol also includes several byte values that are not
SDNV-encoded: Version field, Block Type code, etc. These could easily be declared SDNV values without loosing backwards compatibility (to currently defined values) or processing efficiency.

>       Sure, but while SDNVs are not extremely processor-intensive to handle they always consume more cycles than simply operating on a byte.  If there's a significant likelihood that a field will need to be of different sizes under different circumstances, defining it as an SDNV makes sense; otherwise it doesn't.

4.2. Bundle Processing Control Flags:
"if fields are added
    in the future, the SDNV will grow to the left, and using this
    representation allows the references here to remain valid."
I see no reason why references should become invalid if the field would grow to the right with bit number 0 put on the left. The present representation has the disadvantage that the whole field needs to be received first before standard flags (those in earlier versions) can be parsed.

>       This doesn't seem like a significant disadvantage.  Even if a BP agent received its bundles one byte at a time, it probably shouldn't act on the basis of bundle processing control flags until at least the entire primary block has been received.

Flag 0 "Bundle is a fragment.": This flag obviously refers to the payload block, only, but could it be desirable to support fragmentation in other blocks as well such as in "optional" extension blocks?

>       Nobody has identified a requirement to fragment extension blocks.  If such a requirement were identified we would need to revisit fragmentation and the meaning of this flag might well have to change.

Flag 4 "Destination endpoint is a singleton.": Requiring this knowledge seems to be in direct conflict with late binding.

>       I don't think so.  Late binding is about not requiring the source node to know the topological location of the destination.  Endpoint cardinality is about constraining the processing performed at forwarding nodes.

4.3., last paragraph:
Why the restriction that "the block processing flags must be set to zero on all blocks that follow the payload block"?

4.4. Endpoint EIDs:
"Each endpoint ID conveyed in any bundle block takes the form of a Uniform Resource Identifier (URI; [URI])."
URIs are nice in being human-readable but they are also very wordy.

>       I personally agree with you on this point.  URIs are a great external representation of endpoint IDs but not necessarily a good internal representation; sort of like the difference between 32-bit IPv4 addresses and dotted-string IP address representations.

It would be beneficial to generalize the current notion to support any kind of encoding (including binary) for the scheme-specific part given an
(ASCII) scheme name. This is crucial for bandwidth-constrained environments, and definitely sufficient for applications that don't span multiple networks.

>       This is why there's an RFC for CBHE.

"This array is simply the concatenation of any number of null-terminated scheme names and SSPs."
Instead of null-terminating strings, why not encode them with prefixed SDNV length values? This seems to make the design more consistent and may improve string copy operations. But that's a minor comment.

4.7. Dictionary Revision:
"Any [unreferenced] strings (scheme names and SSPs) in a bundle's dictionary ... may be removed from the
    dictionary at the time the bundle is forwarded."
...subject to that authenticity is not lost.

>       Yes, but that's implicit.  Strings that are needed in order to verify authenticity are referenced, so they can't be removed from the dictionary.

5.2. Bundle Transmission, step 2:
"... with current custodian endpoint ID set to the null endpoint ID "dtn:none"
It should be up to the source to decide whether to support custody transfer, i.e., whether to set the current custodian EID to the source EID or to dtn:none.

>       The custodian EID is initialized to "dtn:none" at bundle creation time, regardless of whether or not the source node subsequently chooses to take custody.  Initial acceptance of custody at the source node happens later in the procedure, in step 4 of 5.4, subject to the decision made in 5.2 step 1.  But I do think the language could be clarified a bit here.

5.6. Bundle Reception, step 4:
"If [a duplicate bundle has been received that] has the
       retention constraint "Custody accepted", custody transfer
       redundancy must be handled."
Why are processing steps 2 and 3, which generate bundle reception status reports, being executed before step 4?

>       Can you say a little more about why they shouldn't be?

_______________________________________________
dtn-interest mailing list
[e-mail]<mailto:[e-mail]>
https://www.irtf.org/mailman/listinfo/dtn-interest