The ONL NPR Tutorial

Course Material >> For Instructors

TOC

The remarks below should help instructors make more effective use of ONL in their courses. If you are using ONL in a course for the first time, you should look at Tilman Wolf's ONL exercises. He has had three years of very successful experiences with ONL. (However, keep in mind that his exercises used the older NSP routers.) I will explain below why I think it was successful.

Note that his course was aimed at non-networking graduate students and fulfilled a breadth requirement in their department. So, the students were not undergraduates. His students were able to do the exercises even though they were not networking students, and he did not devote any lecture hours to ONL itself. That is, the students knew a little about networking, but not much; and Tilman was able to offer lab assignments with very little effort on his part.

In order to better appreciate my comments, let's take a look at some topics that were typically covered in his exercises:

• Lab 1
  • Using a preconfigured experiment file and developing a personal experiment file
  • ONL routing tables
  • Basic networking Unix commands (ifconfig, ping, netstat)
• Lab 2
  • TCP and file transfer using the scp command
  • Generating UDP and TCP traffic with the iperf command
  • Queueing and monitoring queue length
• Lab 3
  • The behavior of traffic from a mix of a UDP and a TCP stream through a bottleneck link in a dumbell topology
  • Comparing the performance results from ONL with those from ns-2 simulations
  • The impact of buffer space on TCP performance using ns-2 simulations
• Lab 4
  • Analyzing properties and packet statistics from a network traffic trace using libpcap
  • Writing a program to record per-flow statistics

• Generating traffic with the tg tool.
• Capturing packet traces using the tcpdump tool (or ONL's tcpdumpW tool, a wrapper for tcpdump).
• Analysing a space-time diagram.

Here are some guidelines for why his course was so successful and how you can be as or even more successful:

• You should do the assignment before distributing it to students.

  Nothing can be more infuriating than working on a problem that can't be done in a reasonable amount of time. You will get a feel for the appropriateness of the assignment if you work out the solution before your students do.

  The ONL uses real hardware. So, measurement results won't be exactly what you might expect from a simulation or analytic equations. You won't get a good sense of how much deviation from the ideal actual measurements will be unless you do the assignment.

  Note that parts of some exercises were done off-line; i.e., without reserving ONL resources. He realized that students shouldn't be holding onto scarce resource (routers) unnecessarily. There are only seven pairs of NP routers. Those things that can be done without actually holding resources should be done off-line (e.g., setting up a topology).

  Furthermore, students should spend some time thinking about the conduct of their experiments and do some preparatory work (e.g., think about what should appear on charts) before actually using the testbed.

• Each assignment should contain a clear statement of its main objectives and contain clear instructions.

  This is obvious but not always followed. For example, instead of asking a student to "provide an analysis of the experimental results", ask them to provide a screen shot of specific bandwidth and queue length charts and explain specific characteristics of these charts and their relationships. Also, provide a clear grading guideline. A good starting point is this grading rubric by Tilman Wolf which he posts as part of the assignment materials.

• Proactively deal with potentially frustrating aspects of an assignment.

  There will be potential areas for confusion. Doing the assignment beforehand will help identify these potential frustrations. The two most confusing issues seemed to be:

  • Building the SSH tunnel:
    The Getting Started link in the sidebar of the ONL Web page will lead you to a page containing the SSH Tunneling page that gives recipes for building the SSH tunnel required by the RLI. You can't do anything without building this tunnel. The Web page also explains how to save the definition for reuse so that it is easy to rebuild the tunnel. We suggest that the first assignment should be to follow the instructions in the Getting Started page and if a student fails to successfully build his/her tunnel after one try, that student should see a TA for assistance rather than waste any more time.
  • Reservation start time:
    Reservations are stated in terms of St. Louis time (CST or CDT), NOT local time. We could fix this problem, but we have been dealing with more pressing problems.
  • Commit required:
    Any time you change a configuration parameter (e.g., link rate) you need to select File => Commit to get the testbed to install the change. Otherwise, you are just using the previous settings. Monitoring windows, though, are updated immediately and therefore, don't need a Commit.

  Once students got over these two issues, they didn't have many major problems. You and/or your teaching assistant can make it easier by settling on a standard approach to building the SSH tunnel and reminding your students about the reservation clock issue.

• Limit most assignments to using just one pair of NPRs.

  Most basic concepts can be explored using just one pair of NPRs. We only have seven pairs of NPRs and often, atleast one or two pairs are in test mode. Even if a project will eventually require more than one pair of NPRs, you can test basic things using just one pair. For example, students shouldn't be reserving two or three pairs of NPRs just to see if he/she understands how netmasks work.

• Provide prompt feedback to your students.

  Most problems that students encounter can be handled by email. If dealt with promptly, student enthusiasm and confidence will remain high. What has worked in the past is to have a course FAQ that records the most recurring problems and their solutions. The ONL staff can also backstop you and your teaching assistant by answering questions that you can not easily resolve.
  Sometimes a student question can turn into a teaching moment.

• Tie an assignment to topics covered in lecture.

  ONL assignments should reinforce concepts covered in class. You can improve knowledge retention if you have students work out paper and pencil exercises on conceptual material covered by a lab assignment. For example, if you are doing a queueing lab assignment, students should have worked out queue length behavior for several cases before doing the lab assignments.

• Organize an assignment so students can make immediate progress.

  One approach is to give the students a configuration file that is known to work and have them work with that before they create their own file. This approach will help isolate misunderstandings about ONL before they become a stumbling block and reduce the chance of a student losing confidence.

• An assignment should be structured so as to lead the student to insights and build on fundamentals.

  "Canned" lab assignments that only ask the student to follow a procedure won't help a student develop the skills required of real engineers working on real problems. Chapter 5 in Teaching Engineering by Wankat and Oreovicz gives some guidance in this area.

Course Material >> For Instructors	TOC