Krishnan © 2007 BBN Technologies Mobility and Interoperability Achieving Critical Mass in Open DTN...

Krishnan

© 2007 BBN Technologies

Mobility and InteroperabilityAchieving Critical Mass in Open DTN Technology

Rajesh [email protected]

with inputs from

Michael Demmer, Kevin Fall, Lillian Dai, Tim Brown, and Abraham Matta

NSF FIND-Mobility Workshop at BBN, Cambridge, MASeptember 27, 2007

September 27, 2007 NSF FIND-Mobility: Mobility and Interoperability Panel Discussion 2

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. :)


Krishnan


DTN: What is Fundamentally New?

Question/Proposition• 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?


Krishnan



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 :)


Krishnan



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 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.


Krishnan



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.


Krishnan


DTN/BP as a Unifying FrameworkQuestion/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?


Krishnan


DTN/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.


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?


Krishnan


Achieving 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]


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 publish-subscribe) as a key research agenda? What else?


Krishnan


New Agenda for Mobile Networking

Discussion• 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.


Krishnan


Other QuestionsQuestion/Proposition

• Are there other questions related to mobility and interoperability that we should discuss today?


Krishnan


Other 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?

Krishnan © 2007 BBN Technologies Mobility and Interoperability Achieving Critical Mass in Open DTN...

Documents

Transcript of Krishnan © 2007 BBN Technologies Mobility and Interoperability Achieving Critical Mass in Open DTN...