|
CSE 561 Syllabus |
|
 CSE Home |
About Us |
Search |
Contact Info |
Final Exam and Presentations: The final exam will be due Friday,
March 16th by email to Tom.
Presentations will be Monday, March 12th in Sieg 327 from 3-5pm.
Textbook: Peterson and Davie, Computer Networks: A Systems Approach, 3rd Edition.
Discussion Board: (UW NetID protected)
Project Webpage: http://www.cs.washington.edu/education/courses/cse561/CurrentQtr/project.html
Project Writeups: http://www.cs.washington.edu/education/courses/cse561/CurrentQtr/projects/
USRP Reservations: http://reserve.cs.washington.edu/visitor/day.php?area=134 (CSE NetID)
Anonymous Feedback anonymous feedback form
Schedule and Reading List: Below.
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 three to four. The project has phases that can be worked on independently, but ultimately, the phases must work together; even better if your project interoperates with the projects of other groups. We will be setting up a lab in Sieg 327 for the class to use.
Phases:
The phases are due at 4:30pm on Feb. 2, Feb. 16, and March 9, respectively. We will conduct an end of project interview with each group, late afternoon on March 9, to give you a chance to demonstrate your solution in its entirety.
For the first phase of the project, you may find the following references useful; there will be a copy on reserve at the engineering library and in CSE 391:
Collaboration/Cheating: Another observation guiding the design of this course is that students typically 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 only one exception 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 one exception is that there will be an open book, take home final; the final is to be done individually without consultation with anyone else.
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.
Discussion and Blogs: 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 reading the paper was a waste of time or that the conclusion is the opposite of that claimed in the paper. 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 10:30am 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.
Final: A take home final will be handed out at 4:30pm on March 9, and will be due back at 4:30pm on March 14. The final will consist of a single network protocol design question, as a capstone to the topics covered in the course. So that students don't take the entire final exam period working on it, the exam is designed to take a day to think about and no more than two hours to write. Students may take any contiguous 48 hour period during that period of the 9th - 14th to work on the final, on the honor system.
Grading: Blogs/Class Discussion: 20%; Project: 40%; Final: 40%.
 |
Computer Science & Engineering University of Washington Box 352350 Seattle, WA 98195-2350 (206) 543-1695 voice, (206) 543-2969 FAX [comments to dhalperi] |