Re: [babel] Iotdir telechat review of draft-ietf-babel-rtt-extension-05

I like the new section, thanks for writing it!
David

On Sat, Mar 2, 2024 at 7:35 AM Juliusz Chroboczek <jch@irif.fr> wrote:

> Hello Pascal,
>
> I've added an applicability section following your advice.  I'll be
> grateful if you find the time to review it.  (David, Toke, Donald, anyone
> else, your comments are also welcome.)
>
> 1.1.  applicability
>
>    The extension defined in Section 3 provides a sequence of accurate
>    but potentially noisy RTT samples.  Since the round-trip time is a
>    symmetric measure of delay, this protocol is only applicable in
>    environments where the symmetric delay is a good predictor of whether
>    a link should be taken by routing traffic; this is the case in most
>    networks known to the authors, but might not necessarily be the case
>    in networks built over exotic link technologies.
>
>    The extension makes minimal requirements on the nodes.  In
>    particular, it does not assume synchronised clocks, but only requires
>    that clock drift be negligible during the time interval between two
>    Hello TLVs.  Since that is on the order of a few seconds, this
>    requirement is met even with cheap crystal oscillators such as the
>    ones used in consumer electronics.
>
>    The algorithm defined in Section 4 makes a number of assumptions
>    about the network.  The assumption with most severe consequences is
>    that all links below a certain RTT (rtt-min in Section 4.2) can be
>    grouped in a single category of "good" links.  While this is the case
>    in wide-area overlay networks, it makes the algorithm inapplicable in
>    networks where distinguishing between low-latency links is important.
>
>    There are other assumptions, but they are less likely to limit the
>    algorithm's applicability.  The algorithm assumes that all links
>    above a certain RTT (rtt-max in Section 4.2) can be assumed to be
>    equally bad, and will only be used as a last resort.  In addition, in
>    order to avoid oscillations, the algorithm is designed to react
>    slowly to RTT variations, thus causing suboptimal routing for seconds
>    or even minutes after an RTT change; while this is a desirable
>    property in fixed networks, as it avoid excessive route oscillations,
>    it might be an issue with networks with high rates of node mobility.
>
> _______________________________________________
> babel mailing list
> babel@ietf.org
> https://www.ietf.org/mailman/listinfo/babel
>