Promoting Tolerance for Delay Tolerant Network Research
Jon Crowcroft, Eiko Yoneki, Pan Hui
Univers i t y of Cambr i dge
England
firstname.lastname@cl.cam.ac.uk
Tristan Henderson
Univers i t y of St Andrew s
Sc ot land
tristan@cs.st-andrews.ac.uk
This ar ticle is an editor ial note s ubmitted t o CCR. It has NOT been peer
reviewed. Aut hors t ake f ull responsibilit y for t his ar t i cle’s t echnical
c ont ent . C omment s c an be pos t ed t hrough CCR O nline.
ABSTRACT
So what is all this DTN research about anyway? Sceptics
ask: “Why are there no DTN applications?”, or “Why is
DTN performance so miserable?” This article attempts to
address some of these complaints. We present suggestions of
expectations for applications, and metrics for performance,
which suggest a more tolerant view of research in the area.
Categories and Subject Descriptors
C[.]: 2.1 [Packet-switching networks],[Network Communi-
cation]
General Terms
General Terms: Algorithms, Performance, Design
1. INTRODUCTION
The Internet architecture has enabled new applications,
such as e-mail, the World Wide Web and Voice over IP,
which have transformed the way in which we access and cre-
ate information. This architecture, however, makes strong
assumptions about connectivity, such as available end-to-
end paths and low round-trip times, and high availability
to naming, caching and search infrastructures to provide
locator-based access such as DNS. This means that it is dif-
ficult to use e-mail or VoIP in a so-called challenged envi-
ronment with unstable or high-delay connectivity, such as
the dark side of the moon. This has led to the emergence of
Delay Tolerant Networks (DTN) [7] as a different communi-
cation paradigm; one which is decentralized and distributed
over a multitude of devices that are dynamically networked,
carried by people, and embedded in everyday-life. For in-
stance, the Haggle Project
1
features a “Pocket-Switched”
variant of DTN where people carry devices in their pock-
ets, which communicate directly with other devices within
their range or with infrastructure. As people move around,
they can exchange messages with nearby devices, carrying a
message until it is close to another device. Thus, our DTN-
device-carrying astronaut might have their e-mail messages
1
http://www.haggleproject.org/
ferried by other DTN users taking their commercial flights
to and from the moon.
The last few years have seen an explosion in DTN research,
with several papers in the main SIGCOMM conference, and
more specific venues such as the CHANTS workshop
2
which
is now in its fourth year. At the same time, however, there
remains some scepticism about the need for a new DTN-
like architecture. This article is designed to address some of
this scepticism. First, we briefly outline a history of DTN
research. We then list some of the usual sceptics’ questions.
Subsequently, we discuss the future of DTN Architectures
and Applications, and what we consider to be the design
space for appropriate Metrics for success.
2. A BRIEF HISTORY OF DTN RESEARCH
DTN research started with Vint Cerf and the Interplane-
tary Internet initiative [5], which proposed a new architec-
ture that could work over both terrestrial and interplanetary
links. This architecture could enable applications such as the
remote operation of scientific experiments on other planets,
controlled using TCP/IP from Earth.
The Interplanetary Internet ideas were generalised by the
IRTF DTN Research Group
3
, which focusses on any kind of
challenged environment where end-to-end connectivity may
not always be available, and the DARPA Disruption Tol-
erant Networking programme
4
, which concentrates on de-
veloping protocols for bundling application-layer data units
into DTN-layer protocol bundles for transport by DTN nodes.
Opportunistic networks [21] and message ferrying [25] con-
centrate on mobile ad hoc DTNs as in the previously-discussed
Haggle example, where routes are built dynamically between
source and destination, and any possible intermediate node
can be used opportunistically to ferry data as required. At
the same time, applied EE/CS researchers, dissatisfied with
the inefficacy of MANETs that they were trying to build
in the real world, have started to do more and more ex-
perimental work, mapping out the world in terms of real
radio propagation experiences, and actual mobility traces
2
http://chants.cs.ucsb.edu/
3
http://www.dtnrg.org/
4
http://www.darpa.mil/sto/strategic/dtn.html
ACM SIGCOMM Computer Communication Review 63 Volume 38, Number 5, October 2008

of genuine users (pedestrian, vehicular, zebras, badgers, al-
batrosses and so on). An important aspect of DTN route-
building is therefore an understanding of mobility patterns,
and as such recent DTN research has studied social net-
works, both in humans [6, 19, 4] and other species [16].
These two strands of research can be seen to have converged
in attempts to build realistic models for high-variance den-
sity MANETs.
As well as being interesting from a systems and experi-
mental point of view, research problems in DTNs, rather like
MANETs before them, are also academically fascinating. A
large class of models from the world of network science and
complex systems can be extended covering the graph theo-
retic properties, and using physical analogs for the propaga-
tion of information through their dynamic topologies (per-
colation, diffusion, statistical thermodynamic/entropic mod-
els, and many more). In some senses, there is a body of work
which stands on its own. In other senses, the reality gap be-
tween these theoretical models and the real results can be
seen in the differences between predicted and measured per-
formance of test applications. We are not trying to write a
“defence of the dark arts of DTNs” syllabus here. Instead,
we concentrate on questioning the realism of DTN research.
3. SCEPTICS’ FAQS
Here are some of the accusations that we have recently
heard levelled against DTN research. Please feel free to add
your own attack (or defence) on CCR Online.
1. Sceptic: The world just keeps getting more connected.
Yes, we may have frequent dropped phone calls over
2G/3G networks, and 3G and WiFi coverage are not
completely ubiquitous yet, but the same can be said of
wireline Internet access in the first ten years.
Short answer: However well-connected the world gets,
there will still be outages. Moreover, there will still
be variation in capacity - it is unrealistic to assume
universally consistent coverage. An architecture that
seamlessly deals with disconnections, disruption and
delay will simply work better than one that doesn’t.
It may have more capacity (at the expense of larger
expected mean and variance of delay), and this may
be tolerable or even transparent to some applications.
2. Sceptic: You don’t have any compelling applications.
Short answer: There was an 11 year gap between the
deployment of TCP/IP in 1981 and the very first WWW
browser/server in 1992, which we now know to be
the Internet’s “killer app”. Expecting the widespread
emergence of new applications during the initial stages
of a network research programme seems a little unfair.
In any case, there may well be several compelling ap-
plications, which we outline below.
3. Sceptic: Do people living without electricity really need
cell phones or $100 laptops? Aren’t there more impor-
tant things on which to spend time, money and effort?
Short answer: Evidently! Indeed growth in cell phone
ownership, despite poor coverage, is faster in these ar-
eas than elsewhere now [22]. DTN systems such as
Kiosknet [10] and similar systems such as the OLPC
data carousels may prove compelling applications for
these areas.
4. Sceptic: OK so sensor networks might usefully be ar-
chitected as DTNs, but aren’t sensors a special case?
Short answer: Sensors, and other send-and-forget ap-
plications are already being integrated on larger de-
vices, such as the Nokia sports mobile phones. Why
build two separate network architectures? Why not
just have one architecture that copes in all ranges of
the operating spectrum/regimes.
5. Sceptic: Provisioning for DTNs makes the APIs harder!
Short answer: Designing DTN applications motivates
us to solve the problem of applications being written to
survive frequent disconnects. This is already occurring
in many web service applications — for instance web-
mail providers such as Google incorporate application-
layer mechanisms to recover from dropped links. If we
can build an architecture that enables such applica-
tions to work in DTN environments, then won’t they
work even better in the “unchallenged” infrastructure
environments?
6. Sceptic: Many challenged environments involve disas-
ter recovery. Shouldn’t we pre-plan for disasters any-
how?
Short answer: The reality is that disasters create un-
predictable failures (see New Orleans for instance), so
you need a network that can cope in unforeseen cir-
cumstances, and moreover allows people to adapt to
these circumstances as well.
7. Sceptic: Why do you believe that your small-scale ex-
periments have anything to do with what you will get
in future large-scale deployments?
Short answer: We believe that there is no reason to say
that the scaling we see in the Haggle experiments and
related measurements with such low delivery success,
low rate and long delay, will not scale up in the multi-
hop wifi and denser populations — indeed, measure-
ments of cell phone networks [8] and transportation
usage [17] appear to confirm this.
8. Sceptic: Why don’t DTN theory and practice link up
better?
Short answer: You might ask the same of the wireline
Internet. “Joining up the dots” between experiments
and theory takes a long long time, as evinced by the
telephone networks.
These are some short and somewhat glib responses. No
doubt all we have done is enourage the sceptics to demand
further details. We provide these by classifying the FAQs
into three broad categories: architectures, applications, and
performance.
4. ARCHITECTURES
So the question here is: do we really need a brand-new
architecture, and if so, how many new architectures do we
need? We describe the generic DTN architecture and a spe-
cific instantiation of this with which we are familiar: Haggle.
ACM SIGCOMM Computer Communication Review 64 Volume 38, Number 5, October 2008