Re: [babel] New Version Notification for draft-ietf-babel-rtt-extension-06.txt

[Pascal Thubert <[e-mail]>]

Hello all

I’m good with either. 

Most OSes we deal with are non deterministic meaning that scheduling the packet (handling is not within interrupt) happens when possible but not at a fixed duration after reception.

 Unless the OS is consistently overloaded this should be negligible vs transfer latency and filtered out during consecutive tries; but certainly this is asymmetrical. 

The usual caveat with time measurement is that the return path might differ from the way in. Even what seems direct at L3 can be tunnels underneath. But we divide by 2 the round trip meaning that we are probably pessimistic one way and optimistic the other.

But does any of that matter? If the metric is roughly constant over time and noise is filtered we can certainly route with it. 

Now, If there’s a huge lower layer path assymetry then we will not get the “best“ path for routes that use this segment but should not when we are optimistic and routes that should have used it when we are pessimistic.

I thought all this could be discussed but none of this impacts the protocol operations. It’s more about setting the expectations correctly.

A bientôt;

Pascal

Le 18 avr. 2024 à 16:57, David Schinazi <[e-mail]> a écrit :



Thanks Juliusz, this helps.

First, to set the stage - I'll be happy with any option you select, this is just to assuage my curiosity.

In terms of the differences between the various options:

1) ease/possibility of implementation

This one is important, but - if we assume that all implementations don't need to match - then we can just say "SHOULD implement as low in the stack as you can" and everyone can do that on whatever platform they are

2) symmetry

As you point out, since RTT is the sum of both one-way delays, it will always be symmetric :-)

3) scheduling jitter

I would assume that it's best to not count scheduling jitter since that'll most likely pollute the measurements and not impact the actual flow of packets along this route

I guess the bit I'm not sure about is the assumption that I mentioned above: the fact that implementations don't need to match. Is there any reason why we'd want them to match?

David

On Thu, Apr 18, 2024 at 7:41 AM Juliusz Chroboczek <[e-mail]> wrote:

> Properties of δ:

>   - it's not symmetric (it only includes local queueing delay);

> Properties of η:

>   - it's not symmetric;

Sorry, that's not correct.  All three measures are symmetric.  Mills'
algorithm is just too brilliant for my small brain to encompass.

-- Juliusz