527, Fall 2015, Ivan Beschastnikh (email@example.com)
Tues/Thur 3:30-5:00PM, ICCS 206, UBC course page
Office hours by appointment
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
Course-level learning goals
The course will provide an opportunity for participants to
- 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
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)
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 firstname.lastname@example.org 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
- 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
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.
List of questions to help you write you review.
- Why was the paper written? What problem does it solve? Does it
completely solve the problem; under what circumstances? Why is the
- 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
- 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
- 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
- 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.
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
- 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
- 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
- This is a computer networks course, so make sure that your
proposal is focused on issues/challenges/objectives relevant to this
- 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
- 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
- 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
Final report advice
The 10 pages should include title page and appendixes. I prefer that
you style your paper
- Your report should have all of the essential sections that a research paper
- 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
- 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
- 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
- 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
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
- You have just 5 minutes, I expect those 5 minutes to be polished:
- Practice your talk. Many, many times. After all, it's so
- 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
- 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
- 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.
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
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,
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,
Academic honesty and collaboration guidelines
The department has a detailed policy
and plagiarism. You must familiarize yourself with this policy.