Layer 9

Today I received a nice (hand-written!) letter from a sophomore at the University of Delaware, where I recently gave an invited talk on our Princeton/Cornell Frenetic project on programming lanaguges for software-defined networks.  The student asked me some specific questions, and I thought the questions and answers might be interest.


Q: Since your bachelor's degree is in electrical engineering, what made you want to pursue graduate work in computer science?

A: My bachelor's degree in electrical engineering was heavily focused on computer engineering, so the transition to computer science wasn't all that big of a jump.  That said, while I enjoyed the "applied math" aspects of EE, I found I didn't have much physical intuition for analog circuits, signal processing, and the like.  What I really liked about computer engineering was that the "bottom layer" of what I was learning was as basic as Boolean logic -- the AND, OR, and NOT gates.  The prospect of being able to understand how computers work from that level up was quite tantalizing.  In graduate school, I was in a PhD program (at U. Michigan) that combined EE and CS into one department.  My thesis work (on hardware support for communication in parallel machines) also straddled the boundary between EE and CS.  Over time, I've gradually drifted toward more CS-oriented topics -- I should say that general trend is true for many computer engineers, as increasingly many of the interesting research problems in (for example) computer architecture lie at the boundaries with software (e.g., compilers, operating systems, and so on).


Q: You mentioned that you spent several years at AT&T.  How do your experiences there compare  to academia?  What are your favorite aspects of each?

A: I thoroughly enjoyed my 8.5 years at AT&T.  I had four internships at AT&T -- two during college and two during graduate school -- that whet my appetite for conducting research on real problems with access to real data.  While at AT&T, I had an "unfair advantage" of access to the people designing and running AT&T's part of the Internet, as well as measurement data from the network and an opportunity to "tech transfer" my ideas into making AT&T's network better.  Plus, as a researcher there, I could focus the bulk of my time on research, and working closely with my peers.  The thing I miss most about AT&T is the close collaboration with my peers, and serving as a bridge between practitioners in the company and more theoretically-inclined researchers in my lab.  That said, being a professor is a blast.  Teaching is even more rewarding than I expected, and not just because I feel like I am "making a difference," but also because I get to think hard about the right way to organize the material in my field and recognize the gaps in our ability to justify why things work the way they do.  Designing a technology like the Internet is a distinctly human endeavor, so it is not surprising that some parts of the design are better justified than others.  When I cannot motivate a design choice to the students in my class, I realize where we need to improve our understanding, and perhaps even change the design.  Plus, working with graduate students over a period of years -- and seeing them grow and develop so much during their time in graduate school -- is very rewarding.


Q: What sparked your interest in the Internet and network management?

A: My interest in the Internet was sparked by my summer internships at AT&T, and the arrival of the World Wide Web on the scene during the middle of my time in graduate school.  In some ways, I felt my PhD thesis research on parallel computing was a bit disconnected from real users and real data, but the Internet was rapidly moving from a research curiosity to a critical part of the world's communication's infrastructure.  How cool is that!  In networking textbooks, I read that the early designers of the Internet made the inside of the network simple, by placing most of the key functionality at the end hosts.  This belied the considerable complexity of managing the network that I saw over and over again at AT&T.  Interacting with network operators at AT&T exposed me to more about how the Internet actually works, and how hard it is to make IP networks efficient, reliable, secure, and cost-effective.  I sometimes "shadowed" the network operations team at AT&T, so I could learn what kinds of challenges they face, and better understand the limitations of existing tools (including the tools I was creating for them!).  That inspired me to create better tools and techniques, and ultimately to focus more of my research on how to design computer networks that are easier to manage in the first place!  That, in turn, spawned my interest in software-defined networking as a way to put networking (and network management, in particular) on a stronger foundation, while still keeping my "eye on the prize" of improving the practice of networking.


Q: When you started your research on BGP modeling, did you anticipate that the work would have impact?

A: At the time I started working on interdomain routing, several other researchers had uncovered important operational problems with BGP -- that the global Internet routing system could be unstable, for instance!  Yet, the research community had relatively little visibility into how BGP is configured in practice. That points to a general challenge is studying the Internet: while the Internet is man made, and we know a lot about the specific protocols underlying the system, we don't know as much about how these protocols are actually used and configured.  And that ends up mattering, a lot.  The modeling work on BGP focused on how network operators configure the protocol to achieve the economic goals of their companies, and also on helping them predict how changes to their networks (whether link failures or new routing policies) would affect the flow of traffic.  Here, as in much of my research at AT&T, I benefitted a great deal from working closely with network operators (to learn how they configure the network, and what "pain points" they have) and real data (to learn how the network is configured, and how the network behaves).  Creating theoretical results (in the form of analytical models, proofs, and algorithms) that faithfully connect with real operational practice is challenging, but I find that kind of research very rewarding.


Q: The subject of networks can be intimidating.  Where would you suggest young students being to study in order to build a solid foundation?

A: Diving in to networking is indeed intimidating at first.  Fortunately, much of the "background" in networking is something you can pick up as you go along, such as knowing how different protocols and mechanisms operate. (For more thoughts on how "details oriented" the networking field is, see "The networking philosopher's problem".)  In that sense, networking has a much gentler "learning curve" than some research areas like physics or mathematics.  Plus, often researchers have deep knowledge in only one aspect of networking, or conduct broader research through collaboration with colleagues who are experts in other areas.  For example, the Frenetic project I presented in my talk is a collaboration among several faculty, postdoctoral researchers, and students with a mix of backgrounds in networking, distributed systems, and programming languages.  Nobody on the team (myself included) has expertise in all of these areas. If you are interested in networking, my suggestion is to focus on one specific area or application, and learn that topic more deeply.  Another way to learn networking is to collect and analyze measurement data -- that's a fun way to learn how the network really works, and there are always some surprises lying in wait!  And, of course, taking a networking course!