CSE 222A Term Project
The centerpiece of CSE222A is the term project, which culminates in
a workshop-quality paper and a public presentation. You are
encouraged to think carefully about the project topic and scope, as I
expect that a number of the projects, with some amount of extra
polishing and follow-up work, will be submittable to a high-quality
venue. Indeed, students with successful projects from the most recent
CSE222A offering earned all-expense-paid trips to present their work
at international conferences in places like Austin, Texas, and
Of course, time is limited. The key to a successful project is to
carefully lay out a plan of action so that some significant
portion---but frequently far from all---of it can be completed in time
to write up and present at the end of the term. Projects will be
graded in the same manner that conference papers are evaluated: we're
looking for interesting insights, clarity of presentation, and
appropriate positioning of your work within the framework of existing
research. From the point of view of the class, the goal of the
project is to give you first hand experience conducting research in
networking and exploring a topic that interests you in more detail
than we well in class.
Each project will be presented orally during the official final
exam period for the course (and possibly in additional sessions as
logistics require). Groups will also submit an 8-10 page research
report describing their efforts. All class members are required to
attend and evaluate their classmates presentations and papers.
Projects should be done in groups of two or three. Exceptions may occasionally be granted; please talk to the instructor.
To assist in the timely completion of the project, we have established the following checkpoints.
1/22: Each student is required to submit two or three brief (a
paragraph or two, maximum) project ideas by email to the TA. We will
then post the submitted ideas to the class through Piazza. Students
who have already formed (partial) project groups should submit a
single email naming each of the group members.
1/25: After consulting the project idea list and communicating
privately with other students, students are encouraged to form their
own project group. Each group should send email to the TA with the
members of the group and a brief description of the project idea(s).
2/05: Each group must submit a page-long project proposal. The proposal should contain four sections:
2/21: Each group will submit a 1-2 page summary of their progress. We will schedule meetings with each project group to discuss the status updates.
3/07: Submit a 1-2 page summary of your progress since the last
checkpoint. In particular, concisely describe the deliverables you
have completed, and provide a brief preview of what you expect to
present during the term project presentations.
3/19: All groups will give a 20-minute presentation, with an
additional 3-4 minutes afterwards for questions. All group members
are expected to participate in the presentation and answer questions.
In addition, students are expected to attend five presentations in
addition to their own and actively participate by asking questions
of the presenters. This will count toward your class participation
A URL for the presentation sign-up sheet (in Google Docs) is available
3/21: Final project reports are due by midnight. All groups
are expected to submit an 8-10 page project report in the format of
the papers we've read in class (i.e., double column, single spaced).
You are free to submit in another format, but it is likely the report
will be much longer in, e.g., single column double spaced. The report
should include references and citations to related work, as well as
graphs, figures, etc., documenting the performance of your software
prototype to the extent possible.
Please email your final report, along with either a tarball of or
pointers to (e.g., in github or similar) your code, to Siva and
- An introduction, providing a basic overview of the goal.
- Related work, which discusses the current state of the art that
you intend to build upon.
- A schedule, specifying concretely what you intend to have
accomplished by each of the two milestones below as well as for the
final report/presentation. It is perfectly acceptable if the final
deliverable is not a completion of the project---which, if successful,
some members of the group may wish to continue after the term
ends---but it does need to be something that can be clearly
- A description of any resources you believe you will need to
complete the assignment, such as access to testbeds, software,
hardware resources, etc. We expect most of you will be able to
complete your projects on resources already available to you, but if
you have some particular needs please call them out and we'll see what
we can do. Note that if the successful completion of your project
depends on these (as opposed to "it would be nice if") please make
sure you discuss this with Siva and/or the instructor before
Below is a list of potential project ideas. You are, however,
encouraged to come up with your own: the most successful projects will
be those that pursue topics of interest to the group members. You are
welcome to propose projects that are related to your research
area---even if that is not networking. Please feel free to ask us if
you're not sure whether something you're considering is appropriate.
Also, keep in mind the ideas below are just starting points: they each
need to be refined and focused. And project topics are not
exclusive--it is perfectly OK for multiple groups to work on similar
Fine-grained Datacenter timing measurements
Lots of studies have been published regarding traffic carried in
modern datacenters, but they tend to report on macroscopic features,
i.e., throughput, latency, etc., over periods of seconds of even
larger. Little information is available about smaller
timescales---i.e., on the order of microseconds. Yet researchers are
designing hybrid optical switching technologies that are hoping to
switch traffic on the order of 10s of microseconds or even faster. It is an open question how well these approaches might work in practice, as it depends critically on what traffic looks like at very fine timescales.
This project would collect very fine-grained measurements of real
datacenter-like applications running on actual hardware, and study how
that traffic behaves: is it stable over short timescales? Are packets
back-to-back or spaced out? Does traffic from different flows get
mixed together, or is it all in bursts of single flows?
Analysis of network failure data
My research group has collected several years worth of data regarding
the routing protocol behavior of the California academic and research
network. We previously published a study describing the failures we
observed using routers' syslog messages, and are currently exploring
how that matches up to the routing protocol messages. As a third
vantage point, however, we have also been conducting active probes of
the network on a periodic basis. We are interested to understand how
well these probes match up with the passive data, and, if there are
significant differences, what their causes might be.
Datacenter "AppStore" applications
My research group is currently exploring a new model for datacenter
network virtualization, where each tenant receives an isolated virtual
network, and can select from a variety of "apps" that define the
behavior of that network, ranging from its routing and forwarding
behavior, to its isolation model, to various middle-box
functionalities such as firewalls and performance-enhancing proxies.
We have a prototype system, called Blender, that defines an API for
writing such apps. This project would write one or more apps that
implemented interesting middle-box functionality, such as a WAN
performance optimizer. Such an app would likely be based on an
existing, publicly available implementation.
Evaluating OpenFlow controllers
Many recent research projects have implemented prototypes in OpenFlow,
in the form of increasingly sophisticated OpenFlow controllers. Due
to the centralized nature of OpenFlow, it is not immediately obvious
how such systems will scale as the size and complexity of the networks
being controlled increases. In order to evaluate the performance of
OpenFlow based networks, researchers at Stanford developed MiniNet.
Several class projects used MiniNet to replicate
published research results. One of the shortcomings of MiniNet,
however, is its inability to run on more than one machine, which
limits the size of the network one can emulate. To address this
shortcoming, my research group is developing an emulation environment
that can emulate larger networks and, eventually, across multiple
This project would demonstrate the utility of a multi-machine
emulation environment by benchmarking application configurations that
cannot be handled on MiniNet. In particular, a successful project
would show that a MiniNet-based network was either unable to run an
experiment at scale, or, more likely, leads to erroneous results when
compared to the same experiment run across a real network.
Conversely, the project would investigate whether the UCSD emulator
was able to provide more accurate results.
The previous offering of CSE222A has a long
list of project suggestions, some of which are no longer timely
(i.e., recent work may have rendered some of the suggestions less
interesting), but most would still make excellent starting points.
Last updated: Tue Mar 05 08:35:44 -0800 2013