The Reasoner consists of three components:
- the fault simulation controller
- the machine learning component
- the automation Reasoner
The fault simulation controller is a collection of tools developed by TID to automate the simulation of various network and hardware constrains that are known to affect the performance of video streaming on mobile devices. The devices that are coordinated to simulate a fault are the mobile device, the gateway/access point, the video server and a wired client that acts as a background traffic generator.
I - The fault simulation controller
Dependencies:
- Server, Traffic Generator: Linux with the following installed sh/bash, screen, python, curl, tstat, iperf, D-ITG, tc + netem, stress
- Router: Open-WRT with the following installed sh/ash, screen, python, curl, tstat, iperf, tc + netem, stress
Installation and execution:
- Simply extract the corresponding tarball to each of the devices
- Run "./startup_controller.sh start" in each of the devices
- On the server run ./experiment_controller.sh <fault>*
- When the experiment is done, run "./startup_controller.sh stop" in all the devices
*supported faults: lan_congested, wan_congested, lan_shaped, wan_shaped, router_stress, mobile_stress, server_stress.
II - The machine learning component
You can run the standalone classifier (using the Weka executable) or perform it within the automation Reasoner (described below). Before the generation of the model, we need to perform feature reduction. The standalone version for doing so (given the training set) is:
java weka.filters.supervised.attribute.AttributeSelection \
-t <training_set.arff> \
-E "weka.attributeSelection.SymmetricalUncertAttributeSetEval" \
-S "weka.attributeSelection.FCBFSearch" \
-o <feat_red_training_set.arff>
Afterwards we can generate the training model:
java weka.classifiers.trees.J48 \
-t <feat_red_training_set.arff> -k \
-d <j48.model>
Testing of the trained model on the new dataset
java weka.classifiers.trees.J48 \
-T <test_set.arff> \
-l <j48.model>
III - The automation Reasoner
The automation Reasoner is responsible to fetch new measurements from the mPlane repostiory (once a video flow has terminated) for every available probe along the path, and pass it through the machine learning component.
In current implementation, the process is triggered by one of the probes (i.e., the mobile, router or server probe is reporting that one of the video sessions has finished). This occurs over an HTTP GET request with a video_ID. Afterwards the controller pulls data from the repository, performs feature reduction and construction and then returns the classification label back to the repository.
Code Availability
Below you can find the corresponding scripts and other tools needed to run the aforementioned steps.