Paper Summaries

Before each class, you should read one of the papers we will be discussing that day (check the schedule). You should also skim (get a decent idea of) the remaining papers.

Deliverable

You summary should be around 500 words, covering: a summary of the paper (the problem solved, the approach, intellectual contributions, etc), a list of strengths (what you liked about the paper), a list of weakness (what you think is missing from the paper), and a list of possible follow-up ideas (extensions, relaxing assumptions, a different application of the same ideas, etc).

Policy: I will ignore the grade of the lowest 5 summaries submitted.

---

Leading Discussions

The class schedule is divided based on topics. Each lecture focuses on a specific paper that solves a problem within the broad topic. Students will select at least one lecture (i.e., one paper) where they act as the discussion lead (i.e., present an overview of the paper and pose discussion questions). They are also responsible for providing an overview about the broad topic of their chosen paper.

Deliverable

Discussion leads have two responsbilities:

• During their selected lecture, discussion leads will prepare a short presentation (10-15 minutes) about the paper covered in that lecture. They will also prepare a set of questions about the paper (or the broad topic) for the class to discuss.
• Topic overview: the lecture before a topic is covered, the discussion leads for that topic will collaborate on a short presentation (10-15 minutes) about the broad topic (not the specific papers).

---

Programming Project

Each student (or group of up to two students) can pick a project related to datacenter networks and systems. As code artifacts for many recent systems papers are available and functional and some or all results of such papers reproduced, students are encouraged to use such artifacts as the starting point of their project. The following types of projects are recommended:

• Research idea: Students are encouraged to propose their original research ideas as a class project. The idea should be related to the topics discussed in class, preferably building in already available codebases. The proposal should include a detailed plan, elaborating on the feasibility of producing a deliverable within the course's timeframe.
• Reproducing results with a twist: Most systems are developed with a specific type of infrastructure and/or workload in mind. Your objective will be to pick an artifact, identify the workload and infrastructure it was developed for, and form a hypothesis about a (reasonable) setting that might be challenging for the studied artifact to handle. The final deliverable should be in the form of experiments that support or disprove your hypothesis. Negative results, that is results that disprove your hypothesis, are acceptable.
• Matchmaking: As we will discuss in class, developing and managing a large-scale infrastructure requires optimizing many parts of it. Optimizing even a small, but critical part, can be the focus of study for many years. Your objective will be to identify two complimentary systems and build a system that combines their strengths, demonstrating the value of the combination through experiments.

Deliverables

Proposal: A short writeup summarizing the motivation, the idea, and a summary of the most related two or three papers. The writeup should also point to the artifacts you intend to use to achieve your goal. This should help make sure that we agree on a promising direction for the project.

Progress Report 1: This report is meant as a checkpoint to ensure that you now have a concrete idea of what the project is about and what deliverable you will be working towards. The report should include the following sections:

• Project objective
• Motivation - why is the objective important?
• Challenges - why is achieving it hard?
• Sketch of the approach - what's your plan for tackling the problem?
• Related Work
• Evaluation Plan - measures of success, timeline, and required resources
• Responsibilities of different team members

You should have the environment needed for your project up and running at this stage (i.e., you should have the artifacts that your project relies on running in the environment where you will conducting your planned experiments).

Progress Report 2: This report is meant as a checkpoint to ensure that you are making progress towards the objective of your project. This report is made of two parts. The first part is an expanded version of the first progress report replacing tentative plans with concrete progress made so far. The second part is a summary of progress made since the first progress report. The summary should cover the following:

• Summary of code - which parts of your approach have you coded? what remains?
• Summary of experiments - which experiments did you run (if any)?
• Summary of unforeseen challenges - are there parts that turned out to be harder than you expected? what did you learn from the experience?
• Responsibilities of different team members - which team member did which part? If it's uneven, what's your plan to correct that?

Final Report and Presentation: The final report should have the same sections as the first progress report with all tentative plans replaced with the concrete outcomes of your research through the semester. You should also summarize that report in a presentation which you will give in class during the last week of class. The grade of the final report is almost execlusively based on the emprical results produced by your research. The grade of the presentation is based on your ability to demonstrate your understanding of the problem, methodology, and approach of your project.