Re: [dtn-interest] Comments on RFC 5050

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

Thanks, Michael, I think this is productive.  More notes in-line below.

Scott

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

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.

	Okay, I think this is worth discussing, but I personally am doubtful that there's more than marginal net advantage here.  In general I don't think it has been difficult for us to make the kinds of design-time decisions this sort of system is designed to shield us from.  At the same time, it makes it impossible to represent a numeric value larger than 63 in a single byte.  The cost in additional metadata doesn't seem, to me, to be justified by the benefit.  But as I say, it's worth discussing.

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

	Again I think we're talking at the margins.  Currently I suspect all implementations process every SDNV as an SDNV, even when it is only a single byte in length.  I think what you're proposing would divide SDNVs into two classes: those that must always be processed as SDNVs and those that may simply be processed as bytes because they're always only a single byte -- except that at some point in the future they might get potentially bigger and have to change into the other sort of SDNV, at which point you've got to change your code.  We could of course get around this by doing an extra check of the high-order bit of the first byte whenever we process an SDNV and, if it's zero, simply processing that single-byte SDNV as a byte.  But that's still slightly more processing than immediately processing the byte field as a byte field, and in addition we've cut the range of possible values in that variable by 50%.   So it's not quite true that if you are confident that the value will always stay low then nothing is lost.  I'm doubtful, but I guess it's not a huge deal one way or the other.

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

	I don't know whether I'd call it a restriction or not.  The real issue, I would say, is that the difference between unicast and multicast (singleton-ness) is orthogonal to the question of how you forward a bundle toward one of its destination nodes (late binding).  The mechanisms are distinct, and the information items required to invoke them successfully are distinct.

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

	No, the eight integer values (node number and service number, for source, destination, report-to, and custodian) are still encoded as SDNVs.  CBHE is not a general solution to the problem of encoding any scheme-specific part given a scheme name; it's a single, very specific header compression mechanism that is available for a limited set of scheme names.  I have a feeling I'm not understanding your question, though.

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

	Hmm.  A BAB can certainly be processed and removed, which would remove its EID references, which would in theory authorize the removal of the BAB's EID(s) from the dictionary, but that couldn't invalidate the authenticity of the bundle.  I think the same is true of other types of extension block.
	More generally, though, I am an ardent advocate of losing the dictionary altogether, using CBHE-like encoding natively in the primary block for routine unicast, and carrying uncompressed EID text in extension blocks when more exotic EID structures need to be processed.  I expect this point of view is not universally held, so it may well not prevail as we move toward updating the BP specification, but I believe it would solve a multitude of problems, not least these dictionary management issues.

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

	That's not unreasonable, but on the other hand those additional status reports might actually be helpful.  They're not of much use to the sending application, which already knows that the end-to-end transmission has succeeded, but that's not the sole purpose of the status reports.  Bundle status reports are often used as network management/debugging tools, to trace the paths taken by bundles through the network, and for that purpose the fact that a bundle was redundantly delivered might be important information.
	In general I think the sense of DTNRG was that bundle status reporting is a mechanism that has to be used sparingly in order to avoid saturating the network with metadata.  In that case, an infrequent redundant report at worst does little harm and at best might do some good.
_______________________________________________
dtn-interest mailing list
[e-mail]
https://www.irtf.org/mailman/listinfo/dtn-interest