Tuesday, November 18, 2008

An Architecture for Internet Data Transfer (DOT)

This paper looks at the benefits that could arise from turning data transfer on the Internet into a separate service, abstracting away transfer details from the application. This is part of a whole movement in Internet architecture towards a higher-level communication API, the point of which is to allow more innovation below the API than the current datagram and stream-oriented transport protocols allow. The DOT paper focuses solely on large bulk data transfers, in which case having a specialized transfer service provides the following advantages:
  • Simplifying application programming required to use complex transfer mechanisms.
  • Providing flexibility so as to support new transfer mechanisms in the future.
  • Taking advantage of caching and multipath to improve performance.
  • Providing disconnection tolerance and mobility tolerance.
Tests with a prototype show mainly that the DOT layer does not add significant overhead and that some interesting transfer mechanisms, such as multipath and USB key based, can be implemented on it. The implementation is mostly a "sanity check" rather than enabling some fantastic new applicaton.

My main criticism of the paper is that although the DOT design provides flexibility, there is not enough motivation for it to be practical. Very few applications seem to require the kind of flexibility that DOT provides, as most transfers are fast enough to happen over a single TCP connection or large enough that the user can manually choose whether to use BitTorrent or physical media. The examples provided in the evaluation are pretty contrived for this very reason - e.g. while the Internet Suspend/Resume project could clearly work over either a connection or an USB key, it's hard to imagine it ever needing to support some other tranfer mechanism, and an application developer could easily implement just these two. I believe that for an architecture paper like this to really be influential, it needs to provide not just a cleaner solution for one particular problem but an architecture that enables some fundamentally new and powerful applications. DOT focuses on too narrow a problem. If it were augmented with maybe some interesting naming system, some way to handle mobility, etc, it would be far more interesting. I had the same criticism for DOA.

Finally, I'd like to point out a thing which always bothered me about some Internet architecture papers, which is that their work could easily be implemented in a library. For something like DOT, which is more or less end-to-end, there probably are libraries today which will provide you an easy to use get/put API for HTTP, BitTorrent, SCP, etc. With such libraries available, do we really need a new service in the OS? Internet architecture work should focus on pieces that require innovation in how we think about networking vs requiring changes to how we componentize our software.

No comments: