UCL logo
People Overview Publications Seminars Calls for Papers Reading Group Networking Resources PhD and Job Applications

Networking and Systems Reading Group

The Networking and Systems Reading Group gives PhD students and faculty an important chance to discuss interesting recently published papers (and the occasional "classic" paper) in detail. Why discuss papers?

  • Successful researchers keep abreast of developments in their field:
    • to spot opportunities (e.g., to identify important problems exposed but unsolved, or techniques whose shortcomings inspire a superior approach)
    • to ensure their work pushes into new territory (i.e., one must understand the state of the art to excel it)
  • One of the essential steps in learning how to produce excellent papers worthy of publication in top venues is to study papers from those venues, and to learn to identify what constitutes great research and a great paper.
  • Debating a system's or problem's merits is one of the best known ways to produce technical insights.
  • Constructive disagreement fosters critical thinking.

The group meets weekly on Wednesday afternoons (hour varying from week to week, depending on room availability; we have the room for 90 minutes, so that a particularly fruitful discussion needn't be cut short.) The schedule of papers and presenters can be found on the seminars page.

Guidelines for Discussion

In the interest of productive discussion, a few guidelines for participants in the reading group:

  • All attendees should read the paper carefully before the discussion group meets; only if we've all critically read and digested the paper beforehand will the discussion be fruitful. Most find it helpful to take notes on a paper while reading it, for reference during discussion.
  • We ask that all participants in the reading group attend discussions for all papers--the aim is to have a group explore the literature together in successive weeks, so that we can all draw on insights gleaned from prior papers while discussing later ones.
  • At each meeting, one person, the presenter, will begin by summarizing the motivation, problem statement, and design presented in the paper for about 10-15 minutes. When needed, the presenter can provide relevant context here (e.g., if there's prior work essential to making sense of the paper, summarize it).
  • The presenter is discouraged from using slides except to display graphs from a paper--these are discussions, not talks. A presenter should sketch notes for his summary ahead of time, and all presenters are welcome to use the whiteboard while presenting a paper.
  • For the remainder of the meeting, all are welcome to raise strengths of, criticisms of, and questions about the work presented in the paper that are conducive to discussion. Many of these discussion points come to mind during your reading of the paper before the meeting (another reason to take notes as you read). Some discussion points arise during the presenter's summary (different readers interpret the same paper differently with regularity), and of course, during the discussion itself.
  • As starting points toward discussion, here are a few questions to bear in mind as you read a paper:
    • Is the problem attacked in the paper worth solving? What's the end-to-end goal, and why do users (or others, e.g., ISPs) care about it?
    • Do the experiments and measurements presented by the authors make a convincing case that they've solved in full the problem they set out to? Or is there a gap between what the experiments show and solving the problem in practice? (If so, how could you design a better set of experiments to close that gap? Can you predict, based on the design of the system, how it would behave under such a more realistic experiment?)
    • Is there a simpler, equally (or more!) effective way to solve the problem than that presented by the authors?

Fall 2008 / Spring 2009

Please email Alan Medlar to request to be presenter for a paper, and to choose the date on which you'll present.

Below is the suggested list of papers for discussion in 2008-2009. Suggestions for additional papers to discuss are welcome!



Congestion Control


Operating System Performance