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
