development

Development notes

Todos, fixmes, and other notes and thoughts concerning development.

Custom routing paths

Currently, vim-emu computes routing paths as shortest paths according to hop count. To be consistent with the placement algorithms, I created a workaround that uses shortest paths according to edge delay.

In the long term, vim-emu and this PEF should be adjusted to support arbitrary, custom routing paths, e.g., specified by a list of PoPs.

Integer link delay

The emulator can only deal with integer values as link delays, i.e., link delays are rounded to full integers in ms. Currently, this happens both at the placement emulation (for emulating the network) and at the placement (for calculating the best placement. They both use the same procedure rounding in the same way to obtain and work with the same integer link delays.

Problem: In networks with short node distances, e.g., Colt, many link delays are below 1 ms and are rounded to 0 ms! This leads to whole chains being placed at different nodes with 0 ms link delay.

Approach: Introduce some kind of delay factor that we use to multiply link delays before rounding to achieve higher resolution of link delays. For example, instead of rounding 1.43 ms to 1 ms, multiply by a factor of 10 to get 14.3 ms, which is rounded to 14 ms. Then the placement emulation is performed and the recorded measurements are divided by the same factor to get the actual delays. For example, for a measured delay of 15.22 ms and a factor of 10, we then get 1.522 ms.

Problem: This would allow to get higher link delay resolution, i.e., consider sub-ms link delays. But it would also reduce the effect of any other delays, e.g., VNF processing delays, which are also divided by the delay factor.

The implementation is also non-trivial. We could multiply link delays at the placement emulation when reading the network and pass the network with increased link delays (e.g., with 14 ms instead of 1.43 ms). But then we would still have to divide the obtained placement delays before writing the result, i.e., inside the placement. Or change the result files afterwards. Alternatively, we could compute and pass a separate network for the placement algorithm that simply has higher link delay precision. For a delay factor of 10, we allow one decimal place for link delays (e.g., 1.4 ms).

Non of these solution is ideal and it will always distort the measured results somehow. Thus, I'd implement it later on (if at all).

Todos

• Proper REST API
• Non-linear service chains
• Custom routing paths
• Auto-assigning IPs and configuring the network to support multiple sources or instances (due to scaling)