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
Hi Juliusz,
On Tue, Mar 07, 2023 at 01:20:28PM +0100, Juliusz Chroboczek wrote:
> I have no signal processing background whatsoever; to my eyes, signal
> processing is a fairly advanced for of magic. (My background is in logic
> and programming languages.)
>
> To be honest, we hacked things
> I would approach the stability problem from an electronics/signal
> processing/control theory background.
I have no signal processing background whatsoever; to my eyes, signal
processing is a fairly advanced for of magic. (My background is in logic
and programming languages.)
> Frankly I
Hi Juliusz,
On Mon, Mar 06, 2023 at 03:59:14PM +0100, Juliusz Chroboczek wrote:
> > In order to prevent RTT based routing from causing persistent traffic
> > oscillations we delay core rte announcement of each prefix by a
> > configurable but metric invariant amount of time.
>
> Could you please
Hi Daniel,
> In order to prevent RTT based routing from causing persistent traffic
> oscillations we delay core rte announcement of each prefix by a
> configurable but metric invariant amount of time.
Could you please explain how that works? How does it interact with
cost smoothing and route
In order to prevent RTT based routing from causing persistent traffic
oscillations we delay core rte announcement of each prefix by a
configurable but metric invariant amount of time.
Initial announcements and withdrawals will go through undelayed but a
chnage in route for a prefix will cancel
