The second session, chaired by Jeff Chase, consisted of three papers reporting on the early stages of projects with ambitious goals -- hence the session title ``Great Expectations''. The first paper, presented by Aaron Brown, described the goals of a new storage system called ISTORE being built at UC Berkeley. Driven by the belief that maintainability, availability and scalability will dominate raw performance in importance, this project seeks to build a system that is extensible and self-tuning. The scope of the project is very broad, spanning hardware, language support, operating system and application components.
Opening the question session, Margo Seltzer expressed skepticism that a designer could anticipate the full range of storage management policies likely to be needed by diverse user communities. Brown replied that the policies in ISTORE were management policies not performance policies, and that these spanned a narrower range because system administrators typically have good intuition of what they need in this regard. Rick Schlichting then asked two related questions regarding changes to policies: whether the adaptive policies could themselves be adapted, and if so, how they were distributed and deployed in a consistent manner through the system. Brown responded that they were still grappling with these issues, and that language-level support in form of triggers, views and mobile code were likely to prove useful for this purpose. Milan Milenkovic observed that the architecture of the system suggested the possibility of moving functionality, such as file system support, directly on to intelligent disk controllers. Brown replied that this was indeed the intent.
Following up on the response to Margo Seltzer's earlier question, Karin Petersen disagreed that characterizing failures was easier than characterizing performance, particularly in a wide-area distributed system like the Web. In response, Brown said the range of failures was relatively narrow since ISTORE was focused on systems that fit within a single rack rather than those distributed over a wide area network. Armando Fox asked who would watch the watchers; in other words, how could self-adjusting code itself be monitored? Brown's reply was that a small, well-trusted diagnostic core would be responsible, but that this was an area still being conceptualized. The final question, from Hari Balakrishnan, observed that the Internet could be viewed as a highly scalable self-adjusting system, and asked whether any thought had been given to exchanging ideas from that domain. Brown replied that they planned to look at wide-area algorithms in the future, but had not done so yet.
The second paper in this session, entitled ``OS Support for General Purpose Routers'', was presented by Larry Peterson. He described the work as being in the ``incubation state'', with the goal of designing router software that allows easy customization. The work differs from the active networks effort in that it also aims to customize edge routers at the trust and control boundary between one's local network and the rest of the Internet. In contrast, active networks imply customization of all routers in an end-to-end path. Current commercial routers levy such a high performance penalty on any packets which require special handling that customization is not attractive. This work strives to preserve high performance on the fast path while reducing the performance penalty for customization.
David Patterson asked what components of the proposed routers could be obtained off the shelf. Peterson replied that he expected all the components to be available off the shelf in about 3 years. Patterson then asked why a special-purpose router was necessary, and whether a general-purpose workstation would suffice. Peterson's reply was that bus bandwidth and expansion limitations were the primary reason for needing special-purpose hardware. Hari Balakrishnan did a quick back-of-the-envelope calculation to derive an aggregate Internet demand of about 10-20 Gb/s, and asked how this demand was going to be met. Peterson's reply was that local area traffic demand from applications such as high-end graphics was likely to be even higher, at about 200 Gb/s. The only way he saw of meeting this high demand was by careful and well-planned engineering. Dickon Reed requested clarification regarding which routers in the Internet were likely to use the proposed system. In reply, Peterson said that this system was meant only for use in edge routers; interior nodes in the Internet were likely to remain unchanged. Jeff Chase asked how many cycles per packet could be spared for customization. Peterson replied that discovering this quantity through experimentation was one of the goals of the project.
The final paper in the session was presented by Mark Yarvis. This paper describes an architecture for adaptive middleware called ``Conductor'', whose goal is allow easy customization of adaptation strategies without requiring modifications to applications. The idea is analogous to stackable file systems, which allow customization of file system internals while preserving application transparency. A given adaptation typically, but not necessarily, consists of a pair of adaptation modules, such as compression/decompression and encryption/decryption. Conductor allows such adaptations to be composed, with individual adaptation modules distributed into the network at Conductor-enabled nodes.
The first question, by David Kidston, was how Conductor ensured that data streams passed through the proxies representing adaptation modules. Yarvis replied that they used split TCP connections. Kidston then asked if this didn't violate end-to-end TCP semantics. Yarvis replied that Conductor provides an end-to-end reliability model on top, which allows adaptation modules to preserve end-to-end semantics if they choose to. Doug Terry followed with two questions: who performed the planning for adaptation, and whether adaptors could themselves adapt to changing conditions. Yarvis responded that installing an adaptor is currently a heavyweight operation, and therefore it makes sense to build adaptors that have the ability to respond to changes in the environment. Hari Balakrishnan observed that this approach was similar in some ways to application-level framing, and asked whether adaptors could perform retransmissions at the level of segments meaningful to applications. Yarvis replied that this was difficult to do because adaptors are transparent to applications.