A Delay-Tolerant Network Architecture for Challenged Internets Author: Kevin Fall Paper Presentation: Vinay Goel

Internet Service Model  TCP/IP based  End to end IPC using concatenation of potentially dissimilar link layer technologies  Packet-switched model of service  A number of key assumptions…

Key Assumptions  Assumptions  End to end path exists b/w data source and its peer(s)  Maximum RTT b/w any node pairs is not excessive  End to end packet drop probability is low  A class of challenged networks violate one or more of the assumptions

Examples of challenged networks  Terrestrial Mobile Networks  Unexpectedly partitioned due to node mobility, changes in signal strength etc.  Exotic Media Networks  High latencies with predictable interruption, suffer outage due to environmental conditions etc.  Military Ad-hoc Networks  Hostile environments  Mobility, environmental factors, or intentional jamming may cause disconnection  Data traffic competing for bandwidth

Characteristics of these networks  Path and Link characteristics  High latency, low data rate  Disconnection  Long queuing times  Network Architectures  Interoperability considerations  Security  End system characteristics  Limited longevity  Low duty cycle operation  Limited resources

Adapt Internet to these environments?  Link-repair approaches  Engineer problem links to appear more similar to the types of links for which TCP/IP was designed  “fool” the internet protocols: strive to maintain end-to-end reliability etc.  Attach these networks to the edge of the Internet  Use of a special proxy agent  Provides access to and from challenged networks from the Internet  No support for using such networks for data transit

Link repair approaches  In-network entities (“middle boxes”)  Performance Enhancing Proxies (PEPs) & protocol boosters  Contain state necessary for connection violating the Internet fate sharing principles  Confound end-to-end diagnostics and reliability, increase system complexity if mobility is frequent  Pose a significant challenge for end-to-end security mechanisms

Application Layer proxies  Provide specialized Internet-to-”special network” name mapping & protocol translation  Used at the edge of special networks  Disadvantage: their specificity  Either respond to a specialized set of commands or act as raw data conduits  Limit the ability to re-use proxies for different applications  Fail to take advantage of special resources (storage, processing capabilities etc.)

Electronic Mail  Asynchronous message delivery system  Provides an abstraction that comes close to addressing many problems  Flexible naming, asynchronous message-based operation etc.  Falls short  Lack of dynamic routing  Weakly defined delivery semantics  lack of consistent API

What’s the most desirable framework?  A network service and API providing non-interactive messaging  System should combine some overlay routing capability (such as in P2P systems) with delay-tolerant and disconnection-tolerant properties of e- mail

Delay Tolerant Message Based Overlay Architecture  Based on abstraction of message switching  Message aggregates known as “bundles”  Routers that handle them are called “bundle forwarders” or DTN gateways  Architecture provides a store-and-forward gateway function between various network architectures

Regions and DTN gateways  Two nodes are in the same region if they can communicate without using DTN gateways  DTN gateway  Point through which data must pass in order to gain entry to a region  Can serve as a basis for both translation and well as a point to enforce policy and control

Name Tuples  Identifiers for objects or groups of objects  DTN name tuple {Region Name, Entity Name}  First portion is a globally unique, hierarchically structured region name  Interpreted by DTN gateways to find the path(s) to one or more DTN gateways at the edge of the specified region  Second portion identifies a name resolvable within the specified region  Need not be unique outside the region

Name resolution  Only region identifier is used for routing a message that is in transit across a collection of regions  Entity name information is locally interpreted in the destination region  Form of late binding

A Postal Class of Service  Priority based resource allocation  Adopt a subset of the types of services provided by US Postal Service  Attractive characteristics  Low, ordinary and high priority delivery  Return receipt, delivery records

Path Selection and Scheduling  Architecture targeted at networks where an end-to-end path can’t be assumed to exist  Routes are comprised of a cascade of time- dependent contacts (communication opportunities)  Particular details of path selection and scheduling - heavily influenced by region- specific routing protocols and algorithms

Custody Transfer and Reliability  Custody transfer: acknowledged delivery of a message from one DTN hop to the next and corresponding passing of reliable delivery responsibility.  End hosts do not ordinarily need to keep a copy of data that has been custodially transferred to a DTN next hop  Custody transfer can be viewed as a performance optimization for end-to-end reliability that involves endpoint movement

Convergence Layers and Retransmission  Facilities provided by transport protocols in use within the regions may vary significantly  Bundle forwarding assumes underlying reliable delivery capability with message boundaries when performing custody transfer  Transport protocols lacking these features must be augmented  Include transport-protocol-specific convergence layers

Time Synchronization  Coarse Level  Identifying message fragments  Purging messages that have exceeded their source specified lifetimes  Stringent constraints  Scheduling, path selection  Congestion management

Security  Verifiable access to the carriage of traffic at a particular class of service  Avoid carrying traffic potentially long distances that is later found to be prohibited  Each message includes an immutable “postage stamp” containing  Verifiable identity of sender, an approval, class of service etc.  Credentials checked at each DTN hop by routers; use of public key cryptography

Congestion and Flow Control  Flow control: limiting the sending rate of a DTN node to its next (DTN) hop  Attempt to take advantage of underlying protocols’ mechanisms  Congestion control: handling of contention for the persistent storage of a DTN gateway  Shared priority queue for allocating custody storage

Application Interface  Applications must be careful not to expect timely responses  Must be capable of operating in a region where a request/response RTT may exceed the longevity of the client and server processes  Structured to continue operating in the face of reboots or network partitioning as much as possible

Conclusion  Design embraces notion of message switching with in-network storage & retransmission, late-binding of names & routing tolerant of network partitions  Puts forth several design decisions worthy of consideration

Questions?