Course overview

Welcome! This is a first-day-of-class overview of the winter 2023 edition of CSE290S (“Distributed Software Systems: Global-First and Local-First Perspectives”), a graduate seminar course in the Computer Science and Engineering Department at the UC Santa Cruz Baskin School of Engineering.

Instructor

Lindsey Kuper

Hi, I’m Lindsey Kuper! (Feel free to call me by my first name.)

  • Email: for anything CSE290S-related, send a PM on the course Zulip instead. Otherwise: lkuper@ucsc.edu
  • Office location: Engineering 2, Room 349B
  • Office hours: By appointment (PM me on Zulip and we’ll find a time)
  • Research areas: programming languages, distributed systems, software verification, parallelism and concurrency (see my website for more information)
  • http://pronoun.is/she

A few essential details about the course

  • 5-unit graduate seminar course (in this context, “seminar” means a course where we discuss assigned readings and everyone participates actively in the discussion)
  • Class meets Mondays, Wednesdays, and Fridays, 1:20-2:25pm Pacific time, in Social Sciences 2, Room 141
  • Most class meetings will be in person, but some will be remote (see the schedule)
  • Canvas (for reading responses and grades): https://canvas.ucsc.edu/courses/59630
  • Zulip (private; for announcements, asynchronous discussions, and socializing): https://ucsc-cse290s.zulipchat.com (all enrolled students will receive an invitation by email)
  • Course web page (you’re soaking in it): https://decomposition.al/CSE290S-2023-01/ (URLs are case-sensitive after the domain name, so be sure to capitalize “CSE”)

What’s this course?

This course is a graduate research seminar covering emerging topics in distributed software systems. It’ll be a reading-heavy and writing-heavy course: much of your time will be spent reading, responding to, and discussing research papers. You will also be expected to carry out an independent research project of your own choosing that somehow fits with the course theme. The schedule has more details on what we’ll be reading and discussing.

Background you’ll need

This course has no official prerequisites, but it isn’t an introductory course. I strongly recommend that you are familiar with the material covered in the UCSC graduate programming languages (PL) course, CSE210A (see, for example, Cormac Flanagan’s winter 2022 offering), and the UCSC graduate distributed systems course, CSE232 (see, for example, my fall 2021 offering).

Many of the papers we read will be PL papers. There’s a high notational overhead in many PL papers, and there are a few standard concepts you’ll want to be familiar with. At a minimum, you should be familiar with the concepts in Jeremy Siek’s “Crash Course on Notation in Programming Language Theory”. Take some time to read it and brush up on anything you’re not familiar with already. If you’re not familiar with operational semantics of programming languages (or maybe even if you are), watch David Van Horn’s excellent 45-minute tutorial video. Ask questions early when you come across notation you don’t understand in this course – if you’re confused, you’re probably not the only one.

For distributed systems background, you might want to check out the lecture videos from my undergrad distributed systems course, CSE138. I don’t publish official lecture notes, but a web search for “CSE138 lecture notes” will turn up lots of unofficial ones.

Reading and responding to research papers

One goal of this course is to equip you to conduct research on emerging topics in distributed software systems by absorbing a lot of relevant papers. One of the best ways to absorb reading material is to write about what you read, so each student in the course will write a short response to each reading.

Reading research papers is a skill that requires a great deal of practice. In this class, you will work on developing that skill. You will need to finish each reading assignment in advance of the day we discuss it in class. In fact, you will need to turn in a reading response by 5pm Pacific time on the day before the day we discuss it in class.

Some advice on how to read papers

Attempting to plow right through a paper from beginning to end is usually not the most productive approach. Here’s some great advice from Manuel Blum on how to read and study:

Books are not scrolls.
Scrolls must be read like the Torah from one end to the other.
Books are random access – a great innovation over scrolls.
Make use of this innovation! Do NOT feel obliged to read a book from beginning to end.
Permit yourself to open a book and start reading from anywhere.
In the case of mathematics or physics or anything especially hard, try to find something
anything that you can understand.
Read what you can.
Write in the margins. (You know how useful that can be.)
Next time you come back to that book, you’ll be able to read more.
You can gradually learn extraordinarily hard things this way.

You may also be interested in time-tested paper-reading advice from Michael Mitzenmacher and from S. Keshav.

What to include in your reading response

For each paper we read, you will submit a short reading response. The reading response process is designed to help you develop the skill of asking good questions about the readings. You should include the following in your reading response:

  • Paper Summary: Using only your own words, write an overview of the paper that can serve as an explanation of the paper for your classmates. Your summary should answer the following questions: What problem does the paper address (1-2 sentences)? What are the paper’s key insights (1-2 sentences)? What are the paper’s key scientific and technical contributions (2-3 sentences)? What are its shortcomings or flaws (up to 3 sentences)? (These guidelines for summarizing a paper are taken from the ASPLOS 2021 review process, with thanks to Emery Berger.)
  • Discussion questions: Please suggest 1-2 questions about the reading for our in-class discussion. These must be questions whose answers do not appear verbatim in the paper. Instead, try to go deeper. Keep in mind that you may need several sentences just to provide sufficient context for a question. For example, if a question has to do with how the paper’s topic relates to other work you were previously familiar with, you’ll need to summarize the relevant part of that other work as part of the question. Furthermore, your questions must be unique (after you submit, you’ll get to see other people’s submitted questions).

(By the way, the summary I’m asking you to write does not, by itself, comprise a review of the paper, like those you would write if you were serving on a conference program committee. A review is much longer and more detailed, and would, among other things, make a case for acceptance or rejection of the paper.)

How to write discussion questions

A good discussion question should be specific to the paper and offer enough detail and context to be understandable by your classmates, i.e., people who have read the paper but may not have internalized every detail.

Here are two examples of good discussion questions written by former students in my graduate distributed systems class (which is a different class, but which has similar expectations to this one regarding reading and responding to papers). In each case, the question begins with a sentence of contextual information from the paper, and then follows that up with a question.

  • “Chain replication improves on primary-backup replication by splitting the read and write responsibility amongst two nodes. Would this be sufficient for an unpredictable workload? Under what circumstances would you choose primary-backup replication over CR?” (for “Chain Replication for Supporting High Throughput and Availability”; discussion question contributed by Meghna Burli)

  • “The paper mentions at the end of section 5.2 that changing masters in networks with poor connectivity is undesirable and boosting sequence numbers with the “right” frequency should help avoid this. How exactly does a master prevent the cycle of changes of masters, using boosting?” (for “Paxos Made Live: An Engineering Perspective”; discussion question contributed by Ramtin Roshanmanesh)

Here are two examples of how not to write a discussion question:

Reading response submission logistics

Reading responses are due at 10pm Pacific time on the day before we discuss the reading in class. The reason for this relatively early deadline is to give me time to look at the responses before class, so that I can structure the in-class discussion based on them. Don’t be surprised if you see some of your questions used in the in-class discussions!

You will submit your reading response on Canvas, in the discussion forums set up for each paper. Once you submit, you’ll get to see other people’s submissions. After submitting, take a look at the other submissions to make sure that your questions aren’t a repeat (or very close to a repeat) of any already-submitted questions. In that case, you should edit your questions to make them clearly distinct from the previously-submitted ones. It is to your advantage to turn in your reading response relatively early, because the earlier you turn it in, the less likely it is that your questions will be a repeat of any previously-submitted questions!

Free pass policy: Because life throws unexpected challenges at each of us, you get three “free passes” to use during the quarter. Using a free pass exempts you from having to submit a response for a reading. If you want to use one of your three free passes, just don’t submit a response – no need to email me.

In-class discussion process

In class, we’ll use a structured small-group in-class discussion process. The process we will use is loosely inspired by one used by Matthew Ahrens, Kathleen Fisher, and Norman Ramsey in courses taught at Tufts University, and the below description borrows from their documentation, with their permission.

You’ll come to class having read and responded to a reading assignment. When you arrive in class, after 5 minutes or so of getting settled, announcements, etc., you’ll spend 30 minutes of class in a randomly assigned small group of 3-4 students, discussing specific questions about the reading. Some people will like this format, while others won’t like it at all – so give some thought to whether it is what you want before you commit to taking this course. (In particular, if you want to take a course where one person gives a slide presentation while others listen silently, that’s not what this course will be.)

Small-group discussion (30 minutes)

The small-group discussion will use the following process:

  1. Each member of the group should introduce themselves.
  2. The group should discuss answers to the provided questions about the reading assignment. On each discussion day, I’ll provide a short list of discussion questions, many of which will be drawn from the reading responses that you and your classmates submitted previously. During the discussion phase, feel free to work together in a shared document and use any resources you like. This is a “brainstorming” phase. Don’t stop with a single answer; look at things from all angles.
  3. The group should try to reach consensus on the most satisfying answers. Perhaps the group will agree on answers that satisfy everyone. Perhaps there will be significant dissent – maybe even no majority view.
  4. The group should prepare to report verbally to the class as a whole. Your report should cover the following points:
    • The preferred answers according to the consensus reached by your group.
    • The reasons that you prefer these answers.
    • Any significant minority views.
    • A few words about answers that your group considered but ultimately rejected.

Large-group discussion (30 minutes)

After 30 minutes, small groups will conclude, and the entire group will reconvene for 30 minutes for a discussion that I’ll moderate. During this time, individual groups will present their groups’ conclusions.

In the large-group discussion, we’ll discuss and evaluate the groups’ conclusions and try to forge a coherent consensus view that the whole class can agree on, but also be alert for gaps, inconsistencies, and incoherence. When possible, I’ll compare the conclusions reached by the class with my interpretation of the consensus position of the body of researchers interested in the topics under discussion.

Course project

Every participant in the course will carry out an independent project. A project requires substantial work (some combination of reading, writing, editing, programming, debugging, and thinking). Expect to spend about 30-40 hours of focused work on the project over the course of the quarter. (Warning: aim low. 30-40 hours isn’t actually that much time.)

Below is a non-exhaustive list of options for your independent project.

Project idea: The research investigation

Dig into one of the research questions that you identify while writing your responses to the readings.

Carry out one of the concrete steps toward answering it (which might involve writing code, measuring performance, writing proofs, and/or something else), and write about what you learn.

Negative or inconclusive results are fine!

Project idea: The literature survey

Choose several (at least five, but possibly many more) related readings that have something to do with the topic of the course, read them thoroughly, and write a survey paper analyzing them.

At most one of your selected readings should be one we’re already covering in class. The idea is to use something we read in class as a jumping-off point to go off on your own, explore the literature on a specific topic, and come back with new insights.

Some good sources of papers for a literature survey include the related work sections of papers we read for class.

Project idea: The experience report

Try out one or more of the systems discussed in the readings, and report on your experience.

For this kind of project, you should expect to write code. Aim higher than just “I got it to compile and run” – ideally, you’ll use the system to accomplish something cool, and report on what worked and what didn’t.

In many cases, it will be appropriate to try to reimplement (a perhaps minimal version of) a system from a paper we read, and reproduce the reported results.

Project time frame

  • Friday, February 10 EOD: Project proposals due. Submit an informal two-page writeup of the project you intend to do. You are encouraged to come talk to me about your project idea beforehand.
  • Monday, March 6-Friday March 10: Project status update week. Make a half-hour appointment to meet with me and show me what you’ve done on your project so far. No need to write anything up. Look at this as an opportunity to course-correct if your project is going sideways.
  • Wednesday, March 22, noon-3pm: In-class project presentations. Give a polished 10-minute presentation to the class about your work.
  • Friday, March 24, noon: Project reports due. Submit an 8-12 page writeup of your project (the most appropriate length will vary, depending on the project). You should be concerned about writing well; making your report a pleasure to read should be a priority.

Grading

  • Written responses to readings: 45%
  • Participation in class discussions: 20%
  • Course project (includes project proposal, status update (i.e., you showed up and made an effort), in-class project presentation, and project report): 35%

As you can see, participation is an important part of your grade – so make an effort to come to class.

If you must miss class on a given day, you can make up for it somewhat by reading your classmates’ responses to that day’s reading and leaving thoughtful comments on Canvas. (This shouldn’t be necessary if you attend class, though.)

Needless to say, the above grading approach assumes no violations of academic integrity.

Academic integrity

Everything you write for this course must be your own original work. It is a very important part of your job as a scholar to understand what counts as plagiarism, and make sure you avoid it. Here’s a handy flowchart that you should internalize.

Properly attribute any work that you use. If you use someone else’s words, you must quote and cite them. The only time you can leave out the citation is if it’s obvious from context. For example, if you’re turning in a reading response for a given paper, you don’t have to cite the paper you’re responding to, but you definitely do have to quote any text from the paper that you use.

Many of the papers we’re reading are classics, and much has been written and said about them. It’s absolutely fine to consult existing videos, blogs, etc. to check your understanding, but using other people’s words without appropriately citing and quoting them is unacceptable. I would much rather have you submit your own writing, even if it is not perfect, and even if you need to turn it in a little late. I can offer flexibility on deadlines, but violations of academic integrity are never acceptable.

If I see that the writing you do for this course contains material that is copied from a source without appropriate citation and quotation, at a minimum, you will get no credit for the assignment in question, and you risk further penalties, such as failing the course.

A note on accessibility

If you have a disability and you require accommodations to achieve equal access in this course, please submit your Accommodation Authorization Letter from the Disability Resource Center (DRC) to me by email, preferably within the first two weeks of the quarter. I am eager to discuss ways we can ensure your full participation in the course.

I encourage all students who may benefit from learning more about DRC services to contact the DRC.