Although I'm confused by the term "challenged internets" (is it a politically correct way to say limited-connectivity networks?), I liked the way the way this paper was organized and the reasoning behind the architecture of DTN. The paper starts out with a good introduction of cases where connectivity may be limited or lacking at times, and these are things that people actually care about: military networks, communications through space, sensor deployments, and even "sneakernet" style store-and-forward networks, of which there are some commercial examples in developing regions. The paper also stresses the importance of interoperability in defining an architecture for such challenged networks, which can lead to a design that gets adopted and implemented by multiple manufacturers. The actual DTN system is designed in a very practical manner, with fairly simple design choices that are adequately explained, such as hierarchical names, overlays for implementaton (rather than requiring redesign of the current Internet), priority, custody transfer, end-to-end acks, and even cryptographic "postage stamps". I liked all the analogies to the postal service and to e-mail.
This paper is different from a lot of the papers we read recently because it's much closer to an RFC-like proposal of a new Internet standard than to a "what-if" architecture paper. This is valuable, as it's good to see how real protocols get designed. However, it makes me wonder about the following question: how often does the opportunity arise in research to define a protocol like this versus exploring more far-fetched ideas that push the boundaries of what technology can do? It seems like a lot of research is focused more on pushing the boundaries, leaving this kind of practical standards design work to industry. How do you know as a researcher when to spend time trying to design this kind of standard versus enabling some interesting demos, getting your viewpoint heard in industry, and then moving on?
Tuesday, November 18, 2008
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment