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

Juliusz, can you elaborate on "Well, we want the timestamping to be
consistent between implementations." ? I'm not sure I completely follow why
we want that. If two implementations differ, then the one with the
closer-to-the-hardware timestamp might appear to be a better route than it
is in practice, which doesn't sound like a really bad issue? My gut feeling
is that we should recommend the measurement to be as close to the hardware
as possible to make the RTT samples as accurate as possible. But maybe I'm
missing something.

David

On Wed, Apr 17, 2024 at 2:03 PM Juliusz Chroboczek <jch@irif.fr> wrote:

> > We don't even have a BPF hook that can do this without jumping through
> > a lot of weird hoops :)
>
> Now don't you get any ideas!
>
> > So maybe we should change the text to address the RX side only, so
> > instead of:
> >
> > "and receive timestamps SHOULD be computed just after the packet is
> > received from the network stack."
> >
> > we'd have something like:
> >
> > "and receive timestamps SHOULD be computed at the earliest possible time
> > after the packet is received from the networking hardware.
>
> I'm really not sure.  There's a tradeoff here between engineering
> excellence and implementability.  The wording you're suggesting might be
> difficult or even impossible to implement on some systems (how many
> non-Linux systems have SO_TIMESTAMP?), so I'm not sure I want to recommend
> it.
>
> On the other hand, the distinction is negligible on the receive side, so
> I'm quite happy with BIRD being only conditionally compliant in this case.
>
> -- Juliusz
>
> _______________________________________________
> babel mailing list
> babel@ietf.org
> https://www.ietf.org/mailman/listinfo/babel
>