Subject: [dtn] Responses to the open issus in dtn-dtnwg-bp-00

From: Elwyn Davies <[email-masked]>
Date: Wed, 22 Jul 2015 13:05:57 +0200

Some thoughts below...
> 3. Open Issues
>
> 13.1. Definitions section structure
>
>     Would it be better to restrict the Definitions section to
>     definitions only, and move description, conceptual operation,
>     potential implementation, justification, and commentary to one or
>     more additional sections?  Or would fractionating this information
>     across multiple sections would make it harder to grasp?
Restrict to definitions.  The later items are 'worse' than the earlier, 
but just having a single stream leads to some ordering problems.
>
> 13.2. Payload nomenclature
>
>     It has been proposed that (a) there is no need to define "nominal
>     payload" and (b) "partial" payload would be better than
>     "fragmentary" payload.  (The term "nominal payload" is used in the
>     definition of fragmentation.)
I don't think 'nominal' helps at all.  'partial' is probably better.
>
> 13.3. Application Agent
>
>     Does the discussion of Application Agent functionality need to be in
>     the BP spec?  If so, should there be a diagram explaining how the
>     various components of the BPA interact?
Absolutely. yes.  Mainly because it impacts the registration story.
>
> 13.4. Bundle Endpoint definition
>
>     Is the source of a bundle always a node, or do we want to define a
>     way in which a set of nodes (an endpoint) can collectively transmit
>     a bundle?
Frankly, in a DTN context 'collectively' just makes the management 
problem an order of magnitude worse.
Just how would one achieve effective coordination?
>   Does the latter trace back to a use case we need to
>     support?
I do hope not!
>
>     Is a bundle custodian always a node, or do we want to define a way
>     in which a set of nodes (an endpoint) can collectively take custody
>     of a bundle?  Does the latter trace back to a use case we need to
>     support?.
Arrrggghhh!  Please only one node.  [Or more accurately one at a time.]  
It occurs to me that I haven't really though through the case where the 
custody node replicates a bundle.    What happens if each (or at least 
two) of the replicas arrive at nodes that are prepared to be 
custodians.  Presumably there is a race and one node gets to be the new 
custodian, but what happens in the other nodes? Hmm.
>
> 13.5. Alignment with ICN
>
>     Is it necessary to modify the bundle transmission procedure to
>     enable BP to be used for information-centric networking, i.e.,
>     delivering data to a node who requests that data after it has
>     already been transmitted?  Specifically, would a DTN ICN cache point
>     "transmit" data to a client (i.e., source a new bundle) or would it
>     merely "forward" a previously transmitted bundle of which it has
>     retained a copy?
I have implemented this scenario.  Effectively you have to originate a 
'new' bundle but with a reduced lifetime and different destination 
address.  As usual with ICN, handling security aspects are non-trivial.  
Easy with public info and an ICN scheme like netinf.
>
> 13.6. Implementation Architectures
>
>     Should the BP spec be divided into two documents? One to talk about
>     conops and context and one that focuses specifically on the
>     protocol?
The current implementation info is really of the 'grandmas and eggs and 
sucking' variety and can be dropped altogether.  The processing 
information needs to be in the same draft.

> 13.7. Security protocol name
>
>     Will the name of the DTN security protocol be Bundle Security
>     Protocol or Streamlined Bundle Security Protocol?
It will be what it will be.  This is not an issue.
>
> 13.8. Bundle format
>
>     Should the rules for defining block structure be presented at the
>     start of section 4 or in the discussion of the payload block and the
>     "last block" flag?
I'd do a major restructure of s4 and including moving the flag defs 
after the block defs as is done in almost all 'conventional' protocols.

Separate the extension blocks into a separate section.
>   Should we require that the payload block always
>     be the last block of the bundle, so that the "last block" flag is no
>     longer needed?  (This would make reactive fragmentation easier.)
This depends on whether (as in RFC 5050) some extension blocks (similar 
to hop-by-hop blocks in IPv6) need to be in every fragment but there are 
'destination' only extension blocks that are only needed in one place. 
This might push the 'last block' payload out of the first fragment if 
the relevant MTU was too small and the destination only extension blocks 
had to be in front of the payload.  It also depends on whether we are 
going to insist on every bundle having a payload block, however small.  
[There is a corner case in RFC 5050 where the fragment MTU means that 
you could fit all of the remainder of the payload into a fragment but 
not some or all of the trailing extension blocks.  Then you have to hold 
back the last octet of the payload so that you have a non-empty payload 
to put into the last fragment along with the trailing extension blocks.  
There is of course a horrible deadly embrace where you can't send the 
trailing extension blocks at all because they need two fragments but I 
think we can brush that one under the carpet.] It might be wise to have 
an extension block flag that says it is a hop-by-hop block rather than 
relying on position in the chain.
>
> 13.9. SDNVs
>
>     Should the SDNV discussion in 4.1 be deleted?
Yes.  Refer to RFC 4256 - and if necessary revise 4256 (but I don't 
think that would be necessary).
>
> 13.10. Bundle Processing Control Flags
>    
>     Should the bit numbering convention described in section 4.2 be
>     moved to another location in the document?
Yes.  Separate out before all format definitions. See the discussion of 
agreeing bit field widths at the end of s2 of RFC 4256.
>
> 13.11. Extended class of service features
>
>     Should these features (critical bundle, best-efforts forwarding
>     requested, reliable forwarding requested) be omitted from the
>     primary block?  If they are omitted, should these application-
>     selected CoS markings be supported in some other way?  If the
>     "critical" CoS feature is retained, should it have a different
>     name?
>
>     Note: a node selection (route computation) procedure might consider
>     the availability of CLAs that match the bundle's CoS when selecting
>     a node to forward to, and that is entirely the business of the route
>     computation procedure.  (Not all route computation procedures will
>     do so.)
This information has to be available 'hop-by-hop' to the routing 
scheme.  If it isn't in the primary block then it needs to be in an 
extension block that would be in every fragment and that seems to be 
potentially a waste of bits.  Note that this does not alter my view that 
the addition of lots of CoS info is unnecessary and, for many 
applications, useless.  For example 'Reliable' is a very tricky concept 
in the context of a DTN.
>
> 13.12. Primary block CRC type
>
>     What are the best CRC options to support here?  CRC-16-ARINC, CRC-
>     16-CCITT, CRC-16-CDMA2000, CRC-16-DECT, etc.? Are there more than 4?
I am not an expert but I do agree that there has to be a CRC that is 
useful with very long payloads.
>
> 13.13. Inventory
>
>     Is a list of the block types of all blocks in the bundle as
>     forwarded by the source node a good implementation of the requested
>     "inventory" feature?  If not, what would be better?
Replace the block number field in block headers with a 'next block type' 
field and scrap the inventory.
The problem is knowing if the inventory has changed and the inventory 
list doesn't necessarily help.
This problem needs to be solved in conjunction with the security 
protocol which should be able to tell you if the block list has been 
altered.  I am not sure what happens if you want to add blocks (the ICN 
implementation wanted to add metadata blocks.)
>
>
> 13.14. Block numbers
>
>     Should the payload always have block number zero?
Use the chain scheme mentioned above - block number is then irrelevant.
>
> 13.15. Clearing flag
>
>     Should an node that is able to process a given extension block be
>     permitted to clear block's "Block was forwarded without being
>     processed" flag?
Or put in a 'but it was processed later on the path' flag?  Do we have 
use cases where the 'unprocessed' info plays a role?, If there are 
extension blocks that wouldn't have either bit 2 or bit 4 set, then do 
later nodes care if the block wasn't processed?  It might just be info 
for the destination and opaque to intermediate nodes.
>
> 13.16. Overriding BP spec
>
>     Is a supplementary DTN protocol specification allowed to override or
>     supersede the BP specification (other than making some BP procedures
>     moot by requiring that the processing of a bundle be terminated
>     under fault conditions recognized by that protocol)?
You can't constrain the future.  Extensions are either compatible with 
the current version or there has to be a new version of the base 
protocol.  "Be liberal in what you accept" - make sure you don't try to 
make unreasonable restrictions that might screw up your successors.
>
> 13.17. Time of forwarding
>
>     Should the BPA control the time at which a bundle is to be forwarded
>     to another node, or should that determination be left to the
>     selected convergence-layer protocol adapter(s)?
None of the above (especially not the CL).  Deciding whether a bundle 
should be forwarded at a particular opportunity is a routing scheme 
decision IMO.  The BPA trying to second guess this outside the context 
of the routing scheme will lead to unpleasant mix ups.
>
> 13.18. Block multiplicity
>
>     Would it be good to restrict BP extensions to one extension block
>     per extension per bundle?  That is, should we require that all
>     information needed to implement a given BP extension for a given
>     bundle be contained in a single extension block?
>
>     This would entail encapsulating any necessary multiplicity for a
>     given extension (for example, multiple Metadata records) within a
>     single block.
Why apply an arbitrary limit?  This seems entirely gratuitous.  Not sure 
where the security extensions are going but some them were using head 
and tail blocks which could not meet this restriction.
>
>     Among the advantages: no need for block numbers (block type would
>     always be sufficient to identify the block), therefore no need for a
>     block number generation mechanism; shorter and simpler inventory;
>     simpler extension implementation (all information is in one block,
>     no need to search through extension blocks for additional relevant
>     information).
Use the chain suggestion.  And design your extensions better.
>
>     Among the disadvantages: very different from RFC 5050; would in some
>     cases require that security blocks operate on data structures that
>     are internal to extension blocks rather than always operate on
>     entire extension blocks.
Scraping the barrel!