---------- Forwarded message --------- From: Steffen Vogel <post=40steffenvogel...@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 <j...@irif.fr> Cc: <ba...@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-boun...@ietf.org> on behalf of Donald Eastlake < d3e...@gmail.com> *Date: *Thursday, 22. June 2023 at 04:10 *To: *Juliusz Chroboczek <j...@irif.fr> *Cc: *<ba...@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 d3e...@gmail.com On Wed, Jun 21, 2023 at 9:53 PM Juliusz Chroboczek <j...@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 ba...@ietf.org https://www.ietf.org/mailman/listinfo/babel _______________________________________________ babel mailing list ba...@ietf.org https://www.ietf.org/mailman/listinfo/babel _______________________________________________ babel mailing list ba...@ietf.org https://www.ietf.org/mailman/listinfo/babel
_______________________________________________ Cerowrt-devel mailing list Cerowrt-devel@lists.bufferbloat.net https://lists.bufferbloat.net/listinfo/cerowrt-devel
