[dtn-interest] Age Block / DTN2 discussion

[Calvin Ardi <[e-mail]>]

Hi everyone,

I've been prototyping the Age block [1] for DTN2 and hope to push it out
alongside the DTN2.8.0 release (after some code review and initial tests
on my end). Implementing the extension block has allowed me to go
through some of the underlying code and I'd like to bring up a few
points for discussion / comments regarding the Age block and future
iterations of DTN2.

Unless otherwise noted, most of the following refers specifically to
DTN2 implementation, but some can refer to the protocol in general.

  ----

Age Block:

* The current Age block spec [1] calls for microseconds (Sec. 4) as the
  Age field; does anyone actually use or forsee a use for such
  precision? The bundle Creation Timestamp Time and Lifetime (RFC5050,
  Sec 4.5.1) use seconds, and I've currently implemented the Age with
  seconds (saves a few extra bits over the wire and a calculation here
  and there :) Unless there's anyone against it, I'll make the minor
  change on the next draft.

* The mechanism for signaling of the use of the Age block is to set the
  Creation Timestamp Time to 0 (which I believe was to maintain
  compliance with 5050?). It would be more useful to fill in the
  Creation Timestamp Time field with the system time in addition to the
  Age block. If the receiving BPA finds that the difference between the
  Creation Timestamp Time + Lifetime and the current time is greater
  than some value X, it can safely assume that either the sender's clock
  or its own clock is out of sync and use the Age block instead.

  This will require some modification to how bundles are processed. If
  I'm getting this right, when a bundle is received, the Creation
  Timestamp Time and Lifetime is checked and then expiry decisions are
  made immediately after. Since there's the potential for additional
  information / metadata to be placed in ext blocks, the daemon should
  process the ext blocks contained in a bundle in addition to the
  primary block before making decisions on what to do with the bundle
  (this could include forwarding, expiration, storage management, etc).

  There's the potential for these ext blocks becoming very large and
  perhaps unwieldy for processing (especially in low power/embedded
  systems and environments) but at this point, overhead seems minimal.

* Known limitations: many. It's assumed that while your clock may be
  unsynchronized, it's at least capable of keeping track of how much
  time has elapsed (otherwise all bets are off).

  With the way ext blocks are handled, the Age for a new bundle is
  calculated as the time it takes from when a bundle is initialized (or
  when the ext block is consumed) until the ext block generate()
  function is called.
  
  This leaves a few gaps in the Age (some of which has been discussed in
  the draft but included for emphasis). Propagation delay tops the list;
  for now it's not taken into account. For some applications or networks
  this might be trivial, but it poses an interesting challenge as to how
  to calculate this. The consensus (as of 2010 March) was to push this
  burden to the convergence layer, which would require extensive
  modification to each convergence layer and moving more information
  between the daemon and CLs.

  The other gap is the time after generate() is called and before it's
  sent to the convergence layer queue. Thus, the Age does not factor the
  time it takes to process additional extension blocks, nor the time it
  sits on a link queue. Slightly trivial, but could be important if we
  have a busy BPA with, for example, a slow connection and many bundles
  to process.

  ----

DTN2 implementation:

* Run-time configuration: The use of extension blocks provides an easy
  way to implement new features, but at the moment there isn't a way to
  configure which BlockProcessors should be initialized or run. Because
  there might be the possibility that not everyone wants an Age block on
  their bundles (hypothetical of course, who wouldn't want the Age
  block? :) I've added some configuration options in dtn.conf to
  enable/disable certain aspects.

* Modularity: What I'd like to see is a more modular system for
  developing and enabling extension blocks without requiring a
  re-compile of DTN2 each time an ext block is developed/updated. I'm
  not sure if the current system supports it or how much additional work
  it'd require, but something similar to Apache2's module system would
  be awesome for DTN2 (e.g., see a2enmod/a2dismod on a Debian/Ubuntu
  system).  

* Minimal code changes to the DTN2 core: Following from the previous
  point, I've tried to make only the necessary changes to the DTN2 core
  as some of the logic / processing wasn't able to be contained within
  the BlockProcessor class. 

  For example, if we want to zero out the Creation Timestamp Time in
  conjunction with adding the Age block, we have to do that in the
  BundleDaemon as opposed to making that change in the BlockProcessor.

  Additionally, some metadata (Timers and a few other things) need to be
  stored to support the Age block and that's done by adding a few more
  variables to the Bundle class; it'd be nice to eventually have the
  situation where all of it could be contained in the BlockProcessor
  itself instead of addition additional fields and cluttering up the
  DTN2 core.

  ----

DTN:

* Storage management: another issue discussed briefly in the draft is
  what happens when a BPA without a synchronized clock loses power and
  wakes up. One way is to expire all of the bundles in the persistent
  store and then delete them (5050, Sec. 5.5). I think a best-effort
  approach, if time is not of the essence, would work better here:

  If there are enough resources to go around, why not just process and
  send the bundles out to their intended destination? This could
  potentially clutter up the network, but combined with a Class of
  Service bit or ext block, we could label them as low priority and
  create a policy as to how to handle them (e.g., if battery is < X% and
  persistant store < Y%, delete bundles with low priority).

I don't have all the solutions or the manpower to implement all these
ideas, but I'm definitely open to collaborating with anyone to get these
ideas off the ground. Any comments welcome.

Cheers,
Calvin

[1] http://tools.ietf.org/html/draft-irtf-dtnrg-bundle-age-block-01