July 2012: Editor Message

By: 
S. Keshav
Appears in: 
CCR July 2012

Networking researchers seem to fall into two nearly non-overlapping categories: those whose blood runs with the practical clarity of “rough consensus and running code” (in the words of Dave Clark) and those who worship, instead, at the altar of mathematical analysis. The former build systems that work, even work well, but don’t necessarily know at what level of scaling or load their systems will catastrophically fail. Congestion collapse in the Internet in the mid-1980’s, for example, was a direct result of this approach, and similar scaling failures recur periodically (HTTP 1.0, “push” content distribution, and Shoutcast, to name a few), although many pragmatically-engineered systems, such as DNS, email, and Twitter, have proved to be incredibly scalable and robust.

Proponents of mathematical modeling are better able to quantify the performance of their systems, using the powerful tools arising from theories such as model checking, queueing theory, and control theory. However, purely analytical approaches (remember PetriNets?) have had little practical success due to three inherent limitations. To begin with, it is not clear what mathematical approach is the best fit to a given problem. There are a plethora of approaches -- each of which can take years to master -- and it is nearly impossible to decide, a priori, which one best matches the problem at hand. For example, to optimize a system one can use linear or quadratic optimization, or any number of heuristic approaches, such as hill-climbing, genetic algorithms, and taboo search. Which one to pick? It all depends on the nuances of the problem, the quality of the available tools, and prior experience in using these approaches. That’s pretty daunting for a seasoned researcher, let alone a graduate student. Second, every mathematically sound approach necessarily makes simplifying assumptions. Fitting the square peg of reality into the round hole of mathematical assumptions can lead to impractical, even absurd, designs. As a case in point, assumptions of individual rationality needed by decision and game theory rarely hold in practice. Third, having spent the time to learn about a particular modeling approach, a researcher may be seduced into viewing the approach as being more powerful than it really is, ignoring its faults and modeling assumptions. For these reasons, I believe that one should couple a healthy respect for mathematical modeling with a hearty skepticism of its outcomes.
 
When mathematical modeling and pragmatic system design come together, it can lead to beautiful systems. The original Ethernet, for example, brought together the elegant mathematics of researchers like Kleinrock, Tobagi, Lam, and Abramson with hands-on implementation by Metcalfe. Similarly, Jacobson and Karels brought a deep understanding of control theory to their inspired design of TCP congestion control. More recently, the Google Page Rank algorithm by Page, Brin, Motwani, and Winograd is based on eigenvalue computation in sparse Markov matrices.
 
Given these enormous successes, it is no wonder that researchers in our community try hard to combine mathematical modeling with system building. Most papers in SIGCOMM these days build and study real systems applying analytical techniques arising from areas such as optimization, protocol verification, information theory, and communication theory. Although I must confess that the mathematical details of many papers are beyond my understanding (despite my recent attempt to remedy the situation), I think this is a positive development.
 
Yet, much needs to be done. As a field, we lack widely accepted abstractions for even relatively simple concepts such as names and addresses, let alone routing and middleboxes. These have stymied our ability to build standard models for networking problems or a standard list of Grand Challenges. The recent emphasis on clean-slate design has renewed focus on these problems, and I look forward to the outcomes of these efforts in the years to come.