Hi Juliusz, On Tue, Mar 07, 2023 at 01:20:28PM +0100, Juliusz Chroboczek wrote:
To be honest, we hacked things until we had acceptable worst-case behaviour.
We had two networks to experiment with: Nexedi's production network (hundreds of tunnels over the public IPv6 Internet) and a simulated network we built ourselves which we believed represented the worst case (a bufferbloated diamond network). We built a first prototype, which we instrumented to log RTT samples and route flaps, and noticed three things:
1. in the production network, the RTT signal is noisy (see figures 4 and 6 of [1]);
2. in the bufferbloated diamond network, when we switch away from a congested route, we switch back too early, before the buffers have had time to drain;
3. in the diamond network, we tend to switch routes as we oscillate around a common value.
I'm working on comparing the exponential filter behaviour to my damping approach, I was wondering if you still have any scripts/notes on how the simulations for Fig 10 and 11 were setup?
References:
Hence, the three mechanisms:
1. smoothing of the RTT, to makes the signal less noisy; the smoothing is exponential just because it's easy to implement;
2. saturating map from RTT to metric, so that congested routes all appear equally bad, and we don't switch back before the buffers drain;
Re-reading this, was the time until a route is reconsidered made dependent on the metric/RTT difference on purpose to get this draining behaviour? While my timer approach doesn't mirror this currently I'm not opposed to it, I just wonder if metric difference is the right variable here. Thanks, --Daniel