Transcript SPINDLE / DTN - University of Colorado Boulder

Krishnan
Mobility and Interoperability
Achieving Critical Mass in Open DTN Technology
Rajesh Krishnan
[email protected]
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
© 2007 BBN Technologies
Krishnan
Agenda
• 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. :)
September 27, 2007
NSF FIND-Mobility: Mobility and Interoperability Panel Discussion
© 2007 BBN Technologies
2
Krishnan
DTN: What is Fundamentally New?
Question/Proposition
•
DTN can be viewed variously as:
•
What if any is really new and fundamental about DTN?
– 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 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?
September 27, 2007
NSF FIND-Mobility: Mobility and Interoperability Panel Discussion
© 2007 BBN Technologies
3
Krishnan
DTN: What is Fundamentally New?
Discussion (1/3)
•
Demmer: [disconnections are expected, storage enables dealing with those]
–
•
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]
–
•
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.
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]
–
September 27, 2007
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 :)
NSF FIND-Mobility: Mobility and Interoperability Panel Discussion
© 2007 BBN Technologies
4
Krishnan
DTN: 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]
–
–
–
–
September 27, 2007
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 power=bandwidth/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.
NSF FIND-Mobility: Mobility and Interoperability Panel Discussion
© 2007 BBN Technologies
5
Krishnan
DTN: What is Fundamentally New?
Discussion (3/3)
•
Dai: [change the TCP paradigm, proactive relays, reduce delay]
–
–
–
September 27, 2007
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.
NSF FIND-Mobility: Mobility and Interoperability Panel Discussion
© 2007 BBN Technologies
6
Krishnan
DTN/BP as a Unifying Framework
Question/Proposition
• 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 R&D
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?
September 27, 2007
NSF FIND-Mobility: Mobility and Interoperability Panel Discussion
© 2007 BBN Technologies
7
Krishnan
DTN/BP as a Unifying Framework
Discussion
•
Demmer, Fall: [Sure, BP has got nice features by design]
•
Demmer: [Could improve some BP features]
•
Brown: [Some improvement to BP possible, micro-sensors need special treatment, need
modular Click-like implementation, network coding may pose issues]
–
–
–
•
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.
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.
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]
–
September 27, 2007
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.
NSF FIND-Mobility: Mobility and Interoperability Panel Discussion
© 2007 BBN Technologies
8
Krishnan
Achieving Critical Mass for DTN/BP
Question/Proposition
• 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?
September 27, 2007
NSF FIND-Mobility: Mobility and Interoperability Panel Discussion
© 2007 BBN Technologies
9
Krishnan
Achieving Critical Mass for DTN/BP
Discussion
•
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]
September 27, 2007
NSF FIND-Mobility: Mobility and Interoperability Panel Discussion
© 2007 BBN Technologies
10
Krishnan
New Agenda for Mobile Networking
Question/Proposition
• 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 publishsubscribe) as a key research agenda? What else?
September 27, 2007
NSF FIND-Mobility: Mobility and Interoperability Panel Discussion
© 2007 BBN Technologies
11
Krishnan
New Agenda for Mobile Networking
Discussion
•
Brown: [Network support for intelligent localized content distribution]
•
Demmer, Fall: [Content-based DTN]
•
Dai: [Application design to be delay tolerant]
–
–
–
September 27, 2007
Network support for BitTorrent-like protocols for intelligent, localized content
distribution. However, BitTorrent only worked when people started having highbandwidth 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.
Again perhaps we're biased, but we definitely agree that disruption-tolerant access to
content is a key research agenda.
I think the problem is that many of the key MANET application drivers are not delaytolerant (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.
NSF FIND-Mobility: Mobility and Interoperability Panel Discussion
© 2007 BBN Technologies
12
Krishnan
Other Questions
Question/Proposition
• Are there other questions related to mobility and interoperability
that we should discuss today?
September 27, 2007
NSF FIND-Mobility: Mobility and Interoperability Panel Discussion
© 2007 BBN Technologies
13
Krishnan
Other Questions
Discussion
•
Demmer: [Application Interface]
•
Fall: [Security and Net Management]
•
Brown: [Standard simulators, GENI-DTN integration]
–
–
–
–
September 27, 2007
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.]
Is there anything new/different in areas of security and management that DTN/BP or
something similar would affect?
Should we standardize network simulators?
How should GENI integrate DTN testing needs?
NSF FIND-Mobility: Mobility and Interoperability Panel Discussion
© 2007 BBN Technologies
14