Re: [babel] Zaheduzzaman Sarker's Discuss on draft-ietf-babel-rtt-extension-05: (with DISCUSS and COMMENT)

[David Schinazi <[e-mail]>]

Hi Zahed,

Thanks for your email. I'm not an author here, but I'm jumping in as a
Babel enthusiast. I have some more specific responses inline, but (and
sorry for saying this), I feel like some of your DISCUSS points might
benefit from reading some portions of RFC 8966 (which I did co-author).
That document defines the Babel protocol and in particular what is required
from a metric in order to maintain the loop-avoidance properties required
for safe operation. I'll add more specific pointers inline. But the
important fact here is that Babel's guarantees are proven mathematically
such that extensions like this one have only a small number of boxes to
check to guarantee safety.

Thanks,
David

On Tue, Feb 13, 2024 at 5:26 PM Zaheduzzaman Sarker via Datatracker <
[e-mail]> wrote:

>
>  # I support Rob's discuss that it is not clear why this is published as
>  standard track document. Apart from what Rob pointed out,


I suggest unifying this part of the conversation on replies to Rob's email:
https://mailarchive.ietf.org/arch/msg/babel/ht1qrWfkTD26YnT9pKCZQxJ71tA/


> there is another
>  place where the experimental nature of this specification is obvious. In
>  section 1 it says -
>
>     "We believe that this protocol may be useful in other situations than
> the
>     one described above, such as when running Babel in a congested wireless
>     mesh network or over a complex link layer that performs its own
> routing;
>     the fine granularity of the timestamps used (1µs) should make it
> possible
>     to experiment with RTT-based metrics on this kind of link layers."
>
>    This shows lack of confidence on the results and request for more
>    experiments. As RTT-based route selection can end up having negative
> impacts
>    by overloading  and congesting low RTT routes, we must run enough
>    experiments and have enough data to declare it safe for the Internet. I
> am
>    lacking the those information.
>

I think you're reading too much into a sentence about potential future
work. This sentence is specific about using this algorithm for something
like 802.11s. The mechanism described in this document has been deployed to
thousands of routers in production for almost a decade.

 # This specification does not specify the relation to other loss-based
> metric
>  and hop-count metric based strategies. I can imagine a network where low
> RTT
>  can be emitted at the cost of packet loss. Will this RTT-based strategy be
>  safe to use?
>

The safety of Babel is guaranteed mathematically if the metrics follow the
properties specified in RFC 8966. See more details here:
https://www.rfc-editor.org/rfc/rfc8966.html#name-metric-computation

 # How would this RTT-based strategy will co-exists with other strategies
> those
>  are deployed already as claimed in this specification? This specification
> need
>  to guide the implementers about what to consider when selecting the
> routing
>  strategy and how the strategies can co-exits.
>

RFC 8966 specifies what properties an implementer needs to guarantee in
order for interoperability and safe operation of the protocol. Can you
clarify what you think is missing here?

 # The periodicity of HELLO message is not clear to me. This is an important
>  piece of information that should be derived from proper experiments as we
>  don't want the HELLO message to overload the route or path. The
> discussion on
>  when to stop sending those HEllO messages is required.  Also the
> frequency of
>  the HELLO message might help adjusting the clock drift, as it is an
> important
>  aspect of the accuracy of the algorithm.
>

This is specified in RFC 8966:
https://www.rfc-editor.org/rfc/rfc8966.html#section-3.4.1

----------------------------------------------------------------------
> COMMENT:
> ----------------------------------------------------------------------
>
> I was also wondering how does A calculate the RTT towards D via B and C?
> does
> it only computes the RTT between itself and B and compares with that with
> C, or
> does it some how knows the whole end to end RTT? this part is also under
> specified or I have certainly missed it.
>

Babel is a distance-vector protocol. It doesn't need to know end-to-end
RTTs. Only local costs and end-to-end metrics are propagated through the
network. Metric computation is defined in RFC 8966:
https://www.rfc-editor.org/rfc/rfc8966.html#section-3.5.2