Skip to main content

The Berkeley Systems Model

One thing we have discussed a bit in my graduate seminar this term is the tension between complexity and simplicity in system designs. As a simple illustrative example, consider B-MAC versus Z-MAC, two MAC protocols for WSNs with very different underlying design philosophies. B-MAC (the B stands for "Berkeley") is a simple, almost minimalist approach to MAC design: a couple of simple primitives (low power listening and ACKs) with a lean API permitting a layer on top to tune the LPL check interval and to turn ACKs on and off. That's it. The paper argues that with this basic set of mechsnisms you can build a wide range of policies on top, including more sophisticated protocols using RTS/CTS or TDMA. Of course, that is largely left to the reader.

Z-MAC, on the other hand, takes quite the opposite approach. It is a hybrid between CSMA and TDMA, includes mechanisms for two-hop neighbor discovery, slot assignment, time synchronization, and adaptivity to low- and high-contention modes using an epidemic ECN protocol. None of these mechanisms are exposed or tunable by the layers above; none of them can be disabled in different situations. Z-MAC is like a rich, sumptuous meal at a two-Michelin-star restaurant (I'll reserve the three stars for later work); whereas B-MAC is like the menu at In-n-Out: "Hamburger. Cheeseburger. Double Double."

Personally, I tend to recoil at designs that pack in so much complexity, especially for something so fundamental as a MAC protocol. (If for no better reason than code footprint -- with Z-MAC, how much memory is left over for the application, anyway?) This leads me to what I like to call the Berkeley Systems Model: a certain approach to doing systems research that strives for elegance and austerity above all. I'm sure it's not unique to Berkeley -- perhaps I should just call it the Harvard Systems Model -- but it seems to be best characterized by work such as Patterson's RISC and RAID, and Culler's Active Messages (by which I mean the original work, not the TinyOS manifestation of the same idea). Compare Active Messages to its main competitor at the time -- distributed shared memory -- and you'll understand immediately what the B.S.M. is all about. The B.S.M. is found in many other places (not all of which are populated with Berkeley alums); and arguably one could claim it actually originated at MIT or UCLA, but let's not split hairs.

Having thought a fair bit about this, I think there are two factors at work in shaping the B.S.M. mindset. The first, frankly, is simply a distaste (or perhaps a fear?) of complexity, irresepective of the merits of whatever system embodies it. Culler is well known for pushing back on work that has too many knobs, bells, or whistles -- he engrains in his students a deep appreciation for minimalism. If you compare some of the earliest systems work in sensor nets -- the TinyOS model and its own version of Active Messages with, say, directed diffusion -- it is immediately evident that the whole idea of combining naming, routing, querying, aggregation, and MAC into a single layer is just not written in the Tao of Culler.

But the deeper, and more important (I think) motivation is the desire to obtain clarity in terms of the fundamental underpinnings for a given system design. Much of the B.S.M. is about stripping away the layers, pulling a system apart into its many constituent pieces, reasoning about how they fit together, which ones belong, and which ones don't. To take another Berkeley example, Eric Brewer is fairly adept at this incisive mode of thinking; you can talk to him for 10 minutes about a system he's never heard of and he'll make an observation that forces you to rethink your whole design. So, I think of the B.S.M. as, essentially, about mediating on a system design, focusing on a mantra while opening one's mind to the whole.

All of that said, there are some real merits to the "kitchen sink" approach. The main one being that a heck of a lot of intellectual satisfaction can be derived from reading such a paper. While a paper from the B.S.M. school has a clean, sharp edge and leaves little aftertaste, something like Z-MAC really gives you something to sink your teeth into. There is so much going on in that paper: an intricate object with innumerable facets and hooks to explore. Of course, there are risks on both sides. A B.S.M. paper might feel vacuous, or fluffed-up, if the One Good Idea is just not profound enough. A kitchen sink paper tends to have a lot of territory to defend, especially in the initial reviewing round when PC members are looking for whatever chinks in the armor to shoot the thing down.

Also, it is clear one can take either approach to research and be successful; within a single community or conference there are plenty of examples of both types of work. It would not surprise me to learn that one's school of thought largely shapes how one approaches these papers, on PC meetings for example. This debate does not usually rise to the surface of the discussions we have in PC meetings themselves, but I think it underlies much of the dissonance between scores that some papers receive, touching a nerve in one camp while mollifying another. In co-chairing Sensys 2009 I'll be interested to see how this plays itself out.


  1. Byung-Gon, Sylvia, and Eddie had a nice paper in NSDI 2008 on this topic: "NetComplex: A Complexity Metric for Networked System Designs."


Post a Comment

Popular posts from this blog

Why I'm leaving Harvard

The word is out that I have decided to resign my tenured faculty job at Harvard to remain at Google. Obviously this will be a big change in my career, and one that I have spent a tremendous amount of time mulling over the last few months.

Rather than let rumors spread about the reasons for my move, I think I should be pretty direct in explaining my thinking here.

I should say first of all that I'm not leaving because of any problems with Harvard. On the contrary, I love Harvard, and will miss it a lot. The computer science faculty are absolutely top-notch, and the students are the best a professor could ever hope to work with. It is a fantastic environment, very supportive, and full of great people. They were crazy enough to give me tenure, and I feel no small pang of guilt for leaving now. I joined Harvard because it offered the opportunity to make a big impact on a great department at an important school, and I have no regrets about my decision to go there eight years ago. But m…

Rewriting a large production system in Go

My team at Google is wrapping up an effort to rewrite a large production system (almost) entirely in Go. I say "almost" because one component of the system -- a library for transcoding between image formats -- works perfectly well in C++, so we decided to leave it as-is. But the rest of the system is 100% Go, not just wrappers to existing modules in C++ or another language. It's been a fun experience and I thought I'd share some lessons learned.

Why rewrite?

The first question we must answer is why we considered a rewrite in the first place. When we started this project, we adopted an existing C++ based system, which had been developed over the course of a couple of years by two of our sister teams at Google. It's a good system and does its job remarkably well. However, it has been used in several different projects with vastly different goals, leading to a nontrivial accretion of cruft. Over time, it became apparent that for us to continue to innovate rapidly wo…

Running a software team at Google

I'm often asked what my job is like at Google since I left academia. I guess going from tenured professor to software engineer sounds like a big step down. Job titles aside, I'm much happier and more productive in my new role than I was in the 8 years at Harvard, though there are actually a lot of similarities between being a professor and running a software team.

I lead a team at Google's Seattle office which is responsible for a range of projects in the mobile web performance area (for more background on my team's work see my earlier blog post on the topic). One of our projects is the recently-announced data compression proxy support in Chrome Mobile. We also work on the PageSpeed suite of technologies, specifically focusing on mobile web optimization, as well as a bunch of other cool stuff that I can't talk about just yet.

My official job title is just "software engineer," which is the most common (and coveted) role at Google. (I say "coveted&quo…