Skip to main content

Posts

Showing posts from February, 2009

The plight of the poor application paper

My research is unapologetically applications-driven: we've deployed sensor networks for monitoring volcanoes, disaster response, and for measuring limb movements in patients with Parkinson's Disease. One of the joys of working on sensor networks is that a lot of exciting research derives from close collaborations with domain experts, shedding light on challenges that we wouldn't otherwise be exposed to. It also keeps us in check and ensures we're working on real problems, rather than artificial ones.

At the same time, it's a sad truth that "deployment" or "application" papers often face an uphill battle when it comes to getting published in major conferences. I've seen plenty of (good!) application-focused papers get dinged in program committees for, well, simply not being novel enough. Now, we could have a healthy argument about the inherent novelty of building a real system, getting it to work, deploying it in a challenging field setting, a…

Requiem for the Compact Disc

It's the end of an era. Today I packed up my entire CD collection (around 1,000 CDs) and stuffed it away in the basement, never to see the light of day again. I had them all on this glorious solid oak rack -- now for sale on Craigslist! -- that I needed to move due to some remodeling work that we're doing in the house. It's too cumbersome to move that many CDs and then put them back again, so I decided, today was the day -- no more CDs. So here is my euology for my Compact Disc collection. It has served me exceptionally well over the years, and I think it deserves a proper sendoff before being relegated, forever, to the dankness of my basement and the phantom dipoles of my hard drive.

I'm an avid music collector -- apart from the physical CDs, I probably have another couple of hundred albums worth of music in digital format alone. Although I have not bought CDs for more than a year (moving completely over to the Amazon MP3 store, and occasionally iTunes), there was alwa…

How I almost killed Facebook

It is a little-known fact that I nearly killed Facebook before it started.

At least, that's what I like to think. Though, perhaps it was inevitable that Facebook would have happened despite my attempted interference. I should make it clear that I'm a huge fan of Facebook and am, well, kind of addicted to it. But imagine how different the world might have been...

You see, back in 2004, Mark Zuckerberg was a student in my Operating Systems course (the much-feared and oft-maligned CS161, widely known as one of the more challenging courses at Harvard). Zuck was one of those students who pretty much nailed the course material without my having to teach it to him; this trait often goes hand-in-hand with having plenty of, shall we say, extracurricular interests and as a result he was not coming to lectures very regularly. At one point I called him to my office to find out where he had been, since class participation (by which I roughly mean, coming to lecture and not falling asleep) is…

Blogging a research project?

This term I am teaching a graduate seminar on wireless sensor networks. Actually, "teaching" is not quite the right word, as I see my role as mainly that of moderating a discussion between the students in the course, and raising the occasional controversial point as grist for the mill. Normally, in these kinds of courses, the content of the discussion is lost to the ether, so this term I decided to run a blog where the students post a summary of our conversation about the assigned papers. Students are encouraged to put their own editorial slant on the content of the blog posting, and the blogger for each class is responsible for leading the discussion.

So far it's been a lot of fun and provides some permanence to those revelations and insights that, otherwise, would be terribly ephemeral. It also gives the students a chance to write up their ideas a bit more formally, with a broader audience than, say, simply emailing them to me.

This has got me thinking about the potentia…

Time management for junior faculty

At SEAS this term we've been holding a professional development seminar for graduate students, basically an informal series of lunchtime talks in which faculty talk about issues like doing a job search, giving a talk, academic writing, and so forth. It's a great idea and touches on a lot of issues that I wish had been brought up in a more formal setting when I was a graduate student. Last week, Vinny Manoharan and I gave a presentation on time management, and this got me thinking about effective techniques for managing one's time, many of which I only learned as a new faculty member.

Of course, I continually struggle with managing my time, especially with distractions like e-mail and reading Digg while trying to get "real work" done. But in the last few years I've developed a few tricks that I find pretty helpful in terms of structuring my day.

The first is to protect my "deep thinking" time, namely, the mornings, when I get my best thinking (and writ…

Your suggestions for SenSys 2009

This year, Jie Liu and I are program co-chairs for ACM SenSys 2009, the 7th year of this highly successful conference on sensor networks. David Culler is the general chair and is doing a great job making the conference actually happen (by comparison, the job that Jie and I have is pretty easy).

SenSys was started, in part, to provide a venue for true systems papers on sensor nets, as opposed to the large body of theoretical and simulation-based work in the area. Prior to SenSys, there was no single good venue to publish these papers: they did not quite belong in traditional networking or mobile communications conferences; nor did they represent a substantial fraction of the programs at the mainstays of the systems community (such as SOSP and OSDI). I think SenSys has done a great job at carving itself out as the premier conference for sensor networks systems research, and it continues to be an extremely vibrant and competitive venue.

Now that SenSys has been around for a while, Jie and…

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…

On the serendipity of failure

My post on the relative difficulty of sensor nets research versus "traditional" systems research made an allusion to a comment that David Culler once made about the handicap associated with field work. David notes that in a field deployment, unlike a simulation or a lab experiment, if you get data you don't like, you can't just throw it away and run the experiment again, hoping for a better result. All systems researchers tend to tweak and tune their systems until they get the graphs they expect to get; it's one of the luxuries of running experiments in a controlled setting. With sensor network field deployments, however, there are no "do overs". You get whatever the network gives you, and if the network is broken or producing bogus data, that's what you have to go with when it's time to write it up. One of the most remarkable examples I have seen of this is the Berkeley paper on "A Macroscope in the Redwoods." In that case, the data …

All pain, all gain

Jon Howell from MSR came to visit yesterday and we got into an interesting discussion about the risk versus reward tradeoff for different approaches to research. Two of my Ph.D. students (Bor-rong Chen and Konrad Lorincz) are graduating this year -- you should hire them, of course -- but they are facing a weak job market and the need to rack up publications is as important as ever. The question is, had we worked on problems in the more traditional systems space, would we have been more successful cranking out the papers?

It has long been my belief that doing research in wireless sensor networks -- especially the applied and experimental variety, where you actually have to build something that works -- involves a (nontrivial) degree of difficulty that is not present in "traditional" systems research. Think of it: Programming motes requires that everything fit into 10KB of RAM. You don't get malloc, threads, or printf. All you get are three LEDs to tell you what's going…