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

[Juliusz Chroboczek <[e-mail]>]

CC-ing Pascal, since his review is what prompted the discussion.  Pascal,
please feel free to chime in if I say something stupid.

> 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.

There are three distinct measures of RTT in this discussion:

  - Δ: measured at the top of the stack (between layers 7 and 4), which
       includes the local queueing delay;
  - δ: measured at the bottom of the stack (somewhere around layer 2),
       which does not include local in-kernel queueing delay (but might
       include hardware queueing in the network interface);
  - η: hybrid RTT, where outgoing packets are measured at the top of the
       stack, and incoming packets are measured at the bottom of the stack.

I am arguing in favour of Δ.  Toke is arguing in favour of η.  Nobody is
arguing in favour of δ, because you guys are growing old and reasonable.

Properties of Δ:

  - it's easy to implement on all reasonable systems;
  - it's been deployed for 7 years, with no ill effects;
  - it's symmetric (it includes both local and remote queueing delay, so
    two peers are going to calculate roughly the same Δ);
  - it includes scheduling jitter.

Properties of δ:

  - it's impossible to implement without either very specific kernel
    support or interleaved encoding (see draft-ietf-ntp-interleaved-modes);
  - it's not symmetric (it only includes local queueing delay);
  - it does not include scheduling jitter.

Properties of η:

  - it can be implemented with existing kernel interfaces, at least on Linux;
  - it's not symmetric;
  - it does not include scheduling jitter if implemented right;
  - it's likely to be very close to Δ (since it includes queueing delay).

Here are the current opinions:

  - Pascal, if I read him correctly, is happy with either measure as long
    as we specify clearly which one is being used;
  - Toke is going to implement η, but he's okay if I specify Δ, since the
    two values are very close in practice;
  - I've specified Δ in the current draft, but I'm fine with Toke
    implementing η instead, since the two values are very close in practice.

By the way, if people are interested in implementing δ, then it would require
an all-new protocol extension, one that does interleaved encoding.  So
I suggest we leave this for potential future work, together with one-way
delay measurements.

-- Juliusz