<?xml version='1.0' encoding='utf-8'?>
<rfc xmlns:xi="http://www.w3.org/2001/XInclude" version="3" docName="draft-ietf-babel-rtt-extension-07" number="9616" updates="" obsoletes="" tocInclude="true" ipr="trust200902" consensus="true" submissionType="IETF" category="std" xml:lang="en" prepTime="2024-09-13T11:39:57" indexInclude="true" scripts="Common,Greek,Latin" sortRefs="false" symRefs="true" tocDepth="3">
  <link href="https://datatracker.ietf.org/doc/draft-ietf-babel-rtt-extension-07" rel="prev"/>
  <link href="https://dx.doi.org/10.17487/rfc9616" rel="alternate"/>
  <link href="urn:issn:2070-1721" rel="alternate"/>
  <front>
    <title abbrev="Babel RTT Extension">Delay-Based Metric Extension for the Babel Routing Protocol</title>
    <seriesInfo name="RFC" value="9616" stream="IETF"/>
    <author fullname="Baptiste Jonglez" initials="B." surname="Jonglez">
      <organization showOnFrontPage="true">ENS Lyon</organization>
      <address>
        <postal>
          <country>France</country>
        </postal>
        <email>baptiste.jonglez@ens-lyon.org</email>
      </address>
    </author>
    <author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek">
      <organization showOnFrontPage="true">IRIF, Université Paris Cité</organization>
      <address>
        <postal>
          <street>Case 7014</street>
          <city>75205 Paris Cedex 13</city>
          <country>France</country>
        </postal>
        <email>jch@irif.fr</email>
      </address>
    </author>
    <date month="09" year="2024"/>
    <area>RTG</area>
    <workgroup>babel</workgroup>
    <abstract pn="section-abstract">
      <t indent="0" pn="section-abstract-1">This document defines an extension to the Babel routing protocol that
measures the round-trip time (RTT) between routers and makes it possible
to prefer lower-latency links over higher-latency ones.</t>
    </abstract>
    <boilerplate>
      <section anchor="status-of-memo" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.1">
        <name slugifiedName="name-status-of-this-memo">Status of This Memo</name>
        <t indent="0" pn="section-boilerplate.1-1">
            This is an Internet Standards Track document.
        </t>
        <t indent="0" pn="section-boilerplate.1-2">
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        </t>
        <t indent="0" pn="section-boilerplate.1-3">
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            <eref target="https://www.rfc-editor.org/info/rfc9616" brackets="none"/>.
        </t>
      </section>
      <section anchor="copyright" numbered="false" removeInRFC="false" toc="exclude" pn="section-boilerplate.2">
        <name slugifiedName="name-copyright-notice">Copyright Notice</name>
        <t indent="0" pn="section-boilerplate.2-1">
            Copyright (c) 2024 IETF Trust and the persons identified as the
            document authors. All rights reserved.
        </t>
        <t indent="0" pn="section-boilerplate.2-2">
            This document is subject to BCP 78 and the IETF Trust's Legal
            Provisions Relating to IETF Documents
            (<eref target="https://trustee.ietf.org/license-info" brackets="none"/>) in effect on the date of
            publication of this document. Please review these documents
            carefully, as they describe your rights and restrictions with
            respect to this document. Code Components extracted from this
            document must include Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        </t>
      </section>
    </boilerplate>
    <toc>
      <section anchor="toc" numbered="false" removeInRFC="false" toc="exclude" pn="section-toc.1">
        <name slugifiedName="name-table-of-contents">Table of Contents</name>
        <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1">
          <li pn="section-toc.1-1.1">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.1"><xref derivedContent="1" format="counter" sectionFormat="of" target="section-1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-introduction">Introduction</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.1.2">
              <li pn="section-toc.1-1.1.2.1">
                <t indent="0" keepWithNext="true" pn="section-toc.1-1.1.2.1.1"><xref derivedContent="1.1" format="counter" sectionFormat="of" target="section-1.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-applicability">Applicability</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.2">
            <t indent="0" keepWithNext="true" pn="section-toc.1-1.2.1"><xref derivedContent="2" format="counter" sectionFormat="of" target="section-2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-specification-of-requiremen">Specification of Requirements</xref></t>
          </li>
          <li pn="section-toc.1-1.3">
            <t indent="0" pn="section-toc.1-1.3.1"><xref derivedContent="3" format="counter" sectionFormat="of" target="section-3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-rtt-sampling">RTT Sampling</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.3.2">
              <li pn="section-toc.1-1.3.2.1">
                <t indent="0" pn="section-toc.1-1.3.2.1.1"><xref derivedContent="3.1" format="counter" sectionFormat="of" target="section-3.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-data-structures">Data Structures</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.2">
                <t indent="0" pn="section-toc.1-1.3.2.2.1"><xref derivedContent="3.2" format="counter" sectionFormat="of" target="section-3.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-protocol-operation">Protocol Operation</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.3">
                <t indent="0" pn="section-toc.1-1.3.2.3.1"><xref derivedContent="3.3" format="counter" sectionFormat="of" target="section-3.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-wrap-around-and-node-restar">Wrap-Around and Node Restart</xref></t>
              </li>
              <li pn="section-toc.1-1.3.2.4">
                <t indent="0" pn="section-toc.1-1.3.2.4.1"><xref derivedContent="3.4" format="counter" sectionFormat="of" target="section-3.4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-implementation-notes">Implementation Notes</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.4">
            <t indent="0" pn="section-toc.1-1.4.1"><xref derivedContent="4" format="counter" sectionFormat="of" target="section-4"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-rtt-based-route-selection">RTT-Based Route Selection</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.4.2">
              <li pn="section-toc.1-1.4.2.1">
                <t indent="0" pn="section-toc.1-1.4.2.1.1"><xref derivedContent="4.1" format="counter" sectionFormat="of" target="section-4.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-smoothing">Smoothing</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.2">
                <t indent="0" pn="section-toc.1-1.4.2.2.1"><xref derivedContent="4.2" format="counter" sectionFormat="of" target="section-4.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-cost-computation">Cost Computation</xref></t>
              </li>
              <li pn="section-toc.1-1.4.2.3">
                <t indent="0" pn="section-toc.1-1.4.2.3.1"><xref derivedContent="4.3" format="counter" sectionFormat="of" target="section-4.3"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-hysteresis">Hysteresis</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.5">
            <t indent="0" pn="section-toc.1-1.5.1"><xref derivedContent="5" format="counter" sectionFormat="of" target="section-5"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-backwards-and-forwards-comp">Backwards and Forwards Compatibility</xref></t>
          </li>
          <li pn="section-toc.1-1.6">
            <t indent="0" pn="section-toc.1-1.6.1"><xref derivedContent="6" format="counter" sectionFormat="of" target="section-6"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-packet-format">Packet Format</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.6.2">
              <li pn="section-toc.1-1.6.2.1">
                <t indent="0" pn="section-toc.1-1.6.2.1.1"><xref derivedContent="6.1" format="counter" sectionFormat="of" target="section-6.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-timestamp-sub-tlv-in-hello-">Timestamp Sub-TLV in Hello TLVs</xref></t>
              </li>
              <li pn="section-toc.1-1.6.2.2">
                <t indent="0" pn="section-toc.1-1.6.2.2.1"><xref derivedContent="6.2" format="counter" sectionFormat="of" target="section-6.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-timestamp-sub-tlv-in-ihu-tl">Timestamp Sub-TLV in IHU TLVs</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.7">
            <t indent="0" pn="section-toc.1-1.7.1"><xref derivedContent="7" format="counter" sectionFormat="of" target="section-7"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-iana-considerations">IANA Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.8">
            <t indent="0" pn="section-toc.1-1.8.1"><xref derivedContent="8" format="counter" sectionFormat="of" target="section-8"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-security-considerations">Security Considerations</xref></t>
          </li>
          <li pn="section-toc.1-1.9">
            <t indent="0" pn="section-toc.1-1.9.1"><xref derivedContent="9" format="counter" sectionFormat="of" target="section-9"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-references">References</xref></t>
            <ul bare="true" empty="true" indent="2" spacing="compact" pn="section-toc.1-1.9.2">
              <li pn="section-toc.1-1.9.2.1">
                <t indent="0" pn="section-toc.1-1.9.2.1.1"><xref derivedContent="9.1" format="counter" sectionFormat="of" target="section-9.1"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-normative-references">Normative References</xref></t>
              </li>
              <li pn="section-toc.1-1.9.2.2">
                <t indent="0" pn="section-toc.1-1.9.2.2.1"><xref derivedContent="9.2" format="counter" sectionFormat="of" target="section-9.2"/>.  <xref derivedContent="" format="title" sectionFormat="of" target="name-informative-references">Informative References</xref></t>
              </li>
            </ul>
          </li>
          <li pn="section-toc.1-1.10">
            <t indent="0" pn="section-toc.1-1.10.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.a"/><xref derivedContent="" format="title" sectionFormat="of" target="name-acknowledgements">Acknowledgements</xref></t>
          </li>
          <li pn="section-toc.1-1.11">
            <t indent="0" pn="section-toc.1-1.11.1"><xref derivedContent="" format="none" sectionFormat="of" target="section-appendix.b"/><xref derivedContent="" format="title" sectionFormat="of" target="name-authors-addresses">Authors' Addresses</xref></t>
          </li>
        </ul>
      </section>
    </toc>
  </front>
  <middle>
    <section numbered="true" removeInRFC="false" toc="include" pn="section-1">
      <name slugifiedName="name-introduction">Introduction</name>
      <t indent="0" pn="section-1-1">The Babel routing protocol <xref target="RFC8966" format="default" sectionFormat="of" derivedContent="RFC8966"/> does not mandate
a specific algorithm for computing metrics; existing implementations use
a packet-loss-based metric on wireless links and a simple hop-count metric
on all other types of links.  While this strategy works reasonably well in
many networks, it fails to select reasonable routes in some topologies
involving tunnels or VPNs.</t>
      <figure anchor="fig-diamond" align="left" suppress-title="false" pn="figure-1">
        <name slugifiedName="name-four-routers-in-a-diamond-t">Four Routers in a Diamond Topology</name>
        <artwork align="left" pn="section-1-2.1">
                   +------------+
                   | A (Paris)  +---------------+
                   +------------+                \
                  /                               \
                 /                                 \
                /                                   \
  +------------+                                     +------------+
  | B  (Paris) |                                     | C  (Tokyo) |
  +------------+                                     +------------+
                \                                   /
                 \                                 /
                  \                               /
                   +------------+                /
                   | D (Paris)  +---------------+
                   +------------+
</artwork>
      </figure>
      <t indent="0" pn="section-1-3">For example, consider the topology described in <xref target="fig-diamond" format="default" sectionFormat="of" derivedContent="Figure 1"/>,
with three routers A, B, and D located in Paris and a fourth router
C located in Tokyo, connected through tunnels in a diamond topology.  When
routing traffic from A to D, it is obviously preferable to use the local
route through B as this is likely to provide better service quality and
lower monetary cost than the distant route through C.  However, the
existing implementations of Babel consider both routes as having the same
metric; therefore, they will route the traffic through C in roughly half the
cases.</t>
      <t indent="0" pn="section-1-4">In the first part of this document (<xref target="rtt-sampling" format="default" sectionFormat="of" derivedContent="Section 3"/>),
we specify an extension to the Babel routing protocol that produces
a sequence of accurate measurements of the round-trip time (RTT) between
two Babel neighbours.  These measurements are not directly usable as an
input to Babel's route selection procedure since they tend to be noisy
and to cause a negative feedback loop, which might give rise to frequent
oscillations.  In the second part (<xref target="route-selection" format="default" sectionFormat="of" derivedContent="Section 4"/>), we
define an algorithm that maps the sequence of RTT samples to a link cost
that can be used for route selection.</t>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-1.1">
        <name slugifiedName="name-applicability">Applicability</name>
        <t indent="0" pn="section-1.1-1">The extension defined in <xref target="rtt-sampling" format="default" sectionFormat="of" derivedContent="Section 3"/> provides
a sequence of accurate but potentially noisy RTT samples.  Since the
RTT is a symmetric measure of delay, this protocol is only
applicable in environments where the symmetric delay is a good predictor
of whether a link should be taken by routing traffic, which might not
necessarily be the case in networks built over exotic link technologies.</t>
        <t indent="0" pn="section-1.1-2">The extension makes minimal requirements on the nodes.  In particular,
it does not assume synchronised clocks, and only requires that clock drift
be negligible during the time interval between two Hello TLVs.  Since that
is on the order of a few seconds, this requirement is met even with cheap
crystal oscillators, such as the ones used in consumer electronics.</t>
        <t indent="0" pn="section-1.1-3">The algorithm defined in <xref target="route-selection" format="default" sectionFormat="of" derivedContent="Section 4"/> depends on
a number of assumptions about the network.  The assumption with the most
severe consequences is that all links below a certain RTT (rtt-min in
<xref target="cost-computation" format="default" sectionFormat="of" derivedContent="Section 4.2"/>) can be grouped in a single category of
"good" links.  While this is the case in wide-area overlay networks, it
makes the algorithm inapplicable in networks where distinguishing between
low-latency links is important.</t>
        <t indent="0" pn="section-1.1-4">There are other assumptions, but they are less likely to limit the
algorithm's applicability.  The algorithm assumes that all links above
a certain RTT (rtt-max in <xref target="cost-computation" format="default" sectionFormat="of" derivedContent="Section 4.2"/>) are equally bad, and they will only be used as a last resort.  In
addition, in order to avoid oscillations, the algorithm is designed to
react slowly to RTT variations, thus causing suboptimal routing for
seconds or even minutes after an RTT change; while this is a desirable
property in fixed networks, as it avoid excessive route oscillations, it
might be an issue with networks with high rates of node mobility.</t>
      </section>
    </section>
    <section numbered="true" removeInRFC="false" toc="include" pn="section-2">
      <name slugifiedName="name-specification-of-requiremen">Specification of Requirements</name>
      <t indent="0" pn="section-2-1">
    The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
    "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>",
    "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
    "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
    "<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are to be
    interpreted as described in BCP 14 <xref target="RFC2119" format="default" sectionFormat="of" derivedContent="RFC2119"/> <xref target="RFC8174" format="default" sectionFormat="of" derivedContent="RFC8174"/> when, and only when, they appear in all capitals, as
    shown here.
      </t>
    </section>
    <section anchor="rtt-sampling" numbered="true" removeInRFC="false" toc="include" pn="section-3">
      <name slugifiedName="name-rtt-sampling">RTT Sampling</name>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-3.1">
        <name slugifiedName="name-data-structures">Data Structures</name>
        <t indent="0" pn="section-3.1-1">We assume that every Babel speaker maintains a local clock that counts
microseconds from an arbitrary origin.  We do not assume that clocks are
synchronised: clocks local to distinct nodes need not share a common
origin.  The protocol will eventually recover if the clock is stepped, so
clocks need not persist across node reboots.</t>
        <t indent="0" pn="section-3.1-2">Every Babel speaker maintains a Neighbour Table, described in
<xref target="RFC8966" sectionFormat="of" section="3.2.4" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8966#section-3.2.4" derivedContent="RFC8966"/>.  This extension extends every
entry in the Neighbour Table with the following data:</t>
        <ul spacing="normal" bare="false" empty="false" indent="3" pn="section-3.1-3">
          <li pn="section-3.1-3.1">the Origin Timestamp, a 32-bit timestamp (modulo 2<sup>32</sup>) according to
the neighbour's clock;</li>
          <li pn="section-3.1-3.2">the Receive Timestamp, a 32-bit timestamp (modulo 2<sup>32</sup>) according to
the local clock.</li>
        </ul>
        <t indent="0" pn="section-3.1-4">Both values are initially undefined.</t>
      </section>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-3.2">
        <name slugifiedName="name-protocol-operation">Protocol Operation</name>
        <t indent="0" pn="section-3.2-1">The RTT to a neighbour is estimated using an algorithm due to Mills
<xref target="RFC891" format="default" sectionFormat="of" derivedContent="RFC891"/>, originally developed for the HELLO routing
protocol and later used in NTP <xref target="RFC5905" format="default" sectionFormat="of" derivedContent="RFC5905"/>.</t>
        <t indent="0" pn="section-3.2-2">A Babel speaker periodically sends Hello messages to its neighbours
(<xref target="RFC8966" sectionFormat="of" section="3.4.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8966#section-3.4.1" derivedContent="RFC8966"/>).  Additionally, it
occasionally sends a set of IHU ("I Heard You") messages, at most one per
neighbour (<xref target="RFC8966" sectionFormat="of" section="3.4.2" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8966#section-3.4.2" derivedContent="RFC8966"/>).</t>
        <figure anchor="fig-seq" align="left" suppress-title="false" pn="figure-2">
          <name slugifiedName="name-mills-algorithm">Mills' Algorithm</name>
          <artwork align="left" pn="section-3.2-3.1">
   A          B
     |      |
  t1 +      |
     |\     |
     | \    |
     |  \   |  Hello(t1)
     |   \  |
     |    \ |
     |     \|
     |      + t1'
     |      |
     |      |               RTT = (t2 - t1) - (t2' - t1')
     |      |
     |      + t2'
     |     /|
     |    / |
     |   /  |
     |  /   |  Hello(t2')
     | /    |  IHU(t1, t1')
     |/     |
  t2 +      |
     |      |
     v      v
</artwork>
        </figure>
        <t indent="0" pn="section-3.2-4">In order to enable the computation of RTTs, a node A <bcp14>MUST</bcp14> include, in
every Hello that it sends, a timestamp t1 (according to A's local clock),
as illustrated in <xref target="fig-seq" format="default" sectionFormat="of" derivedContent="Figure 2"/>.  When a node B receives A's
timestamped Hello, it computes the time t1' at which the Hello was
received (according to B's local clock).  It then <bcp14>MUST</bcp14> record the value t1
in the Origin Timestamp field of the Neighbour Table entry corresponding
to A and the value t1' in the Receive Timestamp field of the Neighbour
Table entry.</t>
        <t indent="0" pn="section-3.2-5">When B sends an IHU to A, it checks whether both timestamps are defined
in the Neighbour Table.  If that is the case, then it <bcp14>MUST</bcp14> ensure that its
IHU TLV is sent in a packet that also contains a timestamped Hello TLV
(either a normally scheduled Hello or an unscheduled Hello, see
<xref target="RFC8966" sectionFormat="of" section="3.4.1" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8966#section-3.4.1" derivedContent="RFC8966"/>).  It <bcp14>MUST</bcp14> include in the IHU
both the Origin Timestamp and the Receive Timestamp stored in the Neighbour
Table.</t>
        <t indent="0" pn="section-3.2-6">Upon receiving B's packet, A computes the time t2 (according to its
local clock) at which it was received.  Node A <bcp14>MUST</bcp14> then verify that it
contains both a Hello TLV with timestamp t2' and an IHU TLV with two
timestamps t1 and t1'.  If that is the case, A computes the value:</t>
        <artwork align="left" pn="section-3.2-7">RTT = (t2 - t1) - (t2' - t1')</artwork>
        <t indent="0" pn="section-3.2-8">(where all computations are done modulo
2<sup>32</sup>), which is a measurement of the RTT between A and B.  (A then stores
the values t2' and t2 in its Neighbour Table, as B did before.)</t>
        <t indent="0" pn="section-3.2-9">This algorithm has a number of desirable properties:</t>
        <ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-3.2-10"><li pn="section-3.2-10.1" derivedCounter="1.">The
algorithm is symmetric: A and B use the same procedures for timestamping
packets and computing RTT samples, and both nodes produce one RTT sample
for each received (Hello, IHU) pair.</li>
          <li pn="section-3.2-10.2" derivedCounter="2.">Since there is no
requirement that t1' and t2' be equal, the protocol is asynchronous: the
only change to Babel's message scheduling is the requirement that a packet
containing an IHU also contain a Hello.</li>
          <li pn="section-3.2-10.3" derivedCounter="3.">Since the algorithm only ever
computes differences of timestamps according to a single clock, it does
not require synchronised clocks.</li>
          <li pn="section-3.2-10.4" derivedCounter="4.">The algorithm requires very little
additional state: a node only needs to store the two timestamps associated
with the last hello received from each neighbour.</li>
          <li pn="section-3.2-10.5" derivedCounter="5.">Since the algorithm only
requires piggybacking one or two timestamps on each Hello and IHU TLV,
it makes efficient use of network resources.</li>
        </ol>
        <t indent="0" pn="section-3.2-11">In principle, this algorithm is inaccurate in the presence of clock
drift (i.e., when A's clock and B's clock are running at different frequencies).
However, t2' - t1' is usually on the order of a few seconds, and
significant clock drift is unlikely to happen at that time scale.</t>
        <t indent="0" pn="section-3.2-12">In order for RTT values to be consistent between implementations,
timestamps need to be computed at roughly the same point in the network
stack.  Transmit timestamps <bcp14>SHOULD</bcp14> be computed just before the packet is
passed to the network stack (i.e., before it is subjected to any queueing
delays); receive timestamps <bcp14>SHOULD</bcp14> be computed just after the packet
is received from the network stack.</t>
      </section>
      <section anchor="wraparound" numbered="true" removeInRFC="false" toc="include" pn="section-3.3">
        <name slugifiedName="name-wrap-around-and-node-restar">Wrap-Around and Node Restart</name>
        <t indent="0" pn="section-3.3-1">Timestamp values are a count of microseconds stored as a 32-bit
unsigned integer; thus, they wrap around every 71 minutes or so.  What is
more, a node may occasionally reboot and restart its clock at an arbitrary
origin.  For these reasons, very old timestamps or nonsensical timestamps
<bcp14>MUST NOT</bcp14> be used to yield RTT samples.</t>
        <t indent="0" pn="section-3.3-2">The following algorithm can be used to discard obsolete samples.  When a node
receives a packet containing a Hello and an IHU, it compares the current
local time t2 with the Origin Timestamp contained in the IHU; if the
Origin Timestamp appears to be in the future, or if it is in the past by
more than a time T (the value T = 3 minutes is recommended), then the
timestamps are still recorded in the Neighbour Table, but they are not used for
computation of an RTT sample.</t>
        <t indent="0" pn="section-3.3-3">Similarly, the node compares the Hello's timestamp with the Receive
Timestamp recorded in the Neighbour Table; if the Hello's timestamp
appears to be older than the recorded timestamp, or if it appears to be
more recent by an interval larger than the value T, then the timestamps
are not used for computation of an RTT sample.</t>
      </section>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-3.4">
        <name slugifiedName="name-implementation-notes">Implementation Notes</name>
        <t indent="0" pn="section-3.4-1">The accuracy of the computed RTT samples depends on Transmit Timestamps
being computed as late as possible before a packet containing a Hello TLV
is passed to the network stack, and Receive Timestamps being computed as
early as possible after reception of a packet containing a (Hello, IHU)
pair.  We have found the following implementation strategy to be
useful.</t>
        <t indent="0" pn="section-3.4-2">When a Hello TLV is buffered for transmission, we insert a PadN sub-TLV
(Section 4.7.2 of <xref target="RFC8966" format="default" sectionFormat="of" derivedContent="RFC8966"/>) with a length of 4 octets
within the TLV.  When the packet is ready to be sent, we check whether it
contains a 4-octet PadN sub-TLV; if that's the case, we overwrite the PadN
sub-TLV with a Timestamp sub-TLV with the current time, and send out the
packet.</t>
        <t indent="0" pn="section-3.4-3">Conversely, when a packet is received, we immediately compute the
current time and record it with the received packet.  We then process the
packet as usual and use the recorded timestamp in order to compute an RTT
sample.</t>
        <t indent="0" pn="section-3.4-4">The protocol is designed to survive the clock being reset when a node
reboots; on POSIX systems, this makes it possible to use the
CLOCK_MONOTONIC clock for computing timestamps.  If CLOCK_MONOTONIC is not
available, CLOCK_REALTIME may be used, since the protocol is able to
survive the clock being occasionally stepped.</t>
      </section>
    </section>
    <section anchor="route-selection" numbered="true" removeInRFC="false" toc="include" pn="section-4">
      <name slugifiedName="name-rtt-based-route-selection">RTT-Based Route Selection</name>
      <t indent="0" pn="section-4-1">The protocol described above yields a series of RTT samples.  While
these samples are fairly accurate, they are not directly usable as an
input to the route selection procedure, for at least three reasons:</t>
      <ol indent="adaptive" spacing="normal" start="1" type="1" pn="section-4-2"><li pn="section-4-2.1" derivedCounter="1.">In the presence of bursty traffic, routers experience
transient congestion, which causes occasional spikes in the measured RTT.
Thus, the RTT signal may be noisy and require smoothing before it can
be used for route selection.</li>
        <li pn="section-4-2.2" derivedCounter="2.">Using the RTT signal for route selection gives rise to
a negative feedback loop.  When a route has a low RTT, it is deemed to be
more desirable; this causes it to be used for more data traffic, which
may lead to congestion, which in turn increases the RTT.  Without some
form of hysteresis, using RTT for route selection would lead to
oscillations between parallel routes, which would lead to packet
reordering and negatively affect upper-layer protocols (such as TCP).</li>
        <li pn="section-4-2.3" derivedCounter="3.">Even in the absence of congestion, the RTT tends to exhibit some
variation.  If the RTTs of two parallel routes oscillate around
a common value, using the RTT as input to route selection will cause
frequent routing oscillations, which, again, indicates the need for some
form of hysteresis.</li>
      </ol>
      <t indent="0" pn="section-4-3">In this section, we describe an algorithm that integrates smoothing and
hysteresis. It has been shown to behave well both in simulation and
experimentally over the Internet <xref target="DELAY-BASED" format="default" sectionFormat="of" derivedContent="DELAY-BASED"/> and is
<bcp14>RECOMMENDED</bcp14> when RTT information is being used for route selection.  The
algorithm is structured as follows:</t>
      <ul bare="false" empty="false" indent="3" spacing="normal" pn="section-4-4">
        <li pn="section-4-4.1">the RTT values are first smoothed in order to avoid instabilities due to
outliers (<xref target="smoothing" format="default" sectionFormat="of" derivedContent="Section 4.1"/>);</li>
        <li pn="section-4-4.2">the resulting smoothed samples are mapped to a cost using a bounded,
non-linear mapping, which avoids
instabilities at the lower and upper end of the RTT range
(<xref target="cost-computation" format="default" sectionFormat="of" derivedContent="Section 4.2"/>);</li>
        <li pn="section-4-4.3">a hysteresis filter is applied in order to limit the amount of
oscillation in the middle of the RTT range (<xref target="hysteresis" format="default" sectionFormat="of" derivedContent="Section 4.3"/>).</li>
      </ul>
      <section anchor="smoothing" numbered="true" removeInRFC="false" toc="include" pn="section-4.1">
        <name slugifiedName="name-smoothing">Smoothing</name>
        <t indent="0" pn="section-4.1-1">The RTT samples provided by Mills' algorithm are fairly accurate, but
noisy: experiments indicate the occasional presence of individual samples
that are much larger than the expected value.  Thus, some form of
smoothing <bcp14>SHOULD</bcp14> be applied in order to avoid instabilities due to
occasional outliers.</t>
        <t indent="0" pn="section-4.1-2">An implementation <bcp14>MAY</bcp14> use the exponential average algorithm, which is
simple to implement and appears to yield good results in practice <xref target="DELAY-BASED" format="default" sectionFormat="of" derivedContent="DELAY-BASED"/>.  The algorithm is parameterised by a constant α,
where 0 &lt; α &lt; 1, which controls the amount of smoothing being
applied.  For each neighbour, it maintains a smoothed value RTT, which is
initially undefined.  When the first sample RTT0 is measured, the smoothed
value is set to the value of RTT0.  At each new sample RTTn, the smoothed
value is set to a weighted average of the previous smoothed value and the
new sample:</t>
        <sourcecode type="pseudocode" markers="false" pn="section-4.1-3">    RTT := α RTT + (1 - α) RTTn</sourcecode>
        <t indent="0" pn="section-4.1-4">The smoothing constant α <bcp14>SHOULD</bcp14> be between 0.8 and 0.9; the value 0.836
is the <bcp14>RECOMMENDED</bcp14> default.</t>
      </section>
      <section anchor="cost-computation" numbered="true" removeInRFC="false" toc="include" pn="section-4.2">
        <name slugifiedName="name-cost-computation">Cost Computation</name>
        <t indent="0" pn="section-4.2-1">The smoothed RTT value obtained in the previous step needs to be mapped
to a link cost, suitable for input to the metric computation procedure
(<xref target="RFC8966" section="3.5.2" sectionFormat="of" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8966#section-3.5.2" derivedContent="RFC8966"/>).  Obviously, the mapping
should be monotonic (larger RTTs imply larger costs).  In addition, the
mapping should be constant beyond a certain value (all very bad links are
equally bad) so that congested links do not contribute to routing
instability.  The mapping should also be constant around 0, so that small
oscillations in the RTT of low-RTT links do not contribute to routing
instability.</t>
        <figure anchor="fig-mapping" align="left" suppress-title="false" pn="figure-3">
          <name slugifiedName="name-mapping-from-rtt-to-link-co">Mapping from RTT to Link Cost</name>
          <artwork align="left" pn="section-4.2-2.1">
  cost
    ^
    |
    |
    |                           C + max-rtt-penalty
    |                       +---------------------------
    |                      /.
    |                     / .
    |                    /  .
    |                   /   .
    |                  /    .
    |                 /     .
    |                /      .
    |               /       .
    |              /        .
    |             /         .
  C +------------+          .
    |            .          .
    |            .          .
    |            .          .
    |            .          .
  0 +----------------------------------------------------&gt;
    0         rtt-min    rtt-max                          RTT
</artwork>
        </figure>
        <t indent="0" pn="section-4.2-3">Implementations <bcp14>SHOULD</bcp14> use the mapping described in <xref target="fig-mapping" format="default" sectionFormat="of" derivedContent="Figure 3"/>, which is parameterised by three parameters:
rtt-min, rtt-max, and max-rtt-penalty.  For RTT values below rtt-min, the
link cost is just the nominal cost C of a single hop.  Between rtt-min and
rtt-max, the cost increases linearly; above rtt-max, the constant value
max-rtt-penalty is added to the nominal cost.</t>
        <t indent="0" pn="section-4.2-4">The value rtt-min should be slightly larger than the RTT of a local,
uncongested link.  The value rtt-max should be the RTT above which a link
should be avoided if possible, either because it is a long-distance link
or because it is congested; reducing the value of rtt-max improves
stability, but prevents the protocol from discriminating between
high-latency links.  As for max-rtt-penalty, it controls how much the
protocol will penalise long-distance links.  The default values
rtt-min = 10 ms, rtt-max = 120 ms, and max-rtt-penalty = 150 are
<bcp14>RECOMMENDED</bcp14>.</t>
      </section>
      <section anchor="hysteresis" numbered="true" removeInRFC="false" toc="include" pn="section-4.3">
        <name slugifiedName="name-hysteresis">Hysteresis</name>
        <t indent="0" pn="section-4.3-1">Even after applying a bounded mapping from smoothed RTT to a cost
value, the cost may fluctuate when a link's RTT is between rtt-min and
rtt-max.  Implementations <bcp14>SHOULD</bcp14> use a robust hysteresis algorithm, such
as the one described in <xref target="RFC8966" sectionFormat="of" section="A.3" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8966#appendix-A.3" derivedContent="RFC8966"/>.</t>
      </section>
    </section>
    <section numbered="true" removeInRFC="false" toc="include" pn="section-5">
      <name slugifiedName="name-backwards-and-forwards-comp">Backwards and Forwards Compatibility</name>
      <t indent="0" pn="section-5-1">This protocol extension stores the data that it requires within
sub-TLVs of Babel's Hello and IHU TLVs.  As discussed in 
<xref target="RFC8966" sectionFormat="of" section="D" format="default" derivedLink="https://rfc-editor.org/rfc/rfc8966#appendix-D" derivedContent="RFC8966"/>, implementations that do not understand this
extension will silently ignore the sub-TLVs while parsing the rest of the
TLVs that they contain.  In effect, this extension supports building
hybrid networks consisting of extended and unextended routers; while
such networks might suffer from sub-optimal routing, they will not suffer
from routing loops or other pathologies.</t>
      <t indent="0" pn="section-5-2">If a sub-TLV defined in this extension is longer than expected, the
additional data is silently ignored.  This provision is made in order to
allow a future version of this protocol to extend the packet format with
additional data, for example high-precision or absolute timestamps.</t>
    </section>
    <section numbered="true" removeInRFC="false" toc="include" pn="section-6">
      <name slugifiedName="name-packet-format">Packet Format</name>
      <t indent="0" pn="section-6-1">This extension defines the Timestamp sub-TLV whose Type field has the value 
3.  This sub-TLV can be contained within a Hello sub-TLV, in which case it
carries a single timestamp, or within an IHU sub-TLV, in which case it
carries two timestamps.</t>
      <t indent="0" pn="section-6-2">Timestamps are encoded as 32-bit unsigned integers (modulo 2<sup>32</sup>),
expressed in units of one microsecond, counting from an arbitrary origin.
Timestamps wrap around every 4295 seconds, or roughly 71 minutes (see also
<xref target="wraparound" format="default" sectionFormat="of" derivedContent="Section 3.3"/>).</t>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-6.1">
        <name slugifiedName="name-timestamp-sub-tlv-in-hello-">Timestamp Sub-TLV in Hello TLVs</name>
        <t indent="0" pn="section-6.1-1">When contained within a Hello TLV, the Timestamp sub-TLV
has the following format:</t>
        <artwork align="left" pn="section-6.1-2">
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type = 3    |    Length     |      Transmit Timestamp       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          (continued)          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
        <dl newline="false" spacing="normal" indent="10" pn="section-6.1-3">
          <dt pn="section-6.1-3.1">Type:</dt>
          <dd pn="section-6.1-3.2">Set to 3 to indicate a Timestamp sub-TLV.</dd>
          <dt pn="section-6.1-3.3">Length:</dt>
          <dd pn="section-6.1-3.4">The length of the body in octets, exclusive of the Type
and Length fields.</dd>
          <dt pn="section-6.1-3.5">Transmit Timestamp:</dt>
          <dd pn="section-6.1-3.6">The time at which the packet containing
this sub-TLV was sent, according to the sender's clock.</dd>
        </dl>
        <t indent="0" pn="section-6.1-4">If the Length field is larger than the expected 4 octets, the sub-TLV
<bcp14>MUST</bcp14> be processed normally (the first 4 octets are interpreted as
described above) and any extra data contained in this sub-TLV <bcp14>MUST</bcp14> be
silently ignored.  If the Length field is smaller than the expected
4 octets, then this sub-TLV <bcp14>MUST</bcp14> be ignored (and the remainder of the
enclosing TLV processed as usual).</t>
      </section>
      <section numbered="true" removeInRFC="false" toc="include" pn="section-6.2">
        <name slugifiedName="name-timestamp-sub-tlv-in-ihu-tl">Timestamp Sub-TLV in IHU TLVs</name>
        <t indent="0" pn="section-6.2-1">When contained in an IHU TLV, the Timestamp sub-TLV has the following
format:</t>
        <artwork align="left" pn="section-6.2-2">
 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Type = 3    |    Length     |        Origin Timestamp       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          (continued)          |        Receive Timestamp      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          (continued)          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
        <dl newline="false" spacing="normal" indent="10" pn="section-6.2-3">
          <dt pn="section-6.2-3.1">Type:</dt>
          <dd pn="section-6.2-3.2">Set to 3 to indicate a Timestamp sub-TLV.</dd>
          <dt pn="section-6.2-3.3">Length:</dt>
          <dd pn="section-6.2-3.4">The length of the body in octets, exclusive of the Type
and Length fields.</dd>
          <dt pn="section-6.2-3.5">Origin Timestamp:</dt>
          <dd pn="section-6.2-3.6">A copy of the Transmit Timestamp of the last
Timestamp sub-TLV contained in a Hello TLV received from the node to which
the enclosing IHU TLV applies.</dd>
          <dt pn="section-6.2-3.7">Receive Timestamp:</dt>
          <dd pn="section-6.2-3.8">The time, according to the sender's clock,
at which the last timestamped Hello TLV was received from the node to which
the enclosing IHU TLV applies.</dd>
        </dl>
        <t indent="0" pn="section-6.2-4">If the Length field is larger than the expected 8 octets, the sub-TLV
<bcp14>MUST</bcp14> be processed normally (the first 8 octets are interpreted as
described above), and any extra data contained in this sub-TLV <bcp14>MUST</bcp14> be
silently ignored.  If the Length field is smaller than the expected
8 octets, then this sub-TLV <bcp14>MUST</bcp14> be ignored (and the remainder of the
enclosing TLV processed as usual).</t>
      </section>
    </section>
    <section numbered="true" removeInRFC="false" toc="include" pn="section-7">
      <name slugifiedName="name-iana-considerations">IANA Considerations</name>
      <t indent="0" pn="section-7-1">IANA has added the following entry to the "Babel Sub-TLV Types"
registry:</t>
      <table align="center" pn="table-1">
        <thead>
          <tr>
            <th align="left" colspan="1" rowspan="1">Type</th>
            <th align="left" colspan="1" rowspan="1">Name</th>
            <th align="left" colspan="1" rowspan="1">Reference</th>
          </tr>
        </thead>
        <tbody>
          <tr>
            <td align="left" colspan="1" rowspan="1">3</td>
            <td align="left" colspan="1" rowspan="1">Timestamp</td>
            <td align="left" colspan="1" rowspan="1">RFC 9616</td>
          </tr>
        </tbody>
      </table>
    </section>
    <section numbered="true" removeInRFC="false" toc="include" pn="section-8">
      <name slugifiedName="name-security-considerations">Security Considerations</name>
      <t indent="0" pn="section-8-1">This extension adds timestamping data to two of the TLVs sent by
  a Babel router.  By broadcasting the value of a reasonably accurate
  local clock, these additional data might make a node more susceptible
  to timing attacks.</t>
      <t indent="0" pn="section-8-2">Broadcasting an accurate time raises privacy issues.  The timestamps
used by this protocol have an arbitrary origin; therefore, they do not leak
a node's boot time or time zone.  However, having access to accurate
timestamps could allow an attacker to determine the physical location of
a node.  Nodes might avoid disclosure of location information by not
including Timestamp sub-TLVs in the TLVs that they send, which will cause
their neighbours to fall back to hop-count routing.</t>
    </section>
  </middle>
  <back>
    <references pn="section-9">
      <name slugifiedName="name-references">References</name>
      <references pn="section-9.1">
        <name slugifiedName="name-normative-references">Normative References</name>
        <reference anchor="RFC2119" target="https://www.rfc-editor.org/info/rfc2119" quoteTitle="true" derivedAnchor="RFC2119">
          <front>
            <title>Key words for use in RFCs to Indicate Requirement Levels</title>
            <author fullname="S. Bradner" initials="S." surname="Bradner"/>
            <date month="March" year="1997"/>
            <abstract>
              <t indent="0">In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="2119"/>
          <seriesInfo name="DOI" value="10.17487/RFC2119"/>
        </reference>
        <reference anchor="RFC8174" target="https://www.rfc-editor.org/info/rfc8174" quoteTitle="true" derivedAnchor="RFC8174">
          <front>
            <title>Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words</title>
            <author fullname="B. Leiba" initials="B." surname="Leiba"/>
            <date month="May" year="2017"/>
            <abstract>
              <t indent="0">RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.</t>
            </abstract>
          </front>
          <seriesInfo name="BCP" value="14"/>
          <seriesInfo name="RFC" value="8174"/>
          <seriesInfo name="DOI" value="10.17487/RFC8174"/>
        </reference>
        <reference anchor="RFC8966" target="https://www.rfc-editor.org/info/rfc8966" quoteTitle="true" derivedAnchor="RFC8966">
          <front>
            <title>The Babel Routing Protocol</title>
            <author fullname="J. Chroboczek" initials="J." surname="Chroboczek"/>
            <author fullname="D. Schinazi" initials="D." surname="Schinazi"/>
            <date month="January" year="2021"/>
            <abstract>
              <t indent="0">Babel is a loop-avoiding, distance-vector routing protocol that is robust and efficient both in ordinary wired networks and in wireless mesh networks. This document describes the Babel routing protocol and obsoletes RFC 6126 and RFC 7557.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8966"/>
          <seriesInfo name="DOI" value="10.17487/RFC8966"/>
        </reference>
      </references>
      <references pn="section-9.2">
        <name slugifiedName="name-informative-references">Informative References</name>
        <reference anchor="DELAY-BASED" target="http://arxiv.org/abs/1403.3488" quoteTitle="true" derivedAnchor="DELAY-BASED">
          <front>
            <title>A delay-based routing metric</title>
            <author fullname="Baptiste Jonglez" initials="B." surname="Jonglez"/>
            <author fullname="M. Boutier" initials="M." surname="Boutier"/>
            <author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek"/>
            <date month="March" year="2014"/>
          </front>
          <seriesInfo name="DOI" value="10.48550/arXiv.1403.3488"/>
        </reference>
        <reference anchor="RFC891" target="https://www.rfc-editor.org/info/rfc891" quoteTitle="true" derivedAnchor="RFC891">
          <front>
            <title>DCN Local-Network Protocols</title>
            <author fullname="D.L. Mills" initials="D.L." surname="Mills"/>
            <date month="December" year="1983"/>
            <abstract>
              <t indent="0">This RFC provides a description of the DCN protocols for maintaining connectivity, routing, and clock information in a local network. These procedures may be of interest to the designers and implementers of other local networks.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="44"/>
          <seriesInfo name="RFC" value="891"/>
          <seriesInfo name="DOI" value="10.17487/RFC0891"/>
        </reference>
        <reference anchor="RFC5905" target="https://www.rfc-editor.org/info/rfc5905" quoteTitle="true" derivedAnchor="RFC5905">
          <front>
            <title>Network Time Protocol Version 4: Protocol and Algorithms Specification</title>
            <author fullname="D. Mills" initials="D." surname="Mills"/>
            <author fullname="J. Martin" initials="J." role="editor" surname="Martin"/>
            <author fullname="J. Burbank" initials="J." surname="Burbank"/>
            <author fullname="W. Kasch" initials="W." surname="Kasch"/>
            <date month="June" year="2010"/>
            <abstract>
              <t indent="0">The Network Time Protocol (NTP) is widely used to synchronize computer clocks in the Internet. This document describes NTP version 4 (NTPv4), which is backwards compatible with NTP version 3 (NTPv3), described in RFC 1305, as well as previous versions of the protocol. NTPv4 includes a modified protocol header to accommodate the Internet Protocol version 6 address family. NTPv4 includes fundamental improvements in the mitigation and discipline algorithms that extend the potential accuracy to the tens of microseconds with modern workstations and fast LANs. It includes a dynamic server discovery scheme, so that in many cases, specific server configuration is not required. It corrects certain errors in the NTPv3 design and implementation and includes an optional extension mechanism. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="5905"/>
          <seriesInfo name="DOI" value="10.17487/RFC5905"/>
        </reference>
      </references>
    </references>
    <section numbered="false" removeInRFC="false" toc="include" pn="section-appendix.a">
      <name slugifiedName="name-acknowledgements">Acknowledgements</name>
      <t indent="0" pn="section-appendix.a-1">The authors are indebted to <contact fullname="Jean-Paul Smets"/>, who prompted the
investigation that originally lead to this protocol.  We are also grateful
to <contact fullname="Donald Eastlake, 3rd"/>, <contact fullname="Toke Høiland-Jørgensen"/>, <contact fullname="Maria Matejka"/>, <contact fullname="David Schinazi"/>,
<contact fullname="Pascal Thubert"/>, <contact fullname="Steffen Vogel"/>, and <contact fullname="Ondřej Zajiček"/>.</t>
    </section>
    <section anchor="authors-addresses" numbered="false" removeInRFC="false" toc="include" pn="section-appendix.b">
      <name slugifiedName="name-authors-addresses">Authors' Addresses</name>
      <author fullname="Baptiste Jonglez" initials="B." surname="Jonglez">
        <organization showOnFrontPage="true">ENS Lyon</organization>
        <address>
          <postal>
            <country>France</country>
          </postal>
          <email>baptiste.jonglez@ens-lyon.org</email>
        </address>
      </author>
      <author fullname="Juliusz Chroboczek" initials="J." surname="Chroboczek">
        <organization showOnFrontPage="true">IRIF, Université Paris Cité</organization>
        <address>
          <postal>
            <street>Case 7014</street>
            <city>75205 Paris Cedex 13</city>
            <country>France</country>
          </postal>
          <email>jch@irif.fr</email>
        </address>
      </author>
    </section>
  </back>
</rfc>
