User login

Blogs

13

Feb

2018

Started integrating the chromium test into AMP, which means being able to run it both standalone (providing my own main function) and as part of the AMP client, and reporting data in the correct protobuf formats.

The way chromium forks and executes itself repeatedly (zygote processes) caused some confusion around why argument parsing was failing, as it was passing through the getopt multiple times with unexpected arguments. It now accepts and ignores the arguments used with zygote processes, letting them pass through to headless chromium.

Found that the timings available to javascript had improved since I last looked, and that I could now fetch the information for the initial page in exactly the same format as the objects in the page, saving a heap of near-duplicate code and getting more accurate information.

13

Feb

2018

Finally successfully linked the chromium libraries with my own test runner after adding a few more compiler flags to match those used by chromium. After getting it linked and running, found it would crash on the first callback made when the page completed loading, complaining about missing vector functions.

Had to rebuild my chromium source as I had been using a debug build, which generated debug versions of some STL containers and caused crashes when other parts of code expected regular containers. It now links and runs and outputs useful data!

13

Feb

2018

Spent the short week trying again to get a useful set of Chromium libraries that I can link my own AMP tests against. Digging into the ninja build configuration I've extracted a list of all the useful libraries that go into building a headless program, as well as the build and link flags that I need to use. Still having issues with the final step where I link with my code, but it's getting much closer to working.

13

Feb

2018

Found and fixed a bug in the BGP prefix code that meant sorting/comparison of prefixes wasn't using some of the attributes that were important for determining differences. Removed some unnecessary special cases and code paths when exporting routes from a peer, which makes the code less complicated and metric collection easier. Added more metrics tracking when route import/export last occurred, how long updates are taking, etc.

12

Feb

2018

This week I spent some time looking at larger topologies that are common in datacenter and carrier networks. I implemented a module which allows creating a dynamic k-arry FatTree topology in Mininet (common in DC networks). I then modified the controllers to find host location in the topology dynamically. This used to be statically specified, however, when implementing the new FatTree topo the pre-specified location no longer worked. Host discovery uses a similar mechanism and approach to RYUs link discovery (LLDP packets) without a liveness check mechanism. So we will only use the packets to figure out where the hosts are in our topology.

I then spent the remainder of the week looking at writing failure scenarios for a FatTree topology of k=4. I have worked on several diagrams that show how path splicing will behave for specific link failure scenarios and also the paths taken for the reactive controller. I am currently in the processing of finishing off a multi-link failure scenario for the new topology and then collecting and processing recovery stats for it.

07

Feb

2018

This week I modified the simulation framework to allow me to perform multi-link timing tests. The failure config file has been modified to allow specifying multiple prober locations. After a bit of initial planning and testing, when dealing with multi-link failures we need to be careful when selecting the logger locations as we may not be able to time that particular link failure. Multi-link failures are now performed sequentially, i.e we take down the first link and time it, then we take down the next and so on.

I then modified the disabled multi-link failure scenario, collected recovery times for it, cleaned up and processed the stats. With this, I have completed the set of recovery time stats for all current network and failure scenarios I have created.

30

Jan

2018

This week was very short due to NZNOG. I worked on cleaning and processing the recovery times I re-collected after the modifications to the timing method of the simulation framework. I have graphed and computed stats based on the collected raw data. I then quickly fixed up comments in my simulation framework and have started looking at my multilink failure scenario. This failure scenario is currently disabled as the reactive and proactive controllers weren't timing the same thing. I am currently in the process of devising a better way to handle multi-link failure scenarios and modifying it so that the recovery times are comparable between the two different controller types.

23

Jan

2018

This week I looked into why the timing results that I collected vary by a large amount for sequential executions of the experiment. After analysing packet traces, I found that TCPDUMP wasn't showing all packets on the primary logger (logger on the primary path directly connected to failed link). When a link is taken down TCPDUMP will crash silently. I was getting packet information by piping TCPDUMPs output to a file. TCPDUMP uses a buffer when it outputs packet information. The buffer doesn't get fully processed when the app exits from a link going down. This was causing fewer packets to be displayed on the output and thus making the results vary by a large margin, depending on the state of the buffer and how many packets were captured. We can fix this problem by running TCPDUMP with the --immediate-mode flag, which disabled the output buffering.

Next, I looked at mitigating the effect of the location of the loggers in the network on recovery time. Because I was using packet timestamps, the location of the logger may affect the recovery time calculation based on the size of the recovery or detour path. I fixed this issue by re-implementing the loggers in libtrace and creating a recovery time calculation app with libtrace. This app will take two packet traces and use the pktgen timestamps to calculate the recovery time. I am also getting packets lost by looking at the pktgen sequence numbers between the traces on the two loggers (last packet on primary logger and first packet on secondary logger). Using the pktgen fields also allows us to place the two loggers on separate switches. Previously we had to have them on the same switch to account for clock differences in the virtual switches.

After these modifications, I have recollected the recovery time stats on my lab machine. I am currently in the process of finishing off the cleaning and re-graphing of these stats.

16

Jan

2018

This week I finished the implementation of all parts of the optimisation mechanism of the proactive controller, which optimises installed recovery paths. While testing I have found several issues and bugs which I have resolved. I then refactored the controllers to clean them up and remove any duplicated code where appropriate. I have also ensured that the controllers have adequate comments.

I then modified the recovery time simulation framework to allow specifying the state for each individual topology. My recovery time framework uses a wait state file which defines the state the network switches (flow and group rule elements), have to be in before starting the failure experiment. This was defined as a per controller file before the modification. Differences in topology may make the wait state mechanism inaccurate. It would have also only worked on topologies that are similar which restricts our simulation testing.

At the end of the week, I have cleaned up, processed and graphed the stats that I have collected which look at the recovery time of the 3 controllers on 3 different topologies using 5 failure scenarios.

08

Jan

2018

This week was a shorter week. I finished implementing the modifications to the proactive controller to allow optimisation of recovery paths. The proactive controller will still use protection to quickly recover from failures at the switch level, however, the controller is made aware of links that have failed. The failed link information is then used to update topology information of the controller and re-compute optimal paths in the network.