[babel] Open issues with draft-ietf-babel-rtt-extension

[Juliusz Chroboczek <[e-mail]>]

Here's my personal take on the issues outlined during Baptiste's talk.

1. Nanosecond granularity

Originally, Baptiste's extension used centiseconds in a 16-bit field,
which gave a granularity of 10ms.  Under Dave Taht's pressure, who was at
the time interested in measuring bufferbloat, Baptiste switched to
microseconds in a 32-bit field.

We still don't have a good example of why this increased prefision is
needed -- in the networks that use this extension in production, the time
scales under consideration are on the order of tens or hundreds of
milliseconds.

Switching to nanoseconds would require switching to 48-bit fields, since
the timestamps must not wrap between two successfully received Hello or
IHU TLVs.  Not a big deal, but a slight implementation issue -- I'd like
to be convinced that this is necessary.

We will be able to switch formats without a flag day.  We first define
a new sub-TLV with nanosecond granularity, and start sending both.  We
wait for a year or so, until most deployed implementations understand the
new format, then we deprecate the old format.  If any old implementations
remain, they will ignore the new sub-TLV, and simply fail to perform any
RTT estimation, falling back to the base protocol.

2. Decoupling timestamps from Hello

Currently, the timestamp data is sent in two pieces:

  - Hello contains the transmit timestamp, which is the same for all
    neighbours;
  - IHU contains the receive timestamp and the timestamp echo, which are
    per-neighbour.

This makes a lot of sense -- after all, IHUs contain per-neighbour data,
while sender data is contained in Hellos.  OTOH, it means that an IHU's
timestamp can only be interpreted if it is sent in a packet that contains
a Hello TLV.

Baptiste outlined two solutions:

  (a) require that all IHUs be sent in packets with a Hello;
  (b) define a new TLV that contains just a timestamp.

In RFC 6126bis, we defined Unicast Hellos and Unscheduled Hellos, which
should in principle make approach (a) easy to implement.  I'd be very
grateful if people could look very carefully at the new kinds of Hello,
and decide whether these mechanisms are enough, or whether we need a new
kind of TLV so we can avoid sending spurious Hellos.

-- Juliusz