Re: [dtn-interest] Comments on RFC 5050

[Michael Noisternig <[e-mail]>]

Thanks again, Scott. See my replies inline.

Michael

> 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.

Well, there are various solutions though they may not be as pretty. One 
is as such, with bits in standard order (msb first):

  0....... data preceded by length value, where
  00......   length value has one byte (6 bits)
  01......   length value has more than one byte (SDNV-encoded)
  10...... data has one byte (6 bits)
  110..... data has two bytes (13 bits)
  1110.... data has three bytes (20 bits)
  aso.

The intent is solely to avoid the decision at the protocol design phase 
whether to directly SDNV-encode the data or to precede it by some 
SDNV-encoded length field.

> 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.

No, the point is that this doesn't make the processing any more complex. 
Type codes etc. are still compared on a byte basis just as now. The only 
difference is that bytes values 128-255 are "reserved" to indicate a 
multi-byte (SDNV-encoded) value. At least that way one can assure that 
the number of type codes later defined will never become too large. (And 
if you are confident that the number will always stay slow then nothing 
is lost either.)

> 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.

I agree, the disadvantage is likely negligible. Still, I dispute the 
rationale given in the RFC for why bits are not in the standard order of 
RFCs:
"This is
    why the descriptions in this section and the next do not follow
    standard RFC conventions with bit 0 on the left; 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."

> 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.

Hm, but then someone (the source/the application) must know that the 
destination EID represents a singleton. It might be a restriction or it 
might be not. (I take your word if you say it is not.)

> 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.

Maybe I don't understand what RFC 6260 (CBHE) says. Section 2.2 states that
"In a CBHE-compressed primary block, the eight SDNVs that
    normally contain EIDs' scheme name and SSP offsets within the
    dictionary are instead used to contain the eight integer values..."
As per the BP spec these must be SDNV values. Are they instead encoded 
as 64-bit integer values? If so, how can non-compatible receivers 
correctly parse the bundle header?

> 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.

Could it happen that some extension block be processed, removed and its 
EID references removed by some intermediate node on a security path? I 
am still trying to figure out what is possible with the current security 
spec.

> 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?

Let's say a duplicate bundle has been received. Then by steps 2 and 3 
the receiving node would potentially already have sent several redundant 
bundle reception status reports. It seems that such behavior on replays 
should be avoided.