CSC2229 - Final Project

Final Project Guidelines and Schedule

Final projects are completed by groups of preferably 3 students. For each deliverable step, a single file (pdf only) should be submitted electronically to the instructor’s e-mail address. If the project involves any simulation, data analysis, … all the necessary files must be uploaded to a web page, and the link should be sent in the same e-mail as the pdf file. In all deliverables, please make sure that all the pages (and especially the figures) can be viewed properly in acrobat reader, and the document is printed properly.

• Project proposal (2 pages)
  • Due: 5pm Fri. Oct. 9th.
  • Check out the list of suggested topics.
  • For each topic, I have included a brief description. This is not meant to be a complete description of the project, and is just a starting point for you to explore. Feel free to stop by my office hours and I can give you more specific problems related to the area.
  • You are also welcome to come up with your own project topic.
  • You are highly encouraged to meet with the instructor and discuss your ideas before submitting your proposal.
  • Should include names of students, indicate who will work on what part, identify the project deliverable, what is the schedule/timetable of work.
• Intermediate report (5 pages max)
  • Due: 5pm Fri. Nov. 13th.
  • The following should be the same as the final report:
    • Table of contents
    • Introduction/background/references
    • Should have placeholder for final results and conclusions.
  • Should Include: table of contents of final Report, background and motivation; problem statement; who did what so far; remaining work for rest of semester.
• Final presentation
  • All presentations in class on the last day of classes.
  • 25 minute presentation of project results.
• Final report (8 pages max)
  • Due: Noon Fri. Dec. 11th.

Suggested Topics

You can choose any project related to software defined networking. Here is a list of example topics that can serve as a starting point in this process. The list, and the project descriptions are not meant to be comprehensive. You are highly encouraged to consult with the instructor before selecting the final project topic.

1. Reproducing Network Experiments. The objective of this project is to reproduce the results of an interesting research paper (chosen from SIGCOMM, NSDI, and HotSDN) using MiniNet. This was a very interesting initiative from Stanford University and you can find more information about it here. The final results will be shared with the community.

2. Comparing SDN Controllers. There are a number of SDN controllers available. The objective of this project is to compare and evaluate distributed SDN controllers. For centralized controllers there are straight-forward metrics, but those metrics might need to be adjusted to have a fair comparison of controllers. This project will shed some light on what those metrics should be, followed by real system evaluations for two or more distributed controllers.

3. Control Application Migration Distributed SDN controllers can move controller applications depending on network load, and performance requirements. The objective of this project is to study and compare various migration algorithms in a distributed controller.

4. Complexity of Controllers. The objective of this project is to compare various SDN controllers in terms of their complexity. The project will first define appropriate metrics, and then use various case studies to show how those metrics can be used to compare existing controllers.

5. Home Networking. An interesting application of software defined networking is home networks. By moving the control and management functionalities of a home switch to a remote host, we can delegate those to the Internet service provider (as a paid service, for instance). This would simplify the process from a user’s perspective. Also, we can provide novel services that are not feasible in today’s home networks. The objective of this project is to study the performance of an OpenFlow-based home network, find potential bottlenecks, and when possible to present ideas/solutions to eliminate those bottleneck. Adding novel services (such at troubleshooting, device management, …) is another interesting direction for this project.

6. Tuning Network Applications using Machine Learning. Network applications usually rely on various parameters defined by the developer. These parameters have a significant impact on the application’s behavior and performance. The objective of this project is to use Machine Learning techniques to optimize a well-chosen network application based on various real/realistic input loads.

7. Debugging in SDNs. We have very limited debugging tools in traditional networks. Given the global view available in SDNs, one might wonder whether we can create a better debugging infrastructure/system. The objective of this project is to explore possible solutions here.

8. Packet Size Variance. Consider a group of flows going through a given switch. We can classify these flows based on their average packet size, and packet size variance (as well as average rate and rate variance). For example, a vide stream may use constant rate (and fixed packet sizes) during short intervals, but change the rate (and packet size) occasionally to match the available bandwidth. Others flows might have different packets sizes during any given interval (e.g. a web browser connection which may fetch small or large objects, while waiting for user input in between). Here, we assume the switch can send samples of packets to the controller. The objective is to design a sampling mechanism as well as a control application that can provide good estimates for packet size average, and variances.

9. Flow Type Classification. Consider a classification application that has access to samples of packets. Can this application classify network traffic if it has access to only the header (and probably a small fraction of the payload, say a few bytes) of sampled packets?

Final Presentation Instructions

• Although each talk is given 25 mins, the talk should last only 20 mins. The remaining 5 mins would be for questions. The 25 minute limit will be strictly imposed without exception.
• You can bring your own laptop for presentation, or you can send me the powerpoint files before 9am on the day of presentation.

Presentation Guidelines (from Stanford’s EE384xy):

Giving an effective technical presentation requires a lot of preparation and practice. For example, in preparation for a 15 minute conference talk, it’s quite common for a researcher to spend several days preparing, and give several practice talks along the way. Here are some guidelines to follow while preparing your presentation.

1. In the beginning, forget the slides.

   The most common mistake in giving a talk is to focus too much attention on the preparation of your slides. Remember that the talk is what comes out of the speaker’s mouth, not the slides. Resist the temptation to spend all your preparation time working on pretty powerpoint slides. Instead, prepare the outline and script of your talk first, and only then think about how slides might help to illustrate some of the key points you are trying to make. A good rule of thumb is to spend 75% of the preparation time on your outline and script, and 25% of the time preparing slides. Remember that the world’s best orators give great talks without slides!

2. Write a 1-paragraph abstract that summarizes your talk.

   Before you start preparing the outline and details, write down a brief abstract. It’s worth spending some time on it. (For what it’s worth, even though I’ve given hundreds of talks and lectures, I still do this before every talk and lecture I prepare).

   Try to write, in the most concise and clear way, a brief summary of the talk. What problem are you solving, and why is it interesting? What is the context in which you are doing the work? What is the essence of your work, and your results? What is the “ah hah!” factor —- what do you want your audience to take away from the talk? If you can’t write a 1-paragraph summary, it tells you that you don’t have a clear idea of what the talk is about. Once you have a good paragraph written, you can be sure that the talk will be a lot easier to prepare.

3. Prepare a bulleted outline of the whole talk.

   Prepare an outline - perhaps in the form of 30-40 bullets - that shows the flow of the whole talk. This will help identify missing or redundant sections; and will help balance the amount of information you include in each part of the talk. It is often tempting to spend too much on one, unimportant detail, leaving too little time for the important stuff.

4. Script the whole talk, and learn it.

   Yes - I mean it. Write down, word for word, your whole talk. You’d be amazed at how many people do this — even skilled speakers who give talks often. If the President can give speeches from a teleprompter, it tells you something about what makes a good talk. In many fields of the humanities, researchers read all their talks from a script.

   The trick is to script the whole talk, read it aloud many times and then learn it. Then the day before your talk, throw away your script. You’ll remember the key sentences and points, and by not reading it you’ll make it sound more natural. Having a script will make your talk get off on the right foot, and help overcome nervousness. Perhaps most importantly, a script will help you avoid missing out some important points, and will help you make best use of the small amount of time you have.

5. Pick/design some slides to illustrate key ideas.

   Think about what slides you need to illustrate your script. Your slides do not have to paint a complete picture on their own. It is a common misconception that the slides should be readable and meaningful without the speaker. This is baloney. If this were true, we wouldn’t need the speaker! Think of them as illustrative tools, to help explain key ideas. It is not a good idea to use them to jog your memory; that is what your own notes are for.

6. Practice the talk with the script several times.

7. Throw away the script.

   Once you have practiced the scripted talk a few times, throw your script away. You will remember the key phrases; and in the moment, you will link it together more naturally than you would by reading it.

8. Give the presentation.

   If all this seems like a lot of work, it is. Giving a good talk involves many hours of preparation.