This course introduces the basics of networking, ranging from sending bits over wires to the Web and distributed computing. We focus on the networking ground between these two extremes, particularly focusing on the engineering of the Internet - goals, constraints, solutions, and experiences. The outcome of this course for you should be an appreciation of the fundamental challenges of networking, design strategies of proven value, and common implementation technologies. Topics will include: framing, error correction, packet switching, multi-access (Ethernet), addressing and forwarding (IP), distance vector and link state routing, queueing and scheduling, reliable transport, congestion control (TCP), quality of service, naming (DNS), and security.

Course Structure

It's likely that there will be elements of this course that aren't quite what you were expecting. Some explanation of what is going on, structurally, may help in understanding what to concentrate on, should things get murky.

There are basically three main threads to the course. The first is learning the specifics of how the major Internet components are built and operate. This means, for example, learning about IP, BGP, TCP, DNS, and HTTP. Becoming familiar with these specifics is important, they affect and explain a lot about how current systems are built. This thread is most directly addressed by the text and the lectures.

The second thread is a more general set of concepts/problems that arise whenever networking is involved, that is, abstracting from the specific Internet solutions to the more general problem and its potential solutions. You'll confront these problems every time you write any networked code, and so understanding what they are is another important goal. As you see, when you build a networked application you'll have to address many of the same issues that the Internet fabric itself must address. Your understanding of the specific solutions used by the Internet can help you, so long as you can abstract its lessons.

The final thread of the Winter 2016 offering of this course is security and anonymity. The course project will involve those topics, even if they're not the main points of the project.


Officially Required

  • CSE 332
  • CSE 333
  • CSE 451: because concurrency is inherent in networking.

I'll assume you have no networking experience, even though there can be some networking in CSE 333. I'll assume as well that you have no experience with concurrency, even though you have had some parallelism in CSE 332 and possibly some concurrency in CSE 333. We won't be covering all the details required to build working networked, concurrent programs, though. There will definitely be things you'll need to look up on your own.

There is a substantial project for this course. You are free to do it in whatever programming language you prefer. That, of course, means that there will be no starter/skeleton code. (We will be supplying pieces of the application, but you interact with them only over the network, not by direct invocation at the programming language level.)

Assignments / Projects

There will be up to three kinds of assignments given throughout the class:
  • Reading: you will be given reading assignments from the course textbook associated with each lecture. You should try to finish the reading before coming to the lecture. We will be covering a large fraction of the topics in the text. It won't be easy to catch up if you fall behind. (From time to time the text may be supplemented with additional reading.)
  • Textbook(-style) questions: Some assignments may include questions from the text, occasionally supplemented with similar questions I invent.
  • Projects: You don't want to come out of a networking course having never once written code that sends data across an actual network. You won't.

    The projects are cumulative (later projects will make use of earlier ones) and communal. By communal I mean that your code will have to interact successfully with everyone else's (over the network).

    Projects will be done in teams. Your team can have one or two members. I don't have any magic solutions for teams that aren't working out. You can switch partners between projects.

This is a 4 credit hour course, meaning that it deserves something like 12-16 hours of your undivided attention per week. Try to reserve hours for the reading and stick to your schedule, even if some programming assignment that isn't going as well as you expected (i.e., all of them, for all of us) is coming due shortly.

Start projects early. There are countless things that can go wrong. Run into those things early, when you can afford to suspend working until you get help, rather than 4 hours before the project is due.


There will be one midterm and a final exam for this course. The dates are subject to change, with reasonable advance notice. It is especially possible the format and scheduling of the final exam will change. As an example, it could become a take-home exam.

  • Midterm: Friday, February 5
  • Final: Thursday, March 17, 8:30-10:20


This might be "fine tuned" later, but grades will be assigned roughly as follows:

  • Assignments/Projects: 55%
  • Midterm: 15%
  • Final: 30%


  • Late Policy: There is a 10% penalty for each late day, or portion thereof. You get two free late days - two days of lateness with no penalty - to use at your discretion. (That's four days total for a team of two.)

  • Reasonableness: No set of rules can apply perfectly in every setting. Reasonable exceptions can be made.

  • Cheating vs. Collaboration: Collaboration is a very good thing. On the other hand, cheating is considered a very serious offense, and is vigorously prosecuted. Vigorous prosecution requires that you be advised of the cheating policy of the course before the offending act. For this course, the policy is simple: don't cheat. You know it when you're doing it. We'll recognize it when you do it.

    That said, collaborating is, for many people, an effective way to learn. Learning isn't cheating. Misrepresenting that you've learned something, or done the work that implies you've learned something, almost certainly is.