Serial Experiments Online

By: 
Juan J. Ramos-Munoz, Lidia Yamamoto, and Christian Tschudin
Appears in: 
CCR April 2008

Current network protocols must comply with rigid interfaces and rules of behavior to fit into well defined, vertical proto- col stacks. It is difficult for network designers to offer a wide spectrum of alternative protocols suitable for diverse situa- tions, and to make the stack evolve to match new needs. The tendency is to design protocols that can adapt to the widest possible spread of use. However, even the best adaptive pro- tocols cannot possibly cope with all situations. When their adaptivity limits are reached, the ability to switch to other protocols becomes a clear advantage.

Our aim in this paper is to present Lightweight Au- tonomous resIlient Networks (LAIN), a framework that ex- ploits the multiplicity of alternative protocol, and exposes the spectrum of choice to the advantage of the applications. The system runs continuous experiments with alternative protocols online, in parallel as well as serially, in order to select automatically those that best match the application’s needs under the current network conditions. We report first results on the feasibility of the approach and point out the need for such a system in network and protocol evolution.

Public Review By: 
Jon Crowcroft

This paper is about adaptation (one is reminded of the exhortations of the character Bobby Shaftoe in Cryptonomicon to “show some adaptation”). Specialized protocols can be devised that are more fit-for-purpose than generalised ones. Atanu Ghosh (now at Berkeley working on XORP) once said that his thesis was really about why TCP isn't much use for anything, for very much these reasons. That work was about devising families of micro-protocols that would be efficient in a narrow operating regime (perhaps application specific, perhaps tuned to a given single network environment). The work was part of an ambitious early 1990s endeavour part of which was a project called HIPPARCH (run by the now-editor of this publication), whose goals included the automatic generation and configuration of such microprotocol systems.
What this paper does is to take a more specific, somewhat more tractable set of problems, and solve them in a number of situations, and it is the selection of these situations that the paper makes its main contribution. Largely assuming that one can devise many protocols that are better in particular circumstances, then, the trick is deciding, online, when the circumstances suit the protocol. To this end, the authors propose running automated experiments on the live network, and comparing the results by switching, serially, between the different protocols, with the goal of finding (for some optimisation goal) which is best. They evaluate two examples to make their point in a reasonably general fashion, namely transport protocols tuned for file transfer, where the goal is minimal transfer time, and interleaving protocols for real-time audio, where the goal is highest audio quality (from a subjective MOS test).
The paper concludes with a discussion of generalising the ideas to automated protocol evaluation and evolution, ad of software architectures for the switching functionality. For this reader, the wealth of work ongoing today on alternative protocols (especially in the transport area, but also in higher levels) means that some framework like this is essential, although a great deal more work needs to be done to understand how this works in the large, as well as in each end system.
I would also propose that some sort of protocol robot Ethics be devises. In some sense, the idea already exists in the Internet community in the form of TCP-friendliness. However this is a narrow goal, and as the network diversifies, and operator goals also become more complex, it may be that we need an interface that is not just solipsistic (end system measurements only allow certain protocol optimization goals to be supported – such as selfish maximisation of throughput, or implicit cooperation). Perhaps more complex APIs to the network (and measurement) would allow other goals (collective capacity of a P2P swarm, for example) to be expressed and automated. Something to fold in to GENI.