Skip to main content

NSDI 2009, Day Three

Today is the last day of NSDI 2009 here in Boston. The conference was great this year, and the community is clearly going strong. My only regret is that, the conference being in Boston, there was no excuse for me to go out cavorting with my colleagues until the wee hours. (Not that this stopped my grad students...)

My favorite talks from today:

Softspeak: Making VoIP Play Well in Existing 802.11 Deployments
Patrick Verkaik, Yuvraj Agarwal, Rajesh Gupta, and Alex C. Snoeren, University of California, San Diego

This paper is about improving the performance of VoIP flows in wireless networks, which can be very negatively impacted by bulk TCP and UDP traffic. I liked how this work looks at something other than bulk throughput as the only performance metric for a wireless network: this paper focuses on the MOS scores for the VoIP calls. The basic idea is to allow the VoIP stations to use a shorter contention window and aggregate downlink traffic across multiple VoIP stations. It's a clever idea and very well evaluated in the paper, although it seems fairly complex and would require substantial changes to the clients and APs to support. I was surprised how many questions were asked after the talk. I raised the question about what happens with multiple TCP bulk flows. Given that a single TCP flow is so badly impacted by VoIP, it seems to me that multiple TCP flows would really hammer the VoIP traffic.

Making Routers Last Longer with ViAggre
Hitesh Ballani, Paul Francis, and Tuan Cao, Cornell University; Jia Wang, AT&T Labs—Research

Cheeky title aside, this paper focuses on the problem of reducing the size of the expensive FIB memory in Internet routers as the routing table sizes increase. The key idea is to partition forwarding responsibility so that each router only maintains routes to a fraction of the IP address space. This can be supported on unmodified routers by using separate "route reflectors" that filter the routing tables on behalf of the routers themselves. Of course, this approach requires encapsulation and tunneling since intermediate routers don't have the complete routing information.

Ironically, the talk just before this (NetReview: Detecting When Interdomain Routing Goes Wrong) dealt with detecting BGP misconfigurations -- the ViAggre approach adds even more complexity and potentially creates a nightmare for someone trying to debug their network (or, at least for Andreas). That said they've thought hard about how to make this deployable in practice.


Comments

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…