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

[David Schinazi <[e-mail]>]

On Fri, Apr 19, 2024 at 9:26 AM Juliusz Chroboczek <[e-mail]> wrote:

> I've reordered your text.
>
> > 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
>
> [...]
>
> > 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?
>
> If two implementations don't match by a significant amount, then the
> protocol will be biased in favour of one implementation.
>
> Suppose that Linux doesn't include local queueing delay and Mac OS X does.
> Then, all other things being equal, the protocol will prefer routing
> through Linux routers rather than Mac OS X routers.  Which is probably the
> right behaviour, but it should be an explicit decision rather than
> a somewhat mysterious side-effect of an implementation detail.
>

Thanks, that's what I was imagining too. Isn't it already the case that two
different implementations could make implementation choices that would lead
one to be prefered over the other? I'm willing to bet that my since-lost
implementation had multiple bugs that would have this unintentional
behavior :-)

> 2) symmetry
> > As you point out, since RTT is the sum of both one-way delays, it will
> always
> > be symmetric :-)
>
> Well, ping is not necessarily symmetric.  If you timestamp ping packets at
> the bottom of the stack, then the RTT measured by ping includes remote
> queueing delay but not the local counterpart.  And the two queueing delays
> are not necessarily equal.
>
> Mills' algorithm, on the other hand, guarantees symmetry.  Good algorithm.
>

Good point, you're absolutely right.

> 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
>
> Agreed, but what if this contradicts requirement (1)?  We need to make
> a choice.
>

I think the two possible choices can be boiled down to:
(A) tell implementers to do the best they can
(B) pick the least common denominator that we know everyone can do

Option (B) guarantees that all implementations behave similarly, but at the
cost of less accurate measurements for everyone. Option (A) gives better
measurements, but can lead some implementations to be selected less. The
differentiator becomes: how common are these implementations that can't (or
don't, or won't) get precise receive timestamps? Every common
general-purpose OS I'm aware of has an equivalent of SO_TIMESTAMP (Linux,
macOS, *BSD, Windows). The environment I'm used to that doesn't have this
feature is ESP32/Arduino, mainly because their network stack is based on
LWIP. That said, such a platform has so many other limitations that RTT
measurements will always be quite imprecise because of how interrupts are
handled. So on that platform, we really will get implementation details
getting in the way of routing no matter what - it's just that it's OS
implementation details instead of Babel implementation details. So I would
posit that we don't need to worry about OSes that don't provide these
precise timestamps. The question becomes: do the existing Babel
implementations want to all progressively switch to more precise
timestamps, or not? From a theoretical standpoint, I prefer (A) to (B), but
at the end of the day I would recommend having the spec match what the real
implementations are doing - or planning to do.

David