TEACHING ARTIFACTS FOR JANET DAVIS

In Winter 2004, I served as the instructor of record for CSE/EE 461: Introduction to Computer Communicationand Networks, a course taken by 58 junior and senior Computer Science, Computer Engineering, and ElectricalEngineering majors. I was responsible for all aspects of the course, including lectures and classroom activities,homework assignments, programming projects, exams, and the assignment of final grades. I also supervised agraduate and an undergraduate teaching assistant, who led discussion sections and graded homework under mydirection.

Networks is a regular course offering in the Computer Science & Engineering department, with an establishedcurriculum and textbook (Peterson and Davie’s Computer Networks: A Systems Approach). In addition to teachingthis course in Winter 2004, I served as a teaching assistant twice, in Autumn 2001 and Winter 2002. I made severalcontributions to the development of this course:

• My offering of Networks was only the second offering in which the syllabus was organized around keyproblems in networking, rather than the more conventional top-down or bottom-up approach. I added a fifthproblem (heterogeneity) to the four discussed in the previous offering (reliability, resource sharing, growthand evolution, cooperation and competition). Furthermore, I reorganized and adapted an existing set oflecture slides to reflect this problem-based approach. This organization is reflected in the course syllabusdiscussed in Artifact A.

• At the same time, I adapted the lecture slides to work with Classroom Presenter, an electronic presentationsystem developed at the University of Washington that allows the instructor to annotate prepared slidesduring class.1 I chose to experiment with this technology because I thought it would work well with theguided notes technique, in which students are given skeletal lecture notes to complete. It also gave me thefreedom to move around a large classroom and focus my attention on different students as I lectured.

• I continued to combine written homework assignments with a substantial programming project intended togive students design and implementation experience, which is described in Artifact B. I contributed to theinitial development of this project in my earlier experience as a teaching assistant. As an instructor, I workedto clarify project requirements and keep student workload manageable.

• Finally, I pioneered the use of Classroom Assessment Techniques (CATs)2 in the Networks course. Theseexercises gave students an opportunity to consolidate and reflect on their own learning, while also helpingme to present different ways of understanding the material, address misconceptions, revisit unclear points,and expand of topics of particular interest. In addition to applying CATs developed by others, I developed anovel CAT addressing the problem of network heterogeneity, presented in Artifact C.

Teaching Networks was a lot of fun; it cemented my decision to pursue a career emphasizing undergraduateteaching. I learned a lot from the experience, and I look forward to teaching another course like it.

List of Artifacts

Artifact A: Course Syllabus and Timeline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 2Artifact B: Programming Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 4Artifact C: Hourglass Analogy Classroom Assessment Technique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . p. 6

Additional materials are available on the course web site:

http://www.cs.washington.edu/education/courses/cse461/04wi/.

1 http://www.cs.washington.edu/education/dl/presenter/2Angelo and Cross 1993, Classroom Assessment Techniques: A Handbook for College Teachers

Teaching Artifacts for Janet Davis 2

Artifact A Course Syllabus and Timeline

I developed the course syllabus based on syllabi from previous offerings. The following is an excerpt from thesyllabus:

Course Description: The goal of this course is to help students learn how to design andimplement network protocols that work—ones that are robust, efficient, scalable, interoper-able, extensible, and secure. We cover the breadth of existing network protocols, includingcoding, routing, transport, congestion control, wireless and LAN media access, quality ofservice, content distribution, and encryption. Our focus, however, is on the concepts neededto understand not only the protocols we currently use, but those that will be developed inthe future. A large part of the course is the programming project: to build a wireless ad hocnetwork capable of carrying real-time voice traffic.

I organized the curriculum around five classic problems in networking: reliability, heterogeneity, resourcesharing, growth and evolution, and cooperation and competition. I intended this organization to help make theproblems stand out from the details of network protocols, and to provide a conceptual structure for students toorganize their knowledge. To keep students oriented, I made these problems prominent in the course timelineshown on the next page.

Collaboration Policy: Unless we specifically state otherwise, we encourage you to col-laborate on homework provided (1) you spend at least 15 minutes on each problem alone,before discussing it with others, and (2) you write up every solution on your own (or with yourpartner for programming assignments), using your own words, and understand the solutionfully. Copying someone else’s written homework or programs is cheating, as is copying fromanother source (prior year’s material, etc.).

Email: Join the class mailing list right away by sending email to majordomo@cs.washington.eduwith “subscribe cse461” as the contents. All messages sent to this list are archived and avail-able on the course web page. We will use the email list for all course-related communicationof general interest, in particular, to answer questions about assignments. You should feelfree to use it for any class-related discussion, and you are specifically encouraged to answerother students’ questions, and to post hints for navigating the inevitable confusions that willoccur in doing the programming projects. Note that I will answer course-related email exactlyonce per day; the mailing list may get you a faster response.

To learn more effectively and build confidence, students need opportunities both to collaborate and to demon-strate their own abilities. I required students to complete programming projects in pairs and written assignmentsindividually. My collaboration and email list policies, quoted above, explicitly encouraged students to collabo-rate and support each others’ learning; I further encouraged collaboration through discussion and groupwork inclass, and through peer teaching in my office hours. However, I also required students to take responsibility forunderstanding problems and solutions on their own.

Late Policy: All assignments are due at the beginning of class and will be considered lateonce we leave the classroom; this includes any electronic and written turnins. We will useflexible slip days for both the project and homeworks; you may turn in the project assignmentsup to an aggregate of four calendar days late, and the homework assignments up to anaggregate of three days late. Solution sets will be handed out shortly after assignments aredue, and once solutions are handed out, no further late homework will be accepted.

Finally, while I have high expectations for my students, I respect students’ time and try to support them inlearning to use their time well. By providing a timeline that shows not only lecture topics but also homework and

Teaching Artifacts for Janet Davis 3

project due dates, I support my students in planning time to complete assignments. Including reading assignmentsin the course timeline is a necessity in a course such as this, in which the textbook is organized differently fromthe syllabus. Many students took advantage of the late policy, quoted above, which gave limited flexibility whenneeded.

Timeline for CSE/EE461 (Winter 2004; Davis)

This is the rough lecture-by-lecture progression we will follow during the course. Expect some variation;check details with the course web page.

Date Topic Reading NotesM 1/5 Introduction 1.1–1.3 P1 outReliability: How do we build a network out of unreliable, distributed components?W 1/7 Coding & framing 2.3F 1/9 Error detection & correction 2.4M 1/12 Reliable transport (TCP) 1.5, 2.5, 5.2 HW1 outW 1/14 TCP retransmission & timers 5.2.5, 5.2.6F 1/16 TCP connections 5.2.1 P1 dueM 1/19 No Class MLK DayW 1/21 Flooding & bridging 3.1–3.2 P1 demo; P2 outF 1/23 Forwarding; distance vector routing 4.2M 1/26 Link state routing; mobility 4.2W 1/28 End-to-end principle Saltzer et al. HW1 due; HW2 outHeterogeneity: How do we support a range of media and applications?F 1/30 Design philosophy of the Internet ClarkM 2/2 IP layer 4.1W 2/4 Sockets & applications 1.4, 9.2 P2 due; P3 outResource Sharing: How do we share resources without centralized control?F 2/6 MAC: wired 2.6–2.7M 2/9 MAC: wireless 2.8W 2/11 Bandwidth allocation 6.1–6.2 HW2 due; HW3 outF 2/13 TCP congestion control 6.3M 2/16 No Class Presidents’ DayW 2/18 Congestion avoidance 6.4Growth & Evolution: How do we cope as networks grow and evolve over time?F 2/20 Interdomain routing (BGP) 4.3 P3 due; P4 outM 2/23 IP addressing 4.3W 2/25 Naming (DNS) 9.1F 2/27 Overlay networks 9.4.1 HW3 dueM 3/1 P2P networks 9.4.2W 3/3 Proxies, load balancers, CDNs 9.4.3Cooperation & Competition: How do we manage divergent interests?F 3/5 Security & cryptography 8.1–8.2 P4 dueM 3/8 Authentication & security systems 8.3–8.4W 3/10 Why you should never trust a computerF 3/12 Review Last day of classW 3/17 8:30–10:30 Final exam Best of luck!

Teaching Artifacts for Janet Davis 4

Artifact B Programming Project

In the Networks course I taught, students worked in pairs on four programming assignments in which they built awireless ad hoc network capable of carrying real-time voice traffic from the ground up.

The assignments build on Fishnet, a network emulation infrastructure which has been used at the Universityof Washington since Autumn 2001. I contributed to the initial development of the Fishnet infrastructure andprogramming assignments in Autumn 2001 and Winter 2002, when I was a teaching assistant for Networks. Asthe instructor in Winter 2004, I worked to clarify project requirements and keep student workload manageable.Development of Fishnet has continued over the past several years, and it is still in use today.

I intended the programming project to serve several learning goals. The project reinforces concepts learned inthe classroom through active, hands-on work. Furthermore, the Fishnet protocols are not identical with Internetprotocols; they show that there is more than one way to solve fundamental networking problems. Students relatetheory to practice in discovering the many details that must be accounted for to build implementations that arecorrect, robust, interoperable, and efficient. The assignments are not straightforward to implement; students mustpractice making design decisions. I required students to explain the reasoning behind their decisions in a writtendesign brief, in addition to appropriate comments in their code. I also posed several discussion questions for eachassignment, which encouraged students to reflect on their process, experiment with and explain protocol behavior,and further explore design decisions. In course evaluations, many students wrote that the programming project wasthe aspect of the course that contributed most to their learning.

The four project components are as follows. The first assignment is described in some detail to give the flavorof the project; all four assignments are available on the course web site.

Assignment 1: Flooding and Neighbor Discovery

In this assignment, I directed students to develop a flooding protocol in which nodes flood each packet received toall other nodes in the network. Flooding is inefficient but algorithmically interesting; it serves as a building blockfor routing in the next assignment. I also instructed students to implement a simple neighbor discovery protocol,which serves as another building block for routing.

In each assignment, I state required behaviors, but I do not specify in detail how students are to implement thosebehaviors. I intend this to give students opportunities to make and reason about design decisions. For example:

• Flooding must deliver a copy of every packet that is sent by any node to all of the other nodesuntil it reaches its destination. At each node, the copy of the packet that is delivered should beprocessed further only if the packet is destined for that node. A packet may be destined for anode either directly, if the destination address of the packet is the node address, or as part of anetwork-wide broadcast, if the destination is the broadcast address.

• Your flooding design must prevent packets from circulating indefinitely. This requires that yournode work out when it has already performed its flooding work for a given packet and not flood itagain. The header fields in Packet (the sequence number and source address in particular) arewell-suited to this task.

Finally, I posed five discussion questions for students to answer after completing their implementations. Thepurpose of each is noted in italics.

1. Now that you have written an event-driven program, describe one advantage and one disadvantageof this style of programming. (Reflect on process)

2. Flooding includes a mechanism to prevent packets from circulating indefinitely, and the TTL fieldprovides another such mechanism. Why have both? What would happen if we only had floodingchecks? What would happen if we only had the TTL? (Reason about protocol behavior)

Teaching Artifacts for Janet Davis 5

3. When your node pings a remote node using its particular destination address (rather than thenetwork broadcast address), how many requests does the remote node receive and why? Howmany responses does your node receive and why? (Experiment with and explain protocol behavior)

4. When your node pings a remote node using its particular destination address (rather than thenetwork broadcast address), how many requests and responses do other nodes handle? Howmany of these packets are unnecessary, and could probably be eliminated with smarter networkingprotocols? (Experiment with and reason about protocol efficiency)

5. Describe one design decision you could have made differently (for this thought experiment, you areallowed to change Fishnet) and the pros and cons compared to the decision you made. (Furtherexplore design decisions)

Assignment 2: Routing

Students used their flooding and neighbor discovery protocols from Assignment 1 to implement a link state routingprotocol. Students also implemented packet forwarding using routing tables.

Assignment 3: Reliable Transport and Congestion Control

Students implemented a data transport protocol with connection setup and teardown, multiple concurrent connec-tions, reliable transmission, and flow control. Optionally, students could implement a congestion control schemeof their choice. Students built a file transfer command to exercise their data transport protocol.

Assignment 4: Applications

Students developed two applications, a walkie-talkie service and a content distribution service, on top of the pro-tocols they implemented in earlier assignments.

Teaching Artifacts for Janet Davis 6

Artifact C Hourglass Analogies Classroom Assessment Technique

As discussed earlier, I used Classroom Assessment Techniques (CATs) to give students an opportunity to consoli-date and reflect on their own learning, as well as to provide me with feedback on how students are learning. CATswere generally well-received; several students wrote in course evaluations that the opportunity for rapid feedbackwas an aspect of the course that contributed most to their learning.

When we discussed layering and the IP protocol, I wanted students to learn about IP as a mediating abstractionthat lets the Internet accommodate a great deal of heterogeneity both in applications and in hardware. I used anhourglass figure, shown below, to draw an analogy between the IP protocol and other mediating abstractions suchas electricity and sewing. In that day’s CAT, I invited students to draw their own hourglass analogies. In thefollowing lecture, I showed the class three examples of student-generated analogies, to reflect learning back to theclass and give students more ways of understanding the material.

Slide presenting IP hourglass analogy Slide summarizing student analogies

Below, I have included several examples of student analogies. Students drew on computer science topics suchas compilers, ideas from other subjects such as biology and linguistics, and other interests such as construction andbanking. Some analogies, particularly that with cooking, were made by serveral students. However, each studentshowed his or her own individuality, and sometimes even humor. This is an example of how I want students torelate what they are learning to their own lives and interests.

Examples of student work