<div dir="auto"></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">---------- Forwarded message ---------<br>From: <strong class="gmail_sendername" dir="auto">Steffen Vogel</strong> <span dir="auto"><post=<a href="mailto:40steffenvogel.de@dmarc.ietf.org">40steffenvogel.de@dmarc.ietf.org</a>></span><br>Date: Thu, Jun 22, 2023, 1:46 AM<br>Subject: Re: [babel] I-D Action: draft-ietf-babel-rtt-extension-01.txt<br>To: Juliusz Chroboczek <<a href="mailto:jch@irif.fr">jch@irif.fr</a>><br>Cc:  <<a href="mailto:babel@ietf.org">babel@ietf.org</a>><br></div><br><br><div lang="en-DE" link="blue" vlink="purple" style="word-wrap:break-word"><div class="m_5560099843460391728WordSection1"><p class="MsoNormal"><span lang="EN-US">Hi Juliusz,<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">Its great to see that the RTT draft has been reactivated!<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">I already started to support its first version it in my Go implementation which I am<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">Planning to use for routing in VPN overlay networks.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">I’ve given the updated draft a first read. Here are my comments so far.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">Sorry if that’s not the correct approach for submitting a review.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">I am a newcomer to the whole RFC process.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US"># Section 1 + 3: Negative feedback loop<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">The introductory section says:<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">> Since this causes a negative feedback loop, special care is needed to ensure<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">> that the resulting network is reasonably stable.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">This statement is repeated in Section 3:<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">> Second, using the RTT signal for route selection gives rise to a negative feedback loop: [...]<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">However, in my understanding a control loop is usually qualified as negative<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">if it dampens systems responses and hence promotes stability.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">This is also in line with the definition on Wikipedia:<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">> Negative feedback (or balancing feedback) occurs when some function of the<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">> output of a system, process, or mechanism is fed back in a manner that tends<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">> to reduce the fluctuations in the output, whether caused by changes in the<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">> input or by other disturbances.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">Source: <a href="https://en.wikipedia.org/wiki/Negative_feedback" target="_blank" rel="noreferrer">https://en.wikipedia.org/wiki/Negative_feedback</a><u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">Should this working be replaced with "positive feedback"?<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US"># Section 2.1: Clock properties<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">The draft permits clocks to be stepped to support reboots of nodes.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">However, I think it would wise to recommend the use monotonic system clocks<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">where available. E.g. CLOCK_MONOTONIC vs CLOCK_REALTIME on Linux systems.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">Otherwise, time adjustments by NTP clients or leap-seconds might<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">impede the protocol operation if the clocks are stepped by a seconds or fractions thereof.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US"># Section 2.1: Clock origin<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">Maybe replace the term clock "origin" with "epoch"?<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">Here are a few definitions which I think match the intended meaning in this context:<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">- "In computing, an epoch is a date and time from which a computer measures system time."<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">   (<a href="https://en.wikipedia.org/wiki/Epoch_(computing)" target="_blank" rel="noreferrer">https://en.wikipedia.org/wiki/Epoch_(computing)</a>)<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">- "In a computing context, an epoch is the date and time relative to which a computer's clock and timestamp values are determined"<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">   (<a href="https://www.techtarget.com/searchdatacenter/definition/epoch" target="_blank" rel="noreferrer">https://www.techtarget.com/searchdatacenter/definition/epoch</a>)<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">- "an instant of time or a date selected as a point of reference"<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">   (Merriam Webster)<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">- "a precise date to which information, such as coordinates, relating to a celestial body is referred (astrology)"<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">   (Collins Dictionary)<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US"># Section 5: Unit of timestamp fields<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">Section 5 defines the 32-bit timestamp as follows:<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">> 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.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">While, section 2.3 defines the timestamp as follows:<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">> Timestamp values are a count of milliseconds stored as a 32-bit unsigned integer; thus, they wrap around every 50 days or so.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">I think having a millisecond resolution of the timestamps is a bit too coarse for some use cases.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">I would recommend to go with microseconds as defined in Section 5.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US"># Section 9: Hyperlink in reference<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">I am a newcomer to writing RFCs, but I was wondering why the URL of<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">the rerence [DELAY-BASED] is not put into <>.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">In the html-ized view of the IETF datatracker, the link is not converted to<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">a hyperlink.<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US"># Typos<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">- Section 2.1:<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">  - Old: "This extesion extends every etry in the Neighbour Table with the following data"<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">  - New: "This **extension** extends every **entry** in the Neighbour Table with the following data<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">- Section 2.2:<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">  - Old: Additionally, it ocasionally sends a set of IHU messages, at most one per neighbour [...].<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">  - New: Additionally, it **occasionally** sends a set of IHU messages, at most one per neighbour [...].<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">  <u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">- Section 2.2:<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">  - Old: This is illustrated in the followsing sequence diagram<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">  - New: This is illustrated in the **following** sequence diagram<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">- Section 2.3:<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">  - Old: Similary, the node compares the Hello's timestamp with the Receive Timestamp recorded in the Neighbour Table<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">  - New: **Similarly**, the node compares the Hello's timestamp with the Receive Timestamp recorded in the Neighbour Table<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">Please let me know if I can support the process of getting this draft into a standard in any other way </span><span lang="EN-US" style="font-family:"Apple Color Emoji"">😊</span><span lang="EN-US"><u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US"><u></u> <u></u></span></p><p class="MsoNormal"><span lang="EN-US">Best regards,<u></u><u></u></span></p><p class="MsoNormal"><span lang="EN-US">Steffen<u></u><u></u></span></p><p class="MsoNormal"><span><u></u> <u></u></span></p><div style="border:none;border-top:solid #b5c4df 1.0pt;padding:3.0pt 0cm 0cm 0cm"><p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">From: </span></b><span style="font-size:12.0pt;color:black">babel <<a href="mailto:babel-bounces@ietf.org" target="_blank" rel="noreferrer">babel-bounces@ietf.org</a>> on behalf of Donald Eastlake <<a href="mailto:d3e3e3@gmail.com" target="_blank" rel="noreferrer">d3e3e3@gmail.com</a>><br><b>Date: </b>Thursday, 22. June 2023 at 04:10<br><b>To: </b>Juliusz Chroboczek <<a href="mailto:jch@irif.fr" target="_blank" rel="noreferrer">jch@irif.fr</a>><br><b>Cc: </b><<a href="mailto:babel@ietf.org" target="_blank" rel="noreferrer">babel@ietf.org</a>><br><b>Subject: </b>Re: [babel] I-D Action: draft-ietf-babel-rtt-extension-01.txt<u></u><u></u></span></p></div><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Hi Juliusz,<u></u><u></u></p><div><p class="MsoNormal"><u></u> <u></u></p></div><div><p class="MsoNormal">Thanks for reactivating this draft !<u></u><u></u></p></div><div><p class="MsoNormal"><br clear="all"><u></u><u></u></p><div><div><p class="MsoNormal">Donald<br>===============================<br> Donald E. Eastlake 3rd   +1-508-333-2270 (cell)<br> 2386 Panoramic Circle, Apopka, FL 32703 USA<br> <a href="mailto:d3e3e3@gmail.com" target="_blank" rel="noreferrer">d3e3e3@gmail.com</a><u></u><u></u></p></div></div><p class="MsoNormal"><u></u> <u></u></p></div></div><p class="MsoNormal"><u></u> <u></u></p><div><div><p class="MsoNormal">On Wed, Jun 21, 2023 at 9:53 PM Juliusz Chroboczek <<a href="mailto:jch@irif.fr" target="_blank" rel="noreferrer">jch@irif.fr</a>> wrote:<u></u><u></u></p></div><blockquote style="border:none;border-left:solid #cccccc 1.0pt;padding:0cm 0cm 0cm 6.0pt;margin-left:4.8pt;margin-right:0cm"><p class="MsoNormal">>    Title           : Delay-based Metric Extension for the Babel Routing Protocol<br>>    Authors         : Baptiste Jonglez<br>>                      Juliusz Chroboczek<br>>    Filename        : draft-ietf-babel-rtt-extension-01.txt<br>>    Pages           : 12<br>>    Date            : 2023-06-21<br><br>I've done some serious rewriting: the document is split into two parts,<br>one which is written in normative language, and the second which is more<br>clearly experimental.<br><br>It's in a somewhat rough state, I'll try to find the time to do some<br>proof-reading and submit a -02.  However, I feel it's ready for reviewing<br>by the WG, so please do so.<br><br>Thanks,<br><br>-- Juliusz<br><br>_______________________________________________<br>babel mailing list<br><a href="mailto:babel@ietf.org" target="_blank" rel="noreferrer">babel@ietf.org</a><br><a href="https://www.ietf.org/mailman/listinfo/babel" target="_blank" rel="noreferrer">https://www.ietf.org/mailman/listinfo/babel</a><u></u><u></u></p></blockquote></div><p class="MsoNormal">_______________________________________________ babel mailing list <a href="mailto:babel@ietf.org" target="_blank" rel="noreferrer">babel@ietf.org</a> <a href="https://www.ietf.org/mailman/listinfo/babel" target="_blank" rel="noreferrer">https://www.ietf.org/mailman/listinfo/babel</a> <u></u><u></u></p></div></div>
_______________________________________________<br>
babel mailing list<br>
<a href="mailto:babel@ietf.org" target="_blank" rel="noreferrer">babel@ietf.org</a><br>
<a href="https://www.ietf.org/mailman/listinfo/babel" rel="noreferrer noreferrer" target="_blank">https://www.ietf.org/mailman/listinfo/babel</a><br>
</div>