The Calvin Emulab was intended, primarily though not exclusively, to be used in the Advanced Computer Networks Course, CS332, which is taught every other year during the Fall semester. Since it was being offered during the Fall of 2006, it was very important that it be up and running at that time. Alas, there were delays, but about one third of the way through the semester, it was capable of running experiments, and the students began to use it.
There was a side benefit to the doubts as to when the Emulab would be ready, a more logical flow to the assignments than usual. We began with Chapter 6 in Douglas E. Comer's Hands-On Networking with Internet Technologies. In Experiment 6.2 students modify echo client and server software that uses a simplified API to use the socket API. I modified the assignment so that instead of echo software the students produced a simple file transfer client/server. The client sends the name of a file to the server, and the server sends back the contents of that file in small packets. Since the software provided was based on TCP, so, of course, was the file transfer software.
For the second assignment, the students rewrote their TCP file transfer software to use UDP.
For the third assignment, the students moved into Chapter 8. They modified their UDP file transfer software to send datagrams through a provided gateway that randomly dropped, corrupted, duplicated, and reordered datagrams. The goal was to produce reliable file transfer through this unreliable gateway. Simultaneously, students were acquiring Emulab accounts and (supposedly) trying simple experiments. The student who had made the most progress performed a variation on the gateway assignment. Instead of using my unreliable gateway, he simply wrote an Emulab experiment with a pair of nodes joined by a link that dropped packets.
At this point, students had both TCP and UDP file transfer client/server suites. Time for an experiment that Jonathan Shapiro, at the time a Professor at Michigan State, showed me. Set up two nodes with a link of limited capacity, start a TCP file transfer over that link, watch it for awhile, and then start up a UDP file transfer over the same link. I was concerned that the students would have trouble setting up the parameters in such a way that they would see the desired effect, but that was not the case. They were able to see the "polite" TCP traffic reduced to crawl as the "rude" UDP traffic just kept going.
For the final project we chose two teams each of which did an experiment involving multicasting. One team, led by Tim Brom, decided to install a multicast library as part of their experiment. However, we did not have an image that supported multicast. Tim simply changed a parameter and recompiled the kernel. What happened next was anything but simple. The new kernel took so long to load that the nodes timed out consistently. The bad news was that this killed the project, but the good news was that Tim was able to find out why the images were taking so long to load and fix the problem which improved overall Emulab performance by a factor of about 12. ADD LINK.
Part IV of Professor Comer's book is titled Configuration Experiments In A Dedicated Intranet Lab: Network Configuration Experiments That Can Be Carried Out In A Completely Dedicated Intranet. Note the phrase "Completely Dedicated". Calvin College is so fortunate as to have a Systems Lab which contains three year old machines, nine Cisco routers, switches, hubs, and lots of cabling. It is possible to configure just about any small network you need. Nevertheless, it is not "completely" dedicated, as it is often used by two courses during the same semester, and conflicts do arise between configurations required by the two courses at roughly the same time. It is my belief that nothing can beat the experience of checking out several pcs, a Cisco router, a hub or switch, and building a network, but part of our project was to demonstrate that many of these experiments can be carried out in an Emulab environment. Hence, a small school without a "Completely Dedicated Internet", can apply to start a project at one of the many Emulabs, and do much of what Professor Comer has in mind.
One thing students miss by doing these experiments on an Emulab is the physical connecting of networks. It might seem that another thing they miss is setting up routing because Emulab experiments tend to come with routing already set up. For that reason I devised a special experiment to give students the routing experience.
As I have gone through this part of Professor Comer's book, I have found some experiments that are very amenable to an Emulab solution, some that (at the present time) do not seem so amenable, and at least one that is harder in an Emulab environment but whose challenges have a high payoff in what can be learned. I have prepared separate notes for the experiments that I have been able to do on the Calvin Emulab. These notes are now available (to faculty only) at the web site accompanying the book.
Had it not been for the aforementioned Jonathan Shapiro, we would have gone into the Emulab project with no Emulab experience. Sometime in 2004 we tried to get a joint research project started with students from Michigan State University and Calvin College. For various reasons it was very difficult for the Calvin students to keep up (mainly jobs!), but Eric Knibbe did produce some work (using BitTornado for variety) that makes an interesting illustration of how to use some advanced Emulab features and why you want to do so.
Eric's first experiment simply sets up some nodes and then lets the experimenter do all the work by sshing to the nodes. Of course, in a serious experiment of this type, you cannot be sshing to 43 clients and starting downloads. So Eric's second attempt, which is dependent on the work of Jonathan Shapiro and his students, is a bit more sophisticated and makes a good example of why you need to do more than set up nodes, ssh to them, and run programs.