Six years since first DTN papers : Is there a clear target ?

Given the huge application diversity, reliabilityand delay-wise, and the node-resource heterogeneity present in DTNs, we argue that a solution framework has to be established to embrace and coordinate research efforts in a focused manner. We contend that proactive service differentiation has to be introduced into the design of data dissemination algorithms for DTNs. Otherwise, the applications’/users’ needs for delay-tolerant networking will be obscured by system constraints. This solution framework should tame the requirements of diverse applications into a welldefined, service-driven taxonomy that will make DTNs a success story. We provide a first step towards that direction. I. WHY SERVICE DIFFERENTIATION AND WHY PROACTIVE The main question that a DTN-routing algorithm has to answer is: ”How many copies of a message should be distributed into the network? ”. The answer may range from ”one” to ”as many as the present nodes are”. In this paper, we argue that this question has to be answered taking into account the desired service outcome, which is not the same in all cases. In particular, we consider there exist two ultimate goals a DTN forwarding algorithm would attempt to achieve: (i) (High) Delivery Ratio, DR, (ii) (Low) Delivery Delay, DD. We call these two goals the Service Targets of a DTN system. Given that DTNs consist mainly of mobile, battery-powered devices, they will be constrained with regard to: (i) Energy Consumption, E and (ii) Storage Space, S. We refer to these constraints as System Constraints. We also refer to the Queuing Time, QT , as the amount of time that a message needs to be stored before it is discarded (either because of an ACK or of a TTL timer). Finally, the Task Completion Time, TCT , is the total time from the message generation at the source till the message is successfully delivered and all ”infected” nodes are ”cured” and hence, storage space becomes available again. Although Delivery Delay may sound contradicting as a Service Target for delay-tolerant networks, we note that delaytolerant may be an application that can tolerate one minute of delay, but delay-tolerant may also be an application that has to tolerate one week of delay. In that sense, some sort of service differentiation seems to be essential. Since the DTN ”killer app” is yet to be found [1], we pick some well-known, but still DTN-applicable applications in order to illustrate the difference. Email requires 100% DR, but is not strict in terms of DD. In contrast, ”web-on-themove”, or non-critical telemetry data becomes useless if not delivered within (relatively) strict deadlines. Applying similar policies to the above applications may drain the system’s energy in case of e-mail flooding, or saturate the system’s storage in case of reliable telemetry delivery, for instance. We argue that holistic, ”one-fits-all” approaches to DTN routing, which appear to be the norm until now, will lead to deadlocks, similar to the ones that the research community faces presently in the conventional Internet (e.g., mice vs elephants). In contrast, proactive, service-target driven designs have the potential to provide, inherently, supply according to demand, instead of reactive patches that would regulate demand according to supply. Based on Observations from the related literature (Section II), we derive a number of Consensus and Conjecture statements regarding the design of forwarding algorithms for DTNs (Section III). Our Conjecture statements lead us to a design position, which we present in Section IV. We roughly illustrate the validity of the proposed design position with a simple reference scenario in Section V. II. OBSERVATIONS FROM THE RELATED LITERATURE OBSERVATION 1. Multiple copies increase the delivery ratio. If a carrier node fails (e.g., battery exhaustion), there will exist alternative carriers to deliver the message. OBSERVATION 2. Multiple copies decrease delivery delay. The more the copies in the network, the more the possibilities to find the fastest possible path. OBSERVATION 3. Multiple copies increase energy consumption. Transmission/reception functions are the most energy consuming operations. OBSERVATION 4. Multiple copies increase storage requirements. A node has to buffer messages it has accepted custody of. Clearly, the above observations provide only a vague framework for the design of efficient DTN protocols. We contend that OBSERVATIONS 1 and 2 cannot hold at the same time if the system is energy and storage constrained (OBSERVATIONS 3 and 4). We argue that node-resource and application heterogeneity has to be taken into account, before the protocol design phase. On that direction, only recently a few studies have investigated routing issues taking into account node-resource heterogeneity (e.g., [2]). Again, however, algorithms in [2] are not designed on a Service Target Driven basis. III. CONSENSUS AND CONJECTURES Based on the Observations discussed before, we attempt to derive a number of Consensus and Conjecture statements, which apply to the whole spectrum of potential DTN deployments. In all cases, we assume that nodes (i) have no Knowledge regarding the emergence of the network graph, (ii) serve several concurrent applications and (iii) are energy and storage constrained. CONSENSUS 1.1. High DR requires high QT . CONSENSUS 1.2. High QT results (temporarily) in low S. CONSENSUS 1.3. Low S may increase TCT . CONJECTURE 1. High DR increases DD. CONSENSUS 2.1. Low TCT requires high E. CONSENSUS 2.2. High E results in (permanent) low S. CONSENSUS 2.3. Low S can lead to reduced DR. CONJECTURE 2. Low DD results in low DR. NOTE: Although consensus statements 1.3 and 2.3 seem to be contradicting, they are indeed both true. In case of 1.3, temporary storage contention may increase TCT, while in case of 2.3, permanent reduction of available network capacity (due to nodes running out of battery) will decrease reliability. Hence, a DTN node needs to make the right decision on whether to accept or reject a message based on specific policies. We argue that these policies have to be defined on the basis of the desired Service Target.