Computer Networks

527, Fall 2015, Ivan Beschastnikh (bestchai@cs.ubc.ca)

Tues/Thur 3:30-5:00PM, ICCS 206, UBC course page

Course piazza

Office hours by appointment

Course description

Computer networks and protocols are critically important to modern life. They range from the small (set of peripherals in a laptop) to the very large (the world wide web), and are also extremely diverse. Yet, at their core, all computer networks have similar challenges, such as addressing and naming the entities in the network. The focus of this course is to explore the broad diversity of computer networks through a series of research papers. Each week (2 class sessions) will focus on a particular networking topic. The course will especially emphasize re-occurring challenges and approaches that appear across topics.

This course satisfies the PhD "Computer Systems and Design" breadth requirement.

Course-level learning goals

• understand key principles involved in designing and implementing network architectures and protocols
• reason about challenges that are inherent to all computer networks
• develop advanced networked systems

Format

This seminar-style course will be primarily driven through in-class discussion of the readings. Most of the readings will be research papers; there is no textbook for the course. The course will also include an open-ended course project that must be completed as part of a team, and a final take-home exam.

• The discussion in each class will focus on 1-2 papers
• The discussion for each paper is led by two students, an advocate and a skeptic
• Everyone except for the paper advocate and skeptic writes a review of each of the assigned papers, due at 9PM the day before class

Advocate and skeptic are in charge of leading the discussion for a paper. Do not use slides. Instead, give a concise summary of the reading and pose questions to dig deeper into why the paper was written, what can we take away from it, how does the paper relate to the course, why it is or is not the final word on the subject, etc.

Advocate and skeptic need to review any other paper(s) that are discussed on same day, but they do not need to write a review for the paper they are leading.

Schedule (a work in progress)

Paper reviews

For each of the assigned readings in the schedule above you must compose a review/critique. (The schedule sometimes lists optional readings; you do not need to review these). I should receive your reviews by email to bestchai@cs.ubc.ca by 9PM the day before the class in which they are discussed. Use one email per paper and for these emails use the subject line: CPSC 527 paper review: NAME, DATE where NAME is your name and DATE is the DATE the paper is discussed in the course. I will collect all of the received paper reviews the following morning and post them to Piazza.

Each paper review must be in the body of the email, in plain text and not as an attachment, and must include (1) a paper summary, and (2) a review of the paper. Aim for a 1-2 paragraph summary and a 3-4 paragraph review. Reviews should engage with the reading at a deep level. Write your review with an eye towards contributing something interesting to the discussion in class the following day (see advice below).

The summary portion of the review is required, but it will not be graded. The review portion of the paper review will be graded using the following scale:

• 3 : the review engages with the reading in great depth
• 2 : the review engages with the reading in some depth
• 1 : the review is shallow, for example it is a summary of the reading
• 0 : no review was posted, or the review is unreadable, off topic, or offers no insight into the reading and/or is a simple re-statement of some text in the reading (e.g., the abstract).

Late reviews will lose 1 point for every 12 hour period that the review is late.

Paper reviews advice

Reviews should engage with the reading at a deep level. Write you review with an eye towards contributing something interesting to the discussion in class the following day.

• Why was the paper written? What problem does it solve? Does it completely solve the problem; under what circumstances? Why is the problem interesting/important?
• How is the paper topic relevant to us today?
• What question would you want to ask the authors, and why?
• Why are we reading this paper? What can we take away from the paper? How did the paper change your perspective on computer networks?
• Is the paper the final word on the subject? What are some questions that it brings up?

Other bits to keep in mind.

• Your review mark depends primarily on the content in the detailed review field, not the summary field.
• The summary of the paper should go into the summary field. The review should go into the review field. Avoid reviews that are summaries of the paper. In your review I want to see that you thought critically about the paper and what the paper has to offer.
• I am interested in reading about what you think, not what the authors think. Therefore, a successful review would primarily revolve around your ideas/thoughts about the paper.
• Make your words count. A longer review is not necessarily a better review.
• Focus on a few specific, technical, aspects of the paper. Avoid making general claims/comments about the paper.
• Spend the time to thoroughly discuss the issues/ideas that you do raise. It is better to have 1 interesting well-discussed idea, rather than 5 short and fragmented bullets. Aim for a cohesive narrative.
• Avoid meta comments (e.g., "paper needs more figures"). If you want to make a meta comment/question about the reading, then make it as specific as possible and interesting to the rest of us.
• When critiquing an aspect of the paper (e.g., no message loss/FIFO queues/etc are unrealistic) consider why the authors ignored these issues (perhaps these are not fundamental to the problem that they are solving?). It also helps to think about how you would overcome these issues (again, I'm much more interested in your thoughts/solutions, then blanket criticisms).
• Every paper has shortcomings, so if you do bring up a shortcoming, then make sure that your detailed review discusses/reflects on the shortcoming in a non-trivial manner. For example, simply stating that "it was not clear how 30s delay was computed" is not sufficient. You need to talk about why you think the authors decided not to solve this problem, why this problem is worth solving, what are the implications of not solving this problem in this specific system, etc. Finally, when you do bring up shortcomings, make sure to bring up shortcomings that are fundamental, and not those that can be easily remedied.

Project

The project must address a non-trivial problem relevant to computer networks and must be done in a team of 2 or 3 students.

There are four project deliverables:

• Project proposal: a paper detailing the problem, your proposed approach/solution, and a realistic timeline for your team. See more proposal advice below.
• Prototype implementation: must involve substantial development effort. The final prototype must be shared with the instructor (at the end of the term), preferably as an hg or git repository.
• Project presentation: a 10-15 minute presentation describing your project. Plan the presentation so that each team member talks for 5 minutes. The presentation will be followed by a 5 minute Q/A period. I encourage you to demo your project during the presentation.
• Project report: a paper detailing the problem, your approach/solution, your prototype, and an evaluation of the prototype. The final report (due at the end of the term) should be no longer than 10 pages and should resemble a research paper.

The project is structured as a series of regularly occurring deadlines, listed in the schedule above and below. Do not miss these! The deadline deliverable must be submitted by email to the instructor by 9PM of the day of the deadline.

• Oct 2 : Project proposal drafts
• Oct 16 : Project proposals
• Oct 30 : Each team must send email by 9PM to schedule a private meeting with instructor to discuss project status.
• Nov 27 : Project code and final reports

Project proposal advice

A project proposal details the problem, your proposed approach/solution, and a realistic timeline for your team. The proposal must be no longer than 5 pages and must include at least the following sections: introduction/motivation, background, proposed approach/solution, evaluation methodology, timeline.

• The timeline must include dates and milestones/deliverables. It must be sufficiently refined to include milestones that are specific to your project. Do not simply list the deadlines for the course without listing the internal project deadlines. The timeline is there to get you to think about your time and to loosely commit to a schedule.
• This is a computer networks course, so make sure that your proposal is focused on issues/challenges/objectives relevant to this topic.
• The bulk of a proposal must be dedicated to design: what will your system/approach look like, what properties will it have, what features will it include/omit. Who are the users/clients of your system (wireless phones, or people, or network routers)? How will clients interact with your system, etc. This section is more critical than related work, or introduction/motivation. Writing this section well is difficult; spend the time to do a good job on it.
• It is important to omit content that is irrelevant to your proposal. Before including text, consider whether or not it plays a purpose in explaining your proposed system and its objectives. If not, then it can probably be cut.
• Consider giving your project/system a name. This way you can easily refer to it in your proposal.
• Your project can re-use external code/algorithms/ideas that you find online. Leverage prior work and build on it to avoid re-inventing the wheel and to get to interesting ideas quicker.
• Make sure to define non-standard/specialized terms, include examples, and intuition -- anything to help get your ideas across. This work will pay off in the long term: (1) it will get you think more deeply about your work, and (2) you can re-used it in the project write-up and project presentation.
• Make sure there is logical flow to your proposal. Define terms before you use them, motivate particular perspectives before launching into details, discuss prior work necessary to understand your proposal before you rely on it for your descriptions. Your proposal has to be self-sufficient, with citations to back-up your arguments. However, do not rely on related work to explain concepts that are critical to your proposal.
• Consider including info-graphics/figures to explain your design. Sometimes it is easier to explain a complex idea with a picture. Likewise, don't hesitate to include formalism/math to explain your ideas (though, be careful with including formalism for formalism sake -- make sure it helps to explain rather than confuse the topic).
• A well thought-out and detailed proposal will only benefit your group in the long run -- you'll have a more clear idea of what to work on!

Final report advice

The 10 pages should include title page and appendixes. I prefer that you style your paper in ACM latex format.

• Your report should have all of the essential sections that a research paper has: title/authors/abstract/introduction/methodology-evaluation/related work/conclusion/references.
• The report may have other, optional sections, that we've seen in research papers: motivation/design/implications/discussion/future work/etc
• The report must properly motivate the research problem you have attempted to answer. Spend at least 1-2 pages motivating the problem (just look at any of the paper we have read this term). You should do this in the introduction, though many papers also have a separate "motivation" section or similar to motivate/introduce the problem in more detail.
• The report must motivate/introduce a problem that you actually solve. Make sure you are not motivating a different problem than what you solved (a common mistake). It helps to connect the problem to a broader context from the very start (see last bullet below).
• You must somehow argue that you have solved the problem. There are many ways to do this. If your problem was algorithmic/theoretical then you may have a proof. If your problem was empirical (e.g., what fraction of traffic on campus is due to BitTorrent) then you should have measurement study/results. If your problem requires a new system, then you should have built a system and demonstrated that it is the right system. Etc.
• Any empirical evaluation results must have a proper methodology to introduce the results. What was the goal of the evaluation? How did you translate the research question into evaluation questions -- why did you measure what you measured? How did you select the subject programs/networks/people/devices/etc and why? Typically, the more information you provide to describe the experiments, the better. But, it requires careful judgment to report just the important details.
• You must have some related work. The project for this class does not need to be a novel research project. But, it helps to position your work in the context of existing research. What is the closest work to your project? How is your work different? I don't expect you to do an exhaustive literature survey, but I would like to see at least half a page of related work discussion. Aim for maximum a page of related work.
• I recommend that you find 1-2 papers that we read that tackle a similar problem or use similar methodology. Then, consider how these papers structured the motivation and the presentation of the solution/argument. Don't hesitate to adopt/copy their structure/form.
• A good project report usually, at some point, takes a step back from the low-level details of the work and considers the broader context. It would be great if you can do this in your work. Show me that you can think more broadly, beyond your project and that you can identify implications of your work for other networking technologies/contexts/problems. Think of it this way: if the reader is generally interested in networks and not in the concrete problem that you solved, then what can they take away from your work? Typically this kind of discussion starts in the introduction, may appear in brief snippets throughout the paper (to connect the low-level details to a larger focus), and then picks up again in the discussion or the implications section.

Final presentation advice

Project presentations are 5% of your course grade. Considering the short length of the presentation (just 5 minutes per person!) it is easy to assume that this is an easy 5% to attain. This is a mistake -- good presentations, and especially short presentations, are difficult to create and require substantial effort. Below I list some suggestions on how you can improve your presentation on Dec 3rd:

• Follow general research talk presentation advice. There is a lot of advice on the web. Here are some good links to get your started: [1] [2] [3] [4]
• You have just 5 minutes, I expect those 5 minutes to be polished:
• Practice your talk. Many, many times. After all, it's so short!
• You should be engaging; staying engaging for 5 minutes is not that difficult.
• Stay within the time limit
• You should not search for words -- you don't have time for that!
• Your group's talk should be coherent:
• Each person has 5 minutes, but the overall talk needs to make sense and flow naturally
• Divide the content in a way that makes sense: don't present parts of the project you don't know
• Make sure the talk has a small number of points that you want the audience to take-away/learn
• Be consistent in your message from one presenter to the next

Final exam

Download: practice final, actual final.

Exam tips

• Almost any topic can go with any paper. But, you have to think deeply about how their relate.
• Check that the topic is not explicitly handled in the paper before you go too far.
• Don't extend the topic too much (e.g., censorship is not the same thing as security).
• The topics on their own are topics, not problems. The technical issue must relate to the topic, but it's not going to simply emerge from the topic or the paper. The issue will emerge from the intersection of the two.
• Yes, choosing the right issue to write about is a difficult part of the final. It is worth it to spend the time to do this well.

Grading

Final course mark will be based off of:

• Class participation: 20%
• Paper reviews: 30%
• Project: 35%
• Proposal: 5% (team)
• Presentation: 2.5% (team) + 2.5% (individual)
• Final report: 25% (team)
• Final exam: 15%

Note that the project must be a team effort. The team's mark for the proposal and final report is the same for all team members. For project presentations each team member will receive a team mark and an individual mark.

The mark for class participation is based on three factors:

• Regular course attendance
• Regular participation in the in-class paper discussions
• Leading of discussion for advocate/skeptic assignments

How to do well in this course

Be prepared to participate in in-class discussion. This is a seminar-style course, which means that most of the class time will be devoted to discussion. The best way to prepare for class is to read the assigned paper(s), write a thoughtful review, and then read and carefully consider the reviews submitted by your peers. Periodically re-read the readings from the first day of class and work to improve your paper reading and reviewing abilities.

Plan you reading time. The readings will likely challenge you. I recommend allocating an explicit time slot each week for reading the papers and for thinking about the papers. Note that some readings will be more difficult than others. Jump ahead and note the readings that are particularly long, theoretical, or may be especially challenging to you.

Invest time into the project. Do not underestimate the importance of a thorough (and interesting!) project proposal. Proposal write-ups that are vague or are incomplete will not be accepted. Put in consistent and weekly effort into the project. Rehearse and polish your presentation, and make sure your final report is well-written and conveys its ideas clearly.

Reach out for success. There are no explicit office hours for this course. Email and schedule a time to meet with the instructor to discuss the course, the project, etc. University students often encounter setbacks from time to time that can impact academic performance. Discuss your situation with your instructor or an academic advisor. Learn about how you can plan for success at: www.students.ubc.ca. For help addressing mental or physical health concerns, including seeing a UBC counselor or doctor, visit: www.students.ubc.ca/livewelllearnwell.

Academic honesty and collaboration guidelines

The department has a detailed policy regarding collaboration and plagiarism. You must familiarize yourself with this policy.