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

["Gunter van de Velde (Nokia)" <[e-mail]>]

Hi Zahed,

Please find the diff:
https://author-tools.ietf.org/diff?doc_1=draft-ietf-babel-rtt-extension-05&doc_2=draft-ietf-babel-rtt-extension-06

Based upon your feedback the document has been enhanced/updated.
Are there any remaining showstoppers from your side?

G/


From: iesg <[e-mail]> On Behalf Of Zaheduzzaman Sarker
Sent: Monday, February 19, 2024 12:44 PM
To: Juliusz Chroboczek <[e-mail]>
Cc: The IESG <[e-mail]>; [e-mail]; [e-mail]; [e-mail]; Donald Eastlake <[e-mail]>
Subject: Re: Zaheduzzaman Sarker's Discuss on draft-ietf-babel-rtt-extension-05: (with DISCUSS and COMMENT)

You don't often get email from [e-mail]<mailto:[e-mail]>. Learn why this is important<https://aka.ms/LearnAboutSenderIdentification>


CAUTION: This is an external email. Please be very careful when clicking links or opening attachments. See the URL nok.it/ext for additional information.


Hi Juliusz,

Thanks for your response.. and it seems like my discuss points will be easily resolved by either putting emphasis on the extension specification or pointing to the right section of RFC8966.

Please find some more reflections inline.

//Zahed

On Fri, Feb 16, 2024 at 1:23 PM Juliusz Chroboczek <[e-mail]<mailto:[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, 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盜) should make it possible
>     to experiment with RTT-based metrics on this kind of link layers."

I'm very confused by this argument.

As David explained, this document proposes an algorithm that we know to be
suitable for a specific application, large overlay networks, as described
in Section 1 of the document.  We have a lot of experience running this
algorithm in such environments (extensive experimentation in simulation
followed by 10 years of production deployment).

What we say in the paragraph that you quote is that we do not know whether
the algorithm has other applications, but we believe it might have.  As
David explained, it does not apply to the application for which we propose
the algorithm, it is just a side note.

If you think that this paragraph hampers intelligibility by those who have
only read the document superficially, I'm open to removing the whole
paragraph, even though it will make the document less informative.  Please
let me know what to do.

I don't see that paragraph as a very essential part of this specification and suggest to remove it. I has certainly gave me a vibe that more experiments are necessary even for this extension to be used.


>    This shows lack of confidence on the results

I'm very confused by this sentence. Please explain how you came to this
conclusion, given that the paragraph you quote is just a side comment
about potential future research.

I think this is because how it was put in the section, one could interpret like I did... .

>    RTT-based route selection can end up having negative impacts by
>    overloading and congesting low RTT routes,

I don't see how this is different from hop-count routing, which runs the
risk of overloading low-hop-count routes.  This is why we perform
congestion control at the transport layer: so that the network layer is
not reponsible for congestion avoidance.

I would be good to give emphasis on the fact that congestion control at the transport layer would help here to avoid congesting the low RTT routes. But I though after reading the RFC 8966 again that this feature is build-in the BUBLE algorithm, so we can point to that.


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

It will be safe to use as long as the resulting metric satisfies the
properties in Section 3.5.2 of RFC 8966.

I would then point to the that section of RFC8966.


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

That's what Sections 3.5.1 and 3.5.2 of RFC 8966 do: they describe the
general conditions under which a combination of cost and metric
computation strategies are safe in Babel.

As I wrote in the response to David. we can just mention that the RTT based strategy does not change what it already described in RFC8966 for the implementers.


>  # The periodicity of HELLO message is not clear to me.

The document says:

   the only change to Babel's message scheduling is the requirement that
   a packet containing an IHU also contains a Hello.

Recommended scheduling of Hellos is described in Appendix B of RFC 8966.

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

Appendix B of RFC 8966 recommends a default of one Hello/IHU exchange
every 4s.  This default is deliberately very conservative, so that the
protocol works well on poor wireless links.  Please let me know if you
need links to publications about Babel's behaviour in hostile environments.

Ok, then a pointer to the Appendix B would be great here.


>  The discussion on when to stop sending those HEllO messages is
>  required.

I'm very confused by this sentence.  Please see Section 2.5 of RFC 8966,
which says:

  A Babel node periodically sends Hello messages to all of its neighbours;
  it also periodically sends an IHU ("I Heard You") message to every
  neighbour from which it has recently heard a Hello.

The exact specification is in Sections 3.4.1 and 3.4.2 of RFC 8966.

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

The document says:

   However, t2' - t1' is usually on the order of seconds, and significant
   clock drift is unlikely to happen at that time scale.

I would say we can point to he sections in RFC8966 for clarity here.

//Zahed


A typical low-cost crystal oscillator has drift under 30ppm.  30ppm of 4s
is 120 microseconds.

-- Juliusz