COMS W6998: NETWORK SYSTEMS DESIGN AND IMPLEMENTATION
Spring 2010


HOME

ANNOUNCEMENTS

SYLLABUS

PROJECTS

GRADES

PAPERS

RESOURCES

C Programming

Linux

VMWare


Potential Class Projects

Class projects involve evaluating, extending, and/or improving a subsystem in the Linux kernel related to networking. Class projects can be designed by students but require a proposal by the student and approval by the instructor. Here are some potential ideas:
  • Zen and KVM are competing linux-based hypervisors.
    • Describe how each handles networking
    • Compare their performance using a networking benchmark. Which is better?
    • Use a profiling tool to determine why.
  • Netfilter is known to scale poorly with large numbers of rules and has a clunky syntax.
    • Change the implementation to scale better while keeping the current design and API.
    • Change the design and corresponding implementation to make netfilter scale better.
    • Change the design to make rule construction simpler/more robust/more expressive
    • Compare/contrast with nftables (design and performance)
  • Networked systems are difficult to get right due to the large number of rare events (e.g., network failures) it must correctly handle. Develop a tool based on MoDist to effectively find errors in networked systems in Linux.
  • Dropbox is an online service to provide backup, sharing, and synchronization for files. Develop a similar open-source service in Linux. Fak3r shows how to do this using inotify, lsync, and rsync.
    • Extend the Fak3r approach to handle revisions, which Dropbox does but Fak3r doesn't.
    • The Fak3r approach has the problem that inotify triggers a full rsync over the whole directory tree. Build an in-kernel equivalent that is smart enough just to send the modified bits (this starts looking like a networked storage project)
    • Turn the Fak3r implementation running as a full fledged service for the CS department. Include nice packaging and test cases. The faculty will thank you.
  • Researchers have tended to invent and re-invent user level network protocol stacks from time to time to enable research and ease experimentation.
    • Port the linux stack to user space.
    • How does it perform? How could it be improved?
    • What are the advantages /disadvantages?
  • rbridges is the IETF TRILL working group approach to scalable data center networking. No operating system yet supports this, although switch vendors and Sun are working on it. Add TRILL to Linux.
  • There are several places to look for networking TODO lists. One such place is run by the Linux Foundation. Another older one is run by Dave Miller, including the famous "putting the sk_buff on a diet" list. He also has a blog with ideas.
    • Identify a project from the above and implement it.
    • Evaluate using microbenchmarks whether it makes a difference
    • Submit your patch to netdev
    • Get your patch accepted into a tree.
  • Qdisc only shapes outgoing traffic.
    • Modify qdisc to shape traffic in both directions.
    • Modify emnet to support your qdisc changes
  • There are two socket structures in the kernel, struct sock and struct socket
    • Unify them.
    • Evaluate if it makes any difference performance wise. If so, why, if not why not.
    • Submit your patch to netdev
    • Get your patch accepted into a tree.
  • SCTP is held up as a more efficient protocol than TCP. Test this assertion.
    • Compare their performance using a networking benchmark. Which is better?
    • Use a profiling tool to determine why.
    • How much of the performance is protocol-specific and how much is implementation specific?
  • The device structure has a comment: "This whole structure is a big mistake. FIXME: cleanup struct net_device such that network protocol info moves out" Make it happen.
  • A naive network adapter generates an interrupt for each received packet, which is both expensive and inefficient. NAPI (Original 2001 Paper, 2009 Linux Foundation Overview), is a new API for polling a networking adapter to retrieve packets in batches rather than being interrupted for each packet. Some potential NAP projects would be:
    • NAPI has a relatively coarse-grained decision process about when to disable and re-enable interrupts. This can cause latency problems under low load. Come up with something more adaptive with load, preferably using control theory.
    • Is there anything different about interrupts in virtualized environments like KVM or Xen that warrants a different approach?