CSE 561 Syllabus

CSE Home

About Us

Search

Contact Info

Discussion board: Here

Textbook: Peterson and Davie, Computer Networks: A Systems Approach, 3rd Edition.

Anonymous Feedback: anonymous feedback form

Schedule and Reading List: Below.

Project Webpage: Here

Overview: This course is on how to design (good) computer network protocols.

While it is relatively easy to learn how a specific network protocol works, it is incredibly hard to design a good network protocol. The Internet is a great example -- one can learn most of the aspects of how the Internet protocols work in a relatively short period of time, but that won't help you (much) in designing a new protocol. The Internet is successful for reasons that are mostly hidden in its design, embodying specific, debatable tradeoffs in balancing robustness, interoperability, scale, evolution, flexibility, operator incentives and security. And while you might think that we don't need any new protocols beyond the Internet, industry is developing new protocols all the time, often quite poorly. As a recent example, one need look no farther than 802.11 (WiFi) -- it has fundamental flaws in security, resource allocation, scalability and management. Added to the fact that the Internet itself is poorly designed for many of these same issues, the need for understanding how to design better protocols has never been greater.

Project: The best way to learn how to design protocols is by practice, and so the core of the course is a substantial protocol design project: to build a wireless ad hoc network using software programmable radios. The project is designed to be done in groups of two to three. We will be setting up a lab in Sieg 324 for the class to use.

Phases:

1. Design and implement a simple but robust connection setup/teardown and sliding window protocol, capable of achieving the full bandwidth of a link despite (a variable amount of) bit errors, as one might find in a wireless network. Demonstrate that your solution works (e.g., with simulated errors). Due: October 12 at 5pm.
2. Design and implement a simple but robust physical layer for a wireless link capable of achieving the full bandwidth of a channel with variable SNR and clock skew. We will provide you a baseline implementation that works in the absence of noise and skew. Demonstrate that your solution works with the software radio hardware, using your solution to Assignment #1 for transport. Due: November 13 at 5pm.
3. For assignments #1 and #2, you could assume that the network consisted of a single link, and the two endpoints of the link are the only users in the system. For assignment #3, we remove those assumptions. First, design and implement a simple but robust routing algorithm for a multihop network that delivers a packet whenever a working path exists in the network for a sufficiently long period of time. Second, design and implement a simple but robust congestion control system that achieves the full bandwidth of the network and avoids starvation for any user, for a variable number of users sharing the multihop network. Demonstrate that your solution works. Due: December 7 at noon.
   Project demonstrations will be conducted during the afternoon of December 7.
4. Make your system interoperate with every other project in the class.

Problem Sets: There will be two relatively short problem sets to test your understanding of the material in the textbook.

Final: There will be a comprehensive, open book final in class on December 10, 8:30-10:30.

Collaboration/Cheating: In my view, students learn more from each other than they do from the faculty. Thus, I encourage you to collaborate with your classmates, including those from other groups, in all aspects of the course, with two exceptions outlined below. The grading in the class is emphatically not curved; I would like nothing better than for all of you to pass.

To draw a very clear line, you may use any idea or code from any other person or group in the class or out, provided you clearly state what you have borrowed and from whom. If you do not provide a citation -- that is, you turn other people's work in as your own -- that's cheating. Anything else is fair game. Of course, we'll be grading you on the ideas you've added, but you should always borrow as much as you can as a starting point - there's no point in reinventing the wheel.

The exceptions are the problem sets and of course the final. You may consult your peers in doing the problem sets, but the writeup of your answers must be done individually.

Readings: The reading list is a mixture of textbook material and research papers. The textbook material is designed to help you understand the basics of the project; the research papers are to bring you to the state of the art. It is a requirement that you do the reading before class, as we will take the research papers as a starting point, not the end point of the class discussion. A goal for each class meeting will be to identify the limits of the research community's knowledge - what are the open research problems for that topic? An illustration of how little we really know about network protocol design is that we will be able to do this even for the most basic of topics. I will attempt to set the stage for the reading by discussing the problems being tackled by the next set of papers at the end of the previous class.

Discussion and Blogs: While I will do some lecturing, most of each class will be taken up with a free form discussion of the papers. For each paper, I'll appoint two people: an advocate and a skeptic, each to speak for 2-3 minutes about the paper. The advocate gives the elevator pitch for the paper: what is the topic of the paper, what are its main results, why the system or idea is better than its competition, why does the result matter and who are the target users. Note that the answers to these questions may be different from the ones the authors gave in the paper! The skeptic speaks on why the conclusions of the paper are not to be trusted. Everyone else (except these two) are to read each paper and blog a unique comment about the paper to the course web site no later than 9:00am on the day of the class. (This is to give time for everyone to read the blog entries before class.) Note that the earlier you post, the easier it is to be unique. Please keep blog entries short: they can be anything that provides insight into the paper, e.g., a summary, the broader context for the work, a question about some aspect of the paper, an answer to someone else's question, a methodogical flaw, or a pointer to related work not described by the paper.

Grading: Blogs/Class Discussion: 20%; Project: 40%; Problem Sets: 10%; Final: 30%.

	Computer Science & Engineering University of Washington Box 352350 Seattle, WA  98195-2350 (206) 543-1695 voice, (206) 543-2969 FAX [comments to dhalperi]