Resources For Educators

Networking educators prepare lots of teaching material. Some of them spent countless hours to prepare detailed slides, collect reference papers or prepare labs or exercises. Most of this material is often only used within a single university.

To allow educators to easily share teaching material, SIGCOMM has launched the website. The objective of this website is to allow networking educators to easily and efficiently share links to educational resources. We strongly encourage you to register and contribute to the SIGCOMM education community. 

In addition to this repository, we will regularly post information on the SIGCOMM education blog to discuss about issues that affect networking educators.

SIGCOMM has recently launched an open-source eBookproject! check it out!  Recent Advances in Networking SIGCOMM eBook

To participate actively to the discussion, you can subscribe to the SIGCOMM Education mailing list via :

SIGCOMM Education Blog

  • Posted on 2016-02-05 15:34 by admin

    ACM SIGCOMM Student Mentoring Column
    Aditya Akella, UW—Madison (
    On Program Committees and Social Networking at Conferences
    Dear students: This edition of the Student Mentoring Column focuses on program committees (their composition and how they work) and the importance of social networking at conferences. The questions below don’t provide comprehensive coverage of either topic; as such, we may revisit them in future editions.
    I got plenty of help in preparing this edition. In particlar, many thanks to Kyle Jamieson (Princeton),Ethan Katz-Bassett (USC),George Porter (UCSD),Vyas Sekar (CMU), andMinlan Yu (USC) for contributing answers.
    Program committees and their inner workings:
    Q: How does one get selected to be on program committees (PCs)?
    A: The conference PC chairs select a program committee; some times they do this in consultation with the conference’s “steering committee”. PC chairs try to balance a range of requirements when determining the PC composition, including expertise, junior vs. senior reviewers, industry vs. academia, diversity across geographical regions, etc.
    One way to increase your chances of being on a PC naturally is to be visible at the venues where you would like to contribute to the PC; e.g., writing high quality papers at these and related venues, contributing to the community by asking questions after talks, signing up for volunteer/organizational work, having engaging discussions at conferences, and socializing with the community. Later in this column, we will talk the topic of social networking at conferences in greater detail.
    In addition, you should let your collaborators and others who know you well--especially those who are more visible or serve on PCs you aspire to--if you are looking to serve or are happy to help with reviews. It is likely these people are asked to serve on more PCs than they accept, and PC chairs often appreciate suggestions of people to ask when someone declines serving (and it can feel easier to decline if one has suggestions ready). Also, these people may appreciate your help as an outside/co-reviewer for your expertise on a particular topic, and the PC members are generally told who helps with reviews, helping spread your name.
    Q: How does a program committee select papers to accept? I got high scores but still got rejected.
    A:  First of all, a bit of background on reviewing: as you probably know, most conferences have multiple rounds of reviewing. This helps the PC narrow down the submission pool and focus its reviewing effort on the most competitive submissions. PC chairs typically filter papers in early rounds based on scores and reviews, often based on active input from reviewers; in general, papers with low scores or weak reviews across the board end up getting filtered in early rounds. Other papers get additional reviews in subsequent rounds. Most conferences have two rounds of reviewing; some may have three. Beyond the reviews themselves, most conferences have a discussion period at the end of reviewing. For top conferences, this discussion will have both an online component and a meeting. The discussion may involve weighing a paper’s strengths vs. limitations, clearing up misunderstandings, or hashing out of differences between people who liked the paper and those who did not. A paper’s fate depends on the outcome of this discussion and not directly on the scores in the reviews, and the discussion may change a reviewer’s opinion of a paper in either direction. Often--but not always--reviewers update their reviews if the discussion changes their opinions. For papers that made it to discussion, authors are often provided with a discussion summary. This summary may be the best signal for what determined the paper’s fate. So read the summary carefully!
    Now back to the question. Note that rejections happen routinely to the best researchers among us. A key reason is that most top conferences reject over 80% of their submissions as there is often limited room in the program. 
    Realize that not all venues use the same scoring scale, and even those that use the same scales have very different submission pools.  Importantly, scores are only part of the equation on what papers ultimately get accepted into the program. High scores from one or two reviewers may indicate niche excitement about the paper, but the paper also needs to be calibrated on other fronts and there are really multiple dimensions to this. For example, relative excitement with respect to other papers in play; whether there is someone “championing” the paper or the high scores are just lukewarm; the expertise of the reviewers; how many papers the conference is willing to accept within a reasonable program, etc. 
    Don’t get hung up on the scores. It is often important try to “debug” what happened and understand why the paper was rejected.  Be brutally honest with yourself: are the scores high, or are they a mixed bag, or even just middling?  Crucially, does your approach have an “Achillies’ heel” that a reviewer called out?  Or is there just limited excitement about the problem you’re solving?  In the former case, armor yourself against the objection, considering whether to do this right up front in the introduction, later in the design section, or elsewhere in related work.  Ask your advisor for help armoring yourself against technical limitations or related work if you’re unsure.  In the latter case, think about other applications of your approach and consider proposing them right up front in the introduction. 
    Take the positive feedback as encouragement, take reviewer concerns seriously instead of dismissing them, and try and “push it over the bar” the next time!
    Q: What do you look for in a paper to accept/reject it?
    A: There's broad consensus in our community that choice of problem is a key factor.  That is to say: is the problem that you've chosen to work on timely, pertinent to application to the field, and intellectually deep.  It is important to orient your writing to highlight these aspects.
    After that, we are looking for the quantum of contribution to knowledge that your submission contributes.  The goal of research is to expand our body of knowledge, and so we are judging your paper on how effectively it does just that. 
    Next, we're looking at the technical approach you take: is it sound, and is your experimental methodology sound (i.e. convinces the reader that your claimed solution actually fulfills its claims) and complete (i.e., you evaluate against appropriate alternative techniques, at suitable scale, and using appropriate workloads)?
    Finally, a necessary but not sufficient property of accepted papers is that the writing quality is above a certain bar.  This is necessary because in order to convince reviewers (and the community) that your technical approach is sound, the reader must understand it in its entirety. This isn’t necessarily about grammar. It is more about how you make your case and the paper’s overall flow.
    It often helps to prepare your paper in advance and get external feedback. This can dramatically improve your paper’s readability, and also help you address the other issues highlighted above.
    Social networking at conferences:
    Q: How important is the “social” networking aspect of conferences?
    A: The social aspect of the conference is almost as important as the presentations and publications at the conference! As a student, talking to other researchers is an opportunity to make new connections, get feedback for your own work, and a great chance to sharpen your “elevator pitch” for your own research. You can learn from industry participants about the importance of your problem and the constraints you may face in practice. You can learn about what others are working on and what problems others find interesting/important. This might inspire new problems that you can work on and/or create new collaborations.
    On a pragmatic note, the social aspects can also help you find internships and connect with future potential employers!  It is also a natural way of getting on the “radar” of senior researchers, which might be helpful for other intangible reasons (e.g., TPC invitations, finding letter writers or potential thesis committee members). Finally, it is also great way to get to know strong Ph.D. students from other schools. You will likely meet them again at other conferences in the future, and you may develop strong long-term friendships and/or fruitful research collaborations with them.
    Of course, the social aspect is easiest when you indeed have something concrete to back it up in terms of good research results, or ideas, or even questions; e.g., it helps to be “visible” at these conferences by presenting your own original papers or posters, or asking good/deep questions after talks.
    Q: I have heard a lot about the hallway track at conferences. Should I listen to talks or talk to people instead?
    A: If you’re new to the field and/or a younger student, it would be best to focus on actually listening to the talks and participating in the Q&A right after. This will help you when you prepare your own talk, and will also help you develop a broad knowledge of current state-of-the-art in the field.  Attending sessions could also help you kick off a conversation, by bringing up a paper you particularly liked, for example. But, not all sessions may be well suited for you. Thus, in some situations, especially as you get older and/or you are on the job market, it might make sense to spend some of the time talking with others. This may help you continue conversations that you started during a break and/or provide additional opportunities for social networking.  

  • Posted on 2015-12-04 11:31 by admin

    ACM SIGCOMM Student Mentoring Column
    Aditya Akella, UW—Madison
    Topic: Various Student Questions
    Dear students: I hope you have been enjoying reading the column. This column is similar to the previous one: it attempts to address a few more of your questions. Thanks for the great questions; keep them coming! Again, many thanks to Brighten Godfrey (UIUC) and Vyas Sekar (CMU) for contributing their thoughts.
    On Research Topics in Networking, and Reading Papers
    Q: “What are the top 10 papers any networking student should know about?”
    A: This is a difficult single question to answer, especially as the networking discipline has become very diverse. It really depends a lot on the “flavor” of networking you may be interested in -- systems vs theory, wired vs wireless, applications vs. lower level, etc. No matter the flavor, here are some ways of finding those top papers to read:
    ·One starting point is to look at what some eminent networking researchers have come up with in the past. There are many such example lists, including those compiled by Jim Kurose [1], Jon Crowcroft [2], Mostafa Ammar [3], George Varghese [4], and Jen Rexford (with a focus on networking theory papers) [5].
    ·Another idea is to look at papers that have received major awards. An example is the set of “test of time” award papers at SIGCOMM and NSDI. These are papers that were well ahead of the pack when they were published, but have had significant real world impact over the years. Similarly, it is worth looking at papers that have won IRTF’s Applied Networking Research Prize. These reflect research ideas with significant potential for impact on practice.
    ·A final idea is to look at the Graduate Networking Classes offered and the recommended readings therein, especially on “classical” topics. You are welcome to check out UW-Madison’s graduate networking [6].
    Q: “How can I get more efficient at reading papers?
    A: Keshav’s “How To Read a Paper” [7] presents a great prescriptive “algorithm” for becoming more efficient at reading a paper. I won’t spoil the surprise for you, but the gist is to do three passes in progressively increasing depth of understanding. The depth to which you need to understand the details of the paper depends on the context/reason you are reading it. For instance, if you are reviewing for a conference/journal you really need to do an in-depth read during the third pass. The same applies if you are planning to work in the same general area as the paper, or if the paper is highly relevant to your current work. In both cases, it may also help to take detailed notes and jot down your thoughts/critiques during the in-depth pass. This may seem onerous at the beginning, but over time you will notice that you’re getting very efficient with each pass taking lesser time. On the other hand, if you are doing a quick survey to understand the state-of-art then you may do only the first/second passes. Generally speaking, the only way to become more efficient at something is practice. So read as many papers as you possibly can.
    A Few More Publication-related Questions
    This appears to be a popular topic, with many different questions. I’ve attempted to address a handful of them below, and will return to the others in future columns.
    Q. “Is X a good venue to publish at?”  
    A: The student had actually asked about a specific “X”, which I decided to anonymize: the purpose of this column is not to answer questions about particular venues, but to offer general advice. To that point, here is a general set of guidelines in choosing what conference venues to publish in:
    ·Are the leading researchers in your field publishing at this venue? Look at prior years’ programs to understand this.
    ·How visible/impactful are papers at this venue? Are these papers cited a lot? Lookup papers published at the venue over the past 2-3 years in Google Scholar. Were some of the “seminal” papers in your field published here? Are these papers you’d put on your must read list?
    ·Do your peers/advisor publish or want to publish here? It doesn’t hurt to ask directly.
    ·Is the PC composed of well-recognized members of the community (e.g., people whose papers you read)? In addition to hinting at the quality of reviews and feedback you would get, this also tells you whether the venue will be well attended and by relevant folks (because in most cases members of the PC do submit to, and attend, the conference).
    Q: “Why do networking conferences seem to go through these "fads" every few years -- multicast, DHTs, peer-to-peer, datacenter networking, and now SDN?”
    A:  Hey, don’t leave out quality of service, ad hoc networking, and the Internet of Things! But seriously, this happens in most fields of research and technology, not just networking.  Hence the “hype cycle” [8]. In general, these things are also driven by where the industry is headed or most focused, technology trends, as well as funding agencies’ areas of priority. If you want to know what these “hot topics” are at the moment, there are a few different sources you can peruse:  (a) You can pick up almost any networking trade magazines and you will find the relevant buzzwords there! (b) Read the most recent call for proposal from the US’s National Science Foundation, or similar organizations at other countries; (c) read conference calls for papers (CFPs).
    Q: What are some good strategies to ensure that my work/publication has "real world" impact?
    A: This is an excellent, and a very important question. Work that has demonstrable real world impact is much more valued, e.g., in job search, than work that did not go beyond a paper. There are a few ways that, in conjunction, can help your work achieve impact:
    ·Fully build out your prototype systems, and release software for public use. This will ensure other people, including those in the industry, build on your work. In cases where folks from the industry read your paper and want to license your work, they will often want a live demo. Having the system built out will help you be prepared for that.
    ·Invite yourself to give industry talks. This is a great way to publicize your work to the relevant groups in key companies, as well as to obtain pointed, relevant and practically important feedback.
    ·Sign up to speak at, or conduct demonstrations at, operator fora, such as NANOG, ONUG and ONS. In addition to publicity and feedback, you may get real world operational insight --- and datasets! --- that open your eyes to important extensions you can pursue for your system.
    [1] “10 networking papers: recommended reading”, Jim Kurose. ACM SIGCOMM Computer Communication Review, Volume 36 Issue 1, January 2006, Pages 51-52.
    [2] “10 networking papers: recommended reading”, Jon Crowcroft. ACM SIGCOMM Computer Communication Review, Volume 36 Issue 2, April 2006, Pages 31-32.
    [3] “10 networking papers: a blast from the past”, Mostafa Ammar. ACM SIGCOMM Computer Communication Review, Volume 37 Issue 1, January 2007, Pages 57-59.
    [4] “10 network papers that changed the world”, George Varghese. ACM SIGCOMM Computer Communication Review, Volume 37 Issue 5, October 2007, Pages 51-53.
    [5] “My Ten Favorite "Practical Theory" Papers”, Jennifer Rexford. ACM SIGCOMM Computer Communication Review, Volume 38 Issue 2, January 2008, Pages 41-43.
    [6] UW-Madison Graduate Computer Networking,
    [7] “How to Read a Paper”, S. Keshav. ACM SIGCOMM Computer Communication Review, Volume 37 Issue 3, July 2007, Pages 31-33.
    [8] Hype Cycle.

  • Posted on 2015-12-04 11:29 by admin

    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!
    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!
    [1] “On future-proofing networks”,

  • Posted on 2015-12-04 11:28 by admin

    ACM SIGCOMM Student Mentoring Column
    Aditya Akella, UW—Madison
    Topic: Various Student Questions
    I’ve received several interesting, and varied, questions from students all over the world. Thank you for the warm response! In this issue, I have hand-picked a small subset of questions to answer. Many thanks to Brighten Godfrey (UIUC) and Vyas Sekar (CMU) for contributing their thoughts. Do write to me with more questions or follow-on questions to the ones below.
    Job search related
    Question: “Say I am starting a company after my graduation. And assuming that my company has failed or has been acquired by another company, will my startup acquisition/failure have any negative impact on academic/industrial positions later?”
    Answer (Brighten Godfrey): One of the most important steps to succeeding at research is learning that repeated failure is part of the natural process of doing risky work.  Experiments don’t turn out as expected, good papers are rejected, start-ups fizzle.  As a result, in general, you will be measured more by the most impactful successes you have, than by failures.  That said, there is often a disadvantage to taking time off from academia – there’s a gap in your publication record, your research looks a bit older, and so on.  In some cases a startup could be viewed less as a gap and more as a positive extension of your research, for example if the startup was based on your work.
    Q: “After Ph.D., the highest academic job one could get is a tenure track professorship. And, most advisors help/gear graduates for that end. If one could not get a tenure-track professorship, the next closest academic position is a teaching professorship assuming that the candidate has interests in teaching. What are the other possible academic positions that fall between a research and a teaching professorship with no tenure/grant overheads from the former and minimal/no teaching load from the latter?”
    A (Aditya Akella/Vyas Sekar): The answer depends on which country you are considering as the overall system and framework for tenure-track/research faculty can vary quite significantly. In the USA, many academic institutions have non tenure-track research scientist positions (also called by other names such as “research professors” or “research associates”). Such positions don’t generally have mandatory teaching obligations, although many research scientists do take up modest teaching loads. However, grant writing is a big part as research scientists are generally expected to raise money to support their research programs (and themselves!). In other words, most academic jobs require you to do at least two things out of research, teaching, and grant writing.
    Paper writing related
    Q: “What is the most important section of a submission (say to Sigcomm)? I.e., Is there a particular section I should pay attention to/spend most time writing?”

    A (Aditya): All sections of a paper are important. Each section adds a different facet to a paper’s overall contribution. That said, as a reviewer, I tend to look for a strong motivation section. This is usually section 2 of the paper. A good motivation section clearly states the problem, using compelling examples and data to motivate why the problem is relevant/important and why it is hard. It also sets out requirements for the solution, highlights challenges in designing the solution, and puts the paper’s claims in the context of related work. Thus, it is totally worthwhile to spend time framing/polishing this section!
    Q: “I have a paper that has been rejected multiple times. Should I give up on it or send to a lower tier venue?”

    A (Brighten): That’s a tough question.  Sometimes you know there’s something good there, and even at a somewhat lower profile venue it can get noticed.  Other times you Arxiv it and move on to your next great idea.  But is there perhaps a third option – that even after you have seen and understood the feedback from reviewers you still believe the work is impactful enough for a top venue?  A paper that I consider one of the most important of my career so far was rejected four times before being accepted at a top venue on the fifth submission.  That can only happen if the authors and especially the leading PhD student really believe in the vision and persist in improving the work.
    Q: “A recent program committee commented that I needed to evaluate my idea using more realistic traces. My work is theoretical in nature, and I have proved strong theoretical guarantees, backed by a small set of experiments on a real prototype using toy workloads. What additional value do experiments with realistic workloads add?”
    A (Brighten/Aditya): At a conference like SIGCOMM or NSDI, this reflects the taste of the community to see real artifacts, whereas a conference like SPAA or PODC might be open to work where the contribution is foundational theory.  Realistic workloads answer different questions than theoretical analysis.  A strong theorem may bound performance in the worst case or it may show expected performance under certain assumptions about the operating environment. A real prototype system evaluated with realistic workloads can demonstrate performance in typical cases that people actually care about in the real world. Crucially, it can show that the system-building and other operational difficulties that inevitably arise (but don’t always appear in a theoretical model) don’t invalidate the main insight/result.
    Q: How does one write a good introduction/abstract for a paper?
    A (Vyas/Aditya): I don’t think there is one good answer and it depends both on the type of paper (e.g., measurement vs. algorithm vs. position paper) and the person writing it. We evolve and develop an individual “style” of writing a good introduction in terms of both the language and presentation. That being said, a good introduction should generally answer the following questions (paraphrasing Jim Kurose’s advice (1) Why is the problem important? (2) What was challenging in solving the problem, and/or why did prior work fall short? (3) What was your key insight and why is it interesting? (4) What are the main “punchlines” in terms of system/algorithm performance that advances the status quo? Crucially, you need to keep practicing your writing. Don’t leave the part of writing up the abstract/introduction to your advisor; draft it yourself! You will eventually become great at churning out perfect introductory sections.

  • Posted on 2013-09-01 21:21 by Anonymous

    Hello Everyone,

    Hamed Haddadi, the Information Service Director for SIGCOMM, has found some of my posts over at "How to Do Great Research" quite worthwhile to read, and has suggested that I cross-post some of the content on the SIGCOMM blog.  I'll point you over to the blog for the full content, but I've posted a teaser below.

    The genesis of the blog is a course for incoming Ph.D. students that Professor Alex Gray and I designed at Georgia Tech and have been teaching for more than five years.  To our surprise, a lot of helpful information on the Ph.D. is "out there", but it's not really consolidated in one place.  We began collecting helpful information and filling in the gaps with our own material; this fall, as much of the material has coalesced, I am putting the material into written form on a blog.  You'll be able to read posts such as the one below throughout the fall term. (I expect the flood of posts this fall may become a trickle in the future, but hopefully once the initial information is seeded, we'll also enrich the information we have with guest posts.)  The course has a variety of twists and turns that we devised, such as assignments to generate cross-disciplinary ideas, time management exercises, a mock program committee, etc.  If anyone is interested in more of the course materials or wants to talk to me more about this concept, I'm all ears.

    Thanks, and happy reading!

    Nick Feamster


    Managing Your Advisor (cross-posted from How to Do Great Research)

    With the new academic term almost upon us, several of my students started to put together a list of practical advice for incoming students—including various niceties such as how to gain access to the lab, how to get accounts, how to submit reimbursements, and so forth.  I wanted to contribute to the list of advice, and I figured I could offer some value by giving advice to new students about how to gain traction on their research as quickly as possible.  This post is the first in a series of a few posts on that topic; in this post, I will cover the topic of managing your advisor.

    The notion of an advisor is an interesting concept for many new Ph.D. students.  Incoming graduate students typically have one of two backgrounds: some come straight from undergraduate studies (and, hence, may have never had a manager or a boss overseeing their career); others have spent some time in the workforce and have decided to return to the university and begin a career in research (and, hence, have some notion of what it is like to have a manager).  An advisor-student relationship is unique, though, and will be a new experience for both types of incoming students.  The relationship is similar to a manager relationship, but has several differentiating features.  First, your advisor is often a collaborator on equal footing.  Although an incoming Ph.D. student is not (yet) a peer of his or her advisor, the goal is that by the end of the Ph.D. process, the student and advisor will be peers.  In this sense, the Ph.D. is a true apprenticeship.  My students don’t work for me; they work with me.  Second, your advisor is not a manager in the strict sense, but is literally an advisor: You are in control of shaping your own graduate career, from what you choose to work on to who you work with.  Your advisor should be a catalyst and facilitator for your success and should not be treating you as an employee or “hired labor”.  Although some research contracts have deliverables, you should be suspicious of any advisor who wants to constantly hold you to tight deliverables, as it will constrain your autonomy and creativity; that type of advisor will ultimately be more like a manager, and you can find plenty of managers in industry who will pay you a much higher salary.  If you find that your advisor is bossing you around or restricting your autonomy or creativity, change advisors as soon as possible.

    In any advisor or managerial context, it is important to recognize the importance of “managing up”.  While there may be strategic reasons to do this in any context, the most important reason to learn how to manage your advisor is to make the most of your graduate career.  Many things compete for your advisor’s attention—papers, grants, proposals, teaching, committees, other students, outside opportunities, etc.  At the same time, everyone’s Ph.D. experience is unique, and it is incumbent on you to work with your advisor to help you define your own trajectory and also to create a working relationship that works for both of you.

    In my seven years as an advisor, I have learned a few things about my working style.  Here is some of the advice I have offered my students about how to manage me.  Many of these tips may be useful in general for other Ph.D. students who want to help build a better relationship with their advisor and help get the most out of their graduate careers:

    • Ask your advisor for what you need.  Want to attend a conference, get an introduction to a senior colleague in the field, buy a book or other equipment, find an internship, get a travel grant, or something else?  Be proactive.  The answer will be “yes” more often than you think .
    • Scheduling meetings. I have a Google calendar that I share with all of my students.  If a meeting or event is not on my calendar, the student should assume that the meeting is not happening, even if the meeting has been discussed (and agreed on!) in the hallway.  There is no way to keep track of hallway discussions for scheduling and they are quickly forgotten.  Though it’s not strictly necessary, I advise my students to consider sending a reminder/minutes/confirmation before the meeting; this relates to the point below on making meetings count.  Scheduling meetings sometimes can generate an explosion of email—this is a recipe for disaster and ensuring that you never get to meet your advisor (see below on email); if scheduling is proceeding slowly, limit the email thread to 1-2 emails before suggesting a meeting invitation by Google calendar.  If all else fails, send a meeting invitation during an open slot; in the worst case, your advisor will react by moving it to a time that works (it is on the calendar and thus can no longer be deferred indefinitely).

    • Try to meet your advisor once a week, even if you think you have nothing to talk about.  Make an effort to schedule a meeting once a week, even if the meeting is short; in my experience, I have found that sometimes even a ten-minute meeting with a student can make a huge difference for working around a mental block or changing an approach to a problem.  Do not assume that a meeting cannot happen simply because your advisor is not in town.  Short meetings by Google hangout are often very handy.  In fact, throughout the summer of 2013, I was rarely at Georgia Tech; many of my students actually found it easier to meet me when I was traveling because I wasn’t being constantly bombarded by things related to the daily drumbeat at the university (e.g., committee meetings, interruptions from admins, teaching, etc.).  Consider having a meeting even if you think there’s nothing to report.  You may find you are stuck in a rathole, and you may not even realize it.  You should be particularly worried if you have spent 2-3 weeks “debugging” or on some “implementation” without getting any feedback.  Chances are, you are ratholing on something that probably isn’t getting you any closer to a publication.  Seek help immediately!

    • Attend every single group meeting.  Do not miss group meetings.  These are one of the most important structural elements of your graduate career that actually relates to your research.  Group meetings are important for several reasons: (1) You learn about what others in the group are doing, which may be a useful resource (or, you may find out you can be a resource to someone else).  This all helps with collaborating across the group. (2) You find out what your advisor has been up to and why he or she has not been replying to your emails immediately. (3) You can quickly identify if you need to have a longer meeting with your advisor, with other students in the group, etc.  This can be a huge timesaver.  (4) Group meetings mark the passage of time.  It is useful to hold yourself accountable and make sure that weeks and months don’t slip away without progress.  I have group meetings with my students three times a week; initially, I thought that this might be excessive, but it turns out to work pretty well.  Three short group meetings can often be a lot better than one extended group meeting.  I will expand on this more in a later post.

    • If you need more of your advisor’s time, ask for it.  Students are often confused or concerned that an advisor spends more time with some students than with others and may even (wrongly) think that the advisor is either less excited about a particular project or (worse) doesn’t like some students as much as others.  (I remember comparing notes with my fellow Ph.D. students in grad school about how much time our advisor was spending with each of us.)  Yet, it is important to remember that good advisors don’t play favorites.  The time that an advisor spends with a student (or on a project) is typically determined by the advisor’s perception of how much time is needed; the required time can vary dramatically according to both the stage of the project and the stage of the student’s development.  Students who are early in their careers typically need (and should be asking for) a lot of guidance and “closed loop” feedback.  Students who are close to graduating also tend to need more attention of a different sort—help with building their professional network, seeking out job prospects, practicing job talks, and generally landing on their feet.  Similarly, nascent research projects or projects with substantial coordination components (e.g., large systems-building efforts) often need a lot of advisor attention, since they have lots of moving parts and can involve coordination between multiple sub-projects and students. Do not be overly concerned about strict time accounting.  If you feel you need more time, simply ask for it—or, better yet, just try to take more time (walk into your advisor’s office, approach him or her on IM, send regular email updates…whatever it takes).  Advisors tend to spend more time with students who demand more of their time.
    • Keep your emails short and to the point.  Here is a simple rule of thumb: If the email is longer than one paragraph, it probably won’t get read right away, particularly if there is no summary at the beginning of it.  It almost certainly won’t get an immediate response.  Additionally, consider whether email is the fastest way to resolve something, or whether it’s quicker to have a 5-10 minute meeting, hangout, IM chat, phone call, or whatever.  Use the right communication mode for the job.

    • Do not assume that if your email doesn’t get a reply, it hasn’t been read.  I read everything in my inbox, almost always on the same day that it arrives.  Unfortunately, I also receive 300-500 emails per day in my inbox (not mailing lists), many of which are actionable.  Suppose that half of those emails required action, and that each one required one minute to process and respond to—that’s already six or seven hours a day just to process email.  That is insane and can kill anyone’s productivity.  I am convinced that it is possible for a professor to do nothing else in life except reply to email.  To control this insanity, I often process emails “in batch mode”—leaving email to (mostly) pile up for a few days and then responding to a bunch at once.  I tell my students that if they do not receive a reply right away, “retransmission” after a few days is fine. I do not consider this to be rude, nagging, or pestering behavior; most likely I have simply just forgotten (I have found that it’s surprisingly difficult to even keep a to do list for all of these things that students ask professors to do, as doing so becomes a monster mega-task in and of itself).  Before sending a retransmission (or initial email), however, consider whether you have chosen the best medium for your message. Sometimes an in-person meeting or IM follow up to a an email will get the response you want/need.

    • Make the meetings count.  Many meetings are wasted by not asking yourself simple “does this make sense?” questions before presenting a plot/result.  I ask my students to read Jon Bentley’s “Programming Pearls”, particularly the chapter on back of the envelope calculations.  Also, I advise my students to read Vern Paxson’s “Strategies for Sound Internet Measurement”. Your advisor has almost certainly seen a ton of plots/experiments/data and is pretty good at quickly determining whether a graph that you spent two days producing makes any sense at all.  You can have a more productive meeting if you do some simple debugging of plots before hand.  On this note, bringing specific, concrete things that your advisor can react to is helpful.  “I ran some experiments and things seem to look OK.” is a report I have heard many times from students.  Such a report is utterly useless.  Even if it were true (often things may not be OK), it is impossible to give feedback on or brainstorm based on vague statements.  You are likely to get a “sounds good!” in response, which is equally useless for you.  Bring something concrete to discuss.  You can present anything: A performance number, a paragraph of writing, a plot, … something to react to and figure out next steps.  Even a plot that appears buggy or inexplicable is sometimes a good topic for a meeting, too, presuming you’ve recognized the discrepancies and can’t figure out the problem.  Sometimes what appears to be a bug might in fact be an interesting artifact, or even the spark for a new paper or discovery.

    • Take notes and organize them. The students who make the best use of meetings tend to have: (1) an agenda beforehand; (2) minutes afterwards; (3) something focused and concrete to discuss/think about/talk about; (4) a consolidated place to keep minutes.  Your advisor can read these minutes to prepare for the upcoming meeting, think about problems offline, review/think about the problem outside of meetings, and guide progress.  Sometimes your advisor may take notes, sometimes not.  Don’t count on it.  Even if your advisor is taking notes, your notes will complement and fill in gaps.  Different people remember different things.  Taking notes is also an important opportunity to practice writing—and students need to practice writing at every opportunity (more on that in a later post).

    • Do not wait until the last minute to write your paper.  Most graduate students are working on one or at most two papers or projects at any given time.  It can thus be easy to overlook the fact  that your advisor is involved in many more things (albeit at a higher level) and, from a purely practical standpoint, might be submitting two or three papers to the same conference deadline. Thus, waiting until the last minute to write a paper draft (or complete a project) is an invitation for scattered, distracted, and superficial feedback (and severely diminished chances of a strong paper submission).   Can you write a good paper or think clearly while doing four things at once?  If not, consider your poor advisor, whose aging brain is no longer as agile as yours.  Write early, write often.  Writing is not a task that happens after the research is done; rather, it is part of the research and thinking process, not something that is done when the research is done.  Writing is part of the research.  I ask my students to have a complete paper draft at least one week before the deadline.  Nobody ever follows this advice, and I think that we can recognize that it is idealistic.  I’ve periodically threatened to ban paper submissions if there is no draft a week before; I don’t have the will to do that, although I know at least one of my collaborators who enforces this rule.  Still, the point remains: early attention == focused attention == good attention.

    • Do not ask for a recommendation letter with less than one week’s notice.  A letter takes at least an hour to write—longer if there is no earlier draft from another instance.  Short notice makes for letters that will probably not be as strong as they could be, because a good letter takes time to polish.  Consider writing the first draft yourself, or at least putting some points into bullet form or providing an up-to-date CV, for quick reference.  All of this stuff makes the letter stronger and easier to write.

    This list is mostly based on tips and tricks that I have found work for me.  I refined this list of advice after a discussion with Professor Jennifer Rexford, who is also full of useful advice.  Jen’s advice for new graduate students is particularly useful; I am in strong agreement with her thoughts on the benefits of regularly coming to the lab and integrating with a research group.  I’m interested to hear what other tips and tricks people have for managing their advisor(s), or thoughts from other faculty members about tips they find that work well.  In the coming weeks and months, I will follow up with specific posts on advice for writing, preparing talks, and managing time.

  • Posted on 2011-08-23 15:38 by obonaventure

    ACM and IEEE have joined again their forces to create a reference Computing Curriculum for Computing Science. The previous edition was released in 2001 with an update in 2008 :

    The 2013 edition is currently being developed and SIGCOMM will provide input concerning the core networking concepts. If you'd like to participate in this discussion, subscribe to the SIGCOMM Education mailing list

  • Posted on 2011-02-15 12:20 by Anonymous

    Nominations for the annual SIGCOMM Award are due on March 31st to Ramesh Govindan ( The nomination procedure is described here.

  • Posted on 2010-10-02 12:06 by obonaventure

    Some time ago, a colleague mentioned that some universities did not offer any networking course to their students and that the networking concepts were taught inside other courses such as programming systems courses. Assuming that a student will be exposed to only five hours of networking concepts, what are the mandatory concepts that he should understand ?

    • a first option would be to consider that the ability to develop a small networked application is the main concept and networking could be introduced by starting from the socket layer and use it to explain the transport layer services as well as DNS and perhaps write a small application such as a basic HTTP or email server
    • a second option could be to consider that packet switching is the most important concept and discuss all the implications of packet switching, perhaps with a brief explanation of addressing and the roles of routers or switches
    • there are probably many other options

    Maybe ACM SIGCOMM should provide recommendations on these mandatory networking concepts. Suggestions/comments are more than welcome, especially from teachers who have had to give such courses.

  • Posted on 2010-09-01 14:34 by obonaventure

    The SIGCOMM Education mailing list has been created to allow all people interested in networking education to exchange information. The list is hosted on ACM's servers and you can subscribe to the list through the following web interface :

  • Posted on 2010-08-25 17:38 by obonaventure

    The objective of SIGCOMM's education blog is to post short documents or initiate discussions about educational issues in the broad networking area. We hope to regularly post content that is useful for networking educators and generates discussions. In August, we contacted about twenty young networking educators and asked them a few questions about the difficulties that they faced in the educational activities and how SIGCOMM could help. Several interesting suggestions were received, including :


    • provide a repository where educators can exchange slides, homeworks exam questions, labs, software, book references, reading lists, ...
    • survey about the most suitable networking textbooks 
    • recommendations on the list of topics that a networking course should cover 
    • package conference tutorials so that they can be easily reused - more venues for graduate students to participate in conferences 
    • information in local languages for non-English speaking students 
    • seminars given by renowned professors 
    • free access to conference/workshop proceedings 
    • short courses on graduate topics 
    • newletters for students with assignments or hacks or recent press information
    • a forum for young faculty 

    For the first three suggestions, we invite educators to consult and register on the SIGCOMM education reprository at

    We hope that the blog will serve as a forum for young faculty and that excellent ideas will be exchanged through the blog.

Syndicate content