Title: SPINDLE / DTN
1Mobility and InteroperabilityAchieving Critical
Mass in Open DTN Technology
Rajesh Krishnan krash_at_bbn.com with inputs from
Michael Demmer, Kevin Fall, Lillian Dai, Tim
Brown, and Abraham Matta
NSF FIND-Mobility Workshop at BBN, Cambridge,
MA September 27, 2007
2Agenda
- DTN what is fundamentally new about it
- DTN/BP as a unifying protocol framework
- Achieving critical mass for DTN/BP
- New agenda for mobile networking
- Other issues
- Note Thanks to everyone who provided inputs. I
request participation from all present. Thanks to
the scribe our goal should be to keep him busy.
)
3DTN What is Fundamentally New?Question/Propositi
on
- DTN can be viewed variously as
- algorithms and protocols to deal with
special-case disrupted networks in which a
contemporaneous end-to-end path is not available - extending the scope of existing networking
algorithms to include disrupted networks as well
as stable networks adapting across heterogeneity
in loads, delays, technologies, topologies, and
traffic - bringing storage/content squarely into the set of
resources managed by the network (including at
Layer 3), whereas traditionally managing storage
and content has been an application layer concern - a confluence of networking and databases (e.g.,
declarative networking) - a confluence of networking and logistics (e.g.,
scheduled data mules) - challenging the end-to-end principles, or if you
prefer causing a reapplication of those
principles under changing resource tradeoffs - something else, ...
- What if any is really new and fundamental about
DTN? - What can DTN do that cannot be done just as
easily or well in the application layer over the
Internet? - Is DTN just the new fad?
4DTN What is Fundamentally New?Discussion (1/3)
- Demmer disconnections are expected, storage
enables dealing with those - Mostly a combination of b and c. It's an
approach to bring link disruption into the
expected from the exceptional. In other words,
alink going up and down does not represent a
network failure, but a characteristic. Storage is
a necessary tool to handle these. - Fall heterogeneity and flexible naming
- DTN is also targeted to handle highly
heterogeneous networks and their protocol
architectures (to tie them together). This
relates to the way flexible naming is conceived.
Maybe this is (g), as I don't really see it being
brought out in the question. - Demmer, Fall more than just multiplier, BP
works over a wide range of nets - Obviously we're biased, but we don't think the
value of DTN/BP is just the multiplier effect. We
spent a lot of time designing for a wide range of
networks with input from several different
sources and the architecture/protocol reflects
this input. - Matta Reinventing email?, DTN is for niche
Internet stubs - I think DTNs/sensor nets/MANETs will remain as
(small) islands within the bigger Internet.
Regarding DTN, it's not new -- email has been a
DTN application )
5DTN What is Fundamentally New?Discussion (2/3)
- Brown support both well/ill connected, storage
is central to DTN, logistics is a special case,
DTN routers determine network functionality while
apps do not have that kind of control - This (b) is a must. It seems that many DTNs will
be well-connected a lot of the time so good
behavior when the network is well-connected is
important. Users will want networks that
transparently move between both well-connected
and disrupted domains, and behave well in both.
It will also enable network designers to
specifically provision for different link types
intermittent, scheduled, opportunistic. - This (c) seems to be a primary aspect of the DTN
architecture. In E2E connected networks, storage
is not the concern of routers they can just drop
packets according to their own storage policies
and resources, with only marginal performance
impact (since at maximum powerbandwidth/delay,
no storage is used anyways). In DTN, this isn't
possible maximum power requires optimal storage
allocation. - This (e) seems like a special case of (a). (a)
is an important first step in DTNs but would be a
limited result if that was all we could
accomplish. Eventually, we should be able to
provision for different types of mobility,
random, deterministic (scheduled), controlled.
Mobility would be come a first-class resource
within networks. - Yes. In DTN, the routers (custodians) determine
the functionality of the network whereas an app
on top of the internet approach can only achieve
what the connectedness of the Internet allows,
assuming that app support isn't possible on
routers. The eventually transportable networks
are not amenable to apps on top of the internet.
6DTN What is Fundamentally New?Discussion (3/3)
- Dai change the TCP paradigm, proactive relays,
reduce delay - Changing the TCP paradigm Mechanism to
differentiate between network congestion and
network disruptions. - Opportunity to incorporate additional
communication infrastructures If there are
relays/data mules available, the trajectories of
these relays can be controlled to reduce/mitigate
delay. Under the DARPA Proactive Mobile Wireless
Network program, we are looking at algorithms to
proactively insert relay nodes and control their
trajectories to improve probability of network
connectivity. DTN protocols can be used
synergistically to reduce delay during rare
disconnection events. - Reduce delay at the expense of using more
communication and storage resources If I have a
message to send, I can either wait for end-to-end
connectivity (storing information at source) or
send now and hope that at least one of the
intermediate nodes can forward information to
destination before I can.
7DTN/BP as a Unifying FrameworkQuestion/Propositio
n
- Current mobile network, system, or application
solutions are insular and do not interoperate.
Due to a lack of common abstractions and
implementations, it is often not possible to do
fair comparisons of alternative solutions or to
easily build upon each others' work to create a
multiplier effect. - Why not use the Bundle Protocol (BP) as the focal
point for RD in mobile and nomadic computing, ad
hoc networking, and content-oriented networking? - What are the limitations if any of the BP and its
implementations in terms of supporting your
research vision? - Are there good alternatives that could serve this
role? - What might be an alternative MANET
interoperability layer?
8DTN/BP as a Unifying FrameworkDiscussion
- Demmer, Fall Sure, BP has got nice features by
design - Perhaps not surprisingly, we find that the BP has
several attractive characteristics for general
use message-oriented payloads, flexible naming,
extensible protocol features, and a reasonably
efficient encoding (i.e. SDNVs Dictionary).
There's no reason per se why it wouldn't be a
good glue for mobile and disruption-tolerant
networking. - Demmer Could improve some BP features
- For some more self-consistency and protocol
elegance when used in non-disrupted environments,
I'd say that some of the DTN-specific features
that are currently encoded in the primary bundle
block could be moved into extension blocks, such
as the alternate reply-to EID, the current
custodian EID, perhaps the status report
requesting flags, etc. - Brown Some improvement to BP possible,
micro-sensors need special treatment, need
modular Click-like implementation, network coding
may pose issues - Everyone has their niche the BP (like all
protocols) trades overhead (14 SDNVs in the
header) for functionality. This is somewhat
bloated and for a given research task (like our
work in sensor data collection) it may be faster
to implement a limited protocol. However, our
experience is that as the BP has evolved and our
needs have evolved our protocols have been moving
closer to BP. At this stage, I think any
parallel development of an alternative BP would
only be marginally better (i.e. I don't see any
killer features missing or poison pills present
in the current implementation). Sensor nets
might hack up the BP to fit into small packets,
with mediators augmenting these bundles to the
fully-fledged BP but this is a small niche. An
approach, would be to specify the protocol in a
more modular implementation (e.g. the Click
Router) where components could be included or not
included cleanly. Things like network coding
might mean that nodes in a DTN receive increasing
amounts of partial information without ever
receiving a cleanly-delimited bundle. It's not
clear what kinds of applications would use this
network coding, yet. - Matta DTN is weird, not yet convinced it is an
elixir - it seems strange to rely on randomly moving
vehicles, randomly thrown-from-airplane sensors,
or randomly .. etc. to do anything serious ) I
don't know the details of BP, but I can't imagine
it solves all of our internetworking problems.
9Achieving Critical Mass for DTN/BPQuestion/Propos
ition
- One way for DTN/BP to be adopted widely and gain
a critical mass is to create a successful
application (similar to NCSA Mosaic which caused
HTTP to become popular). Another way is to vector
into as many devices as possible (similar to
Bluetooth and IrDA technologies). A third way is
to use it as a glue protocol between disparate
mobile networks. - What is the killer application for DTN, and if
there is none, how can we achieve critical mass?
10Achieving Critical Mass for DTN/BPDiscussion
- Demmer No killer app, DTN will transform but
become invisible - There shouldn't ever be a DTN-specific killer app
-- it should be that the existing killer apps on
the internet can be made disruption tolerant with
appropriate shifts in API and protocols. - Fall Generalized sync
- Generalized 'sync' is the killer app.
Synchronization of databases, caches, backups,
etc... - Brown VANETs, disaster comm, maybe social
networking - ... vehicle nets, M2M computing, disaster
communication. - ... social networking (but SMS, mobile data, etc.
are already delivered opportunistically over
cellular networks. So what's new with DTN?) - Krishnan Disruption-tolerant caching search
pub-sub
11New Agenda for Mobile NetworkingQuestion/Proposit
ion
- Provocative Research in MANETs have so far been
largely irrelevant as far as commercial
applications go. MANETs do not scale, do not
take advantage of infrastructure whenavailable,
and despite the proliferation of wireless
devices, there is no hope of interoperability
yet. MANETs have an inferiority complex and want
to stay at the edge of the Internet. - Should we set a new agenda for mobile networking
research? - What about rapidly formed high-speed mobile
wireless transit ASes that can fix Internet
partitions arising from say, multiple concurrent
Katrina-scale disasters? - Should the focus be on vendor-neutral
interoperability all the way from applications to
the physical layer? - What about disruption-tolerant access to content
(distributed content-flow management including
caching, search, and publish-subscribe) as a key
research agenda? What else?
12New Agenda for Mobile NetworkingDiscussion
- Brown Network support for intelligent localized
content distribution - Network support for BitTorrent-like protocols for
intelligent, localized content distribution.
However, BitTorrent only worked when people
started having high-bandwidth free-per-bit
internet connections. Prior to that, there was
no way I was going to pay to store-and-forward
your bits. I think MANETs suffer from that
problem right now, if I want to join your MANET,
I have to pay for your bits (either by wasting
power routing them, or by letting you use my
EVDO/GPRS backbone). The power problem might get
incrementally better the backbone problem will
probably get much better. It seems that more
work on MANET routing won't really help either.
We're faced with as much a social problem as
anything even on the Internet, how often does
one let a friend have storage/services/processing
power? People are still happy to rely on big
service providers (YouTube, Blogspot, Facebook),
rather than providing their own services. - Demmer, Fall Content-based DTN
- Again perhaps we're biased, but we definitely
agree that disruption-tolerant access to content
is a key research agenda. - Dai Application design to be delay tolerant
- I think the problem is that many of the key MANET
application drivers are not delay-tolerant (ie.
search and rescue, battlefield communication). Is
there a way we can serve these delay-sensitive
applications without grossly over-deploy or
over-design the network? Should this be one of
the areas of active research? The issue probably
lies in the network architecture, and cannot be
adequately resolved no matter how much we improve
routing, resource allocation, etc.
13Other QuestionsQuestion/Proposition
- Are there other questions related to mobility and
interoperability that we should discuss today?
14Other QuestionsDiscussion
- Demmer Application Interface
- How does DTN affect the programming abstractions
that networking stacks provide to the application
developer? For example, it seems clear that
basing a networked program around an end-to-end
pipe abstraction (i.e. a TCP socket) is
inappropriate for frequently disrupted
environments, but then what is the appropriate
general alternative. Disclaimer I'm currently
working on research work to address this exact
question. - Fall Security and Net Management
- Is there anything new/different in areas of
security and management that DTN/BP or something
similar would affect? - Brown Standard simulators, GENI-DTN
integration - Should we standardize network simulators?
- How should GENI integrate DTN testing needs?