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 Bern, Switzerland.

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.

Timeline

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 grade.

A URL for the presentation sign-up sheet (in Google Docs) is available on Piazza.

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 me.

Project Suggestions

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 projects.

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 machines.

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.

Other suggestions

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 [validate xhtml]