The DTNRG: Where are we?

1. The DTNRG: Where are we? R. Durst – The MITRE Corporation K. Fall – DTNRG Chair, Intel Research, Berkeley M. Demmer – University of California, Berkeley/Intel K. Scott – The MITRE Corporation S. Burleigh – NASA/Jet Propulsion Laboratory 9 March 2005 Excerpted from: DARPA Disruption Tolerant Networking Kickoff Meeting

2. DTN challenges… • Intermittent/Scheduled/Opportunistic Links • Scheduled transfers can save power and help congestion; scheduling common for esoteric links • Interrupted Links • RF noise, light or acoustic interference, LPI/LPD concerns • Frequent disconnection among mobile nodes due to terrain/fading • Very Large Delays • Natural prop delay could be seconds to minutes • If disconnected, may be (effectively) much longer • Different Network Architectures • Many specialized networks won’t/can’t ever run IP

3. Delay-Tolerant Networking Architecture • Goals • Support interoperability across ‘radically heterogeneous’ networks • Acceptable performance in high loss/delay/error/disconnected environments • Decent performance for low loss/delay/errors • Components • Flexible naming scheme with late binding • Message overlay abstraction and API • Routing and link/contact scheduling w/CoS • Per-(overlay)-hop reliability and authentication

4. Background • IETF/IRTF DTNRG formed end of 2002 • See http://www.dtnrg.org • DTN1 Agent Source code released 3/2003 • DTN2 Agent Source code released 12/2004 and 3/2005 • SIGCOMM Papers: 2003 [arch], 2004 [routing] • Several other documents (currently ID’s): • DTNRG Architecture document • Bundle specification • Application of DTN in the IPN

5. Perspective

6. Perspective: Where do we think we are with all of this? • Scope: • The Architecture Document and associated protocols • Considerations: • Things we’re pretty sure about • Things we think are good ideas • Things we believe need refinement • Things that are totally open

7. Things that we’re pretty sure about in the Architecture Document • Message-oriented abstraction • But messages can be short (100 bits) • Some pressure to support streaming • Store and forward operation with Custodial transfers (advancing the point of retransmission toward the destination) • Network of internets • Postal-like COS: Relative priorities and basic notifications • Synchronized time (to some degree) and time-based message purge • Fragmentation (proactive and reactive) • Two-part endpoint identifiers (region, admin; admins opaque outside region; eventual reachability within a region) • Taxonomy of contacts

8. Things we think are good ideas • Architecture Document: • Security focus on infrastructure protection • Persistent, asynchronous application registration • In-network persistent storage traded for end-to-end retransmission • Maintenance of routing state across network partitioning

9. Things that probably need refinement • Architecture document • Use of bundle expiration time as (sole) mechanism for routing loop recovery • Must be reconciled with intentional replication for robustness • Recent discussion of a bundle node in the network adding an optional header analogous to a VIA field to identify loops, etc. May need more than one of these fields • Is this better than a replay cache? • Using multipath routing & forwarding to improve reliability/ decrease latency • How to removeduplicates once we decide they’re no longer needed? • Endpoint identifiers: What is the relation between administrative identifiers across regions? Is there constancy that can be assumed? In what circumstances? • Congestion and flow control (utility of economic models?) • Ability to use forward erasure coding in conjunction with multipath routing / forwarding • How and when to trust assertions of security made by lower layers

10. Things that are totally open • Architecture document • Network startup and bootstrapping • Resource discovery (e.g. multicast session information, • Authentication mechanisms: PKI, IBC, other? • What are regions? Do they have topological significance? Are they simply namespace identifiers? • What routing architectures are preferable? Flat? Single level hierarchy? Multi-level? Overlapping? • Do nodes move among regions? What are the dynamics of inter-region mobility? Is an additional, topology-independent identifier space necessary? • What benefits accrue from late binding when regions do not have topological significance? • Policy issues

11. The Protocols

12. Things that we’re pretty sure about in the Bundle Protocol spec • Service Primitives (§2.5) • E.g., send, register, start/stop delivery, poll, change/end registration • Header Chaining Structure (§3.1) • Administrative Payloads (§5) • Application data where the bundle node is the application, and the data units support the operation of the bundle protocol itself • Bundle status payloads, Custody ACKs, etc. • Split of responsibilities between bundle & convergence layers (§6)

13. Things that we’re pretty sure about in the LTP protocol spec • LTP spec: • Most of the concepts inherited from CFDP: • Transaction/session model versus stream model) • Use of non-volatile storage for both state and data • Absence of negotiation • Laconic acknowledgement • Adjacency (point-to-point as opposed to end-to-end • Lives under a network and above a [functional] link) • Deferred transmission. • Protocol features that are intended to fix problems in CFDP: • Reducing the number of different protocol data unit types • Replacing the periodic retransmission of NAKs with reciprocal acknowledgements • Protocol extension mechanism

14. Things we think are good ideas • Bundle Protocol Spec: • Dictionary to improve header overhead (§3.8) • Pointers in primary bundle header currently assume two-part naming • Supporting indirect transfers • Alternatives include DHTs, FTP-passive-mode-like rendezvous • LTP Spec: • Partial reliability • Timeout interval computation • Accelerated retransmission

15. Things that probably need refinement • Bundle protocol spec • API required to implement security architecture • Protocol support for multipoint delivery

16. Things that are totally open • Bundle Protocol Spec: • Interaction between user desires and policy • API for notification / negotiation • Protocol support for streaming apps?