Overview

The default form for a project is as a research proposal of 10 to 15 pages. It should include a survey of the relevant literature, identification and justification for one or more research projects that should be undertaken, and a discussion of the expected contributions that might be made should the research project be successful. Providing a practical component, such as a simulation study or a prototype implementation/experimentation is a big plus.

Draft Project Timeline

• October 10 Draft Project Proposal Due
• October 17 Revised Project Proposal Due
• December 5 Final Project Report Due

Proposal Format

Write a 2-3 page proposal that describes:

1. The problem you plan to study
   • Be specific!!!
2. Why you think it's important
   • You should want to read this paper because...
3. Related work you have found so far
4. What you plan to do including:
   1. Specific milestones you will achieve; these serve as a baseline -- something that is evaluate-able, but not very impressive.
   2. Specific milestones you plan to achieve
   3. Specific milestones you could achieve if things go incredibly well and you find yourselves ahead of schedule; this is the list of cool things you could do building on the accomplishments of a + b.

Examples of specific milestones include: do a thorough literature survey of the problem, write code implementing A,B,C; run experiments X,Y,Z to measure 1,2,3; or analyze/prove the performance of system XX.

Sample Project Topics

You can either select a topic from the list below, or come up with your own.

• Placement and factoring of software defined networking control logic
• Applications of software defined networking to network management, monitoring, security, etc.
• SDN/NFV architectures, applications, and use cases
• Programming languages, verification techniques, and tools for software defined networks
• SDN/NFV-based service orchestration
• SDN in Mobile and Wireless Networks

Sample Project Ideas

• Application Aware Networking: The SDN controller can monitor traffic generated from an application and then configure the network to provide proper QoS to the application (e.g., MapReduce, video streaming, etc.). The controller can collect information from the application in two ways: (i) consider the application as a black box - only look at the traffic generated so far and then predict future requirements, (ii) the application can have an embedded client that communicates with the SDN controller to tell it about its requirements.
• Conducting experiments with DOT (dothub.org):Try to reproduce results reported in SDN related papers in DOT. Then go one step further by conducting the same experiments at a larger scale. The website REPRODUCING NETWORK RESEARCH provides the source codes for some works reproduced in Mininet. Your task will be to do the same in DOT and then push to larger scale experiments. The objective is to test the scalability of DOT, Mininet and the work itself. You can choose the papers yourself or pick from the following list:
  • FlowVisor: A Network Virtualization Layer
  • DCell: a scalable and fault-tolerant network structure for data centers
  • Jellyfish: Networking data centers randomly
  • Hedera: Dynamic flow scheduling for data center networks
  • Trading a little bandwidth for ultra-low latency in the data center
  • Data Center TCP (DCTCP)
  • How hard can it be? designing and implementing a deployable multipath TCP
• Managing the Software in Software Defined Networks: SDN extracts the control logic from the switch hardware and places it on a general-purpose commodity server. One of the vision of SDN proponents is that this approach will promote an open market of controller applications similar to Apps on Apple App Store or Google Play Store. A very interesting research challenge is to explore the issues involved in managing the different software components in SDN and then compare/contrast them to the way similar components (software running on dedicated hardware) are currently managed.
• Inter-Controller Communication: In a multi controller deployment scenario the controllers need to communicate with each other to maintain a global view of the network. The controllers can exchange information through a central relay point or in a purely distributed manner or some other mechanism. The data consistency model can also differ (strong, weak or eventual) depending on the situation. The project can analyze the different mechanisms and propose selection criteria for each model.