An Introductory Course in Computer Communication and Networks

An Introductory Course in Computer Communication and Networks Thomas Narten

Raj Yavatkar

Department of Computer Science

Department of Computer Science

SUNY at Albany

University of Kentucky

Albany, NY 12222

Lexington, KY 40506

[email protected]

[email protected]

Abstract This paper reports on the curriculum contents and experience obtained in the teaching of a semester-long introductory course in computer communication networks. The course is aimed at rst year graduate and senior undergraduate students and covers a broad survey of networking issues. We focus on all seven layers of the OSI reference model and assign four major programming projects to reinforce the ideas covered in lectures. Projects include writing the client side of a client-server program that implements a sliding window data-link layer protocol complete with acknowledgements and retransmissions, writing client and server programs that interact via remote procedure calls, and writing client and server programs that use UDP datgrams to locate and register services with a name server utility and TCP to actually invoke services registered with the name server.

1

Introduction

This paper reports on the curriculum contents and experience obtained in the teaching of an introductory course in computer communication networks. The course is aimed at rst year graduate and senior undergraduate students and was taught during the spring of 1990 and 1991 in the Computer Science Departments at the University of Kentucky and the State University of New York at Albany. So far, approximately 150 students have taken the course, and student feedback on the course has been overwhelmingly positive. The semester-long

course covers a broad survey of networking issues, and programming projects and written assignments augment and reinforce the abstract topics covered in lectures. The contents of the course were strongly in uenced by the author's experience designing, building, and using actual network software. Three underlying themes emerged. First, we wanted the course to serve as a broad introduction to all aspects of networking. While it may be tempting to emphasize areas of particular interest to the instructors, we feel that it is inappropriate to focus on particular areas at the expense of breadth in an introductory course. Thus, our course covers every layer of the ISO reference model, spending enough time on each layer to introduce important issues. Second, lectures are no substitute for actually using and writing programs that utilize networks; thus, we assign four major programming projects. Programming projects include writing client-server programs, implementing a sliding window protocol complete with ow control, acknowledgments, and retransmissions, writing client and server programs that communicate using the remote procedure call paradigm, and registering and accessing services through name servers. The particular choice of assignments was in uenced by the unavailability of dedicated equipment to implement protocols and modify operating systems [1, 2]; all of our assignments can be done in a traditional Unix 1 environment. Finally, we give written assignments on a regular basis to insure students keep up with the lectures, the bulk of which consist of typical end-of-chapter-type questions. In addition, we make it a point to assign two readings from the research literature. Such readings serve two purposes. First, outside readings provide contrasting views from those presented in the texts and give an idea of what sort of research is being done. Second, the advanced networking course for which the introductory course is a prerequisite consists entirely of readings from the literature. In practice, students have rarely, if ever, read any research papers in the eld of networking and having them read a few papers gives them an idea of what to expect in the advanced course and reduces the level of intimidation frequently associated with a course consisting entirely of readings. The following sections describe the course in more detail. Section 2 describes the topics covered in the lectures and the text books used as references. Section 3 discusses the pro1 Unix

is a registered trademark of AT&T Bell Laboratories.

gramming projects, and Section 4 describes some of our written assignments. In Section 5, we provide perspective on the experience obtained from teaching the course and report on feedback from the students. Section 6 summarizes our accomplishments.

2

Lectures

Lectures span a 15-week semester and present approximately 13 weeks of course material, leaving sucient time to hold one in-class exam, answer questions about programming projects and homeworks, and give a nal during examination week. The course uses two textbooks: Tanenbaum's Computer Networks [3] and Comer's Internetworking with TCP/IP [4]. During the rst half of the course, lectures focus on the material at the physical, data link, and network layers, covering topics such as Fourier analysis, LAN technologies, error and

ow control, and routing. Tanenbaum's book does a particularly good job here and serves as the primary reference on which lectures are based. In the second half of the course, emphasis shifts to the TCP/IP protocol suite, which provides a concrete example of an existing protocol family. Comer's book does a particularly good job here and serves as the primary text reference. In the following, we describe topics covered during lectures on an approximate week-byweek basis. See Table 1 for a summary of covered topics. Lectures in the rst week provide an overview of networking from a high-level perspective. We discuss the basic bene ts of networking such as bulletin boards, electronic mail, and le transfer, present common terminology (e.g., packet-switching, connectionless vs. connectionoriented, client-server model, etc.), and brie y describe a few sample network technologies. In addition, we present the notion of layering, introduce the OSI reference model, and describe the role (positive and negative) of the standardization process. Next, we spend about two weeks discussing the physical layer. We begin by examining the implications of Fourier analysis on data transmission, Nyquist and Shannon's results, and followup with descriptions and comparisons of such transmission technologies as coaxial cable, twisted pair, ber, and ISDN. In addition, we discuss the realities imposed by the telephone system, modem technologies, the concepts of time division and frequency division

Week Material 1 2

3 4 5

6 7 8 9 10 11 12 13

Reference (chapters) Overview of networks, layering, OSI reference model, Tanenbaum: 1. client/server model. Physical layer: theory (Nyquist, Shannon, Fourier); Tanenbaum: 2.1{2.3. transmission media: twisted pair, RS-232, RS-442, coax, ber, satellite; phone system, analog vs. digital transmission, modems. FDM, TDM, circuit switching, packet switching, ISDN, Tanenbaum: 2.4{2.6, 3.1{3.3.3. MAC layer: ALOHA, CSMA/CD. Token ring, FDDI; data link layer: framing, bit stung, Tanenbaum: 3.4.1{ error detection and correcting codes; LAN frame formats. 3.5.1, 4.1{4.2. Flow control, stop and wait, sliding window protocols; Tanenbaum: 4.3{4.4, Network layer: goals, design issues, resource manage- 5.1. ment issues (congestion, fairness), Virtual Circuits vs. datagrams. Routing: RIP, link-status broadcast and SPF, bridges vs. Tanenbaum: 5.2{5.3. routers, congestion control, resource management. Internetworking: IP datagrams, addressing, fragmenta- Tanenbaum: 5.4. tion, best-eort delivery, time to live, gateways, ICMP, Comer: 4, 5, 7 & 9. ARP, demultiplexing, gateways. RIP, EGP, autonomous systems; Transport layer: goals, Tanenbaum: 6.1{6.2. function, addressing, connection setup and tear down, Comer 8,13{16.

ow control, error control, congestion control. UDP: ports, unreliability, lack of ow and congestion con- Tanenbaum: 6.4.2 trol; TCP: 3-way handshake, congestion control, slow- Comer: 11-12. start, retransmit timers, urgent data, checksum. DNS: mapping names to addresses, name space, caching, Tanenbaum: MX records; Session layer: purpose, etc.; remote proce- 7.1{7.1.6, 7.2. Comer: 20. dure call (RPC), registry, marshaling. RPC (continued); Presentation layer: purpose, data rep- Tanenbaum: 8.1{8.3 resentation, ASN.1, Sun XDR, compression, Human en- Comer 25.7 coding, run length encoding 8.4, Security, cryptography, and authentication (DES & Tanenbaum: RSA), digital signatures; Application layer: overview; 9.1{9.3, 9.6.2 Comer 24. Electronic mail: SMTP, X.500. 9.4, Virtual terminals, telnet, rlogin; Directory services: Tanenbaum: white pages, yellow pages; Network File Systems: Sun 9.5.1, 9.6.2. Comer: 19.3{19.4, NFS. 22{23. Table 1: Breakdown of topics showing what is discussed each week.

multiplexing, and digital vs. analog communication. During the third week, we examine the medium access sublayer, studying the ALOHA protocols, CSMA protocols, FDDI protocols, and the IEEE 802 family of token ring, bus, and ethernet protocols. At this point, we also introduce students to rudimentary performance evaluation, examining the performance of the ALOHA protocols. In studying the theoretical performance of CSMA networks, we have found it useful to provide an alternative perspective by having students read the Boggs et al. paper Measured Capacity of an Ethernet: Myths

vs. Reality [5]. Students can be asked to answer questions about its contents, or provide a short summary of the its main points. The fourth week of class completes our discussion of the medium access sublayer, and we proceed by moving to the data link layer. For the data link layer, we emphasize framing issues, error control (e.g., error detection using checksums and forward error correction),

ow control, and sliding window protocols. At this point, students are already working on a two-part, data-link layer programming assignment, in which they write a client program that implements a complete data link layer protocol. The rst part of the assignment focuses on separating the logical functions into four logical layers (application, data link, framing, and physical) and getting the application and framing layers working. The programming project is described in detail in Section 3.1. The fth week covers sliding window protocols, starting with stop-and-wait and ending up with go-back-n and selective repeat. The sliding window protocol concepts are reinforced by having students implement a variant of one of the sliding window protocols as the second part of the data-link layer programming project. Although this project is the most dicult of the semester, students also report it as being one of the best because it forces them to really think about the subtle details of protocol correctness in the presence of lost and duplicate packets (either data or acknowledgment). The remainder of the fth week and all of the sixth week is spent on the network layer. The two topics we focus on most are conceptual issues of routing and congestion control. However, these are two areas in which the lectures are dicult, no doubt in part because satisfactory, general solutions for the problems in this area aren't in abundant supply. With routing, for example, Tanenbaum's book spends a lot of time on conceptual issues and pre-

senting various approaches, but students nd it dicult to sort out what works well in practice from such ideas as isarithmic control or random walk that have mostly esoteric value. We have found it bene cial to spend extra time examining the \old" Arpanet routing algorithm [6] and its associated problems (slow convergence) 2 in detail as well as the \new" one [7] with its inherent limitations (e.g., lack of multipath routing support, failure to incorporate dierences in link capacity). We conclude the network layer with a discussion of bridges vs. routers. At this point, emphasis shifts to the TCP/IP protocol suite and Comer's text becomes the primary reference. While we continue to refer to Tanenbaum's book for good coverage of general issues at the transport layer and above (e.g., encryption, remote procedure call, etc.), we nd the concreteness of the TCP/IP protocol suite invaluable in giving students a rm grasp on networking. In addition, because students make use of the TCP/IP protocols on a daily basis, they are eager to learn about them. Having already studied the physical, data link, and network layers (and sliding window protocols in particular), we are able to cover much of the material quickly, spending most time on such areas as TCP and the domain name system. We begin the seventh week by examining the format of Internet addresses, and the problem of mapping between physical and logical addresses (e.g., ARP and RARP). We then discuss the format of Internet datagrams, the purpose of IP options, and the role of ICMP in error reporting, followed by a discussion of routing from both the host and gateway perspectives. Our description of Internet datagrams shows how fragmentation and reassembly is done, and we emphasize the concepts of best-eort delivery and connectionless service throughout. The eighth week is spent describing interior gateway protocols (IGPs) such as RIP (whose description is straightforward after having discussed the \old" Arpanet algorithm) and a few conceptual aspects of OSPF. We conclude with a description of EGP and autonomous systems together with the shortfalls of the \core" model. As we describe routing, we also introduce subnetting, and show how some routing protocols (e.g., RIP) don't understand subnetting, while some others do (e.g., OSPF), and the implications on routing. 2 Surprisingly, Tanenbaum's rst edition contains a more complete description of the problems of the old Arpanet routing algorithm.

The remainder of the eighth and all of the ninth week considers transport layer issues and TCP in particular. We begin by examining general transport layer issues, such as overcoming de ciencies in network layer services and incorporating congestion control policies within transport layer protocols when connectionless network layers are used. We also emphasize the need for ow control and the requirement that connection-oriented transport protocols maintain state at the two endpoints of communication. Our examination of TCP/IP begins by showing how UDP ports are used to demultiplex incoming datagrams to their intended endpoints. Our coverage of TCP includes its push mechanism, ow control window, and urgent pointer, as well as the use of ags for the three-way handshake. We also describe the implementation issues of maintaining dynamic round trip time estimates, slow start's use of a congestion window, as well as the policies governing expansion and contraction of the congestion window. The tenth week covers the domain name system (DNS), focusing on its name space, the objects it maintains, and how fault tolerance and management is distributed through delegation of authority and replication. We also include a detailed examination of remote procedure calls together with such implementation issues as service binding, stub generation, parameter marshaling, and VMTP [8, 9] as an alternate transport protocol for eciently implementing remote procedure calls. At this point, students are working on the third programming assignment, which involves writing a client and a server that interact through remote procedure calls. The eleventh week concludes RPC and focuses on such presentation layer issues as data representation (e.g., ASN.1 vs. Sun's XDR) and data compression. At this point, we discuss such security issues as authentication, encryption, and digital signatures, covering conventional (single key) cryptography, public key encryption, and the RSA method for generating public keys. The remainder of the twelfth and all of the thirteenth (and last) week are spent covering application layer protocols, focusing on electronic mail (SMTP), remote login (telnet and Berkeley's rlogin ), le transfer (FTP ) and Sun's NFS . For the last programming project, students ( nally!) write programs in which they directly use the TCP/IP protocol suite. They are asked to write a server program providing any service they wish, so long as the

server fetches requests and sends responses via the TCP connection. The server program must also advertise its services using a name server. Students also write a client that locates desired services through the name server and then contacts them directly to access their services. The details of the project are described in Section 3.3.

3

Programming Projects

Our course includes four main projects, all of which run under a conventional Unix timesharing system. While it would be interesting to have access to a laboratory of dedicated machines on which students can implement and modify network protocols embedded within operating system code, we don't have such facilities at this time. Still, we wanted students to obtain hands-on experience writing real network applications and protocols. In retrospect, there are distinct advantages to using a conventional Unix environment for program development and debugging. Implementing and modifying protocols embedded within a machine's operating system requires a good understanding of such operating systems issues as synchronization, mutual exclusion, interrupt handling, etc., and we do not want to require an operating systems course as a prerequisite. In addition, by using a standard program development environment, students have access to familiar program development and debugging tools. 3.1

Four-Layer Client-Server Protocol

Following the outline of most textbooks, our lectures start with the lowest layers and nish with applications. Thus, we do not want to give assignments using TCP/IP and the socket library before covering them extensively. We begin with a two-part assignment that simulates a four-layer protocol model shown in Figure 1. The assignment serves three purposes. First, it introduces students to the client-server paradigm. Second, it demonstrates the importance of layering. One thing that has surprised us is the diculty some students have in grasping the importance of layering and hiding service implementations behind interfaces. Finally, students must implement (and hence understand) the details of framing, character stung, and the subtleties of sliding window protocols.

Application Layer DataLinkSend()

Application Layer

DataLinkRead()

Data Link Layer FrameSend()

Framing Layer

Client

FrameSend()

FrameRead()

Framing Layer

PhysicalRead()

Physical Layer

DataLinkRead()

Data Link Layer

FrameRead()

PhysicalSend()

DataLinkSend()

Unix write() Unix read()

PhysicalSend()

PhysicalRead()

Physical Layer

Server

Figure 1: Layering in our four-layer communication architecture. For simplicity, the framing service has been pulled out of the data link layer and placed in its own layer. Students implement a client in which they write code for three of the four layers of our model; we supply the physical layer and a server used to test client programs. The project itself is divided into two parts. Although students write the client from scratch, we supply the students with protocol de nitions for each layer and an executable image of the server that implements them. For the rst part of the assignment, students implement the application layer and the framing layer. During phase I, the physical layer is reliable, always delivering individual bytes to the server in the same order in which the client sends them. For the second part of the assignment, students add a data link layer to their clients. The data link layer implements a sliding window protocol complete with checksums, sequence numbers, acknowledgements, and retransmissions. To fully test their code, our server drops and garbles arbitrary characters sent and received at the physical layer. To contact our server, a student's client program invokes a special routine we supply that starts the server and returns a le descriptor that can be used to send and receive raw characters at the physical layer. Invoking the server and hiding the nature of physical layer communication in this way has several bene ts. First, students need not concern themselves with the details of how client-server communication actually takes place. Second, in the Unix

environment, the supplied routine can fork and exec the server executable image. Because the newly created server process inherits the client's open le descriptors, the server can be directed to send debugging output to a student's terminal. This has proven to be a big win; an earlier version of the server ran as a standalone server daemon that was unable to print diagnostics to the student's terminal. When students implement the data link layer, a \bad checksum" message is in nitely more helpful than silence. Another advantage arises when considering that students work at dierent speeds. While advanced students may be debugging their data link layers using a server that understands the data link layer (and damages and discards data to simulate an unreliable physical layer), other students may not even have started working on the data link layer at all! Again, our initialization routine handles this by accepting an extra argument that speci es what quality of service the physical layer should provide. The quality of service parameter oers a progressively less robust physical layer, ranging from a completely reliable link to one that only garbles frames to a link that both drops and garble frames. Finally, letting the client actually create the server process eliminates the need to restart a daemon server after machine restarts. For the rst part of the assignment, students implement the application and framing layers. The application layer has an interactive front end that maps input commands into requests sent to the server. While the exact details of the application program are unimportant, we have settled on a small set of service requests that test the important cases in the lower level protocols and simplify the task of verifying the correctness of an implementation. The set of commands is given in Table 2. The load, fortune, and date commands are single query, single response messages. The

cat command sends a single query to the server, but receives a multi-message stream of consecutive responses. The count command tests the reverse process in which the client sends a multi-message stream of data packets to the server. The copy command is similar to cat , but is necessary for copying non-text les whose contents can't be printed to the terminal. Indeed, properly testing the escape sequences used in the framing layer may require the sending and receiving of non-ascii data. The copy command also allows students to verify the correct operation of their protocols by comparing an original le with its copied version using such utilities as di. The ping command has the server return a sequence of messages containing increasing sequence numbers. This function becomes especially useful

Command load

Action The client sends a single query to server; the server returns single response giving the current load. fortune The client sends a single query to the server; the server returns a \fortune" message. date The client sends a single query to the server; the server returns a string containing the current time of day. cat lename The client sends a query containing the name of a le to the server; the server returns consecutive messages containing the le's contents. count lename The client sends one more messages to the server containing the contents of le lename ; the server returns a single message containing a count of the number of words in the le. copy src dest The client sends the name of a le to the server; the server returns one or more messages containing the le's contents. ping count The client sends a single message containing a number to the server; the server returns count response messages containing consecutive integers. quit The client sends a single message to the server directing it to terminate; the server returns a response and exits. Table 2: Service interactions between the client and server. when students begin debugging their sliding window protocols, showing when duplicate messages slip through to the application layer, or when the data link layer loses messages. For the rst part of the project, the data link layer is a \no op" that simply invokes the framing layer routines to send and receive individual packets. In the second part, students add a full blown data link layer that uses checksums, sequence numbers, acknowledgements, and retransmissions. To simulate a noisy channel, our server randomly garbles and drops bytes sent and received at the physical layer. Once again, having students contact our server through a provided routine facilitates easy selection the quality of physical layer service they want to use. At rst, they use a server without a data link layer and whose physical layer is reliable. As students progress, the server is directed to include data link layer headers in messages, and nally to require timeouts and retransmissions by randomly dropping or garbling messages. Implementation of a data link layer for part II presents several challenges. Speci cally, students must deal with concurrency : packets containing data or acknowledgments can arrive at any time, and they must be processed at the time they arrive. In contrast, for the rst part of the project, the server returns packets only after acting on the request sent by a client. Because the client must have nished transferring the entire request before the server

can act on it, server replies never arrive before the client expects them. In part II, however, the server returns acknowledgments even as the client continues to send additional data to the server (e.g., as part of the count command). If the client doesn't process incoming acknowledgments, communication deadlocks when the client blocks attempting to send into a full window. While we provide routines to simplify the handling of asynchronous events such as timeouts and arrival of an acknowledgement while sending out a message, their presence requires a subtlety of understanding by students. In addition, it should be noted that while handling asynchronous events in Unix is complex, the real issue is concurrency; having multiple threads of execution within the client process would change the details of a particular solution, but would raise mutual exclusion issues more appropriately covered in an operating systems course. Overall, the organization of our server has worked well. Separating the system into four layers has allowed us to make changes to individual layers with only minor eort. Such a capability is especially helpful when repeating the same course. It is straight forward to change the particular checksum algorithm used, replace the go back n protocol with one implementing selective repeat, changing the escape sequences used by the framing layer, and so on. 3.2

Programming With Remote Procedure Calls

The third assignment involves writing client and server programs that interact using the remote procedure call paradigm. The particular application used is only of minor importance. The chief aims of this assignment are to expose students to the RPC paradigm, and to get them to use tools such as Sun's rpcgen to automatically generate client and server stub procedures from speci cations of the remote procedures. Due to the nuances of Sun's RPC routines, we add some extra requirements for our assignment. First, students initially work on their programs assuming that they run as a single process in which the \client" can directly invoke \server" operations through procedure call invocations. Once the application portion of the project has been completely debugged, students separate the client and server into two processes that interact using RPCs. Un-

fortunately, because of the way Sun RPC passes arguments and return values, using RPC changes the details of how a remote service is actually invoked. In particular, Sun remote procedures may only pass a single argument or return value, although the single argument can be a pointer to a structure containing multiple elds. Thus, we have students add a \mapping layer" that converts high-level application calls into the low-level stub calls so that the application layer need not be rewritten to make use of RPCs. 3.3

Accessing Services Through Name Servers

The fourth and nal assignment is the rst one in which students actually use TCP, UDP, and sockets directly. For this assignment, students write two programs, a server that elds requests from remote clients, and a client that interacts with servers, both their own and servers provided by other students. The centerpiece of the assignment is a name server we provide called oracle 3. The oracle server acts as a central white pages registry that stores information about the services provided by student servers. The main information maintained by the oracle consists of service (name, description, transport address) triples. When a server rst starts up, it obtains a local transport address at which the server can be reached and sends a UDP message to the oracle containing a short name for the service (e.g., \date"), a short description of the service (e.g., \get current time and date"), and the transport address clients can use to connect to the server. Figure 2 shows the interaction between clients, servers, and the oracle. Once a service has been registered, a client accesses it by sending a query to the oracle asking for the transport address at which it resides. All the interactions with the oracle take place using UDP as the transport protocol. Once the client has obtained the server's transport address, it simply opens a TCP connection to it. In addition to asking about speci c servers, the oracle can be asked to return information on all available services, and one of the client's functions is to provide users with a directory listing of the oracle 's current contents. When two or more students pick the same service name, a particular service can be disambiguated by giving the user id associated with a provided service. To make the assignment fun and interesting, students have the freedom to invent and 3 The oracle server was designed and implemented by Prof. Tim Korb at Purdue University. We are grateful to him for making it available to us.

TCP Connection Client

Server (to invoke a service)

UDP queries (to locate a service)

UDP queries (to register a service)

Oracle

Figure 2: Interactions between the client, server, and the oracle . design servers that provide whatever service they choose. The only constraint on a service is that all client-server interactions be through the TCP connection and that the interactions consist of strings intended for human consumption. Thus, a client can invoke any service by establishing a TCP connection with the desired server. Once a connection has been established, the client simply copies keystrokes from the terminal to the server and copies output from the server to the terminal. An end-of- le indication from either the keyboard or the TCP connection terminates the session. The oracle assignment has several goals. First, it introduces students to the need for name servers to locate and access remote dynamic (temporary) services. Second, using oracle to register services provides a practical way of having students write their own servers without having to give out well-known port numbers. Third, the oracle interacts with client and servers using single request-response message transactions encapsulated within UDP datagrams. Because students create servers that use TCP, the assignment exposes students to both datagram and stream-oriented communication. Finally, the use of sockets takes students through the steps of such Unix system calls as socket , bind, and connect , as well as library routines for mapping host names to internet addresses.

4

Homework Assignments

We give approximately six written homework assignments in addition to the programs. The homeworks are not intended to require a lot of time, rather, they are intended to force

students to stay up-to-date with the material covered in class. Typically, students answer selected questions from the texts, or those taken from lectures. We have also found it useful to ask questions related to the programming projects either while they are working on them or after they have been completed. For example, while the use of rpcgen for the RPC project seems appropriate given the wide-spread use of RPC stub-generation tools, students can also complete the project without necessarily understanding the details of how the RPC stub procedures actually work. Thus, we have asked questions about how the rpcgen -generated server obtains UDP and TCP port numbers, how a client obtains the transport address associated with a particular remote program, and so on. Comparing and contrasting the services of the oracle server with Sun's portmap (Sun's counterpart to oracle ) is also useful. For the graduate students, we make it a point to also have them read at least two research papers. Reading and reporting on papers has two bene ts. First, our course is a prerequisite for a follow-up networking course that consists entirely of readings from the research literature. Because most students have never read such papers before, they have little idea of what to expect. Indeed, the prospect of reading 40-50 papers can be quite intimidating. Second, it provides a means of demonstrating that the concepts and issues discussed in the text are not always universally accepted by all scientists, and that there are several sides to every issue. The choice of which papers to read, of course, is crucial. They must be well written and thought provoking. As mentioned earlier, one paper we have given is Boggs et al. paper Measured Capacity of an Ethernet: Myths vs. Reality [5], which provides a stimulating perspective of the Ethernet's intrinsic performance. Other papers we have assigned include Saltzer et al.'s End-To-End Arguments in System Design [10] which provides an interesting perspective on the design and functionality of layers in the OSI reference model.

5 5.1

Evaluation and Perspective Prerequisites

Our course has three main prerequisites. First, students should have taken a basic course in probability. Although probability is only used in a few places in the course, it is extremely

helpful when talking about the performance of the ALOHA and CSMA/CD protocols. Second, students should be comfortable writing moderately large programs (e.g., 500-1000 lines of source code) in a conventional programming language such as C or Pascal. While our projects can be done in a straightforward manner in 300-500 lines of code, students aren't always articulate programmers; inexperienced programmers can make the projects more dif cult than they are intended to be. Finally, students should be comfortable with such basic data structures as linked lists and should either already know C and Unix, or know at least one conventional programming language well enough that learning C is a matter of syntax rather than semantics. In practice, the programming aspect of the course has been dicult for some students, particularly those having undergraduate degrees in areas other than computer science. To help get students up to speed, we have given one or two introductory assignments whose purpose is to help students become comfortable with programming in C and using such Unix tools as dbx and lint. To ease the burden of later assignments, the introductory assignments can include calculating checksums (for use with the data-link layer assignment) or writing simple scanning and parsing routines for reading interactive commands. 5.2

Student Feedback

Student feedback on the course has been overwhelmingly positive. While the workload is fairly heavy, students feel that the material learned justi es the work load. Student feedback on the course comes from two sources. First, some students report their impressions directly during oce hours and after class. In addition, we solicit feedback from students through anonymous surveys 4 asking various questions about course content and organization. When asked about the programming projects, many students indicate that the datalink layer assignment (and the sliding window protocol in particular) was the most dicult. At the same time, however, students overwhelmingly choose it as the best and the most bene cial assignment. Students cite three important bene ts: reinforcing the importance and practical aspects of layering, forcing students to think about all the subtle cases the sliding window protocol must handle, and demonstrating just how dicult it is in practice 4 Feedback is obtained through an anonymous course evaluation conducted by the department whose results and analysis are made available to instructors only after nal grades have been assigned.

to work out all the bugs in network protocols. In addition, the only projects that were mentioned as \boring" or \worthless" were those designed to get students familiar with the Unix environment. Of the four major projects, none was suggested for omission from future oerings of the course. The most common complaint was the fast pace of the course, particularly from undergraduates. Some students also felt that the programming projects were too hard, though no one indicated that they weren't bene cial. For the oracle project in which students create their own servers, several students have created novel services. One server allows users to unregister services from the oracle. While the actual protocol for doing this is simple, it provides a useful service in practice: should a registered server terminate unexpectedly, the oracle continues advertising the service. Having an \unregister" service allows students to easily purge the oracle database of invalid entries. Another common approach was to take an existing program written for another course and convert it into server that gets its input from the TCP connection. An example program in this regard included an anagram generator. Finally, some students created server programs from scratch. Examples of such servers include a front end to the domain name system, a listing of times and places for courses, a multi-user chat program, an \Ask Bart Simpson questions" server, and of course, an echo server. 5.3

Weaknesses

One of the glaring weaknesses of the course is lack of a large component on performance evaluation of computer networks. We brie y analyze the performance of ALOHA and CSMA/CD protocols at the level presented in Tanenbaum. Also, the discussion of ow control includes rudimentary performance analysis of the stop-and-wait and sliding window protocols. However, the course does not address the basic aspects of performance analysis including modeling, simulation, measurement techniques, and data analysis. Even though only a separate course can do justice to this important aspect of computer systems, it may be appropriate to replace one of the programming projects with a performance evaluation exercise that includes simulation of alternatives for routing, ow control, or congestion control. A recent textbook on performance analysis by Raj Jain [11] provides excellent case studies for this

purpose. Another omission is the discussion of protocol speci cation and veri cation. Again, a one-semester introductory course simply cannot do justice to all the aspects of networking. However, future oerings of the course may replace or reduce discussion of some topics with the presentation of a protocol speci cation technique such as the nite state machine model or petri nets. Apart from these weaknesses, we found the available textbooks lacking in one respect. While Tanenbaum's book does an outstanding job in presenting all the layers of ISO protocol stack in great detail, its broad focus includes only cursory coverage of the TCP/IP protocol suite. Likewise, while Comer's book provides an excellent coverage of the TCP/IP Internet protocol suite, it provides only cursory coverage of physical and data link layer protocols and general OSI reference model topics. Given the diering focuses of the two books, and the large amount of material covered in each, it seems dicult to imagine a single book covering both topics adequately. Still, having two textbooks signi cantly increases the amount of outside reading students must perform. In addition, there is presently no textbook that integrates the discussion of ISO protocol layering with the implementation aspects as is common with compilers [12] and operating systems [13, 2]. A recent book by Comer [14] on TCP/IP implementation could serve as a good basis for a course that concentrates on the theory and implementation of the TCP/IP protocol suite. The TCP/IP suite, however, omits some of the layers in the ISO protocol stack. It would be interesting to see a textbook integrate discussion of the seven layer ISO protocol stack with a toy programming project that includes ingredients from each layer.

6

Summary and Conclusions

We have described the curriculum contents and experience obtained in the teaching of an introductory course in computer communication networks. The course has been oered twice, both at the University of Kentucky and the State University of New York at Albany. Student response has been overwhelmingly positive. Although we cover a large amount of material, and assign demanding programming projects to demonstrate abstract topics,

students gladly put up with the work because of the high quality, relevance, and amount of information learned.

7

Acknowledgments

The original oracle program was written by Tim Korb at Purdue University.

References [1] Douglas E. Comer. The costs and bene ts of a teaching laboratory for the operating systems course. Technical Report TR-CS-589, Purdue University, Computer Science Department, West Lafayette, IN 47907, March 1986. [2] Andrew S. Tanenbaum. A unix clone with source for operating systems courses. Operating System Review, pages 20{29, January 1987. [3] Andrew S. Tanenbaum. Network Protcols. Prentice Hall, 2nd edition edition, 1988. [4] Douglas E. Comer. Internetworking with TCP/IP: Principles, Protocols, Architecture. Prentice hall, 2nd edition, 1991. [5] David R. Boggs, Jerey Mogul, and Christopher Kent. Measured capacity of an ethernet: Myths and reality. In SIGCOMM 88. ACM, August 1988. [6] John M. McQuillan, Gilbert Falk, and Ira Richer. A review of the development and performance of the ARPANET routing algorithm. IEEE Transactions on Communications, COM-26(12):1802{1810, December 1978. [7] John M. McQuillan, Ira Richer, and Eric C. Rosen. The new routing algorithm for the ARPANET. IEEE Transactions on Communications, COM-28(5):711{719, May 1980. [8] David R. Cheriton and Carey Williamson. Vmtp as the transport layer for highperfromance distributed systems. IEEE Communications Magazine, pages 37{??, June 1989. [9] David R. Cheriton. VMTP: Versatile Message Transaction Protocol. DARPA Networking Information Center, February 1988. RFC 1045. [10] J. H. Saltzer, D. P. Reed, and David D. Clark. End-to-end arguments in system design. ACM Transactions on Computer Systems, 2(4):277{288, November 1984. [11] Raj Jain. The Art of Computer Systems Performance Analysis; Techniques for Experimental Design, Measurement, Simulation and Modelling. John Wiley & Sons, 1990. [12] Charles N. Fischer. Crafting a compiler with C. Cummins Publishing Co., 1991.

[13] Douglas E. Comer. Operating System Design The XINU Approach. Prentice Hall, 1984. [14] Douglas Comer and David Stevens. Internetworking With TCP/IP Vol II: Implementation and Internals. Prentice Hall, Inc., 1991.