[Cerowrt-devel] Fwd: [babel] I-D Action: draft-ietf-babel-rtt-extension-01.txt

Mon Jun 26 09:54:42 EDT 2023

---------- Forwarded message ---------
From: Steffen Vogel <post=40steffenvogel.de at dmarc.ietf.org>
Date: Thu, Jun 22, 2023, 1:46 AM
Subject: Re: [babel] I-D Action: draft-ietf-babel-rtt-extension-01.txt
To: Juliusz Chroboczek <jch at irif.fr>
Cc: <babel at ietf.org>

Hi Juliusz,

Its great to see that the RTT draft has been reactivated!

I already started to support its first version it in my Go implementation
which I am

Planning to use for routing in VPN overlay networks.

I’ve given the updated draft a first read. Here are my comments so far.

Sorry if that’s not the correct approach for submitting a review.

I am a newcomer to the whole RFC process.

# Section 1 + 3: Negative feedback loop

The introductory section says:

> Since this causes a negative feedback loop, special care is needed to
ensure

> that the resulting network is reasonably stable.

This statement is repeated in Section 3:

> Second, using the RTT signal for route selection gives rise to a negative
feedback loop: [...]

However, in my understanding a control loop is usually qualified as negative

if it dampens systems responses and hence promotes stability.

This is also in line with the definition on Wikipedia:

> Negative feedback (or balancing feedback) occurs when some function of the

> output of a system, process, or mechanism is fed back in a manner that
tends

> to reduce the fluctuations in the output, whether caused by changes in the

> input or by other disturbances.

Source: https://en.wikipedia.org/wiki/Negative_feedback

Should this working be replaced with "positive feedback"?

# Section 2.1: Clock properties

The draft permits clocks to be stepped to support reboots of nodes.

However, I think it would wise to recommend the use monotonic system clocks

where available. E.g. CLOCK_MONOTONIC vs CLOCK_REALTIME on Linux systems.

Otherwise, time adjustments by NTP clients or leap-seconds might

impede the protocol operation if the clocks are stepped by a seconds or
fractions thereof.

# Section 2.1: Clock origin

Maybe replace the term clock "origin" with "epoch"?

Here are a few definitions which I think match the intended meaning in this
context:

- "In computing, an epoch is a date and time from which a computer measures
system time."

   (https://en.wikipedia.org/wiki/Epoch_(computing))

- "In a computing context, an epoch is the date and time relative to which
a computer's clock and timestamp values are determined"

   (https://www.techtarget.com/searchdatacenter/definition/epoch)

- "an instant of time or a date selected as a point of reference"

   (Merriam Webster)

- "a precise date to which information, such as coordinates, relating to a
celestial body is referred (astrology)"

   (Collins Dictionary)

# Section 5: Unit of timestamp fields

Section 5 defines the 32-bit timestamp as follows:

> Timestamps are encoded as 32-bit unsigned integers, expressed in units of
one microsecond, counting from an arbitrary origin. Timestamps wrap around
every 4295 seconds, or slightly more than one hour.

While, section 2.3 defines the timestamp as follows:

> Timestamp values are a count of milliseconds stored as a 32-bit unsigned
integer; thus, they wrap around every 50 days or so.

I think having a millisecond resolution of the timestamps is a bit too
coarse for some use cases.

I would recommend to go with microseconds as defined in Section 5.

# Section 9: Hyperlink in reference

I am a newcomer to writing RFCs, but I was wondering why the URL of

the rerence [DELAY-BASED] is not put into <>.

In the html-ized view of the IETF datatracker, the link is not converted to

a hyperlink.

# Typos

- Section 2.1:

  - Old: "This extesion extends every etry in the Neighbour Table with the
following data"

  - New: "This **extension** extends every **entry** in the Neighbour Table
with the following data

- Section 2.2:

 - Old: Additionally, it ocasionally sends a set of IHU messages, at most
one per neighbour [...].

  - New: Additionally, it **occasionally** sends a set of IHU messages, at
most one per neighbour [...].

- Section 2.2:

  - Old: This is illustrated in the followsing sequence diagram

  - New: This is illustrated in the **following** sequence diagram

- Section 2.3:

  - Old: Similary, the node compares the Hello's timestamp with the Receive
Timestamp recorded in the Neighbour Table

  - New: **Similarly**, the node compares the Hello's timestamp with the
Receive Timestamp recorded in the Neighbour Table

Please let me know if I can support the process of getting this draft into
a standard in any other way 😊

Best regards,

Steffen

*From: *babel <babel-bounces at ietf.org> on behalf of Donald Eastlake <
d3e3e3 at gmail.com>
*Date: *Thursday, 22. June 2023 at 04:10
*To: *Juliusz Chroboczek <jch at irif.fr>
*Cc: *<babel at ietf.org>
*Subject: *Re: [babel] I-D Action: draft-ietf-babel-rtt-extension-01.txt

Hi Juliusz,

Thanks for reactivating this draft !

Donald
===============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 2386 Panoramic Circle, Apopka, FL 32703 USA
 d3e3e3 at gmail.com

On Wed, Jun 21, 2023 at 9:53 PM Juliusz Chroboczek <jch at irif.fr> wrote:

>    Title           : Delay-based Metric Extension for the Babel Routing
Protocol
>    Authors         : Baptiste Jonglez
>                      Juliusz Chroboczek
>    Filename        : draft-ietf-babel-rtt-extension-01.txt
>    Pages           : 12
>    Date            : 2023-06-21

I've done some serious rewriting: the document is split into two parts,
one which is written in normative language, and the second which is more
clearly experimental.

It's in a somewhat rough state, I'll try to find the time to do some
proof-reading and submit a -02.  However, I feel it's ready for reviewing
by the WG, so please do so.

Thanks,

-- Juliusz

_______________________________________________
babel mailing list
babel at ietf.org
https://www.ietf.org/mailman/listinfo/babel

_______________________________________________ babel mailing list
babel at ietf.org https://www.ietf.org/mailman/listinfo/babel
_______________________________________________
babel mailing list
babel at ietf.org
https://www.ietf.org/mailman/listinfo/babel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.bufferbloat.net/pipermail/cerowrt-devel/attachments/20230626/72346622/attachment.html>