Feb 13, 2019

Teaching routing and network security — Daily log

Today I have been mostly teaching or preparing upcoming courses. I also had a nice lunch discussion with colleagues on DNS and the role of transaction IDs, but that story will have to wait until tomorrow!

Teaching routing

I gave another networking course for first year's students today. This was the first practical session where they actually had to plug some cables around: you can imagine the excitement but also the mess! To make things even easier, the course was in a new networking lab I had never been before, so I had to improvise with the hardware lying around.

The students learnt how to configure network interfaces (ifconfig, route & netstat on FreeBSD), and they had to use their prior knowledge of packet capture and ping to troubleshoot when things didn't work as expected. They had to form a simple "chain" topology (shown below) with two subnets, and the computer in the middle needed to be configured as a router. They needed to figure out that static routes were required on both edge computers, so that they knew how to reach the remote subnet through the router. Finally, they looked in details at the behaviour of ARP and the scope of MAC addresses.


Network security course

I then prepared an upcoming practical session on network security with a colleague working for Quarkslab. I already have a good part of the course ready from last year on firewalling and advanced uses of iptables (including compiling custom BPF programs!). My colleague wants to add a part where students will practice ARP spoofing, so we looked at how to integrate that with the existing content.

Interestingly, he showed me how to automate virtual machine generation using Packer. This should be really helpful for future teachers in this course: they will be able to easily customize and rebuild the virtual machine images used by the students! Last year, I installed and configured the virtual machine manually, which makes it hard to update it or apply the same modifications to a new VM image.

Feb 12, 2019

Multipath scheduling simulation — Daily log

Multipath scheduling

Today I mostly worked on my current research project, a simulator of multipath multistream scheduling algorithms.

Multipath scheduling is needed when you want to transmit data over several concurrent paths: which piece of data should be sent on which path? This problem has been made visible by Multipath TCP, since the Linux implementation includes several schedulers that can be changed at runtime. Several new schedulers for MPTCP are being proposed in the academic literature every year: the original LowRTT and its evaluation, Delay-Aware Packet Scheduling, BLocking ESTimation, Earliest Completion First, and many others.

All these algorithms mostly differ in the objective function they try to optimize or in assumptions that can be made for specific data flows (e.g. video streaming traffic). However, they all adopt the semantic of TCP, which transports a single flow of data. I am interested in extending the problem for several streams (have you heard of QUIC?) that need to be scheduled on multiple paths. Instead of a single optimisation problem, you now end up with several concurrent streams, where each stream wants to complete as soon as possible!

Writing a simulator

The goal of my simulator is to quickly obtain an intuition on the behaviour of scheduling algorithms: it provides a graphical and animated visualisation of what's going on over time. The simulator also allows for more in-depth exploration, for instance comparing the completion times of streams for different scheduling algorithms.

Below is a screenshot of the current simulator: it is not very pretty because that's not its goal! The streams are represented by vertical bars whose size equals the amount of data remaining to be transmitted, and the darker parts represent in-flight data. Below are two paths, each modelled as a packet queue with a constant-rate service (link capacity) and a fixed propagation time.

Screenshot of the current simulator

I am writing this simulator in Python thanks to salabim: this is a really well designed, easy-to-use and well-documented simulation framework. I had an initial simulation prototype working in less than one day, and it took only an additional day to add graphical visualisation. One of the reasons it's so easy to use is thanks to Python: I didn't want to spend days implementing complex algorithms in NS-3, even though it would be much more realistic. At the same time, salabim is reasonably fast once you disable logging and visualisation.

After working with salabim some more, I did find some limitations: the programming style around salabim is fine for small simulations, but quickly becomes a mess for larger projects. All examples use lots of global variables, which encourages you to write all your code in one file (after all, this is how salabim itself is developed with its 15k lines in a single file...)