|
CSE 561: Computer Communication and Networks (Graduate Networking) |
|
 CSE Home |
Previous Quarters |
About Us |
Search |
Contact Info |
|
|
CSE561 Autumn 2005When & where: Mondays and Wednesdays, 10:30am-11:50am, CSE 203 (status)
Instructor: Tom Anderson (mail)
TA: Pat Tressel (mail)
Required Textbook:
Peterson and Davie, Computer Networks: A Systems Approach,
3rd Ed. Prerequisites: Graduate standing in CSE or permission of the instructor. Mailing List: Please subscribe to the class mailing list. | ||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
OverviewThis 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. ProjectThe 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 sound waves as the means for communication. Ideally, we would use radio waves, but to date, WiFi systems lack the flexibility to be changed at a fundamental level. Essentially, a PC with a microphone and speaker can serve as a poor man's software radio. 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. You may use any available machine (e.g., in your offices) to run the project, but we will also try to have ones set up in the network lab for experimentation. Phase 1: Design and implement (efficient) reliable communication between two PCs using a microphone and speaker. Phase 2: Design and implement robust ad hoc routing between a set of PCs using sound as their only means of communication. Phase 3: Design and implement (efficient, fair, etc.) resource control (that is, sound control) among a set of PCs using sound as their only means of communication. You may do the phases in any order, but at least one of the phases must be turned in by 5pm on each of the following dates: Nov. 3, Nov. 17, and Dec. 12. For the first two turn-ins, send your (working) code and a 3-5 page high-level description of what you did. We will conduct an end of project interview in the late afternoon on Dec. 12 to give you a chance to demonstrate your solution in its entirety. CollaborationAnother 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. However, collaboration should not extend into plagarism. 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, if 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 theres 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. ReadingsThe 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. 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. 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 the paper and blog a unique comment, question about some aspect of the paper, or answer to someone else's question, by 9:30am on the day of the class. Please keep these blog entries short. FinalA take home final will be handed out on the last day of class, and will be due at 5pm on Dec. 16 (by e-mail to Tom). 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 between the 7th and the 16th to work on the final, on the honor system. GradingBlogs: 20%; Project: 40%; Final: 40%. The grading in the class is emphatically not curved; I would like nothing better than for all of you to pass. Schedule and Reading List
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
Computer Science & Engineering University of Washington Box 352350 Seattle, WA 98195-2350 (206) 543-1695 voice, (206) 543-2969 FAX [comments to tressel] |
