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

[Zaheduzzaman Sarker <[e-mail]>]

Hi David,

I appreciate your responses here even you are not a author, your expertise
helps.

I actually skimmed through RFC8966 when I was reviewing as a part of my
review process. I very often review documents as part of IESG evaluation
those are from working groups which I am not completely involve in, hence I
need to remind be the technologies and protocols during my reviews ( even
if I might have balloted some of the documents in earlier IESG evaluation
that the current one refers to). As I am not involved with all those
documents while they are developed,  my review comments for such documents
usually want to achieve at least two things ( there are other consideration
of course, and every AD has their own flavors I guess) -

    1. that I bring up the points which as I think MUST have thought about
during the design of the protocol I am reviewing, if those are not clearly
mentioned ( usually becomes discuss points).
    2. that I help uplift the document by either clarifying some important
points inline in the document or by pointing to the right pointer.

The discuss points for this specification is mostly coming from 1. and can
be solved by 2.

More responses inline --

//Zahed


On Wed, Feb 14, 2024 at 2:57 AM David Schinazi <[e-mail]>
wrote:

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

Fair point.


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

yes, that is why I thought this sentence is misleading and confusing. As
you wrote one can read too much into that sentence. I don't see much point
about adding such statements on future work on this PS specification.


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

I was thinking that you can't measure delay of lost packets, then what do
we do? I think a pointer to this mentioned section might help here to
emphasis on the independence of the metric unavailability.


>
>
>  # 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?
>

As this draft is extending the metric used for RFC8966, I think it should
be very explicit about the co-existence packet-loss and rtt-based. We can
add or emphasis the fact you mentioned here in the document that the
guideline in RFC 8966 is independent of the metrics used.


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

I see. OK. I would recommend to say that the extension does not change any
behavior or need to be change any behavior, that is mentioned in the
section you mentioned. In my read it was not clear about that.


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

I was suspecting that it does not need to know end-to-end RTTs, can we be
specific about it even though that is the case?  I see, it also created
some doubt in others mind.