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

[Dave Taht <[e-mail]>]

I had had a chance to buttonhole baptiste at battlemesh, and also
tried to get a test up and running.

A couple points.

A) Packet loss is not much of a thing on modern wifi networks,
particularly with unicast
B) As you have larger numbers of routes (1000s), congestion control
becomes a problem

My "solution" for some congestion control issues is to start
dynamically increasing the route announcement
interval for stabler routes, while still announcing the most important
ones (like defaults) in the hello. the protocol has an underused
feature where we can announce a per route interval larger than the
default.

i long ago patched out CS6 as it lands in the VO queue which cannot
aggregate on wireless-n in favor of ecn. I've had a variant that just
ecn's the hello, also.

Most of my babel routing failures were congestive in nature before I
did this. (I also, in the end dramatically
reduced the size of my route table and the size of the babel network,
at one point it was 100+ nodes with ~10 route announcements each which
became rather unreliable. Now, it's < 20 with ~3). I do wish more folk
would do the kind of experiments teco did to test larger babel
networks, and I did with the rtod tool on github. Until more core folk
start pushing the protocol (and daemons) to larger numbers of routes
we're not going to have mutually clear insights here.

On Wed, Jul 24, 2019 at 2:46 PM Juliusz Chroboczek <[e-mail]> wrote:
>
> 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.

I have largely been waiting for all the other stuff to land before
pursuing these ideas again. Needed
SS routing, thought unicast would change the game on wifi entirely.

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

It certainly was my hope at the time to be able to extend this to real
networks, on wifi. nsec
resolution is not required there either, but 10s of usec precision
seemed feasible at the time.

nsec might buy some better ability to detect (when coupled with the
increasingly common hw timestamping and/or hw pacing techniques) -
1gigE+ networks.

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

I don't presently see a need for nsec.

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

Generically I had looked as this as a path forward to getting
congestive controls to start working,
leveraging the must-ack tlv also, whatever it's called. So being able
to include a timestamp at the end of a route burst seemed helpful.

>
> -- Juliusz
>
> _______________________________________________
> babel mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/babel



--

Dave Täht
CTO, TekLibre, LLC
http://www.teklibre.com
Tel: [phone]