Results

Source Code

Our source code with configuration and documentation can be found at https://github.ncsu.edu/ipolins/csc591sdn

Testing Results

As seen in the table above, each of the test plans passed without any problem. However, the test plan did not account for how the demo was going to be executed and there is one case that fails in the demo but not in the local testing. Both Neighborhood Watch implementations were developed expecting to be called from the command line, and during testing everything worked fine. In the demo we decided it would be easier to run the daemons as services. Since the daemons were not developed with this in mind, the daemons do not clean up properly when the service is stopped. This is not a failure of the script but rather a failure in the use of the script. To get around this in the demo we wrote an additional bash script that did the clean up on each host.

Screenshots of the testing can be found in Appendix A of the final report.

Self-Study Evaluation

Our evaluation can be found in the report below.

Project Reflection

Team Learning Experiences

Isaac Polinsky: I learned a lot about Linux Kernel networking internals, such as the main data structures and packet processing but it was unfortunately not enough to develop a kernel module as we expected. As a result I learned more about userspace tools, networking devices, and artificially causing congestion to get the information we wanted. On the development side, I learned a lot about ZeroMQ and message queueing architectures and how to use them to implement our protocol. I also learned when developing a schedule it is best to allocate more time to tasks you have very little experience in and that it is important to identify when you are spending too much time on a given task and need to start looking into alternative approaches.

Ankith Divakar Raja: I gained a lot of information in how to design and set up a network on GENI and automating manual steps by developing bash scripts. Gained valuable information on the working and usage of zeroMQ queue management library which helped in a speedy development of the code to coordinate the drop probability between routers. Learnt to use different tools to simulate and monitor queues on ingress and egress interface of routers using ifb tc netmq linux commands. Also learnt the importance of active queue management in tuning different parameters (tradeoff) to achieve optimal performance of the required parameters (delay,jitter).

Sampreetha Naattamai SureshBabu: I learned about setting up a network on GENI and configuring the nodes in the network in order to have connectivity between them. I also learned how to automate the configuration by writing bash script. I also came to know about ZeroMQ library which enables easier socket communication between concurrent applications. I also learned about using network performance measuring tool, iperf and the various options that it supports. Also, I learnt about how delay and jitter are co-related and the parameters that impact the overall network performance.

Yichi Zhang: I learned a lot some basic stuff like how enable multiple remote ssh access, how automated parse config file and how automated frequently manual job (like install software and execute various service for each individual machine). I learned how RED work and extract the core part with adjusted parameter. I practice to measure several common metric in network(packet drop, queue, latency, jitter, file transfer time) and also how visualize with help of wireshark. Find out ZeroMQ publisher/subscriber mode work for us and the way to create congestion is the biggest challenge, from where I learn how zmq basic workflow and ifb netem with tc command.

Expectations

Throughout the development of this project a lot had to be changed based on our knowledge and time constraintants. The rest of this section discusses what went as expected, what things did not go as expected, and limitations of our project.

Going into this project, we expected dropping at the previous hop egress to aid in easing congestion at a router and improve network performance, such as latency and network jitter. After testing, we were very pleased in the noticeable reduction to latency and jitter compared to the base case and very surprised in the reduction to upload time in a congested network. Our peer to peer network implementation exceeded our expectations of development time. Initially, the coordination between peers and message passing was expected to take a large amount of our time and be very difficult. Fortunately, we discovered the ZeroMQ Python library could be east used to implement our protocol. ZeroMQ was so easy to use and quick to develop that we ended up using it in our SDN design as well (discussed as a failure below).

Although some expectations were met, our design had to be changed many times due to time constraints and lack of knowledge. Initially we had hoped to write a kernel module that could report the size of the ingress queue for every device on a router. This failed for many reasons, one we had very little knowledge about the networking internals of the Linux kernel and our research found very little help. Although we ended up learning a lot about the Linux kernel and the data structures it uses for networking, we were unable to construct a kernel module to report this information. It was unclear if we were using the wrong data structures or if we are struggling to cause congestion at the ingress queue. In general, causing congestion turned out to be more difficult than anticipated, but causing congestion specifically on an ingress device was particularly difficult. Due to these problems we had to emulate congestion on the ingress device. Since we could not find a way to report ingress queue size from the kernel and all userspace tools only reported egress queue congestion, we decided to use the IFB kernel module to create a virtual device for every device present on a router. We then redirected all ingress traffic to the router to these IFB devices. To cause congestion we then rate limited the egress traffic of a given IFB device. Thus the resulting egress traffic congestion of an IFB device translates into the ingress congestion of the original device. Unfortunately this was not ideal, but it allowed us to continue development and evaluate our system and approach. The final shortcoming of our project was we expected to use OpenFlow and implement Neighborhood Watch as a application to run on a Software Defined Network controller. Unfortunately, due to time constraints we only made slight modifications to our peer to peer network and did not work with OpenFlow at all.

Finally, during the implementation of our project we identified additional things we would have liked to do but had not thought about in the beginning and did not have time to do it in the end. For example, our base case does not use any Active Queue Management techniques and we compare our implementation of an AQM technique to this base case. Future work should explore how Neighborhood Watch compares to existing AQM techniques, such as RED. In addition, future testing should be done with a more robust traffic generator tool, and many more hosts with more data collection than what was done in our Self-Study. We believe our results show good preliminary information, but given more time we could have design an evaluation that could potentially find more corner cases to compare the different implementations.