Course Information
TTh 10:30a-11:45a
LWSN B134
PSO-002:
Mon, Haas 257, 9:30a-11:20a
PSO-003:
Fri, Haas 257, 3:30p-5:20p
Course Contact Email:
For corresponance regarding the course, rather than email the professors or
TA individually, please email cs536-contact@cs.purdue.edu.
This will help make sure the course is handled consistently and fairly.
Instructors:
Charles Killian
email: ckillian@cs.purdue.edu
phone: 765-494-6014
office: LWSN 1187
office hours: by appointment
Ramana Kompella
email: kompella X cs Y purdue Y edu
(X and Y mean the usual @ and dot)
phone: 765-496-9369
office: LWSN 1203
office hours: by appointment
Teaching Assistant:
Fadi Meawad [email : fmeawad at cs]
Textbook:
James F. Kurose and Keith W. Ross.
Computer Networking - A Top Down Approach Featuring the Internet.
5th Edition.
(Note: students with an earlier edition will probably be OK, but if
you are looking to buy the book for yourself, I recommend getting the
latest edition. Additionally, the course materials will come from the 5th
edition, and may vary a little from earlier editions.)
Announcements
- 2009-12-01: Rubric for the final project posted.
- 2009-11-30: NOTE: Final project papers will be accepted until class time on 12/8 without penalty.
- 2009-11-24: Written homework 4 posted below.
- 2009-10-28: Written homework 3 posted below.
- 2009-10-27: Grades section updated below. Note that 20% of the final grade is still being scaled by the paper reviews, but it is now spread across the homeworks, midterm, and final.
- 2009-10-27: Written homework 1 grades posted on BlackBoard.
- 2009-09-28: Written homework 2 posted below.
- 2009-09-25: Final project details posted. Note in particular the first deliverable due (10/1).
- 2009-09-25: Programming Assignment 2 deadline extended to 6am Monday (9/28).
- 2009-09-10: Next three papers reordered/revised. Link layer slides updated.
- 2009-09-07: Written homework 1 posted below.
- 2009-09-04: Programming Assignment 2 Posted below.
- 2009-09-03: Project 1 deadline extended to Sunday midnight (9/6).
- 2009-08-28: Tentative schedule posted, reading list finalized.
- 2009-08-26: Submission instructions for programming assignment posted.
- 2009-08-26: Submission now available for first 6 reviews at Blackboard (through Mid-Term).
- 2009-08-25: Course contact address estabblished. Please use cs536-contact@cs.purdue.edu when contacting any of the course staff about the class.
- 2009-08-13: The website content updated. First programming assignment available.
- 2009-05-27: The webpage is created. New content added as available. The book is Kurose-Ross for all those asking.
Course Description
This course is intended to provide a tour through the basic concepts underlying data communications and computer networks with an eye toward research and implementation. The structure and components of computer networks, packet switching, layered architectures, TCP/IP, physical layer, error control, window flow control, local area networks (Ethernet, Token Ring, FDDI), network layer, congestion control, quality of service and so on will be covered in this course.Pre-requisites
- This course is focused on the principles of field of computer networks. A major part of this understanding is to learn network programming. The programming language of choice in this course is C; so, if you are unfamiliar with C, please take the undergraduate C programming course before you register for this course. This is a strong requirement and no exceptions will be made at all.
- CS 354 (undergraduate operating systems) or CS 422 (undergraduate networks) or equivalent courses or experience. While this course will cover the basics of computer networking, it's task is to prepare you for research in the field of networks. Thus, we will be covering basic material quickly, to enable more of the field to be covered, as well as making room for discussion of classical papers in the field of networking. If in doubt, please see me before you register. These courses are not required but no exposure to any of these courses would make it really hard for you to follow the course.
- Speaking and reading in English. Written and spoken English is essential since most exams will be in English (US or UK should be fine, i.e., you can spell color as color or colour and not be afraid of getting penalized).
Grades
Subject to change.UPDATED: 27 October, 2009
- 20% - Programming assignments
- 10% - Written homeworks & reading discussion
- The grade will be computed as follows: HWavg/100 * Reviews/2. Below, the method for computing the review score is given, and has a maximum score of 20. HWavg will only consider grades from HW1 and HW2.
- 25% - Midterm
- The grade will be computed as follows: RawMidterm/100 * (20 + Reviews/4). Below, the method for computing the review score is given, and has a maximum score of 20.
- 20% - Final prjoect
- 25% - Final exam
- The grade will be computed as follows: RawFinal/100 * (20 + Reviews/4). Below, the method for computing the review score is given, and has a maximum score of 20.
Schedule
Updated in an ongoing basis. Note that the paper review schedule is below.- Week 1 (Aug 24-28): Chapter 1/Intro [slides: Chapter 1]
- Weeks 2-3 (Aug 31-Sept 11): Chapter 5/Physical Layer, Link Layer [slides: 9/1 Physical Layer Notes link layer (updated 9/10)]
- Weeks 4-6 (Sept 14-Oct 2): Chapter 4/Network Layer [slides: Networks I Networks II ATM/MPLS]
- Week 7 (Oct 5-9): Midterm Review and Midterm (Midterm is October 8th in class)
- OCTOBER BREAK (Oct 12-13): NO CLASS
- Weeks 8-10 (Oct 14-30): Chapter 3/Transport Layer [slides: Transport I Transport II TCP Vegas Extra Topics]
- Weeks 11-13 (Nov 2-20): Chapter 2/Application Layer [slides: Application Layer Akamai Link to slides about Chord Link to slides about RON Link to slides about MapReduce]
- THANKSGIVING BREAK (Nov 25-29): NO CLASS
- Weeks 14-16 (Nov 23-Dec 8): Advanced topics and project presentations [slides: Wireless Multimedia]
- Last Class (Dec 10th): Final exam review
Programming assignments
There will be two individual programming assigments.
Programming Assignment 1: Building and evaluating a web server
The details and description of homework 1 are available here: (HTML). The resources mentioned in the project WRiteup are available here [resources.html]. This homework is adapted for the Purdue environment from the same assignment at Duke University's Computer Science department. The grading criterion is available here: (TXT). Programming assignment 1 is due at 11:59pm on Sunday, September 6th. This assignment is to be done individually. There should be no sharing of code or text. If you have questions, please email the course staff alias.
Programming Assignment 2: Simple Transport Control Protocol (STCP)
The details and description of homework 2 are available here: (HTML). The grading criterion is available here: (HTML). Programming assignment 2 is due at 6:00am on Monday, September 28th. This assignment is to be done individually. There should be no sharing of code or text. If you have questions, please email the course staff alias.
Generic Submission Instructions for PROGRAMMING ASSIGNMENTS
Login to one of xinu* machines. Create a directory having your user name (career account username); say YYYY. Copy everything that you want to submit into this directory. Please do not submit unnecessary files. Move to the parent directory of YYYY. Enter the following command: turnin -c cs536=XXX YYYY XXX is your section name: PSO2 - 9:30 am - 11:20 am Monday PSO3 - 3:30 pm - 5:20 pm Friday It is not necessary to specify the project under which you are making the submission for turnin assumes that submissions are accepted only for the current project. e.g: If your user name is foo and you are in section PSO2 you would enter the following command: turnin -c cs536=PSO2 foo Please verify that all your files have been properly submitted using the command. turnin -c cs536=XXX -v.
Written homeworks
There will be around four written homeworks this semester. Homeworks must be written up individually. Collaboration on the homeworks is allowed, provided that the homework explicitly state who collaboration was done with, and that the homework is written up completely independently (i.e. no sharing of text, solutions, etc.). Homeworks are to be submitted electronically, not by paper. Use either a TXT file or a PDF file. If you need to draw a diagram by hand, that is fine, provided that you scan in the paper and submit it as a PDF.
Homeworks 3 and 4 will not count towards the final grade. We welcome you to submit answers, and we will be happy to provide feedback.
They will be posted here as they become available:
- Homework 1 - Due 9/17/2009 by class time
- Homework 2 - Due 10/6/2009 by class time
- Homework 3 - Due 11/5/2009 by class time
- Homework 4 - Due 12/4/2009 by 10:30am
Reading discussion
There will be about 1 paper each week. Students will review each paper in an online submission prior to the class in which it is due. This is included as part of the overall homework grade. If you do not have experience reading research papers, this pamphlet may help you figure out how to read research papers efficiently.
Reviews should be submitted via BlackBoard in the appropriate assignment. Reviews are DUE by class time. Reviews should include the following:
- State the main contribution of the paper
- Describe the soundness of the methodology. For example: do the experiments support the conclusions? Are the assumptions practical? Are there other experiments which would have been better? Were there other methodological errors?
- What are the three strongest/most interesting ideas in the paper?
- What are the three biggest weaknesses of the paper?
- What question would you ask the author if seen presented at a conference?
Reviews will be graded on a 0-2 point scale. 0 points will be awarded if there is no submission (or a submission not in good faith). 1 point will be awarded if the submission does not follow the guidelines above. 2 points will be awarded if the review is submitted and meets the guidelines above. The total score for assigned reviews will max out at 20 (in essence, 3 reviews of your choosing may be omitted).
Assigned reviews:
- Week 1: (8/27) J. Saltzer, D. Reed, and D. Clark, End-to-end Arguments in System Design. ACM Transactions on Computer Systems (TOCS), Vol. 2, No. 4, pp. 195-206, 1984.
- Week 2: (9/3) Kim, C., Caesar, M., and Rexford, J. 2008. Floodless in seattle: a scalable ethernet architecture for large enterprises. In Proceedings of the ACM SIGCOMM 2008 Conference on Data Communication (Seattle, WA, USA, August 17 - 22, 2008). SIGCOMM '08. ACM, New York, NY, 3-14. DOI= http://doi.acm.org/10.1145/1402958.1402961
- Week 3: (9/10) Andy Myers, Eugene Ng, Hui Zhang, "Rethinking the Service Model: Scaling Ethernet to a Million Nodes" ACM SIGCOMM HotNets'04
- Week 4: (9/17) Srinivasan, V. and Varghese, G. 1999. Fast address lookups using controlled prefix expansion. ACM Trans. Comput. Syst. 17, 1 (Feb. 1999), 1-40. DOI= http://doi.acm.org/10.1145/296502.296503
- Week 5: (9/24) XL: An Efficient Network Routing Algorithm, Kirill Levchenko, Geoffrey M. Voelker, Ramamohan Paturi, and Stefan Savage, Proceedings of the ACM SIGCOMM Conference, Seattle, WA, August 2008.
- Week 6: (10/1) Matt Caesar and Jennifer Rexford, "BGP routing policies in ISP networks," IEEE Network Magazine, special issue on interdomain routing, November/December 2005.
- Week 8: (10/15) L. S. Brakmo and L. L. Peterson, TCP Vegas: End to End Congestion Avoidance on a Global Internet. IEEE Journal of Selected Areas in Communication, Vol. 13, No. 8, pp. 1465-1480, October 1995.
- Week 9: (10/22) "Modeling TCP Throughput: A Simple Model and Its Empirical Validation," by Jitendra Padhye, Victor Firoiu, Don Towsley, and Jim Kurose, Proc. of ACM SIGCOMM 1998.
- Week 10: (10/29) Floyd, Sally; Jacobson, Van (August 1993). "Random Early Detection (RED) gateways for Congestion Avoidance". IEEE/ACM Transactions on Networking 1 (4): 397-413. doi:10.1109/90.251892
- Week 11: (11/5) Ion Stoica, Robert Morris, David Karger, M. Frans Kaashoek, and Hari Balakrishnan, Chord: A Scalable Peer-to-peer Lookup Service for Internet Applications, ACM SIGCOMM 2001, San Deigo, CA, August 2001, pp. 149-160.
- Week 12: (11/12) "Resilient Overlay Networks," David G. Andersen, Hari Balakrishnan, M. Frans Kaashoek, Robert Morris, Proc. 18th ACM SOSP, Banff, Canada, October 2001.
- Week 13: (11/19) MapReduce: Simplified Data Processing on Large Clusters, Jeffrey Dean and Sanjay Ghemawat, Google, Inc., OSDI 2004
- Week 15: (12/3) Review the focal paper of your final project.
Final project
Topics: The networking final project must have a strong networking component. In particular, security and distributed systems are courses of their own, and so those projects should be conducted there. The project topics must be centered on one or more published research papers. To find appropriate papers, you can look at papers published in TON (Transactions on Networking), SIGCOMM, and INFOCOM. In most cases, a well done project has the potential to (with additional work) go on and be published. The end of the project will be a great time to evaluate whether you are interested in continuing the project, and what faculty members might be interested in continued involvement in the project.
In order of desirability (most desirable first), the following are possible types of projects:
- New and novel networking research. This type of project would be to take a new idea of your own, and proceed to prepare a conference submission for the idea. For this course, you would essentially be getting started on the project, and developing the first workshop paper for the idea.
- Measurement project. Rather than designing and implementing some new network functionaity or feature, you could seek to conduct original measurements of real network environments with an eye towards increasing understanding of networks for the purpose of building better networks or better networked systems.
- Renewing a paper. This type of project will involve taking a research paper, and implementing the idea of the paper, and conducting analysis of the idea. Basic analysis would answer the question "is the idea in the paper still true today, if it was ever true?" Extended analysis might include evaluating the paper in new environments or scenarios for which the paper does not describe, to further analyze the applicability of the idea.
- Survey paper. The bar for survey papers is intentionally higher, since this is the one type of project which will not contain a software artifact. To complete a successful survey paper, the authors must do more than just describe a set of related papers, but must do analysis, categorization, comparison, and create taxonomies of the ideas described in the papers. A successful survey paper will allow its readers to easily understand how the surveyed papers fit together in the overal research scope. A survey paper must include at least 10 papers per team member.
If you need help figuring out appropriate project ideas, feel free to contact the professors. A few possible ideas might include:
- Can you come up with a model for how BitTorrent swarms will behave given the network graph and status of different peers?
- Measure the performance of TCP in a virtual machine, possibly considering the different flavors of TCP.
- Do analysis of the XL paper in simulation
- Explore the behavior of routing (e.g. count-to-infinity problems) by implementing and simulating routing over a variety of generated topologies.
- Evaluate how well RON (Resilient Overlay Networks) can route around network failures.
- Compare different multicast techniques (network and overlay multicast).
Deliverables: The final project will be done in groups of 2-3 (no more, no less). We will expect more work from a 3-person project than a 2-person project. The final project deliverables are:
- (10/1) Notify us of your team by email to the contact list.
A short email will suffice, one from each team. After receiving the email, we will create a group in BlackBoard for your team so that future components can be submitted as a team.
- (10/15) A project proposal, submitted to BlackBoard
The project proposal should be .5 to 1 page, in extended abstract format. It should contain the title of the project, the team members, a problem statement, a possible approach you can take, and references for the work. If the project is a survey paper, the proposal should contain the references you intend to read for the project (at least 10 papers per project member). You need not have read them, but should have identified what papers you plan to read.
Teams may wish to meet with one or both professors prior to the proposal, or we may request meetings after the proposal, to discuss the proposed work and help refine it to a suitable course project. Feel free to email us to request such meetings. After submission of the proposals, the professors will assign each project a "shepherd", who will be the primary contact for each project.
- (11/6) A status report, submitted to BlackBoard
The status report is essentially an extension and refinement of the proposal. To it should be added a discussion of the work completed thus far, as well as a timeline for the remaining work, including a collaboration plan describing the division of work. Following the status report, the project shepherd will again work with the team to make sure that the work outlined and conducted for the project is both adequately enough for a course project and not too much work to be completed.
- (12/3) The final report, submitted to BlackBoard
The final report should be roughly 5-7 pages, in conference style (typeset in 2-column, 9 or 10 point font). The final report should contain sections for Introduction/Motivation, Problem Statement, Related Work, Approach/Technique, Results/Evaluation, and Future Work. In a survey paper, the related work section will be of critical importance, and instead of Approach and Results section, you should have a section to present the analysis of the surveyed work, including any taxonomies, categorizations, and comparisons. In all papers, the future work section is important to identify what work remains to turn this paper into a conference submission (should you choose to do so), and also may present ideas for future projects. Note that the SIGCOMM deadline is in late January, and would be an excellent venue for good projects to be submitted with extra work.
- (12/3 and 12/8) The project presentations, in class
Presentations will be roughly 10-15 minutes, and will be in class. We will use random assignment to determine the order of presentations. In your presentation you should describe the problem, the approach you took, and the results you have found.
Additional guidelines: The work for this course project is to be conducted between now and the deadline for the project. Work previously conducted is not appropriate for this course, nor is work completed after the semester ends. We welcome projects which you can also use in your research; however, the work done for this course project must not be used toward any other course you are concurrently taking. That includes independent studies. At the same time, however, it may be appropriate to define a larger project for multiple courses, and identify which part of the project is being done for this course.
Resources: In conducting the course projects, you may find that you need resources for running various experiments. Talking to the professors is a great way to find out what resources are available, but in particular, you might expect to be able to use network simulators (NS2, NS3, GTNetS), network emulators (ModelNet), virtual machines, local clusters of machines, PlanetLab, and possibly Amazon's EC2.
Grading: Subject to change, the grading for the final project is available in the rubric.
Course Mailing-lists
We will sometimes use an iTap-maintained announce-only mailing list to send announcements to the class. iTap automatically adds your official Purdue email to the mailing list when you are registered for the class. You should make sure you can receive mail at that address.
Course Policies
Late Policy: All assignments are due on the day and time posted. Paper discussion responses may not be turned in late. Written homeworks may be turned in up to 1 day late, and late submissions will be scored out of 90 points instead of 100. On programming assignments only, students may have 6 free late half-days to spread across the two programming assignments as they see fit. After the late time is used up, 10 points will be deducted from the assignment score per day late. No programming assignment will be accepted more than 6 days after the assigned due date.
Ample time is given in advance for assignments, so excuses that you did not have enough will not be considered. Extraordinary circumstances will be considered at the discretion of the professors, contact him if you think these apply to you. If you have forseeable circumstantial problems, the best advise is to get the assignment done early. If that will not be possible, contact the professor.
Emergencies: In the event of a major campus emergency, course requirements, deadlines and grading percentages are subject to changes that may be necessitated by a revised semester calendar or other circumstances. Here are ways to get information about changes in this course. The course web page, the class mailing list, or by contacting the professors directly.
General policies: This course further adheres to the policies posted at http://spaf.cerias.purdue.edu/cpolicy.html. Please familiarize yourself with them.
Special note on academic dishonesty: In particular, note the section on academic honesty. Violations of this policy are treated as very significant, and will be dealt with both through punitive grading and notification to the Dean of Students.