Demo Abstract at TridentCom 2012We present the extensions made to NEPI, the Network Experimentation Programming Interface, to allow easy creation and cus-tomization of routing overlays on top of PlanetLab. We particularly focus on demonstrating the traffic shaping capabilities provided by NEPI, with the use of customizable stream filters on PlanetLab overlays to induce controllable packet prioritization. This demonstration is intended to supplement the paper[1] accepted at TRI-DENTCOM'12. We focus on demonstrating the experiment use case presented in that paper, in which we make use of stream filters as a means to control the characteristics of an overlay deployed in PlanetLab, [2] providing a realistic yet controllable environment where to test the POPI[4] tool. NEPI [3] is an experiment management framework which provides support for design, deployment, control and gathering of results of network experiments. We added support for automating deployment and customization of routing overlays on PlanetLab, to alleviate the complexities of performing these tasks manually , and to more easily circumvent administrative limitations. NEPI automates resource discovery, node provisioning, application deployment, and creation of tunnels between the selected nodes to build the overlay network. It also provides the ability to customize traffic in the overlays by adding user defined stream filters , processing functions applied to packets traversing the overlay tunnels. They can be used to implement custom queues, packet filters or transformations, and tunnelling protocols. To demonstrate NEPI's ability to provide a solution to existing problems when using PlanetLab, we selected a previously published experiment case [4]. In this experiment, researchers developed the POPI tool to attempt to infer packet priorities in the intervening routers between two endpoints, by inducing bulk traffic and analyzing point-to-point loss rates. However, in order to verify the results obtained after running POPI on PlanetLab, it was necessary to ask ISPs about their routing policies, because no other means were available to verify that the priorities reported by the tool corresponded to actual prioritization policies
