[PATCH] [RFC] Babel: Implement route daming with fixed delay

[Daniel Gröber]

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:
> 
> [1] https://arxiv.org/pdf/1403.3488.pdf


> 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