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

[Zaheduzzaman Sarker via Datatracker <[e-mail]>]

Zaheduzzaman Sarker has entered the following ballot position for
draft-ietf-babel-rtt-extension-05: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-babel-rtt-extension/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thanks for working on this specification. It seems like a oversight from us
that it didn't get any TSVART review at the earlier stage of this document.

I have following issues to discuss -

 # I support Rob's discuss that it is not clear why this is published as
 standard track document. Apart from what Rob pointed out, 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.

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

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

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


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