acm sigcomm

ACM SIGCOMM Student Mentoring Column
Aditya Akella, UW—Madison
 
BIN Problems
 
 
As some of you may know, I gave a talk at CoNEXT 2014 titled “On future-proofing networks” (see [1] for slides). While most of the talk was focused on my past research projects, I spent a bit of time talking about the kind of problems I like to work on. I got several interesting questions about the latter, both during the talk and in the weeks following the talk.
 
Given this, I thought I would devote this column (and perhaps parts of future columns) to putting my ideas on problem selection into words. I suspect what I write below will generate more questions than answers in your mind. Don’t hold your questions back, though! Write to me at guru@sigcomm.org!
 
BIN problems
 
I like to work on BIN problems, which are research problems that are: Big in scope; Important in terms of their potential for intellectual or practical impact; and, Nebulous in terms of how to approach them. It is hard to precisely define BIN problems, but here are examples of BIN problems that I worked on that may give you a sense of what I’m talking about: How to design an evolvable Internet architecture? How to model and mitigate network complexity? And, how to exercise software-defined control over network functions?
 
Why am I attracted to BIN problems?
 
Pick one of the examples above, say, control over network functions (NFs). The scope is Big—different networks use different subsets of NFs, and there are many different kinds of NFs out there. The problem appears Important—the industry is starting to think about this. From a research standpoint, there appear to be few studies that offer systematic answers. Thus, the potential for impact on both practice and research exists.
 
The Big-ness of scope and the Nebulous-ness of approach mean, naturally, that the “field is wide open”, i.e., there is no immediately obvious answer here. There are many places to start approaching this problem, and many potential ideas/issues to consider. For example, do we simply control routing to NFs? Does it make sense to control internal state? How about dynamic context? NF logic? Algorithms? How to deal with NF diversity?
 
I hope this example gives you a sense as to why I think BIN problems are so cool: they keep your mind constantly jogging. And, if you succeed, the pay-off can be huge. In what follows, I will try to address two questions that may arise regarding such problems.
 
Are BIN problems risky?
 
Some of you may wonder if this is too much to take up. Where do you start? Which thread(s) do you explore first? What if your exploration fails? It may also be the case that the BIN problem you picked doesn’t seem “hot” (this isn’t exactly true for network functions—there’s a lot of buzz surrounding them these days—but this concern may arise more naturally for other topics such as network complexity, or the Internet’s evolvability).
 
I would argue that the situation is quite the contrary. First, note that once you’ve picked a reasonable starting point (control over internal NF state in the example above), you’ve rooted a version of the problem, and this immediately makes things less vague. From this point on, it is like any other research problem in terms of the likelihood of finding something tangible. But the Importance aspect means that whatever you find has a big likelihood of having impact. The impact could be intellectual in nature—your work could spur others to build similar, perhaps better, systems but your system will be the first. Or, you may hit the nail on its head right away, in which case you could directly impact practice.
 
As you explore, things may turn out to be not what you started out hoping for. But the thing about BIN problems is that there’s enough room for refinement: e.g., maybe you started out by casting too wide a net around NFs, and your initial experience taught you that focusing on, say, distributed control across multiple copies of an NF is still Big and Important, and now it’s also less Nebulous.
 
Finally, BIN problems naturally lead to bodies of work. The many threads to explore at each starting point, and the different potential starting points themselves, often map on to distinct but related research projects/problems. In-depth exploration of one particular starting point and associated threads often gives you enough context to explore in a more focused fashion other starting points and associated threads.
 
How to work on BIN problems?
 
Crucially, as a student, how do you know something is Important? Also, you may not be able to judge if the scope is Big enough, or perhaps it too Big. And related to this is the question of whether your problem statement is clear enough for you to start coming up with meaningful solutions.
 
You don’t have to fight these battles alone. Working on BIN problems is not something you could or would want to do sitting behind locked doors.
 
To clarify scope and to pin down a problem statement, I strongly encourage you to talk to your advisor about your idea (in case you haven’t noticed, advisors love to hear bold and fresh ideas from you more than having you simply “do what you are told”). Talk to others in your research group, including both professors and students. Then, talk to others in the broader networking area, perhaps when you bump into them at conferences; also, consider inviting yourself to go give a talk some place and chat 1-on-1 with people there about your BIN idea (your advisor could be of help in setting up such a rendezvous). In particular, talking to practitioners is quite valuable here, and this set includes your local campus network operators, researchers at industry research labs, engineers at major online service providers, etc.
 
The initial reaction you get may make you feel like you are wasting your time. I have in the past had people tell me I was “crazy” to work on something, or that what I was working on was “not relevant”. But this is actually constructive feedback in the sense that what may be happening is that your pitch for the problem needs refinement. Go back to your notepad, and come up with a better framing of your problem! And then repeat the process above.
 
Approaching BIN problems doesn’t necessarily have to be top-down, i.e., you don’t have to start with a BIN problem. Often, you may find yourself working on a concrete and interesting problem. Perhaps you have a couple of papers on that already. It is a good idea to stop there and ask, “Is the scope of what I am working on bigger than what I’ve looked at in my 1-2 papers so far?” And, you should be open to the fact that broadening the scope may require a different approach (one that is necessarily nebulous at the beginning) than what you’re currently exploring.
 
Working on BIN problems can take time. In particular, getting the right initial intuition nailed down could take a year, perhaps more. All the things I mentioned above—talking to people, gathering feedback, going back to the notepad—can appear to drag things out, too. But once you have the right intuition, and given the experience you’ve gathered along the way, you’re going to be unstoppable!
 
References
 
[1] “On future-proofing networks”, http://www.cs.wisc.edu/~akella/talks/conext-keynote-web.pptx