<?xml version='1.0' encoding='utf-8'?> version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">
]>
<?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
<!-- generated by https://github.com/cabo/kramdown-rfc version 1.6.37 (Ruby 3.0.2) -->
<?rfc rfcedstyle="yes"?>
<?rfc tocindent="yes"?>
<?rfc strict="yes"?>
<?rfc comments="yes"?>
<?rfc compact="yes"?>
<?rfc inline="yes"?>
<?rfc text-list-symbols="-o*+"?>

<rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft-ietf-ippm-explicit-flow-measurements-07" category="info" number="9506" submissionType="IETF" category="info" consensus="true" tocDepth="6" tocInclude="true" sortRefs="true" symRefs="true" updates="" obsoletes="" xml:lang="en" version="3">
  <!-- xml2rfc v2v3 conversion 3.17.4 -->

  <front>
    <title abbrev="Delay and Loss bits">Explicit abbrev="Host-to-Network Flow Measurements">Explicit Host-to-Network Flow Measurements Techniques</title>
    <seriesInfo name="Internet-Draft" value="draft-ietf-ippm-explicit-flow-measurements-07"/> name="RFC" value="9506"/>
    <author initials="M." surname="Cociglio" fullname="Mauro Cociglio">
      <organization>Telecom Italia - TIM</organization>
      <address>
        <postal>
          <street>Via Reiss Romoli, 274</street>
          <city>Torino</city>
          <code>10148</code>
          <country>Italy</country>
        </postal>
        <email>mauro.cociglio@outlook.com</email>
      </address>
    </author>
    <author initials="A." surname="Ferrieux" fullname="Alexandre Ferrieux">
      <organization>Orange Labs</organization>
      <address>
        <email>alexandre.ferrieux@orange.com</email>
      </address>
    </author>
    <author initials="G." surname="Fioccola" fullname="Giuseppe Fioccola">
      <organization>Huawei Technologies</organization>
      <address>
        <postal>
          <street>Riesstrasse, 25</street>
          <city>Munich</city>
          <code>80992</code>
          <country>Germany</country>
        </postal>
        <email>giuseppe.fioccola@huawei.com</email>
      </address>
    </author>
    <author initials="I." surname="Lubashev" fullname="Igor Lubashev">
      <organization>Akamai Technologies</organization>
      <address>
        <email>ilubashe@akamai.com</email>
      </address>
    </author>
    <author initials="F." surname="Bulgarella" fullname="Fabio Bulgarella">
      <organization>Telecom Italia - TIM</organization>
      <address>
        <postal>
          <street>Via Reiss Romoli, 274</street>
          <city>Torino</city>
          <code>10148</code>
          <country>Italy</country>
        </postal>
        <email>fabio.bulgarella@guest.telecomitalia.it</email>
      </address>
    </author>
    <author initials="M." surname="Nilo" fullname="Massimo Nilo">
      <organization>Telecom Italia - TIM</organization>
      <address>
        <postal>
          <street>Via Reiss Romoli, 274</street>
          <city>Torino</city>
          <code>10148</code>
          <country>Italy</country>
        </postal>
        <email>massimo.nilo@telecomitalia.it</email>
      </address>
    </author>
    <author initials="I." surname="Hamchaoui" fullname="Isabelle Hamchaoui">
      <organization>Orange Labs</organization>
      <address>
        <email>isabelle.hamchaoui@orange.com</email>
      </address>
    </author>
    <author initials="R." surname="Sisto" fullname="Riccardo Sisto">
      <organization>Politecnico di Torino</organization>
      <address>
        <email>riccardo.sisto@polito.it</email>
      </address>
    </author>
    <date/>
    <area>Transport</area>
    <workgroup>IPPM</workgroup>
    <keyword>Internet-Draft</keyword>
    <date year="2023" month="October" />
    <area>tsv</area>
    <workgroup>ippm</workgroup>
    <keyword>Performance</keyword>
    <keyword>Monitoring</keyword>
    <keyword>Passive</keyword>
    <keyword>Hybrid</keyword>
    <keyword>Loss</keyword>
    <keyword>Delay</keyword>
    <keyword>Client</keyword>
    <keyword>Server</keyword>
    <keyword>On-path</keyword>
    <keyword>Observer</keyword>
    <keyword>Probe</keyword>
    <keyword>Alternate</keyword>
    <keyword>Marking</keyword>
    <keyword>Round</keyword>
    <keyword>Trip</keyword>
    <keyword>Latency</keyword>
    <keyword>Encrypted</keyword>
    <keyword>Protocol</keyword>
    <keyword>Bits</keyword>
    <abstract>
      <?line 108?>

<t>This document describes protocol independent protocol-independent methods called Explicit
Host-to-Network Flow Measurement Techniques that can be applicable to
transport-layer protocols between the client and server. These methods employ just a
few marking bits inside the header of each packet for performance measurements
and require collaborative the client and server. server to collaborate. Both endpoints cooperate by marking
packets and, possibly, mirroring the markings on the round-trip connection. The
techniques are especially valuable when applied to protocols that encrypt
transport headers, headers since they enable loss and delay measurements by passive passive,
on-path network devices. This document describes several methods that can be
used separately or jointly, jointly depending of the availability of marking bits,
desired measurements, and properties of the protocol to which the methods are
applied.</t>
    </abstract>
  </front>
  <middle>
    <?line 123?>

<section anchor="introduction">
      <name>Introduction</name>
      <t>Packet loss and delay are hard and pervasive problems of day-to-day network
operation. Proactively detecting, measuring, and locating them is crucial to
maintaining high QoS and timely resolution of end-to-end throughput issues.</t>
      <t>Detecting and measuring packet loss and delay allows network operators to
independently confirm trouble reports and, ideally, be proactively notified of
developing problems on the network. Locating the cause of packet loss or
excessive delay is the first step to resolving problems and restoring QoS.</t>
      <t>Traditionally, network
      <t>Network operators wishing to perform quantitative measurement of
packet loss and delay have been heavily relying on information present in the
clear in transport-layer headers (e.g. (e.g., TCP sequence and acknowledgment
numbers). By passively observing a network path at multiple points within one's
network, operators have been able to either quickly locate the source the
problem within their network or to reliably attribute it to an upstream or
downstream network.</t>
      <t>With encrypted protocols, the transport-layer headers are encrypted and passive
packet loss and delay observations are not possible, as also noted in
<xref target="TRANSPORT-ENCRYPT"/>. target="RFC9065"/>. Nevertheless, accurate measurement of packet loss and
delay experienced by encrypted transport-layer protocols is highly desired,
especially by network operators who own or control the infrastructure between the
client and server.</t>
      <t>The measurement of loss and delay experienced by connections using an encrypted
protocol cannot be based on a measurement of loss and delay experienced by
connections between the same or similar endpoints that use an unencrypted
protocol, since
protocol because different protocols may utilize the network differently and be
routed differently by the network. Therefore, it is necessary to directly
measure the packet loss and delay experienced by users of encrypted protocols.</t>
      <t>The Alternate-Marking method <xref target="AltMark"/> target="RFC9341"/> defines a consolidated method to
perform packet loss, delay, and jitter measurements on live traffic. However,
as mentioned in <xref target="IPv6AltMark"/>, target="RFC9343"/>, <xref target="AltMark"/> target="RFC9341"/> mainly applies to a network layer
controlled network-layer-controlled
domain managed with a Network Management System (NMS), where the CPE Customer Premises Equipment (CPE)
or the PE Provider Edge (PE) routers are the starting or the ending nodes. <xref target="AltMark"/> target="RFC9341"/> provides
measurement within a controlled domain in which the packets are
marked. Therefore, applying <xref target="AltMark"/> target="RFC9341"/> to end-to-end transport-layer
connections is not easy because packet identification and marking by network
nodes is prevented when encrypted transport-layer headers (e.g. (e.g., QUIC, TCP with
TLS) are being used.</t>
      <t>This document defines Explicit Host-to-Network Flow Measurement Techniques that
are specifically designed for encrypted transport protocols. According to the
definitions of <xref target="IPPM-METHODS"/>, target="RFC7799"/>, these measurement methods can be classified as
Hybrid. They are to be embedded into a transport-layer protocol and are
explicitly intended for exposing delay and loss rate information to on-path
measurement devices. Unlike <xref target="AltMark"/>, target="RFC9341"/>, most of these methods require
collaborative endpoint nodes. Since these measurement techniques make performance
information directly visible to the path, they do not rely on an external NMS.</t>
      <t>The Explicit Host-to-Network Flow Measurement Techniques described in this
document are applicable to any transport-layer protocol connecting a client and a
server. In this document document, the client and the server are also referred to as the
endpoints of the transport-layer protocol.</t>
      <t>The different methods described in this document can be used alone or in
combination. Each technique uses few bits and exposes a specific measurement.
It is assumed that the endpoints are collaborative in the sense of the
measurements, indeed both the client and server needs need to cooperate.</t>
      <t>Following the recommendation in <xref target="RFC8558"/> of making path signals explicit,
this document proposes adding some dedicated measurement bits to the clear
portion of the transport protocol headers. These bits can be added to an
unencrypted portion of a transport-layer header, e.g. e.g., UDP surplus space (see
<xref target="UDP-OPTIONS"/> target="I-D.ietf-tsvwg-udp-options"/> and <xref target="UDP-SURPLUS"/>) target="I-D.herbert-udp-space-hdr"/>) or reserved bits in a QUIC v1 header, as
already done with the latency Spin bit (see Section 17.4 of
<xref target="QUIC-TRANSPORT"/>). target="RFC9000" sectionFormat="of" section="17.4"/>). Note that this document does not recommend the use of any
specific bits, as these would need to be chosen by the specific protocol
implementations (see <xref target="applications"/>).</t>
      <t>The Spin bit, Delay bit bit, and loss bits explained in this document are inspired by
<xref target="AltMark"/>, target="RFC9341"/>, <xref target="QUIC-MANAGEABILITY"/>, target="RFC9312"/>, <xref target="QUIC-SPIN"/>, target="I-D.trammell-quic-spin"/>, <xref target="I-D.trammell-tsvwg-spin"/> target="I-D.trammell-tsvwg-spin"/>,
and <xref target="I-D.trammell-ippm-spin"/>.</t>
      <t>Additional details about the Performance Measurements performance measurements for QUIC are described in
the paper <xref target="ANRW19-PM-QUIC"/>.</t>
    </section>
    <section anchor="latency-bits">
      <name>Latency Bits</name>
      <t>This section introduces bits that can be used for round trip round-trip latency
measurements.  Whenever this section of the specification refers to packets, it
is referring only to packets with protocol headers that include the latency
bits.</t>
      <t>In section 17.4, <xref target="QUIC-TRANSPORT"/> target="RFC9000" sectionFormat="comma" section="17.4"/> introduces an explicit explicit, per-flow
transport-layer signal for hybrid measurement of RTT.  This signal consists of a
Spin bit that toggles once per RTT. Section 4 of <xref target="QUIC-SPIN"/> target="I-D.trammell-quic-spin" sectionFormat="of" section="4"/> discusses an
additional two-bit Valid Edge Counter (VEC) to compensate for loss and
reordering of the Spin bit and to increase fidelity of the signal in less than
ideal network conditions.</t>
      <t>This document introduces a stand-alone standalone single-bit delay signal that can be used
by passive observers to measure the RTT of a network flow, avoiding the Spin bit
ambiguities that arise as soon as network conditions deteriorate.</t>
      <section anchor="spinbit">
        <name>Spin Bit</name>
        <t>This section is a small recap of the Spin bit working mechanism. For a
comprehensive explanation of the algorithm, see Section 3.8.2 of
<xref target="QUIC-MANAGEABILITY"/>.</t> target="RFC9312" sectionFormat="of" section="3.8.2"/>.</t>
        <t>The Spin bit is an a signal generated by Alternate-Marking <xref target="AltMark"/> generated signal, target="RFC9341"/>, where the
size of the alternation changes with the flight size each RTT.</t>
        <t>The latency Spin bit is a single bit single-bit signal that toggles once per RTT,
enabling latency monitoring of a connection-oriented communication
from intermediate observation points.</t>
        <t>A "spin "Spin bit period" is a set of packets with the same Spin bit value sent during one
RTT time interval. A "spin "Spin bit period value" is the value of the Spin bit shared by
all packets in a spin Spin bit period.</t>
        <t>The client and server maintain an internal per-connection spin value (i.e. (i.e., 0 or
1) used to set the Spin bit on outgoing packets. Both endpoints initialize the
spin value to 0 when a new connection starts. Then:</t>
        <ul spacing="normal">
          <li>when the client receives a packet with the packet number larger than any
 number seen so far, it sets the connection spin value to the opposite value
 contained in the received packet;</li> packet; and</li>
          <li>when the server receives a packet with the packet number larger than any
 number seen so far, it sets the connection spin value to the same value
 contained in the received packet.</li>
        </ul>
        <t>The computed spin value is used by the endpoints for setting the spin Spin
bit on outgoing packets.  This mechanism allows the endpoints
to generate a square wave such that, by measuring the distance in time
between pairs of consecutive edges observed in the same direction, a
passive on-path observer can compute the round trip round-trip network delay of that
network flow.</t>
        <t>Spin bit enables round trip round-trip latency measurement by observing a single direction
of the traffic flow.</t>
        <t>Note that packet reordering can cause spurious edges that require heuristics to
correct. The Spin bit performance deteriorates as soon as network impairments
arise as explained in <xref target="delaybit"/>.</t>
      </section>
      <section anchor="delaybit">
        <name>Delay Bit</name>
        <t>The Delay bit has been designed to overcome accuracy limitations experienced by
the Spin bit under difficult network conditions:</t>
        <ul spacing="normal">
          <li>packet reordering leads to generation of spurious edges and errors in delay
estimation;</li>
          <li>loss of edges causes wrong estimation of spin Spin bit periods and therefore wrong RTT
measurements;</li>
measurements; and</li>
          <li>application-limited senders cause the Spin bit to measure the application
delays instead of network delays.</li>
        </ul>
        <t>Unlike the Spin bit, which is set in every packet transmitted on the network,
the Delay bit is set only once per round trip.</t>
        <t>When the Delay bit is used, a single packet with a marked bit (the Delay bit)
bounces between a client and a server during the entire connection lifetime.
This single packet is called the "delay sample".</t>
        <t>An observer placed at an intermediate point, observing a single direction of
traffic,
traffic and tracking the delay sample and the relative timestamp, can measure the
round trip
round-trip delay of the connection.</t>
        <t>The delay sample lifetime comprises two phases: initialization and reflection.
The initialization is the generation of the delay sample, while the
reflection realizes the bounce behavior of this single packet between the two
endpoints.</t>
        <t>The next figure describes the elementary Delay bit mechanism.</t>
        <figure>
          <name>Delay bit mechanism</name> Bit Mechanism</name>
          <artwork><![CDATA[
              +--------+   -   -   -   -   -   +--------+
              |        |      ----------->     |        |
              | Client |                       | Server |
              |        |     <-----------      |        |
              +--------+   -   -   -   -   -   +--------+

              (a) No traffic at beginning.

              +--------+   0   0   1   -   -   +--------+
              |        |      ----------->     |        |
              | Client |                       | Server |
              |        |     <-----------      |        |
              +--------+   -   -   -   -   -   +--------+

              (b) The Client starts sending data and sets
                  the first packet as Delay Sample. the delay sample.

              +--------+   0   0   0   0   0   +--------+
              |        |      ----------->     |        |
              | Client |                       | Server |
              |        |     <-----------      |        |
              +--------+   -   -   -   1   0   +--------+

              (c) The Server starts sending data
                  and reflects the Delay Sample. delay sample.

              +--------+   0   1   0   0   0   +--------+
              |        |      ----------->     |        |
              | Client |                       | Server |
              |        |     <-----------      |        |
              +--------+   0   0   0   0   0   +--------+

              (d) The Client reflects the Delay Sample. delay sample.

              +--------+   0   0   0   0   0   +--------+
              |        |      ----------->     |        |
              | Client |                       | Server |
              |        |     <-----------      |        |
              +--------+   0   0   0   1   0   +--------+

              (e) The Server reflects the Delay Sample delay sample
                  and so on.
]]></artwork>
        </figure>
        <section anchor="generation-phase">
          <name>Generation Phase</name>
          <t>Only the client is actively involved in the generation phase. Generation Phase. It maintains an
internal per-flow timestamp variable (<tt>ds_time</tt>) updated every time a delay
sample is transmitted.</t>
          <t>When connection starts, the client generates a new delay sample initializing the
Delay bit of the first outgoing packet to 1.  Then it updates the <tt>ds_time</tt>
variable with the timestamp of its transmission.</t>
          <t>The server initializes the Delay bit to 0 at the beginning of the connection,
and its only task during the connection is described in <xref target="reflection-phase"/>.</t>
          <t>In absence of network impairments, the delay sample should bounce between the client
and server continuously, continuously for the entire duration of the connection.  That  However, that is
highly unlikely for two reasons:</t>
          <ol spacing="normal" type="1"><li>the type="1"><li>The packet carrying the Delay bit might be lost;</li>
            <li>an lost.</li>
            <li>An endpoint could stop or delay sending packets because the application is
limiting the amount of traffic transmitted.</li>
          </ol>
          <t>To deal with these problems, the client generates a new delay sample if more
than a predetermined time (<tt>T_Max</tt>) has elapsed since the last delay sample
transmission (including reflections). Note that <tt>T_Max</tt> should be greater than
the max measurable RTT on the network. See <xref target="tmax-selection"/> for details.</t>
        </section>
        <section anchor="reflection-phase">
          <name>Reflection Phase</name>
          <t>Reflection is the process that enables the bouncing of the delay sample between
a client and a server.  The behavior of the two endpoints is almost the same.</t>
          <ul spacing="normal">
            <li>Server side
            <li>Server-side reflection: when When a delay sample arrives, the server marks the
first packet in the opposite direction as the delay sample.</li>
            <li>Client side
            <li>Client-side reflection: when When a delay sample arrives, the client marks the
first packet in the opposite direction as the delay sample. It also updates
the <tt>ds_time</tt> variable when the outgoing delay sample is actually forwarded.</li>
          </ul>
          <t>In both cases, if the outgoing delay sample is being transmitted with a delay
greater than a predetermined threshold after the reception of the incoming delay
sample (1ms (1 ms by default), the delay sample is not reflected, and the outgoing
Delay bit is kept at 0.</t>
          <t>By doing so, the algorithm can reject measurements that would overestimate the
delay due to lack of traffic on at the endpoints.  Hence, the maximum estimation
error would amount to twice the threshold (e.g. 2ms) (e.g., 2 ms) per measurement.</t>
        </section>
        <section anchor="tmax-selection">
          <name>T_Max
          <name><tt>T_Max</tt> Selection</name>
          <t>The internal <tt>ds_time</tt> variable allows a client to identify delay sample losses.
Considering that a lost delay sample is regenerated at the end of an explicit
time (<tt>T_Max</tt>) since the last generation, this same value can be used by an
observer to reject a measure and start a new one.</t>
          <t>In other words, if the difference in time between two delay samples is greater
or equal than <tt>T_Max</tt>, then these cannot be used to produce a delay measure.
Therefore, the value of <tt>T_Max</tt> must also be known to the on-path network probes.</t>
          <t>There are two alternatives to select selecting the <tt>T_Max</tt> value so that both the client and
observers know it. The first one requires that <tt>T_Max</tt> is known a priori
(<tt>T_Max_p</tt>) and therefore set within the protocol specifications that implements
the marking mechanism (e.g. (e.g., 1 second second, which usually is greater than the max
expectable
expected RTT). The second alternative requires a dynamic mechanism able to
adapt the duration of the <tt>T_Max</tt> to the delay of the connection (<tt>T_Max_c</tt>).</t>
          <t>For instance, the client and observers could use the connection RTT as a basis for
calculating an effective <tt>T_Max</tt>. They should use a predetermined initial value
so that <tt>T_Max = T_Max_p</tt> (e.g. (e.g., 1 second) and then, when a valid RTT is
measured, change <tt>T_Max</tt> accordingly so that <tt>T_Max = T_Max_c</tt>. In any case, the
selected <tt>T_Max</tt> should be large enough to absorb any possible variations in the
connection delay. This also helps to prevent the mechanism from failing when the
observer cannot recognize sudden changes in RTT exceeding T_max.</t> <tt>T_Max</tt>.</t>
          <t><tt>T_Max_c</tt> could be computed as two times the measured <tt>RTT</tt> plus a fixed amount
of time (<tt>100ms</tt>) (100 ms) to prevent low <tt>T_Max</tt> values in the case of very small RTTs.
The resulting formula is: <tt>T_Max_c = 2RTT + 100ms</tt>. 100 ms</tt>. If <tt>T_Max_c</tt> is greater than
<tt>T_Max_p</tt>
<tt>T_Max_p</tt>, then <tt>T_Max_c</tt> is forced to the <tt>T_Max_p</tt> value.
Note that the value of 100ms 100 ms is provided as an example, and it may be chosen
differently depending on the specific scenarios. For instance, an implementer may
consider using existing protocol-specific values if appropriate.</t>
          <t>Note that the observer's <tt>T_Max</tt> should always be less than or equal to the
client's <tt>T_Max</tt> to avoid considering as a valid measurement what is actually
the client's <tt>T_Max</tt>. To obtain this result, the client waits for two
consecutive incoming samples and computes the two related RTTs. Then it takes
the largest of them as the basis of the <tt>T_Max_c</tt> formula. At this point,
observers have already measured a valid RTT and then computed their <tt>T_Max_c</tt>.</t>
        </section>
        <section anchor="delay-measurement-using-delay-bit">
          <name>Delay Measurement Using the Delay Bit</name>
          <t>When the Delay bit is used, a passive observer can use delay samples directly
and avoid inherent ambiguities in the calculation of the RTT as can be seen in
Spin bit analysis.</t>
          <section anchor="rtt-measurement">
            <name>RTT Measurement</name>
            <t>The delay sample generation process ensures that only one packet marked with the
Delay bit set to 1 runs back and forth between two endpoints per round trip round-trip
time.  To determine the RTT measurement of a flow, an on-path passive observer
computes the time difference between two delay samples observed in a single
direction.</t>
            <t>To ensure a valid measurement, the observer must verify that the distance in
time between the two samples taken into account is less than <tt>T_Max</tt>.</t>
            <figure>
              <name>Round-trip time (both direction)</name>
              <name>Round-Trip Time (Both Directions)</name>
              <artwork><![CDATA[
           =======================|======================>
           = **********     -----Obs---->     ********** =
           = * Client *                       * Server * =
           = **********     <------------     ********** =
           <==============================================

                     (a) client-server RTT

           ==============================================>
           = **********     ------------>     ********** =
           = * Client *                       * Server * =
           = **********     <----Obs-----     ********** =
           <======================|=======================

                     (b) server-client RTT
]]></artwork>
            </figure>
          </section>
          <section anchor="half-rtt-measurement">
            <name>Half-RTT Measurement</name>
            <t>An observer that is able to observe both forward and return traffic directions
can use the delay samples to measure "upstream" and "downstream" RTT components,
also known as the half-RTT measurements. It does this by measuring the time
between a delay sample observed in one direction and the delay sample previously
observed in the opposite direction.</t>
            <t>As with RTT measurement, the observer must verify that the distance in time
between the two samples taken into account is less than <tt>T_Max</tt>.</t>
            <t>Note that upstream and downstream sections of paths between the endpoints and
the observer, i.e. observer (i.e., observer-to-client vs vs. client-to-observer and
observer-to-server vs server-to-observer, vs. server-to-observer) may have different delay
characteristics due to the difference in network congestion and other factors.</t>
            <figure>
              <name>Half Round-trip time (both direction)</name> Round-Trip Time (Both Directions)</name>
              <artwork><![CDATA[
           =======================>
           = **********     ------|----->     **********
           = * Client *          Obs          * Server *
           = **********     <-----|------     **********
           <=======================

                  (a) client-observer half-RTT

                                  =======================>
             **********     ------|----->     ********** =
             * Client *          Obs          * Server * =
             **********     <-----|------     ********** =
                                  <=======================

                  (b) observer-server half-RTT
]]></artwork>
            </figure>
          </section>
          <section anchor="intra-domain-rtt-measurement">
            <name>Intra-Domain
            <name>Intra-domain RTT Measurement</name>
            <t>Intra-domain RTT is the portion of the entire RTT used by a flow to traverse the
network of a provider.  To measure intra-domain RTT, two observers capable of
observing traffic in both directions must be employed simultaneously at the ingress
and egress of the network to be measured.  Intra-domain RTT is the difference
between the two computed upstream (or downstream) RTT components.</t>
            <figure>
              <name>Intra-domain Round-trip time (client-observer: upstream)</name> Round-Trip Time (Client-Observer: Upstream)</name>
              <artwork><![CDATA[
        =========================================>
        = =====================>
        = = **********      ---|-->           ---|-->      **********
        = = * Client *         Obs               Obs       * Server *
        = = **********      <--|---           <--|---      **********
        = <=====================
        <=========================================

                 (a) client-observer RTT components (half-RTTs)

                               ==================>
            **********      ---|-->           ---|-->      **********
            * Client *         Obs               Obs       * Server *
            **********      <--|---           <--|---      **********
                               <==================

                 (b) the intra-domain RTT resulting from the
                     subtraction of the above RTT components
]]></artwork>
            </figure>
          </section>
        </section>
        <section anchor="observers-algorithm">
          <name>Observer's Algorithm</name>
          <t>An on-path observer maintains an internal per-flow variable to keep track of
the time at which the last delay sample has been observed. The flow characterization
should be part of the protocol.</t>
          <t>A unidirectional
          <t>If the observer is unidirectional or in case of asymmetric routing, then upon detecting a
delay sample:</t>
          <ul spacing="normal">
            <li>if a delay sample was also detected previously in the same direction and the
distance in time between them is less than <tt>T_Max - K</tt>, then the two delay
samples can be used to calculate RTT measurement. <tt>K</tt> is a protection
threshold to absorb differences in <tt>T_Max</tt> computation and delay variations
between two consecutive delay samples (e.g. (e.g., <tt>K = 10% T_Max</tt>).</li>
          </ul>
          <t>If the observer can observe both forward and return traffic flows, and it is
able to determine which direction contains the client and the server (e.g. (e.g., by
observing the connection handshake), then upon detecting a delay sample:</t>
          <ul spacing="normal">
            <li>if a delay sample was also detected in the opposite direction and the distance
in time between them is less than <tt>T_Max - K</tt>, then the two delay samples can
be used to measure the observer-client half-RTT or the observer-server
half-RTT, according to the direction of the last delay sample observed.</li>
          </ul>
          <t>Note that the accuracy can be influenced by what the observer is capable of
observing. Additionally, the type of measurement differs, as described in the
previous sections.</t>
        </section>
        <section anchor="two-bits-delay-measurement-spin-bit-delay-bit">
          <name>Two Bits Delay Measurement: Spin Bit + Delay Bit</name>
          <t>Spin
          <t>The Spin and Delay bit algorithms work independently. If both marking methods are
used in the same connection, observers can choose the best measurement between
the two available:</t>
          <ul spacing="normal">
            <li>when a precise measurement can be produced using the Delay bit, observers
choose it;</li> it; and</li>
            <li>when a Delay bit measurement is not available, observers choose the
approximate Spin bit one.</li>
          </ul>
        </section>
      </section>
    </section>
    <section anchor="loss-bits">
      <name>Loss Bits</name>
      <t>This section introduces bits that can be used for loss measurements.
Whenever this section of the specification refers to packets, it is
referring only to packets with protocol headers that include the loss
bits -- the only packets whose loss can be measured.</t>
      <ul spacing="normal">
        <li>T: the "round Trip
      <dl>
        <dt>T:</dt>
        <dd>The "round-Trip loss" bit is used in combination with the Spin bit to
measure round-trip loss. See <xref target="rtlossbit"/>.</li>
        <li>Q: the "sQuare signal" target="rtlossbit"/>.</dd>
        <dt>Q:</dt>
        <dd>The "sQuare" bit is used to measure upstream loss. See
<xref target="squarebit"/>.</li>
        <li>L: the target="squarebit"/>.</dd>
        <dt>L:</dt>
        <dd>The "Loss event" Event" bit is used to measure end-to-end loss. See <xref target="lossbit"/>.</li>
        <li>R: the target="lossbit"/>.</dd>
        <dt>R:</dt>
        <dd>The "Reflection square signal" square" bit is used in combination with the Q bit to
measure end-to-end loss. See <xref target="refsquarebit"/>.</li>
      </ul> target="refsquarebit"/>.</dd>
      </dl>
      <t>Loss measurements enabled by T, Q, and L bits can be implemented by those loss
bits alone (T bit requires a working Spin bit). Two-bit combinations Q+L and Q+R
enable additional measurement opportunities discussed below.</t>
      <t>Each endpoint maintains appropriate counters independently and separately for
each separately identifiable flow (each (or each sub-flow for multipath connections).</t>
      <t>Since loss is reported independently for each flow, all bits (except for the L bit)
require a certain minimum number of packets to be exchanged per flow before any
signal can be measured. Therefore, loss measurements work best for flows that
transfer more than a minimal amount of data.</t>
      <section anchor="rtlossbit">
        <name>T Bit -- Round Trip Round-Trip Loss Bit</name>
        <t>The round Trip round-Trip loss bit is used to mark a variable number of packets exchanged
twice between the endpoints realizing a two round-trip reflection. A passive
on-path observer, observing either direction, can count and compare the number
of marked packets seen during the two reflections, estimating the loss rate
experienced by the connection. The overall exchange comprises:</t>
        <ul spacing="normal">
          <li>the client selects and consequently sets the T bit to 1 in order to identify
a first train of packets;</li>
          <li>the server, upon
          <li>upon receiving each packet included in the first train, the server sets the T bit to 1 and reflects
to the client a respective second train of packets of the same size as the
first train received, by setting the T bit to 1;</li>
          <li>the client, upon received;</li>
          <li>upon receiving each packet included in the second train, the client sets the T bit to 1 and reflects
to the server a respective third train of packets of the same size as the
second train received, by setting the T bit to 1;</li>
          <li>the server, upon received; and</li>
          <li>upon receiving each packet included in the third train, the server sets the T bit to 1 and finally
reflects to the client a respective fourth train of packets of the same size
as the third train received, by setting the T bit to 1.</li> received.</li>
        </ul>
        <t>Packets belonging to the first round trip (first and second train)
represent the Generation Phase, while those belonging to the second
round trip (third and fourth train) represent the Reflection Phase.</t>
        <t>A passive on-path observer can count and compare the number of marked
packets seen during the two round trips (i.e. (i.e., the first and third
or the second and the fourth trains of packets, depending on which
direction is observed) and estimate the loss rate experienced by the
connection. This process is repeated continuously to obtain more
measurements as long as the endpoints exchange traffic.  These
measurements can be called Round Trip round-trip losses.</t>
        <t>Since the packet rates in two directions may be different, the number of marked
packets in the train is determined by the direction with the lowest packet rate.
See <xref target="tbit-details"/> for details on packet generation.</t>
        <section anchor="round-trip-loss">
          <name>Round Trip
          <name>Round-Trip Loss</name>
          <t>Since the measurements are performed on a portion of the traffic exchanged
between the client and the server, the observer calculates the end-to-end Round
Trip Round-Trip
Packet Loss (RTPL) that, statistically, will correspond to the loss rate
experienced by the connection along the entire network path.</t>
          <figure>
            <name>Round-trip packet loss (both direction)</name>
            <name>Round-Trip Packet Loss (Both Directions)</name>
            <artwork><![CDATA[
           =======================|======================>
           = **********     -----Obs---->     ********** =
           = * Client *                       * Server * =
           = **********     <------------     ********** =
           <==============================================

                     (a) client-server RTPL

           ==============================================>
           = **********     ------------>     ********** =
           = * Client *                       * Server * =
           = **********     <----Obs-----     ********** =
           <======================|=======================

                     (b) server-client RTPL
]]></artwork>
          </figure>
          <t>This methodology also allows the Half-RTPL half-RTPL measurement and
the Intra-domain RTPL measurement in a way similar to RTT measurement.</t>
          <figure>
            <name>Half Round-trip packet loss (both direction)</name> Round-Trip Packet Loss (Both Directions)</name>
            <artwork><![CDATA[
           =======================>
           = **********     ------|----->     **********
           = * Client *          Obs          * Server *
           = **********     <-----|------     **********
           <=======================

                  (a) client-observer half-RTPL

                                  =======================>
             **********     ------|----->     ********** =
             * Client *          Obs          * Server * =
             **********     <-----|------     ********** =
                                  <=======================

                  (b) observer-server half-RTPL
]]></artwork>
          </figure>
          <figure>
            <name>Intra-domain Round-trip packet loss (observer-server)</name> Round-Trip Packet Loss (Observer-Server)</name>
            <artwork><![CDATA[
                           =========================================>
                                             =====================> =
        **********      ---|-->           ---|-->      ********** = =
        * Client *         Obs               Obs       * Server * = =
        **********      <--|---           <--|---      ********** = =
                                             <===================== =
                           <=========================================

             (a) observer-server RTPL components (half-RTPLs)

                           ==================>
        **********      ---|-->           ---|-->      **********
        * Client *         Obs               Obs       * Server *
        **********      <--|---           <--|---      **********
                           <==================

             (b) the intra-domain RTPL resulting from the
                 subtraction of the above RTPL components
]]></artwork>
          </figure>
        </section>
        <section anchor="tbit-details">
          <name>Setting the Round Trip Round-Trip Loss Bit on Outgoing Packets</name>
          <t>The round Trip round-Trip loss signal requires a working Spin-bit Spin bit signal to separate trains
of marked packets (packets with T bit set to 1).  A "pause" of at least one
empty spin-bit Spin bit period between each phase of the algorithm serves as such a
separator for the on-path observer. The connection between T Bit bit and Spin-bit Spin bit
helps the correlations on the observer.</t> observer correlate packet trains.</t>
          <t>The client maintains a "generation token" count that is set to zero at the
beginning of the session and is incremented every time a packet is received
(marked or unmarked). The client also maintains a "reflection counter" that
starts at zero at the beginning of the session.</t>
          <t>The client is in charge of launching trains of marked packets and does so
according to the algorithm:</t>
          <ol spacing="normal" type="1"><li>Generation Phase. The client starts generating marked packets for two
consecutive spin-bit periods; when Spin bit periods. When the client transmits a packet and a
"generation token" is available, the client marks the packet and retires a
"generation token". If no token is available, the outgoing packet is
transmitted unmarked.  At the end of the first spin-bit Spin bit period spent in
generation, the reflection counter is unlocked to start counting incoming
marked packets that will be reflected later;</li> later.</li>
            <li>Pause Phase. When the generation is completed, the client pauses till it has
observed one entire Spin bit period with no marked packets.  That Spin bit
period is used by the observer as a separator between generated and
reflected packets.  During this marking pause, all the outgoing packets are
transmitted with T bit set to 0.  The reflection counter is still
incremented every time a marked packet arrives;</li> arrives.</li>
            <li>Reflection Phase. The client starts transmitting marked packets,
decrementing the reflection counter for each transmitted marked packet until
the reflection counter has reached zero. The "generation token" method from the
generation phase
Generation Phase is used during this phase as well.  At the end of the first
spin-period
Spin bit period spent in reflection, the reflection counter is locked to avoid
incoming reflected packets incrementing it;</li> it.</li>
            <li>Pause Phase 2. The pause phase Pause Phase is repeated after the reflection phase Reflection Phase and
serves as a separator between the reflected packet train and a new packet
train.</li>
          </ol>
          <t>The generation token counter should be capped to limit the effects of a
subsequent sudden reduction in the other endpoint's packet rate that could
prevent that endpoint from reflecting collected packets. It is recommended a A
cap value of <tt>1</tt>.</t> 1 is recommended.</t>
          <t>A server maintains a "marking counter" that starts at zero and is incremented
every time a marked packet arrives. When the server transmits a packet and the
"marking counter" is positive, the server marks the packet and decrements the
"marking counter". If the "marking counter" is zero, the outgoing packet is
transmitted unmarked.</t>
          <t>Note that a choice of 2-RTT 2 RTT (two spin Spin bit periods) for the generation phase Generation Phase is a
tradeoff
trade-off between the percentage of marked packets (i.e. (i.e., the percentage of
traffic monitored) and the measurement delay. Using this value value, the algorithm
produces a measurement approximately every 6-RTT (<tt>2</tt> generation, <tt>~2</tt>
reflection, <tt>2</tt> 6 RTT (2 generations, ~2
reflections, 2 pauses), marking <tt>~1/3</tt> ~1/3 of packets exchanged in the slower
direction (see <xref target="tbit-losscov"/>). Choosing a generation phase Generation Phase of 1-RTT, 1 RTT, we would
produce measurements every 4-RTT, 4 RTT, monitoring just <tt>~1/4</tt> ~1/4 of packets in the
slower direction.</t>
          <t>It is worth mentioning that problems can happen in some cases cases, especially if the
rate suddenly changes, but in the implementation, the mechanism here described here
worked well with normal traffic conditions.</t> conditions in the implementation.</t>
        </section>
        <section anchor="observers-logic-for-round-trip-loss-signal">
          <name>Observer's Logic for Round Trip Round-Trip Loss Signal</name>
          <t>The on-path observer counts marked packets and separates different trains by
detecting spin-bit Spin bit periods (at least one) with no marked packets.  The Round
Trip Round-Trip Packet Loss (RTPL) is the difference between the size of the Generation
train and the Reflection train.</t>
          <t>In the following example, packets are represented by two bits (first one
is the Spin bit, second one is the round Trip round-Trip loss bit):</t>
          <figure>
            <name>Round Trip
            <name>Round-Trip Loss signal example</name> Signal Example</name>
            <artwork><![CDATA[
        Generation          Pause           Reflection       Pause
   ____________________ ______________ ____________________ ________
  |                    |              |                    |        |
   01 01 00 01 11 10 11 00 00 10 10 10 01 00 01 01 10 11 10 00 00 10
]]></artwork>
          </figure>
          <t>Note that 5 marked packets have been generated generated, of which 4 have been reflected.</t>
        </section>
        <section anchor="tbit-losscov">
          <name>Loss Coverage and Signal Timing</name>
          <t>A cycle of the round Trip round-Trip loss signaling algorithm contains 2 RTTs of Generation
phase, 2 RTTs of Reflection phase, Phase, and two 2 Pause phases Phases at least 1 RTT in
duration each.  Hence, the loss signal is delayed by about 6 RTTs since the loss
events.</t>
          <t>The observer can only detect the loss of marked packets that occurs after its
initial observation of the Generation phase Phase and before its subsequent
observation of the Reflection phase. Phase. Hence, if the loss occurs on the path that
sends packets at a lower rate (typically ACKs in such asymmetric scenarios),
<tt>2/6</tt> (<tt>1/3</tt>)
2/6 (1/3) of the packets will be sampled for loss detection.</t>
          <t>If the loss occurs on the path that sends packets at a higher rate,
<tt>lowPacketRate/(3*highPacketRate)</tt> of the packets will be sampled for loss
detection. For protocols that use ACKs, the portion of packets sampled for loss
in the higher rate direction during unidirectional data transfer is
<tt>1/(3*packetsPerAck)</tt>, where the value of <tt>packetsPerAck</tt> can vary by protocol,
by implementation, and by network conditions.</t>
        </section>
      </section>
      <section anchor="squarebit">
        <name>Q Bit -- sQuare Bit</name>
        <t>The sQuare bit (Q bit) takes its name from the square wave generated by its
signal. This method is based on the Alternate-Marking method <xref target="AltMark"/> target="RFC9341"/>, and
the Q bit represents the "packet color" that allows can be switched between 0 and 1 in order to mark consecutive blocks
of packets with different colors. This method does not require cooperation from
both endpoints.</t>
        <t><xref target="AltMark"/> target="RFC9341"/> introduces two variations of the Alternate-Marking method depending
on whether the color is switched according to a fixed timer or after a fixed
number of packets. The method based Cooperating and synchronized observers on fixed timer either end of a network
segment can use the fixed-timer method to measure packet loss on a
network segment by cooperating and synchronized observers on both ends of the
segment by comparing packets packet counters for the same packet blocks.  The time length of
the blocks can be chosen depending on the desired measurement frequency, but it
must be long enough to guarantee the proper operation with respect to clock errors
and network delay issues.</t>
        <t>The Q bit method described in this document chooses the color-switching method
based on a fixed number of packets for each block. This approach has the
advantage that it does not require cooperating or synchronized observers or
network elements. Each probe can measure packet loss autonomously without
relying on an external Network Management System (NMS). NMS. For the purpose of the
packet loss measurement, all blocks have the same number of packets, and it is
necessary to detect only the loss event and not to identify the exact block with
losses.</t>
        <t>Following the method based on fixed number of packets, the square wave signal is
generated by the switching of the Q bit: every outgoing packet contains the Q
bit value, which is initialized to 0 and inverted after sending N packets (a
sQuare Block or simply Q Block). Hence, Q Period is 2*N.</t>
        <t>Observation points can estimate upstream losses by watching a single direction
of the traffic flow and counting the number of packets in each observed Q Block,
as described in <xref target="upstreamloss"/>.</t>
        <section anchor="q-block-length-selection">
          <name>Q Block Length Selection</name>
          <t>The length of the block must be known to the on-path network probes.  There are
two alternatives to selecting the Q Block length. The first one requires that
the length is known a priori and therefore set within the protocol
specifications that implements implement the marking mechanism. The second requires the
sender to select it.</t>
          <t>In this latter scenario, the sender is expected to choose N (Q Block
length) based on the expected amount of loss and reordering on the
path.  The choice of N strikes a compromise -- the observation could
become too unreliable in case of packet reordering and/or severe loss
if N is too small, while short flows may not yield a useful upstream
loss measurement if N is too large (see <xref target="upstreamloss"/>).</t>
          <t>The value of N should be at least 64 and be a power of 2. This requirement allows
an Observer observer to infer the Q Block length by observing one period of the square
signal. It also allows the Observer observer to identify flows that set the loss bits to
arbitrary values (see <xref target="ossification"/>).</t>
          <t>If the sender does not have sufficient information to make an informed decision
about Q Block length, the sender should use N=64, since this value has been
extensively tried in large-scale field tests and yielded good results.
Alternatively, the sender may also choose a random power-of-2 N for each flow,
increasing the chances of using a Q Block length that gives the best signal for
some flows.</t>
          <t>The sender must keep the value of N constant for a given flow.</t>
        </section>
        <section anchor="upstreamloss">
          <name>Upstream Loss</name>
          <t>Blocks of N (Q Block length) consecutive packets are sent with the same
value of the Q bit, followed by another block of N packets with an
inverted value of the Q bit.  Hence, knowing the value of N, an
on-path observer can estimate the amount of upstream loss after
observing at least N packets.  The upstream loss rate (<tt>uloss</tt>) is one
minus the average number of packets in a block of packets with the
same Q value (<tt>p</tt>) divided by N (<tt>uloss=1-avg(p)/N</tt>).</t>
          <t>The observer needs to be able to tolerate packet reordering that can
blur the edges of the square signal, as explained in <xref target="endmarkingblock"/>.</t>
          <figure>
            <name>Upstream loss</name> Loss</name>
            <artwork><![CDATA[
          =====================>
          **********     -----Obs---->     **********
          * Client *                       * Server *
          **********     <------------     **********

            (a) in client-server channel (uloss_up)

          **********     ------------>     **********
          * Client *                       * Server *
          **********     <----Obs-----     **********
                               <=====================

            (b) in server-client channel (uloss_down)
]]></artwork>
          </figure>
        </section>
        <section anchor="endmarkingblock">
          <name>Identifying Q Block Boundaries</name>
          <t>Packet reordering can produce spurious edges in the square signal. To address
this, the observer should look for packets with the current Q bit value up to X
packets past the first packet with a reverse Q bit value. The value of X, a
"Marking Block Threshold", should be less than <tt>N/2</tt>.</t>
          <t>The choice of X represents a trade-off between resiliency to reordering and
resiliency to loss. A very large Marking Block Threshold will be able to
reconstruct Q Blocks despite a significant amount of reordering, but it may
erroneously coalesce packets from multiple Q Blocks into fewer Q Blocks, Blocks if loss
exceeds 50% for some Q Blocks.</t>
          <section anchor="Qburst">
            <name>Improved Resilience to Burst Losses</name>
            <t>Burst losses can affect the accuracy of Q measurements accuracy. measurements. Generally, burst losses can be
absorbed and correctly measured if smaller than the established Q Block
length. If the entire Q Block length of packets get is lost in a burst, however, the
observer may be left completely unaware of the loss.</t>
            <t>To improve burst loss resilience, an observer may consider a received Q Block
larger than the selected Q Block length as an indication of a burst loss
event. The observer would then compute the loss as three times the Q Block length
minus the measured block length. By doing so, the observer can detect burst
losses of less than two blocks (e.g., less than 128 packets for a Q Block length
of 64 packets). A burst loss of two or more consecutive periods would still
remain unnoticed by the observer (or underestimated if a period longer than Q
Block length were formed).</t>
          </section>
        </section>
      </section>
      <section anchor="lossbit">
        <name>L Bit -- Loss Event Bit</name>
        <t>The Loss Event bit uses an Unreported Loss counter maintained by the protocol
that implements the marking mechanism. To use the Loss Event bit, the protocol
must allow the sender to identify lost packets. This is true of protocols such
as QUIC, partially true for TCP and SCTP Stream Control Transmission Protocol (SCTP) (losses of pure ACKs are not detected) detected),
and is not true of protocols such as UDP and IPv4/IPv6.</t>
        <t>The Unreported Loss counter is initialized to 0, and the L bit of every outgoing
packet indicates whether the Unreported Loss counter is positive (L=1 if the
counter is positive, and L=0 otherwise).</t>
        <t>The value of the Unreported Loss counter is decremented every time a packet
with L=1 is sent.</t>
        <t>The value of the Unreported Loss counter is incremented for every packet that
the protocol declares lost, using whatever loss detection machinery the protocol
employs. If the protocol is able to rescind the loss determination later, a
positive Unreported Loss counter may be decremented due to the rescission.
In general, it should not become negative due to the rescission, but it can happen
in few cases.</t>
        <t>This loss signaling is similar to loss signaling in <xref target="ConEx"/>, target="RFC7713"/>, except that the Loss
Event bit is reporting the exact number of lost packets, whereas Echo Loss bit the signal mechanism
in <xref target="ConEx"/> target="RFC7713"/> is reporting an approximate number of lost bytes.</t>
        <t>For protocols, such as TCP (<xref target="TCP"/>), <xref target="RFC9293"/>, that allow network devices to change data
segmentation, it is possible that only a part of the packet is lost. In these
cases, the sender must increment the Unreported Loss counter by the fraction of the
packet data lost (so the Unreported Loss counter may become negative when a packet
with L=1 is sent after a partial packet has been lost).</t>
        <t>Observation points can estimate the end-to-end loss, as determined by the
upstream endpoint, by counting packets in this direction with the L bit equal to
1, as described in <xref target="endtoendloss"/>.</t>
        <section anchor="endtoendloss">
          <name>End-To-End Loss</name>
          <t>The Loss Event bit allows an observer to estimate the end-to-end loss rate by
counting packets with L bit value values of 0 and 1 for a given flow. The end-to-end
loss ratio is the fraction of packets with L=1.</t>
          <t>The assumption here is that upstream loss affects packets with L=0 and L=1
equally. If some loss is caused by tail-drop in a network device, this may be a
simplification.  If the sender's congestion controller reduces the packet send
rate after loss, there may be a sufficient delay before sending packets with L=1
that they have a greater chance of arriving at the observer.</t>
          <section anchor="loss-profile">
            <name>Loss Profile Characterization</name>
            <t>The Loss Event bit allows an observer to characterize the loss profile, since the
distribution of observed packets with the L bit set to 1 roughly corresponds to the
distribution of packets lost between 1 RTT and 1 RTO retransmission timeout (RTO) before (see
<xref target="loss-correlation"/>).  Hence, observing random single instances of the L bit set
to 1 indicates random single packet loss, while observing blocks of packets
with the L bit set to 1 indicates loss affecting entire blocks of packets.</t>
          </section>
        </section>
        <section anchor="lq-bits-loss-measurement-using-l-and-q-bits">
          <name>L+Q Bits -- Loss Measurement Using L and Q Bits</name>
          <t>Combining L and Q bits allows a passive observer watching a single direction of
traffic to accurately measure:</t>
          <ul spacing="normal">
            <li>upstream loss: sender-to-observer
          <dl>
            <dt>upstream loss:</dt>
            <dd>sender-to-observer loss (see <xref target="upstreamloss"/>)</li>
            <li>downstream loss: observer-to-receiver target="upstreamloss"/>)</dd>
            <dt>downstream loss:</dt>
            <dd>observer-to-receiver loss (see <xref target="downstreamloss"/>)</li>
            <li>end-to-end loss: sender-to-receiver target="downstreamloss"/>)</dd>
            <dt>end-to-end loss:</dt>
            <dd>sender-to-receiver loss on the observed path (see
<xref target="endtoendloss"/>) with loss profile characterization (see <xref target="loss-profile"/>)</li>
          </ul> target="loss-profile"/>)</dd>
          </dl>
          <section anchor="loss-correlation">
            <name>Correlating End-to-End and Upstream Loss</name>
            <t>Upstream loss is calculated by observing packets that did not suffer the
upstream loss (<xref target="upstreamloss"/>). End-to-end loss, however, is calculated by
observing subsequent packets after the sender's protocol detected the loss.
Hence, end-to-end loss is generally observed with a delay of between 1 RTT (loss
declared due to multiple duplicate acknowledgements) acknowledgments) and 1 RTO (loss declared
due to a timeout) relative to the upstream loss.</t>
            <t>The flow RTT can sometimes be estimated by timing the protocol handshake
messages. This RTT estimate can be greatly improved by observing a dedicated
protocol mechanism for conveying RTT information, such as the Spin bit (see
<xref target="spinbit"/>) or Delay bit (see <xref target="delaybit"/>).</t>
            <t>Whenever the observer needs to perform a computation that uses both upstream and
end-to-end loss rate measurements, it should use consider the upstream loss rate leading the
end-to-end loss rate by approximately 1 RTT. If the observer is unable to
estimate RTT of the flow, it should accumulate loss measurements over time
periods of at least 4 times the typical RTT for the observed flows.</t>
            <t>If the calculated upstream loss rate exceeds the end-to-end loss rate calculated
in <xref target="endtoendloss"/>, then either the Q Period is too short for the amount of
packet reordering or there is observer loss, described in <xref target="observerloss"/>. If
this happens, the observer should adjust the calculated upstream loss rate to
match end-to-end loss rate, unless the following applies.</t>
            <t>In case of a protocol, such as TCP or SCTP, that does not track losses of pure
ACK packets, observing a direction of traffic dominated by pure ACK packets
could result in measured upstream loss that is higher than measured end-to-end
loss,
loss if said pure ACK packets are lost upstream. Hence, if the measurement is
applied to such protocols, and the observer can confirm that pure ACK packets
dominate the observed traffic direction, the observer should adjust the
calculated end-to-end loss rate to match upstream loss rate.</t>
          </section>
          <section anchor="downstreamloss">
            <name>Downstream Loss</name>
            <t>Because downstream loss affects only those packets that did not suffer upstream
loss, the end-to-end loss rate (<tt>eloss</tt>) relates to the upstream loss rate
(<tt>uloss</tt>) and downstream loss rate (<tt>dloss</tt>) as <tt>(1-uloss)(1-dloss)=1-eloss</tt>.
Hence, <tt>dloss=(eloss-uloss)/(1-uloss)</tt>.</t>
          </section>
          <section anchor="observerloss">
            <name>Observer Loss</name>
            <t>A typical deployment of a passive observation system includes a network tap
device that mirrors network packets of interest to a device that performs
analysis and measurement on the mirrored packets. The observer loss is the loss
that occurs on the mirror path.</t>
            <t>Observer loss affects the upstream loss rate measurement, measurement since it causes the
observer to account for fewer packets in a block of identical Q bit values (see
<xref target="upstreamloss"/>). The end-to-end loss rate measurement, however, is unaffected
by the observer loss, loss since it is a measurement of the fraction of packets with
the L bit value of 1, and the observer loss would affect all packets equally
(see <xref target="endtoendloss"/>).</t>
            <t>The need to adjust the upstream loss rate down to match the end-to-end loss rate as
described in <xref target="loss-correlation"/> is an indication of the observer loss, whose
magnitude is between the amount of such adjustment and the entirety of the
upstream loss measured in <xref target="upstreamloss"/>. Alternatively, a high apparent
upstream loss rate could be an indication of significant packet reordering,
possibly due to packets belonging to a single flow being multiplexed over
several upstream paths with different latency characteristics.</t>
          </section>
        </section>
      </section>
      <section anchor="refsquarebit">
        <name>R Bit -- Reflection Square Bit</name>
        <t>R bit requires a deployment alongside Q bit. Unlike the square signal for which
packets are transmitted in blocks of fixed size, the number of packets in
Reflection square signal blocks (also an Alternate-Marking signal) varies
according to these rules:</t>
        <ul spacing="normal">
          <li>when the transmission of a new block starts, its size is set equal
to the size of the last Q Block whose reception has been completed;</li>
          <li>if, before transmission of the block is terminated, completed; and</li>
          <li>if the reception of at least one further Q Block is completed, completed before transmission of the block is terminated, the size of the block
is updated to be the average size of the further received Q Blocks.</li>
        </ul>
        <t>The Reflection square value is initialized to 0 and is applied to the R bit of
every outgoing packet.  The Reflection square value is toggled for the first
time when the completion of a Q Block is detected in the incoming square signal
(produced by the other endpoint using the Q bit). The number of packets
detected within this first Q Block (<tt>p</tt>), is used to generate a reflection
square signal that toggles every <tt>M=p</tt> packets (at first). This new signal
produces blocks of M packets (marked using the R bit) and each of them is
called "Reflection Block" (R (Reflection Block).</t>
        <t>The M value is then updated every time a completed Q Block in the
incoming square signal is received, following this formula:
<tt>M=round(avg(p))</tt>.</t>
        <t>The parameter <tt>avg(p)</tt>, the average number of packets in a marking
period, is computed based on all the Q Blocks received since the
beginning of the current R Reflection Block.</t>
        <t>The transmission of an R a Reflection Block is considered complete (and the signal toggled)
when the number of packets transmitted in that block is at least the latest
computed M value.</t>
        <t>To ensure a proper computation of the M value, endpoints implementing the R bit
must identify the boundaries of incoming Q Blocks. The same approach described
in <xref target="endmarkingblock"/> should be used.</t>
        <t>Looking
        <t>By looking at the R bit, unidirectional observation points have an indication of
loss experienced by the entire unobserved channel plus the loss on the path
from the sender to them.</t>
        <t>Since the Q Block is sent in one direction, and the corresponding reflected R
Block is sent in the opposite direction, the reflected R signal is transmitted
with the packet rate of the slowest direction. Namely, if the observed direction
is the slowest, there can be multiple Q Blocks transmitted in the unobserved
direction before a complete R Reflection Block is transmitted in the observed direction. If
the unobserved direction is the slowest, the observed direction can be sending R
Blocks of the same size repeatedly before it can update the signal to account
for a newly-completed newly completed Q Block.</t>
        <section anchor="enhancement-of-r-block-length-computation">
          <name>Enhancement of R Reflection Block Length Computation</name>
          <t>The use of the rounding function used in the M computation introduces errors
that can be minimized by storing the rounding applied each time M is computed, computed
and using it during the computation of the M value in the following R Reflection Block.</t>
          <t>This can be achieved by introducing the new <tt>r_avg</tt> parameter in the computation of
M.  The new formula is <tt>Mr=avg(p)+r_avg; M=round(Mr); r_avg=Mr-M</tt> where the
initial value of <tt>r_avg</tt> is equal to 0.</t>
        </section>
        <section anchor="improved-resilience-to-packet-reordering">
          <name>Improved Resilience to Packet Reordering</name>
          <t>When a protocol implementing the marking mechanism is able to detect when
packets are received out of order, it can improve resilience to packet
reordering beyond what is possible by using methods described in
<xref target="endmarkingblock"/>.</t>
          <t>This can be achieved by updating the size of the current R Reflection Block while it is
being transmitted.  The reflection block Reflection Block size is then updated every time an
incoming reordered packet of the previous Q Block is detected.  This can be
done if and only if the transmission of the current reflection block Reflection Block is in
progress and no packets of the following Q Block have been received.</t>
          <section anchor="Rburst">
            <name>Improved Resilience to Burst Losses</name>
            <t>Burst losses can affect the accuracy of R measurements accuracy similarly similar to how they affect
accuracy of Q
measurements accuracy. measurements. Therefore, recommendations in section <xref target="Qburst"/> apply
equally to improving burst loss resilience for R measurements.</t>
          </section>
        </section>
        <section anchor="rq-bits-loss-measurement-using-r-and-q-bits">
          <name>R+Q Bits -- Loss Measurement Using R and Q Bits</name>
          <t>Since both sQuare and Reflection square bits are toggled at most every N packets
(except for the first transition of the R bit as explained before), an on-path
observer can count the number of packets of each marking block and, knowing the
value of N, can estimate the amount of loss experienced by the connection.  An
observer can calculate different measurements depending on whether it is able to
observe a single direction of the traffic or both directions.</t>
          <t>Single
        <dl newline="true" spacing="normal">
          <dt>Single directional observer:</t>
          <ul observer:</dt>
          <dd><dl newline="false" spacing="normal">
            <li>upstream
            <dt>upstream loss in the observed direction: the direction:</dt>
            <dd>the loss between the sender and the
observation point (see <xref target="upstreamloss"/>)</li>
            <li>"three-quarters" target="upstreamloss"/>)</dd>
            <dt>"three-quarters" connection loss: the loss:</dt>
            <dd>the loss between the receiver and
the sender in the unobserved direction plus the loss between the
sender and the observation point in the observed direction</li>
            <li>end-to-end direction</dd>
            <dt>end-to-end loss in the unobserved direction: the direction:</dt>
            <dd>the loss between the
receiver and the sender in the opposite direction</li>
          </ul>
          <t>Two direction</dd>
          </dl></dd>
          <dt>Two directions observer (same metrics seen previously applied to both
direction, plus):</t>
          <ul spacing="normal">
            <li>client-observer plus):</dt>
          <dd><dl>
            <dt>client-observer half round-trip loss: the loss:</dt>
            <dd>the loss between the client
and the observation point in both directions</li>
            <li>observer-server directions</dd>
            <dt>observer-server half round-trip loss: the loss:</dt>
            <dd>the loss between the
observation point and the server in both directions</li>
            <li>downstream loss: the directions</dd>
            <dt>downstream loss:</dt>
            <dd>the loss between the observation point and the
receiver (applicable to both directions)</li>
          </ul> directions)</dd>
          </dl></dd></dl>
          <section anchor="tqloss">
            <name>Three-Quarters Connection Loss</name>
            <t>Except for the very first block in which there is nothing to reflect
(a complete Q Block has not been yet received), packets are
continuously R-bit marked into alternate blocks of size lower or equal
than N.  Knowing  By knowing the value of N, an on-path observer can estimate the
amount of loss that has occurred in the whole opposite channel plus the loss
from the sender up to it in the observation channel. As for the
previous metric, the <tt>three-quarters</tt> connection loss rate (<tt>tqloss</tt>) is
one minus the average number of packets in a block of packets with the
same R value (<tt>t</tt>) divided by <tt>N</tt> (<tt>tqloss=1-avg(t)/N</tt>).</t>
            <figure>
              <name>Three-quarters connection loss</name>
              <name>Three-Quarters Connection Loss</name>
              <artwork><![CDATA[
        =======================>
        = **********     -----Obs---->     **********
        = * Client *                       * Server *
        = **********     <------------     **********
        <============================================

            (a) in client-server channel (tqloss_up)

          ============================================>
          **********     ------------>     ********** =
          * Client *                       * Server * =
          **********     <----Obs-----     ********** =
                               <=======================

            (b) in server-client channel (tqloss_down)
]]></artwork>
            </figure>
            <t>The following metrics derive from this last metric and the upstream
loss produced by the Q bit.</t>
          </section>
          <section anchor="end-to-end-loss-in-the-opposite-direction">
            <name>End-To-End Loss in the Opposite Direction</name>
            <t>End-to-end loss in the unobserved direction (<tt>eloss_unobserved</tt>) relates to the
"three-quarters" connection loss (<tt>tqloss</tt>) and upstream loss in the observed
direction (<tt>uloss</tt>) as <tt>(1-eloss_unobserved)(1-uloss)=1-tqloss</tt>.  Hence,
<tt>eloss_unobserved=(tqloss-uloss)/(1-uloss)</tt>.</t>
            <figure>
              <name>End-To-End loss Loss in the opposite direction</name> Opposite Direction</name>
              <artwork><![CDATA[
          **********     -----Obs---->     **********
          * Client *                       * Server *
          **********     <------------     **********
          <==========================================

            (a) in client-server channel (eloss_down)

          ==========================================>
          **********     ------------>     **********
          * Client *                       * Server *
          **********     <----Obs-----     **********

            (b) in server-client channel (eloss_up)
]]></artwork>
            </figure>
          </section>
          <section anchor="half-round-trip-loss">
            <name>Half Round-Trip Loss</name>
            <t>If the observer is able to observe both directions of traffic, it is able to
calculate two "half round-trip" loss measurements -- loss from the observer to
the receiver (in a given direction) and then back to the observer in the
opposite direction.  For both directions, "half round-trip" loss (<tt>hrtloss</tt>)
relates to "three-quarters" connection loss (<tt>tqloss_opposite</tt>) measured in the
opposite direction and the upstream loss (<tt>uloss</tt>) measured in the given
direction as <tt>(1-uloss)(1-hrtloss)=1-tqloss_opposite</tt>.  Hence,
<tt>hrtloss=(tqloss_opposite-uloss)/(1-uloss)</tt>.</t>
            <figure>
              <name>Half Round-trip loss (both direction)</name> Round-Trip Loss (Both Directions)</name>
              <artwork><![CDATA[
        =======================>
        = **********     ------|----->     **********
        = * Client *          Obs          * Server *
        = **********     <-----|------     **********
        <=======================

      (a) client-observer half round-trip loss (hrtloss_co)

                               =======================>
          **********     ------|----->     ********** =
          * Client *          Obs          * Server * =
          **********     <-----|------     ********** =
                               <=======================

      (b) observer-server half round-trip loss (hrtloss_os)
]]></artwork>
            </figure>
          </section>
          <section anchor="downstream-loss">
            <name>Downstream Loss</name>
            <t>If the observer is able to observe both directions of traffic, it is able to
calculate two downstream loss measurements using either end-to-end loss and
upstream loss, similar to the calculation in <xref target="downstreamloss"/> target="downstreamloss"/>, or using "half
round-trip" loss and upstream loss in the opposite direction.</t>
            <t>For the latter, <tt>dloss=(hrtloss-uloss_opposite)/(1-uloss_opposite)</tt>.</t>
            <figure>
              <name>Downstream loss</name> Loss</name>
              <artwork><![CDATA[
                               =====================>
          **********     ------|----->     **********
          * Client *          Obs          * Server *
          **********     <-----|------     **********

             (a) in client-server channel (dloss_up)

          **********     ------|----->     **********
          * Client *          Obs          * Server *
          **********     <-----|------     **********
          <=====================

             (b) in server-client channel (dloss_down)
]]></artwork>
            </figure>
          </section>
        </section>
      </section>
      <section anchor="e-bit-ecn-echo-event-bit">
        <name>E Bit -- ECN-Echo Event Bit</name>
        <t>While the primary focus of this document is on exposing packet loss and
delay, modern networks can report congestion before they are forced to
drop packets, as described in <xref target="ECN"/>. target="RFC3168"/>.  When transport protocols keep
ECN-Echo feedback under encryption, this signal cannot be observed by
the network operators.  When tasked with diagnosing network
performance problems, knowledge of a congestion downstream of an
observation point can be instrumental.</t>
        <t>If downstream congestion information is desired, this information can be
signaled with an additional bit.</t>
        <ul spacing="normal">
          <li>E: The
        <dl>
          <dt>E:</dt>
          <dd>The "ECN-Echo Event" bit is set to 0 or 1 according to the Unreported ECN
Echo ECN-Echo
counter, as explained below in <xref target="ecnbit"/>.</li>
        </ul> target="ecnbit"/>.</dd>
        </dl>
        <section anchor="ecnbit">
          <name>Setting the ECN-Echo Event Bit on Outgoing Packets</name>
          <t>The Unreported ECN-Echo counter operates identically to Unreported Loss counter
(<xref target="lossbit"/>), except it counts packets delivered by the network with CE Congestion Experienced (CE)
markings, according to the ECN-Echo feedback from the receiver.</t>
          <t>This ECN-Echo signaling is similar to ECN signaling in <xref target="ConEx"/>. target="RFC7713"/>. The ECN-Echo
mechanism in QUIC provides the number of packets received with CE marks. For
protocols like TCP, the method described in <xref target="ConEx-TCP"/> target="RFC7786"/> can be employed. As
stated in <xref target="ConEx-TCP"/>, target="RFC7786"/>, such feedback can be further improved using a method
described in <xref target="ACCURATE-ECN"/>.</t> target="I-D.ietf-tcpm-accurate-ecn"/>.</t>
        </section>
        <section anchor="ech-usage">
          <name>Using E Bit for Passive ECN-Reported Congestion Measurement</name>
          <t>A network observer can count packets with the CE codepoint and determine the
upstream CE-marking rate directly.</t>
          <t>Observation points can also estimate ECN-reported end-to-end congestion by
counting packets in this direction with an E bit equal to 1.</t>
          <t>The upstream CE-marking rate and end-to-end ECN-reported congestion can provide
information about the downstream CE-marking rate. Presence The presence of E bits along with L
bits, however, can somewhat confound precise estimates of upstream and
downstream CE-markings in case CE markings if the flow contains packets that are not
ECN-capable.</t>
ECN capable.</t>
        </section>
        <section anchor="multiple-e-bits">
          <name>Multiple E Bits</name>
          <t>Some protocols, such as QUIC, support separate ECN-Echo counters. For example,
Section 13.4.1 of
<xref target="QUIC-TRANSPORT"/> target="RFC9000" sectionFormat="of" section="13.4.1"/> describes separate counters for ECT(0),
ECT(1), and ECN-CE. To better support such protocols, multiple E bits can be
used, one per a corresponding ECN-Echo counter.</t>
        </section>
      </section>
    </section>
    <section anchor="summary-of-delay-and-loss-marking-methods">
      <name>Summary of Delay and Loss Marking Methods</name>
      <t>This section summarizes the marking methods described in this document, which
proposes a toolkit of techniques that can be used separately, partly partly, or all
together depending on the need.</t>
      <t>For the Delay delay measurement, it is possible to use the Spin bit and/or the delay Delay
bit. A unidirectional or bidirectional observer can be used.</t>
      <figure
        <table anchor="fig_summary_D">
          <name>Delay Comparison</name>
        <artwork><![CDATA[
 +---------------+----+------------------------+--------------------+
 | Method        |# of|        Available       |             | # of |
 |               |bits|
	  <thead>
	    <tr>
		<th rowspan="2" colspan="1">Method</th>
		<th rowspan="2" colspan="1" align="center"># of bits</th>
		<th rowspan="1" colspan="2" align="center">Available Delay Metrics     | Impairments | meas.|
 |               |    +------------+-----------+ Resiliency  |      |
 |               |    |   UniDir   |   BiDir   |             |      |
 |               |    |  Observer  |  Observer |             |      |
 +---------------+----+------------+-----------+-------------+------+
 |S: Metrics</th>
		<th rowspan="2" colspan="1" align="center">Impairments Resiliency</th>
		<th rowspan="2" colspan="1" align="center"># of meas.</th>
	    </tr>
            <tr>
                <th align="center">UniDir Observer</th>
                <th align="center">BiDir Observer</th>
	    </tr>
	  </thead>
	  <tbody>
	    <tr>
		<td>S: Spin Bit    | 1  | RTT        | x2        | low         | very |
 |               |    |            | Bit</td>
		<td align="center">1</td>
		<td align="center">RTT</td>
		<td align="center">x2, Half RTT  |             | high |
 +---------------+----+------------+-----------+-------------+------+
 |D: RTT</td>
		<td align="center">low</td>
		<td align="center">very high</td>
	    </tr>
	    <tr>
		<td>D: Delay Bit   | 1  | RTT        | x2        | high        |medium|
 |               |    |            | Bit</td>
		<td align="center">1</td>
		<td align="center">RTT</td>
		<td align="center">x2, Half RTT  |             |      |
 +---------------+----+------------+-----------+-------------+------+
 |SD: RTT</td>
		<td align="center">high</td>
		<td align="center">medium</td>
	    </tr>
	    <tr>
		<td>SD: Spin Bit & | 2  | RTT        | x2        | high        | very |
 | &amp; Delay Bit *|    |            | *</td>
		<td align="center">2</td>
		<td align="center">RTT</td>
		<td align="center">x2, Half RTT  |             | high |
 +---------------+----+------------+-----------+-------------+------+

 x2 Same RTT</td>
		<td align="center">high</td>
		<td align="center">very high</td>
	    </tr>
	  </tbody>
        </table>
      <dl indent="6">
         <dt>x2</dt>
         <dd>Same metric for both directions
 *  Both directions</dd>
         <dt>*</dt>
         <dd>Both bits work independently; an observer could use less accurate Spin bit measurements when Delay bit ones are unavailable
]]></artwork>
      </figure> unavailable.</dd>
      </dl>
      <t>For the Loss measurement, each row in the table of <xref target="fig_summary_L"/>
represents a loss marking loss-marking method. For each method method, the table specifies
the number of bits required in the header, the available metrics using
a unidirectional or bidirectional observer, applicable protocols,
measurement fidelity fidelity, and delay.</t>
      <figure
      <table anchor="fig_summary_L">
        <name>Loss Comparison</name>
        <artwork><![CDATA[
 +-------------+-+-----------------------+-+------------------------+
 | Method      |B|        Available      |P|  Measurement Aspects   |
 |             |i|
	<thead>
	  <tr>
                <th rowspan="2" colspan="1">Method</th>
		<th rowspan="2" colspan="1" align="center">Bits</th>
		<th rowspan="1" colspan="2" align="center">Available Loss Metrics     |r+------------+-----------+
 |             |t|   UniDir  |   BiDir   |t|  Fidelity  |   Delay   |
 |             |s|  Observer |  Observer |o|            |           |
 +-------------+-+-----------+-----------+-+------------+-----------+
 |T: Round Trip|$| RT        | x2        | | Rate by    | ~6 RTT    |
 | Metrics</th>
		<th rowspan="2" colspan="1" align="center">Prto</th>
		<th rowspan="1" colspan="2" align="center">Measurement Aspects</th>
	  </tr>
          <tr>
                <th align="center">UniDir Observer</th>
                <th align="center">BiDir Observer</th>
                <th align="center">Fidelity</th>
                <th align="center">Delay</th>
          </tr>
	</thead>
	<tbody>
	  <tr>
		<td>T: Round-Trip Loss Bit  |1|           | Bit</td>
		<td align="center">$1</td>
		<td align="center">RT</td>
		<td align="center">x2, Half RT   |*| RT</td>
		<td align="center">*</td>
		<td>Rate by sampling   +-----------+
 |             | |           |           | | 1/3 to 1/(3*ppa) of    |
 |             | |           |           | | pkts over 2 RTT        |
 +-------------+-+-----------+-----------+-+------------+-----------+
 |Q: RTT</td>
		<td>~6 RTT</td>
	  </tr>
 	  <tr>
		<td>Q: sQuare Bit|1| Upstream  | x2        |*| Rate Bit</td>
		<td align="center">1</td>
		<td align="center">Upstream</td>
		<td align="center">x2</td>
		<td align="center">*</td>
		<td>Rate over  | N pkts    |
 |             | |           |           | | N (e.g., 64)</td>
		<td>N pkts     | (e.g. 64) |
 |             | |           |           | | (e.g. 64)  |           |
 +-------------+-+-----------+-----------+-+------------+-----------+
 |L: Loss Event|1| E2E       | x2        |#| (e.g., 64)</td>
	  </tr>
	  <tr>
		<td>L: Loss Event Bit</td>
		<td align="center">1</td>
		<td align="center">E2E</td>
		<td align="center">x2</td>
		<td align="center">#</td>
		<td>Loss shape | Min: RTT  |
 |   Bit       | |           |           | | (and rate) | rate)</td>
		<td>Min: RTT, Max: RTO  |
 +-------------+-+-----------+-----------+-+------------+-----------+
 |QL: RTO</td>
	  </tr>
	  <tr>
		<td rowspan="3" colspan="1">QL: sQuare + |2| Upstream  | x2        | | -> see Q   | Up: see Q |
 | Loss Ev. | | Downstream| x2        |#| -> see Q|L | Others:   |
 |    Bits     | | E2E       | x2        | | -> see L   |     see L |
 +-------------+-+-----------+-----------+-+------------+-----------+
 |QR: Bits</td>
		<td rowspan="3" colspan="1" align="center">2</td>
		<td rowspan="1" colspan="1" align="center">Upstream</td>
		<td rowspan="1" colspan="1" align="center">x2</td>
		<td rowspan="1" colspan="1" align="center">#</td>
		<td rowspan="1" colspan="1">see Q</td>
		<td rowspan="1" colspan="1">see Q</td>
	  </tr>
	  <tr>
		<td rowspan="1" colspan="1" align="center">Downstream</td>
		<td rowspan="1" colspan="1" align="center">x2</td>
		<td rowspan="1" colspan="1" align="center">#</td>
		<td rowspan="1" colspan="1">see Q|L</td>
		<td rowspan="1" colspan="1">see L</td>
          </tr>
	  <tr>
		<td rowspan="1" colspan="1" align="center">E2E</td>
		<td rowspan="1" colspan="1" align="center">x2</td>
		<td rowspan="1" colspan="1" align="center">#</td>
		<td rowspan="1" colspan="1">see L</td>
		<td rowspan="1" colspan="1">see L</td>
          </tr>
          <tr>
                <td rowspan="3" colspan="1">QR: sQuare + |2| Upstream  | x2        | | Rate over  | Up: see Q |
 | Ref. Sq. | | 3/4 RT    | x2        | | Bits</td>
                <td rowspan="3" colspan="1" align="center">2</td>
                <td rowspan="1" colspan="1" align="center">Upstream</td>
                <td rowspan="1" colspan="1" align="center">x2</td>
                <td rowspan="1" colspan="1" align="center">*</td>
                <td rowspan="3" colspan="1">Rate over N*ppa pkts | Others:   |
 |    Bits     | | !E2E      | E2E       |*| (see Q bit |  N*ppa pk |
 |             | |           | Downstream| | for N)   | N)</td>
                <td rowspan="1" colspan="1">see Q</td>
          </tr>
          <tr>
                <td rowspan="1" colspan="1" align="center">3/4 RT</td>
                <td rowspan="1" colspan="1" align="center">x2</td>
                <td rowspan="1" colspan="1" align="center">*</td>
                <td rowspan="2" colspan="1">N*ppa pkts (see Q  |
 |             | |           | Half RT   | |            | bit for N) |
 +-------------+-+-----------+-----------+-+------------+-----------+

 *   All protocols
 #   Protocols N)</td>
          </tr>
          <tr>
                <td rowspan="1" colspan="1" align="center">!E2E</td>
                <td rowspan="1" colspan="1" align="center">E2E, Downstream, Half RT</td>
                <td rowspan="1" colspan="1" align="center">*</td>
          </tr>
	</tbody>
       </table>
       <dl indent="6">
         <dt>*</dt>
         <dd>All protocols</dd>
         <dt>#</dt>
         <dd>Protocols employing loss detection (with or without pure ACK loss detection)
 $   Require detection)</dd>
         <dt>$</dt>
         <dd>Require a working Spin bit
 !   Metric bit</dd>
         <dt>!</dt>
         <dd>Metric relative to the opposite channel
 x2  Same channel</dd>
         <dt>x2</dt>
         <dd>Same metric for both directions
 ppa Packets-Per-Ack
 Q|L See directions</dd>
         <dt>ppa</dt>
         <dd>Packets-Per-Ack</dd>
         <dt>Q|L</dt>
         <dd>See Q if Upstream loss is significant; L otherwise
]]></artwork>
      </figure> otherwise</dd>
         <dt>E2E</dt>
         <dd>End to end</dd>
       </dl>
      <section anchor="implementation-considerations">
        <name>Implementation Considerations</name>
        <t>By combining the information of the two tables above, it can be deduced that the
solutions with 3 bits, i.e. bits (i.e., QL or QR + S or D, D) or 4 bits, i.e. bits (i.e., QL or QR + SD, SD)
allow having more complete and resilient measurements.</t>
        <t>The methodologies described in the previous sections are transport agnostic and
can be applied in various situations. The choice of the the methods also depends
on the specific protocol, for example protocol. For example, QL is a good combination, but, in the case
of combination; however, if
a protocol which does not support support, or cannot set set, the L bit, QR is the only
viable solution.</t>
      </section>
    </section>
    <section anchor="applications">
      <name>Examples of Application</name>
      <t>This document describes several measurement methods, but it is not expected that
all methods will be implemented together. For example, only some of the methods
described in this document (i.e. (i.e., sQuare bit and Spin bit) are utilized in
<xref target="I-D.ietf-core-coap-pm"/>. Also, the binding of a delay signal to QUIC is
partially described in Section 17.4 of <xref target="QUIC-TRANSPORT"/>, target="RFC9000" sectionFormat="of" section="17.4"/>, which adds only the
Spin bit to the first byte of the short packet header, leaving two reserved bits
for future use (see Section 17.2.2 of <xref target="QUIC-TRANSPORT"/>).</t> target="RFC9000" sectionFormat="of" section="17.2.2"/>).</t>
      <t>All signals discussed in this document have been implemented in succesful successful
experiments for both QUIC and TCP. The application scenarios considered allow
the monitoring of the interconnections inside a data center (Intra-DC), between
data centers (Inter-DC), as well as end-to-end large scale large-scale data transfers.  For
the application of the methods described in this document, it is assumed that
the monitored flows follow stable paths and traverse the same measurement
points.</t>
      <t>The specific implementation details and the choice of the bits used for the
experiments with QUIC and TCP are out of scope for this document.  A
specification defining the specific protocol application is expected to discuss
the implementation details depending on which bits will be implemented in the
protocol, e.g. e.g., <xref target="I-D.ietf-core-coap-pm"/>. If bits used for specific
measurements can also be used for other purposes by a protocol, the
specification is expected to address ways for on-path observers to disambiguate
the signals or to discuss limitations on the conditions under which the
observers can expect a valid signal.</t>
    </section>
    <section anchor="ossification">
      <name>Protocol Ossification Considerations</name>
      <t>Accurate loss and delay information is not required for the operation of any
protocol, though its presence for a sufficient number of flows is important for
the operation of networks.</t>
      <t>The delay and loss bits are amenable to "greasing" described in <xref target="RFC8701"/>, target="RFC8701"/> if
the protocol designers are not ready to dedicate (and ossify) bits used for loss
reporting to this function. The greasing could be accomplished similarly to the
Latency
latency Spin bit greasing in Section 17.4 of <xref target="QUIC-TRANSPORT"/>. target="RFC9000" sectionFormat="of" section="17.4"/>. For example,
the protocol designers could decide that a fraction of flows should not encode
loss and delay information and, information, and instead, the bits would be set to arbitrary
values. Setting any of the bits described in this document to arbitrary values
would make the corresponding delay and loss information resemble noise rather
than the expected signal for the flow, and the observers would need to be ready
to ignore such flows.</t>
    </section>
    <section anchor="security-considerations">
      <name>Security Considerations</name>
      <t>The methods described in this document are transport agnostic and potentially
applicable to any transport-layer protocol, and especially valuable for encrypted
protocols. These methods can be applied to both limited domains and the Internet,
depending on the specific protocol application.</t>
      <t>Passive loss and delay observations have been a part of the network operations
for a long time, so exposing loss and delay information to the network does not
add new security concerns for protocols that are currently observable.</t>
      <t>In the absence of packet loss, Q and R bits signals do not provide any
information that cannot be observed by simply counting packets transiting a
network path. In the presence of packet loss, Q and R bits will disclose
the loss, but this is information about the environment and not the endpoint
state. The L bit signal discloses internal state of the protocol's loss
detection loss-detection
machinery, but this state can often be gleaned by timing packets and
observing the congestion controller response.</t>
      <t>The measurements described in this document do not imply that new packets injected
into the network causing can cause potential harm to the network itself and to data
traffic. The measurements could be harmed by an attacker altering the marking
of the packets or injecting artificial traffic. Authentication techniques may be
used where appropriate to guard against these traffic attacks.</t>
      <t>Hence, loss bits do not provide a viable new mechanism to attack data integrity
and secrecy.</t>
      <t>The measurement fields introduced in this document are intended to be included
into
in the packets. But However, it is worth mentioning that it may be possible to use this
information as a covert channel.</t>
      <t>The current
      <t>This document does not define a specific application, and the described
techniques can generally apply to different communication protocols operating in
different security environments. A specification defining a specific protocol
application is expected to address the respective security considerations and
must consider specifics of the protocol and its expected operating environment.
For example, security considerations for QUIC, discussed in Section 21 of
<xref target="QUIC-TRANSPORT"/> target="RFC9000" sectionFormat="of" section="21"/> and Section 9 of <xref target="QUIC-TLS"/>, target="RFC9001" sectionFormat="of" section="9"/>, consider a possibility of
active and passive attackers in the network as well as attacks on specific QUIC
mechanisms.</t>
      <section anchor="optimistic-ack-attack">
        <name>Optimistic ACK Attack</name>
        <t>A defense against an Optimistic optimistic ACK Attack, attack, described in Section 21.4 of
<xref target="QUIC-TRANSPORT"/>, target="RFC9000" sectionFormat="of" section="21.4"/>, involves a sender randomly skipping packet numbers to detect
a receiver acknowledging packet numbers that have never been received. The Q bit
signal may inform the attacker which packet numbers were skipped on purpose and
which had been actually lost (and are, therefore, safe for the attacker to
acknowledge). To use the Q bit for this purpose, the attacker must first receive
at least an entire Q Block of packets, which renders the attack ineffective
against a delay-sensitive congestion controller.</t>
        <t>A protocol that is more susceptible to an Optimistic optimistic ACK Attack attack with the loss
signal provided by the Q bit and that uses a loss-based congestion controller, controller should
shorten the current Q Block by the number of skipped packets numbers. For example,
skipping a single packet number will invert the square signal one outgoing
packet sooner.</t>
        <t>Similar considerations apply to the R bit, although a shortened R Reflection Block along
with a matching skip in packet numbers does not necessarily imply a lost
packet, since it could be due to a lost packet on the reverse path along with a
deliberately skipped packet by the sender.</t>
      </section>
      <section anchor="delay-bit-with-rtt-obfuscation">
        <name>Delay Bit with RTT Obfuscation</name>
        <t>Theoretically, delay measurements can be used to roughly evaluate the distance
of the client from the server (using the RTT) or from any intermediate observer
(using the client-observer half-RTT). As described in <xref target="RTT-PRIVACY"/>, connection
RTT measurements for geolocating endpoints are usually inferior to even the
most basic IP geolocation databases. It is the variability within RTT
measurements (the jitter) that is most informative, as it can provide insight
into the operating environment of the endpoints as well as the state of the
networks (queuing delays) used by the connection.</t>
        <t>Nevertheless, to further mask the actual RTT of the connection, the Delay bit
algorithm can be slightly modified by, for example, delaying the client-side
reflection of the delay sample by a fixed fixed, randomly chosen time value. This
would lead an intermediate observer to measure a delay greater than the real
one.</t>
        <t>This Additional Delay should be randomly selected by the client and kept
constant for a certain amount of time across multiple connections. This ensures
that the client-server jitter remains the same as if no Additional Delay had
been inserted. For example, a new Additional Delay value could be generated
whenever the client's IP address changes.</t>
        <t>Despite the Additional Delay, this Hidden Delay technique still allows an
accurate measurement of the RTT components (observer-server) and all the
intra-domain measurements used to distribute the delay in the network.
Furthermore, unlike the Delay bit, the Hidden Delay bit does not require the
use of the client reflection threshold (1ms (1 ms by default). Removing this
threshold may lead to increasing the number of valid measurements produced by
the algorithm.</t>
        <t>Note that the Hidden Delay bit does not affect an observer's ability to measure
accurate RTT using other means, such as timing packets exchanged during the
connection establishment.</t>
      </section>
    </section>
    <section anchor="privacy-considerations">
      <name>Privacy Considerations</name>
      <t>To minimize unintentional exposure of information, loss bits provide an explicit
loss signal -- a preferred way to share information per <xref target="RFC8558"/>.</t>
      <t>New protocols commonly have specific privacy goals, and loss reporting must
ensure that loss information does not compromise those privacy goals. For
example, <xref target="QUIC-TRANSPORT"/> target="RFC9000"/> allows changing Connection IDs in the middle of a
connection to reduce the likelihood of a passive observer linking old and new
sub-flows to the same device (see Section 5.1 of <xref target="QUIC-TRANSPORT"/>). target="RFC9000" sectionFormat="of" section="5.1"/>). A QUIC
implementation would need to reset all counters when it changes the destination
(IP address or UDP port) or the Connection ID used for outgoing packets. It
would also need to avoid incrementing the Unreported Loss counter for loss of
packets sent to a different destination or with a different Connection ID.</t>
      <t>It is also worth highlighting that, if these techniques are not widely deployed,
an endpoint that uses them may be fingerprinted based on their usage.
But,
However, since there is no release of user data, the techniques seem unlikely to
substantially increase the existing privacy risks.</t>
      <t>Furthermore, if there is experimental traffic with these bit bits set on the network,
a network operator could potentially prioritize this marked traffic by placing it
in a priority queue. This may result in the delivery of better service, which
could potentially mislead an experiment intended to benchmark the network.</t>
    </section>
    <section anchor="iana-considerations">
      <name>IANA Considerations</name>
      <t>This document makes has no request of IANA.</t>
    </section>
    <section anchor="contributors">
      <name>Contributors</name>
      <t>The following people provided valuable contributions to this document:</t>
      <ul spacing="normal">
        <li>Marcus Ihlar, Ericsson, marcus.ihlar@ericsson.com</li>
        <li>Jari Arkko, Ericsson, jari.arkko@ericsson.com</li>
        <li>Emile Stephan, Orange, emile.stephan@orange.com</li>
        <li>Dmitri Tikhonov, LiteSpeed Technologies, dtikhonov@litespeedtech.com</li>
      </ul>
    </section>
    <section anchor="acknowledgements">
      <name>Acknowledgements</name>
      <t>The authors would like to thank the QUIC WG for their contributions, Christian
Huitema for implementing Q and L bits in his picoquic stack, and Ike Kunze for
providing constructive reviews and helpful suggestions.</t> IANA actions.</t>
    </section>

  </middle>
  <back>

<displayreference target="RFC9293" to="TCP"/>
<displayreference target="RFC3168" to="ECN"/>
<displayreference target="RFC7799" to="IPPM-METHODS"/>
<displayreference target="RFC9000" to="QUIC-TRANSPORT"/>
<displayreference target="RFC9001" to="QUIC-TLS"/>
<displayreference target="RFC9065" to="TRANSPORT-ENCRYPT"/>
<displayreference target="RFC9312" to="QUIC-MANAGEABILITY"/>
<displayreference target="I-D.trammell-quic-spin" to="QUIC-SPIN"/>
<displayreference target="I-D.ietf-tsvwg-udp-options" to="UDP-OPTIONS"/>
<displayreference target="I-D.herbert-udp-space-hdr" to="UDP-SURPLUS"/>
<displayreference target="I-D.ietf-tcpm-accurate-ecn" to="ACCURATE-ECN"/>
<displayreference target="RFC9341" to="AltMark"/>
<displayreference target="RFC9343" to="IPv6AltMark"/>
<displayreference target="RFC7713" to="ConEx"/>
<displayreference target="RFC7786" to="ConEx-TCP"/>
<displayreference target="I-D.trammell-tsvwg-spin" to="TSVWG-SPIN"/>
<displayreference target="I-D.trammell-ippm-spin" to="IPPM-SPIN"/>
<displayreference target="I-D.ietf-core-coap-pm" to="CORE-COAP-PM"/>

    <references>
      <name>References</name>
      <references>
        <name>Normative References</name>
        <reference anchor="TCP">
          <front>
            <title>Transmission Control Protocol (TCP)</title>
            <author fullname="W. Eddy" initials="W." role="editor" surname="Eddy"/>
            <date month="August" year="2022"/>
            <abstract>
              <t>This document specifies the Transmission Control Protocol (TCP). TCP is an important transport-layer protocol in the Internet protocol stack, and it has continuously evolved over decades of use and growth of the Internet. Over this time, a number of changes have been made to TCP as it was specified in RFC 793, though these have only been documented in a piecemeal fashion. This document collects and brings those changes together with the protocol specification from RFC 793. This document obsoletes RFC 793, as well as RFCs 879, 2873, 6093, 6429, 6528, and 6691 that updated parts of RFC 793. It updates RFCs 1011 and 1122, and it should be considered as a replacement for the portions of those documents dealing with TCP requirements. It also updates RFC 5961 by adding a small clarification in reset handling while in the SYN-RECEIVED state. The TCP header control bits from RFC 793 have also been updated based on RFC 3168.</t>
            </abstract>
          </front>
          <seriesInfo name="STD" value="7"/>
          <seriesInfo name="RFC" value="9293"/>
          <seriesInfo name="DOI" value="10.17487/RFC9293"/>
        </reference>
        <reference anchor="ECN">
          <front>
            <title>The Addition of Explicit Congestion Notification (ECN) to IP</title>
            <author fullname="K. Ramakrishnan" initials="K." surname="Ramakrishnan"/>
            <author fullname="S. Floyd" initials="S." surname="Floyd"/>
            <author fullname="D. Black" initials="D." surname="Black"/>
            <date month="September" year="2001"/>
            <abstract>
              <t>This memo specifies the incorporation of ECN (Explicit Congestion Notification) to TCP and IP, including ECN's use of two bits in the IP header. [STANDARDS-TRACK]</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="3168"/>
          <seriesInfo name="DOI" value="10.17487/RFC3168"/>
        </reference>
        <reference anchor="IPPM-METHODS">
          <front>
            <title>Active and Passive Metrics and Methods (with Hybrid Types In-Between)</title>
            <author fullname="A. Morton" initials="A." surname="Morton"/>
            <date month="May" year="2016"/>
            <abstract>
              <t>This memo provides clear definitions for Active and Passive performance assessment. The construction of Metrics and Methods can be described as either "Active" or "Passive". Some methods may use a subset of both Active and Passive attributes, and we refer to these as "Hybrid Methods". This memo also describes multiple dimensions to help evaluate new methods as they emerge.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7799"/>
          <seriesInfo name="DOI" value="10.17487/RFC7799"/>
        </reference>
        <reference anchor="QUIC-TRANSPORT">
          <front>
            <title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>
            <author fullname="J. Iyengar" initials="J." role="editor" surname="Iyengar"/>
            <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"/>
            <date month="May" year="2021"/>
            <abstract>
              <t>This document defines the core of the QUIC transport protocol. QUIC provides applications with flow-controlled streams for structured communication, low-latency connection establishment, and network path migration. QUIC includes security measures that ensure confidentiality, integrity, and availability in a range of deployment circumstances. Accompanying documents describe the integration of TLS for key negotiation, loss detection, and an exemplary congestion control algorithm.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9000"/>
          <seriesInfo name="DOI" value="10.17487/RFC9000"/>
        </reference>
        <reference anchor="RFC8558">
          <front>
            <title>Transport Protocol Path Signals</title>
            <author fullname="T. Hardie" initials="T." role="editor" surname="Hardie"/>
            <date month="April" year="2019"/>
            <abstract>
              <t>This document discusses the nature of signals seen by on-path elements examining transport protocols, contrasting implicit and explicit signals. For example, TCP's state machine uses a series of well-known messages that are exchanged in the clear. Because these are visible to network elements on the path between the two nodes setting up the transport connection, they are often used as signals by those network elements. In transports that do not exchange these messages in the clear, on-path network elements lack those signals. Often, the removal of those signals is intended by those moving the messages to confidential channels. Where the endpoints desire that network elements along the path receive these signals, this document recommends explicit signals be used.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8558"/>
          <seriesInfo name="DOI" value="10.17487/RFC8558"/>
        </reference>

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9293.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3168.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7799.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8558.xml"/>

      </references>
      <references>
        <name>Informative References</name>

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9001.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9065.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9312.xml"/>
<reference anchor="QUIC-TLS"> anchor="I-D.trammell-quic-spin" target="https://datatracker.ietf.org/doc/html/draft-trammell-quic-spin-03">
<front>
            <title>Using TLS to Secure QUIC</title>
            <author fullname="M. Thomson" initials="M." role="editor" surname="Thomson"/>
            <author fullname="S. Turner" initials="S." role="editor" surname="Turner"/>
            <date month="May" year="2021"/>
            <abstract>
              <t>This document describes how Transport Layer Security (TLS) is used to secure QUIC.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9001"/>
          <seriesInfo name="DOI" value="10.17487/RFC9001"/>
        </reference>
        <reference anchor="TRANSPORT-ENCRYPT">
          <front>
            <title>Considerations around Transport Header Confidentiality, Network Operations, and the Evolution of Internet Transport Protocols</title>
            <author fullname="G. Fairhurst" initials="G." surname="Fairhurst"/>
            <author fullname="C. Perkins" initials="C." surname="Perkins"/>
            <date month="July" year="2021"/>
            <abstract>
              <t>To protect user data and privacy, Internet transport protocols have supported payload encryption and authentication for some time. Such encryption and authentication are now also starting to be applied to the transport protocol headers. This helps avoid transport protocol ossification by middleboxes, mitigate attacks against the transport protocol, and protect metadata about the communication. Current operational practice in some networks inspect transport header information within the network, but this is no longer possible when those transport headers are encrypted.</t>
              <t>This document discusses the possible impact when network traffic uses a protocol with an encrypted transport header. It suggests issues to consider when designing new transport protocols or features.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9065"/>
          <seriesInfo name="DOI" value="10.17487/RFC9065"/>
        </reference>
        <reference anchor="QUIC-MANAGEABILITY">
          <front>
            <title>Manageability of the QUIC Transport Protocol</title>
            <author fullname="M. Kühlewind" initials="M." surname="Kühlewind"/>
            <author fullname="B. Trammell" initials="B." surname="Trammell"/>
            <date month="September" year="2022"/>
            <abstract>
              <t>This document discusses manageability of the QUIC transport protocol and focuses on the implications of QUIC's design and wire image on network operations involving QUIC traffic. It is intended as a "user's manual" for the wire image to provide guidance for network operators and equipment vendors who rely on the use of transport-aware network functions.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9312"/>
          <seriesInfo name="DOI" value="10.17487/RFC9312"/>
        </reference>
        <reference anchor="QUIC-SPIN">
          <front>
            <title>Adding
<title>
Adding Explicit Passive Measurability of Two-Way Latency to the QUIC Transport Protocol</title> Protocol
</title>
<author fullname="Brian Trammell" initials="B." surname="Trammell"> surname="Trammell" role="editor">
<organization>ETH Zurich</organization>
</author>
<author fullname="Piet De Vaere" initials="P." surname="De Vaere">
<organization>ETH Zurich</organization>
</author>
<author fullname="Roni Even" initials="R." surname="Even">
<organization>Huawei</organization>
</author>
<author fullname="Giuseppe Fioccola" initials="G." surname="Fioccola">
<organization>Telecom Italia</organization>
</author>
<author fullname="Thomas Fossati" initials="T." surname="Fossati">
<organization>Nokia</organization>
</author>
<author fullname="Marcus Ihlar" initials="M." surname="Ihlar">
<organization>Ericsson</organization>
</author>
<author fullname="Al Morton" initials="A. C." initials="A." surname="Morton">
<organization>AT&amp;T Labs</organization>
</author>
<author fullname="Stephan Emile" initials="S." surname="Emile">
<organization>Orange</organization>
</author>
<date day="14" month="May" year="2018"/>
            <abstract>
              <t>   This document describes the addition of a "spin bit", intended for
   explicit measurability of end-to-end RTT, to the QUIC transport
   protocol.  It proposes a detailed mechanism for the spin bit, as well
   as an additional mechanism, called the valid edge counter, to
   increase the fidelity of the latency signal in less than ideal
   network conditions.  It describes how to use the latency spin signal
   to measure end-to-end latency, discusses corner cases and their
   workarounds in the measurement, describes experimental evaluation of
   the mechanism done to date, and examines the utility and privacy
   implications of the spin bit.

              </t>
            </abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-trammell-quic-spin-03"/>
</reference>
        <reference anchor="RTT-PRIVACY">
          <front>
            <title>Revisiting the Privacy Implications of Two-Way Internet Latency Data</title>
            <author fullname="Brian Trammell" initials="B." surname="Trammell">
              <organization/>
            </author>
            <author fullname="Mirja Kühlewind" initials="M." surname="Kühlewind">
              <organization/>
            </author>
            <date year="2018"/> year="2018" month="March"/>
          </front>
          <seriesInfo name="Passive and Active Measurement" value="pp. 73-84"/>
          <seriesInfo name="DOI" value="10.1007/978-3-319-76481-8_6"/>
          <seriesInfo name="ISBN" value="[&quot;9783319764801&quot;, &quot;9783319764818&quot;]"/>
          <refcontent>Springer value="9783319764801"/>
          <refcontent>Passive and Active Measurement, pp. 73-84, Springer International Publishing</refcontent>
        </reference>
<reference anchor="UDP-OPTIONS"> anchor="I-D.ietf-tsvwg-udp-options" target="https://datatracker.ietf.org/doc/html/draft-ietf-tsvwg-udp-options-23">
<front>
<title>Transport Options for UDP</title>
<author fullname="Dr. Joseph D. Touch" initials="J. D." initials="J." surname="Touch">
<organization>Independent Consultant</organization>
</author>
<date day="9" month="June" day="15" month="September" year="2023"/>
            <abstract>
              <t>   Transport protocols are extended through the use of transport header
   options. This document extends UDP by indicating the location,
   syntax, and semantics for UDP transport layer options.

              </t>
            </abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-ietf-tsvwg-udp-options-22"/>
        </reference>
        <reference anchor="UDP-SURPLUS">
          <front>
            <title>UDP Surplus Header</title>
            <author fullname="Tom Herbert" initials="T." surname="Herbert">
              <organization>Intel</organization>
            </author>
            <date day="8" month="July" year="2019"/>
            <abstract>
              <t>   This specification defines the UDP Surplus Header that is an
   extensible and generic format applied to the UDP surplus space. The
   UDP surplus space comprises the bytes between the end of the UDP
   datagram, as indicated by the UDP Length field, and the end of the IP
   packet, as indicated by IP packet or payload length. The UDP Surplus
   Header can be either a protocol trailer of the UDP datagram, or a
   protocol header which effectively serves as an extended UDP header.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-herbert-udp-space-hdr-01"/>
        </reference>
        <reference anchor="ACCURATE-ECN">
          <front>
            <title>More Accurate Explicit Congestion Notification (ECN) Feedback in TCP</title>
            <author fullname="Bob Briscoe" initials="B." surname="Briscoe">
              <organization>Independent</organization>
            </author>
            <author fullname="Mirja Kühlewind" initials="M." surname="Kühlewind">
              <organization>Ericsson</organization>
            </author>
            <author fullname="Richard Scheffenegger" initials="R." surname="Scheffenegger">
              <organization>NetApp</organization>
            </author>
            <date day="30" month="March" year="2023"/>
            <abstract>
              <t>   Explicit Congestion Notification (ECN) is a mechanism where network
   nodes can mark IP packets instead of dropping them to indicate
   incipient congestion to the endpoints.  Receivers with an ECN-capable
   transport protocol feed back this information to the sender.  ECN was
   originally specified for TCP in such a way that only one feedback
   signal can be transmitted per Round-Trip Time (RTT).  Recent new TCP
   mechanisms like Congestion Exposure (ConEx), Data Center TCP (DCTCP)
   or Low Latency, Low Loss, and Scalable Throughput (L4S) need more
   accurate ECN feedback information whenever more than one marking is
   received in one RTT.  This document updates the original ECN
   specification in RFC 3168 to specify a scheme that provides more than
   one feedback signal per RTT in the TCP header.  Given TCP header
   space is scarce, it allocates a reserved header bit previously
   assigned to the ECN-Nonce.  It also overloads the two existing ECN
   flags in the TCP header.  The resulting extra space is exploited to
   feed back the IP-ECN field received during the 3-way handshake as
   well.  Supplementary feedback information can optionally be provided
   in two new TCP option alternatives, which are never used on the TCP
   SYN.  The document also specifies the treatment of this updated TCP
   wire protocol by middleboxes.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-tcpm-accurate-ecn-24"/>
        </reference>
        <reference anchor="AltMark">
          <front>
            <title>Alternate-Marking Method</title>
            <author fullname="G. Fioccola" initials="G." role="editor" surname="Fioccola"/>
            <author fullname="M. Cociglio" initials="M." surname="Cociglio"/>
            <author fullname="G. Mirsky" initials="G." surname="Mirsky"/>
            <author fullname="T. Mizrahi" initials="T." surname="Mizrahi"/>
            <author fullname="T. Zhou" initials="T." surname="Zhou"/>
            <date month="December" year="2022"/>
            <abstract>
              <t>This document describes the Alternate-Marking technique to perform packet loss, delay, and jitter measurements on live traffic. This technology can be applied in various situations and for different protocols. According to the classification defined in RFC 7799, it could be considered Passive or Hybrid depending on the application. This document obsoletes RFC 8321.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9341"/>
          <seriesInfo name="DOI" value="10.17487/RFC9341"/>
        </reference>
        <reference anchor="IPv6AltMark">
          <front>
            <title>IPv6 Application of the Alternate-Marking Method</title>
            <author fullname="G. Fioccola" initials="G." surname="Fioccola"/>
            <author fullname="T. Zhou" initials="T." surname="Zhou"/>
            <author fullname="M. Cociglio" initials="M." surname="Cociglio"/>
            <author fullname="F. Qin" initials="F." surname="Qin"/>
            <author fullname="R. Pang" initials="R." surname="Pang"/>
            <date month="December" year="2022"/>
            <abstract>
              <t>This document describes how the Alternate-Marking Method can be used as a passive performance measurement tool in an IPv6 domain. It defines an Extension Header Option to encode Alternate-Marking information in both the Hop-by-Hop Options Header and Destination Options Header.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="9343"/>
          <seriesInfo name="DOI" value="10.17487/RFC9343"/> value="draft-ietf-tsvwg-udp-options-23"/>
</reference>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.herbert-udp-space-hdr.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tcpm-accurate-ecn.xml"/>

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9341.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9343.xml"/>

        <reference anchor="ANRW19-PM-QUIC">
          <front>
            <title>Performance measurements of QUIC communications</title>
            <author fullname="Fabio Bulgarella" initials="F." surname="Bulgarella">
              <organization>Politecnico di Torino</organization>
            </author>
            <author fullname="Mauro Cociglio" initials="M." surname="Cociglio">
              <organization>Telecom Italia</organization>
            </author>
            <author fullname="Giuseppe Fioccola" initials="G." surname="Fioccola">
              <organization>Huawei Technologies</organization>
            </author>
            <author fullname="Guido Marchetto" initials="G." surname="Marchetto">
              <organization>Politecnico di Torino</organization>
            </author>
            <author fullname="Riccardo Sisto" initials="R." surname="Sisto">
              <organization>Politecnico di Torino</organization>
            </author>
            <date month="July" year="2019"/>
          </front>
          <seriesInfo name="Proceedings of the Applied Networking Research" value="Workshop"/>
          <seriesInfo name="DOI" value="10.1145/3340301.3341127"/>
          <refcontent>ACM</refcontent>
        </reference>
        <reference anchor="ConEx">
          <front>
            <title>Congestion Exposure (ConEx) Concepts, Abstract Mechanism, and Requirements</title>
            <author fullname="M. Mathis" initials="M." surname="Mathis"/>
            <author fullname="B. Briscoe" initials="B." surname="Briscoe"/>
            <date month="December" year="2015"/>
            <abstract>
              <t>This document describes an abstract mechanism by which senders inform the network about the congestion recently encountered by packets in the same flow. Today, network elements at any layer may signal congestion to the receiver by dropping packets or by Explicit Congestion Notification (ECN) markings, and the receiver passes this information back to the sender in transport-layer feedback. The mechanism described here enables the sender to also relay this congestion information back into the network in-band at the IP layer, such that the total amount
          <refcontent>Proceedings of congestion from all elements on the path is revealed to all IP elements along the path, where it could, for example, be used to provide input to traffic management. This mechanism is called Congestion Exposure, or ConEx. The companion document, "Congestion Exposure (ConEx) Concepts and Use Cases" (RFC 6789), provides the entry point to the set of ConEx documentation.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7713"/>
          <seriesInfo name="DOI" value="10.17487/RFC7713"/>
        </reference>
        <reference anchor="ConEx-TCP">
          <front>
            <title>TCP Modifications Applied Networking Research Workshop (ANRW '19), Association for Congestion Exposure (ConEx)</title>
            <author fullname="M. Kuehlewind" initials="M." role="editor" surname="Kuehlewind"/>
            <author fullname="R. Scheffenegger" initials="R." surname="Scheffenegger"/>
            <date month="May" year="2016"/>
            <abstract>
              <t>Congestion Exposure (ConEx) is a mechanism by which senders inform the network about expected congestion based on congestion feedback from previous packets in the same flow. This document describes the necessary modifications to use ConEx with the Transmission Control Protocol (TCP).</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="7786"/>
          <seriesInfo name="DOI" value="10.17487/RFC7786"/> Computing Machinery</refcontent>
        </reference>

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7713.xml"/>
<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7786.xml"/>

<reference anchor="I-D.trammell-tsvwg-spin"> anchor="I-D.trammell-tsvwg-spin" target="https://datatracker.ietf.org/doc/html/draft-trammell-tsvwg-spin-00">
<front>
            <title>A
<title>
A Transport-Independent Explicit Signal for Hybrid RTT Measurement</title> Measurement
</title>
<author fullname="Brian Trammell" initials="B." surname="Trammell"> surname="Trammell" role="editor">
<organization>ETH Zurich</organization>
</author>
<date day="2" month="July" year="2018"/>
            <abstract>
              <t>   This document defines an explicit per-flow transport-layer signal for
   hybrid measurement of end-to-end RTT.  This signal consists of three
   bits: a spin bit, which oscillates once per end-to-end RTT, and a
   two-bit Valid Edge Counter (VEC), which compensates for loss and
   reordering of the spin bit to increase fidelity of the signal in less
   than ideal network conditions.  It describes the algorithm for
   generating the signal, approaches for observing it to passively
   measure end-to-end latency, and proposes methods for adding it to a
   variety of IETF transport protocols.

              </t>
            </abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-trammell-tsvwg-spin-00"/>
</reference>

<reference anchor="I-D.trammell-ippm-spin"> anchor="I-D.trammell-ippm-spin" target="https://datatracker.ietf.org/doc/html/draft-trammell-ippm-spin-00">
<front>
            <title>An
<title>
An Explicit Transport-Layer Signal for Hybrid RTT Measurement</title> Measurement
</title>
<author fullname="Brian Trammell" initials="B." surname="Trammell"> surname="Trammell" role="editor">
<organization>ETH Zurich</organization>
</author>
<date day="9" month="January" year="2019"/>
            <abstract>
              <t>   This document defines an explicit per-flow transport-layer signal for
   hybrid measurement of end-to-end RTT.  This signal consists of three
   bits: a spin bit, which oscillates once per end-to-end RTT, and a
   two-bit Valid Edge Counter (VEC), which compensates for loss and
   reordering of the spin bit to increase fidelity of the signal in less
   than ideal network conditions.  It describes the algorithm for
   generating the signal, approaches for observing it to passively
   measure end-to-end latency, and proposes methods for adding it to a
   variety of IETF transport protocols.

              </t>
            </abstract>
</front>
<seriesInfo name="Internet-Draft" value="draft-trammell-ippm-spin-00"/>
</reference>
        <reference anchor="I-D.ietf-core-coap-pm">
          <front>
            <title>Constrained Application Protocol (CoAP) Performance Measurement Option</title>
            <author fullname="Giuseppe Fioccola" initials="G." surname="Fioccola">
              <organization>Huawei</organization>
            </author>
            <author fullname="Tianran Zhou" initials="T." surname="Zhou">
              <organization>Huawei</organization>
            </author>
            <author fullname="Mauro Cociglio" initials="M." surname="Cociglio">
              <organization>Telecom Italia</organization>
            </author>
            <author fullname="Fabio Bulgarella" initials="F." surname="Bulgarella">
              <organization>Telecom Italia</organization>
            </author>
            <author fullname="Massimo Nilo" initials="M." surname="Nilo">
              <organization>Telecom Italia</organization>
            </author>
            <author fullname="Fabrizio Milan" initials="F." surname="Milan">
              <organization>Telecom Italia</organization>
            </author>
            <date day="19" month="April" year="2023"/>
            <abstract>
              <t>   This document specifies a method for the Performance Measurement of
   the Constrained Application Protocol (CoAP).  A new CoAP option is
   defined in order

<xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-core-coap-pm.xml"/>

<xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8701.xml"/>

      </references>
    </references>
     <section anchor="acknowledgments" numbered="false">
      <name>Acknowledgments</name>
      <t>The authors would like to enable network telemetry both end-to-end and hop-
   by-hop.  The endpoints cooperate by marking and, possibly, mirroring
   information on thank the round-trip connection.

              </t>
            </abstract>
          </front>
          <seriesInfo name="Internet-Draft" value="draft-ietf-core-coap-pm-00"/>
        </reference>
        <reference anchor="RFC8701">
          <front>
            <title>Applying Generate Random Extensions And Sustain Extensibility (GREASE) to TLS Extensibility</title>
            <author fullname="D. Benjamin" initials="D." surname="Benjamin"/>
            <date month="January" year="2020"/>
            <abstract>
              <t>This document describes GREASE (Generate Random Extensions And Sustain Extensibility), a mechanism to prevent extensibility failures QUIC WG for their contributions,
<contact fullname="Christian Huitema"/> for implementing Q and L bits in the TLS ecosystem. It reserves a set of TLS protocol values that may be advertised his picoquic stack, and <contact fullname="Ike Kunze"/> for
providing constructive reviews and helpful suggestions.</t>
    </section>
    <section anchor="contributors" numbered="false">
      <name>Contributors</name>
      <t>The following people provided valuable contributions to ensure peers correctly handle unknown values.</t>
            </abstract>
          </front>
          <seriesInfo name="RFC" value="8701"/>
          <seriesInfo name="DOI" value="10.17487/RFC8701"/>
        </reference>
      </references>
    </references> this document:</t>
        <contact fullname="Marcus Ihlar">
          <organization>Ericsson</organization>
          <address>
            <email>marcus.ihlar@ericsson.com</email>
          </address>
        </contact>
        <contact fullname="Jari Arkko">
          <organization>Ericsson</organization>
          <address>
            <email>jari.arkko@ericsson.com</email>
          </address>
        </contact>
        <contact fullname="Emile Stephan">
          <organization>Orange</organization>
          <address>
            <email>emile.stephan@orange.com</email>
          </address>
        </contact>
        <contact fullname="Dmitri Tikhonov">
          <organization>LiteSpeed Technologies</organization>
          <address>
            <email>dtikhonov@litespeedtech.com</email>
          </address>
        </contact>
    </section>
  </back>
  <!-- ##markdown-source:
H4sIAAAAAAAAA+19a3fbRpbg9/oVGHt3W4xJxrKdl3s8E0VWOtqWbVmWe2bO
nj0RSIIi2iTAAKBkju357XufVbcAUJLdmZ19jDpJSyRQj1u37vsxGo1ckzfL
7Gly9H69zKd5k/xS1s2oKUcvs+a6rN4lPy/L6+RFltabKltlRVMn59l0UeS/
bbLapZNJlV09TZ5ny3SbpMUsOSnrOpnkTe1m5bRIVzD0rErnzSjPmvkoX69X
o0ymGs1h6NHKDD16+J2bpQ288+H5wfnRJzeFPy7Lavs0yYt56Vy+rp4mTbWp
m0cPH/7w8JFLqyx9mpxXaVGvy6pxuOTLqtysnybHp6cv3LtsCx/N4K+iyaoi
a0bPcTWu3kxWeV3nZXG+XcN8x0fnPztXN7CFX9NlWcBHW9jfOn/qkqSaT7NZ
3WyX8mmSNOXU/DrL1s3iafIt/5UXM9iLfl3DqqpsXvu/t6voz6bKp/7habki
OJi/12n4Oi+WeRHWkL1vRsscTgvGnJRLeGtUfvXAuXTTLMoKFz6Cf/E1+OrF
ODmEtV0u85I+5KN5kW6qMv6irC4BoNkyg8mT4yZd5mkySs6PX9C3sN4sgwX9
BT49ywCCyVm5Kpf5MHn03RN6Ag4Wjuu8rPKCB5yWM5hp/+H+k+/l703R4JHi
4Fv6KFul+fJpssLVjKeymh/LTbMsy3fwwSrey8E4+TmrqjzbvDd7OVhm7+H4
qiz+kvbzChDkMktO0kltJ0z1lfFcXvmxpCe7c/4J5szL6bRcpmbOP+WbOluv
s/g7mvKXTXqd5XxZymV5mWd1BMEz+AB+T+s6A+B9Y2D3YlPk04WB3fcPf/jh
UQy7P2XVKi0i6F3KWsZzWcuPC1pCdy/H4+RkM0nrRXZl9nIMFy3+nPZx8C6F
8bv7kFnzJb/xY0rPdSf7eZz8tFlewkVdRqD7OZ3kZfur/0Dkm+N6xhO/nh8v
gcA144YXk9NaxnnTuVUv82V8o4CqrMrw8X/ofaK1jAtYy483bwRQ4pd0NV2k
5Sa3OFGnEwBG1vrypjuVyyvjhb6y806djd8A+bLQO8un07SalUn4guY6BZA0
2RTuRZnMcgsNmbWSF8c1vvjjGp8vcZfOFSVclSa/ypAinh+ewiw/H/7w6IfH
8OfR4Uv68/H+twhMZBmjF0fnv7x6/oY+/+67H36Az1+/PT4cnZ8dvHxz+urs
nAd4+PAh8CPgSmZ0fu7kjT6xjzPqa6Ojl4dn/3Kqr3/7jb7w4uDlwZ+ODn46
Pjk+/xf+9vH+I/32zekxrPF49HwMxALYw3I5+m2TT0f1Oi/gmbPz89Hp2fFf
Dg7h1eevjsf7D+Gfh999/cN3348ejx7v/zD67tsn3++Pvv8V+dPb56ejV6fn
x69evuFBiS039dX15WgzW4/KdQM8sZYn37w9Oz15K08usmqSVQ09VgNbykaL
WQUPHhwevj0Dbj0iYIYxp8Dq0+l0UwEPH8HZ4aPL5kVavZM9PtknkF992/oY
D+bg5dk/wdLhOBAIYWf7T775+vHjJw8fP9wfw//v7z/6Dp4+LIuj93Jg+4/1
g5Ee9nffff+tc6PRKAFcBShOAS3OF3mdgIiyQYabzLJ6WuWTrE7WVQk8vFwm
yMbXGfHyZJUBR53VyTQFxJ55WcndJisZUSlpFmkDAxTJJEvSNQ6QTuBiAZY3
Kr2MQIjKKr8EkKNg3Cwrkukyx9FQvqqz6iqrxsn5Iqszv7BstV6W2+SvIBgl
qZtn13D3q3d5cUmiGN62fAZzLbJkkaUzmKOcJ1k6XSRwju+yJgEsTtZZRchc
THHcIJQ5nLbKAOmAtcKylukELjSifN+6fiqbRQJgW5c5yorTsoRxAQOSyVbX
5HjSGt8bJmsQGPPJcjtMVnlV4cW+pIXKw3VSFvQ3CHXFbATi0hoGLYpsiohK
cHBNgDLQ7iSr19k0h6PaJlfpckNgvl4AGAnscH5NaWBM55IV02q7bsJRCJzq
YVLnCBBYwRaeorGWKOLinmck9VpY4S7XSHWvMlcWo3UKwCgEOWbZVT7Nalxy
P+rVGUAwXfpDNRjjgLUjjNcpwhI2Buf1V4Qwwo3xFOEGp4qgSq+AJgI7Axq4
xc8sLgwdTAgnOYvWPaT9AFDgsBrg8DqSvw0AsusFSCV8NLJAALYTmI75fq3y
2WyZOXcf5e2qnG3olJw7ZTRrQQ4PawFUmycHBEoRcDgpgHlFi5ilW7xg8H8K
R8cIRYd/WpVwmeEdgMgsaxAnisuh7Ix+xZGXJagRglYr4E/JtNogfuDdA+5R
NPAvfr3ILxfJ6/INvdTkKxy1yupyucHZ6MogBpajDL9fAEJeLtabBkasAfUA
As91CTSCX4Vesvbul0Atao8evK2yqnFZhvjAIgDf53m1AsWn3CACVhmiqNwf
uNiI6kOkK2sDj6Js8jliezmHI4ePyjWtxQOXr5VMDxKhgRJgHSAc7tguvaxc
9h4wmA6J95DX9DisDghP3WRrRBSC2VU0GZMQ4MwED4AxQAuUtlmOkOXld+Fw
ndcLWlCptCn5bZMWoLAy9TEIjJvsh/IihScnSEThRl/ldKTLLV2WIvHsG35f
w/pwpJzg4qbLLK3ojxZ1FsKQ7GXjyzHKE3AtgfQgkcBZYRFFeQ1c4hLX5YrN
CphmPQDC6CkDXt8J0kvCFL9xIhZw41ebZZOv4ZiFhF7nDYABlpv9oXby8NCA
KexQGEqSwRuwUhQT3sFkhP9M/etyUzE1c3I2Ojx8lFfhECo+SBAVgTTDqoDu
TjYwSN7gF0CTNmsUXdMVYsWsvC7kL0Un5/4pJ0ZAdDWbBYI7pIXsgirRb/8S
0QUhp/3Hy4CkE+SXAe2VpYBelcKHy7rET2E4EJg+fOjIY58+gRCPpBfWtQTs
hrdEamlhWPseO15C9h6OIkcEmCH5D6vfzdfh2iCxIapFxHjoDNOabPsuw6JM
AMx4MkAOgBIsCY6AwaBCNkDQGlioCgyuy5hR4ulsqAXM1k4Cm62TTc1kLWzP
ed4ALAqhDvQHNEEkOICJnzWTszOpzEPoCkoB7hi0GGBolZEriDcijUJULLqL
Ur49y+eg2uMiAvRXsAAg6cv8XzNLAsOzSzZlAdsFgosnab8BwER0E8BaZUBG
ANty5AXwDdLItNriTZnB6U7hNSfwYK7ai8ot6MPmqpqZTucOyWmC3JxVBYrX
L4TDM2dOPnwQkfrTJxh8nhcoGeF5AmHO0cA20yeB1yhtNasa8pKYff41b2Ca
WMyBI14iCQYUn8/zKSiP5TVeoaGDG4ePwFHShYOlGAn/06dhtDbkvghskiFq
oiz+NOjOOMF1lLpnJT4O7xTpJfyJdAseV9H7BX1M6PZmC5xoley9fPFmMETJ
T8B+eHrkkLDBr6dHCR2tUBzCtSatiP/JIyJSFaBtg8xmVw3HcAVct3YWx4WM
pkl3xfBPkJ287AuyE8plIDpZFEJQEHeyEyJJN5JHTFaiy4PoB1cR1gWImjEX
l3PNUZgAiWDK7I4kFJULg3BF28VhgB1ewQsIaBSdd1O1mB+itjYkrogAcaAL
DwjCkwwnQil23NW9GEHvbIFua1VoBE6IfOLulkJVLxEBUa/pWbq5ScnBdFpW
M5EzkDHSenKGJ1w/ROBgFUAMbkT1CgsK+iGpd9Ml8iwSvtLa/bKdVDmfMou8
MA88lIFgMJvRJSG838UtWKoAbFGzOewPXkHhUPb3Hvgdrn/mjfBEWYiDWQkH
phGdJMJcr5e8LZb5u8xiHojScBaiDBh1U7RBF2uDSp31zrxRzakFLaOurVKY
0Ciezq5XaWdylRM7lwMiQWnIGtmMWDuJdMR2AFHfE01cJnD7hUx+EWKpWjZj
gTAnfwYjLJ5hpMHDvNvd56f3k4Q9w5hTpzrzMc8QrgSJ4OFJIk/0LM+NEg0Q
jKyqWJlNSQp3gTuK9rZrSQKXwBv1XDubDksS1CY9lBwkSCdBoJqWq0leiD52
hCYFf7z4cJ2gMYKMELgTwlViRnpfLWaM3TFxULg9MOmMmbzQYtlZ2rFB5CIq
ZAVrLAiJWLVFZQp5KlomOoIRUL5sRqzHmyoAPD+XqJypNlRl7JiZMV4SV/u7
s58Pv//mm++BPJOG/Y4VPZgCSQ8cUaL3dehiSKKWzUCYEdmpyxWqUzOkzLFa
znATrCeFxOFpijIanXBAN6HHaiGiIdTsRPSG8NUZoSkxg3bpEI83TIi8v30O
6s6mWi83dUI2wGSvzjKQqo1dESCC4OXPxIL46dMA8QVVLAD6TK1SMB0yjORq
308DBDNdgioxw8sNWEZsHre6BOgU023yBtRYfJ9mTt4w50v2vxs/QSXww4fY
VgsTg3RfkvpDyBRxnjKrhX7IAdNMovqie8VjKZlO5KLB19flZjkj1BFqPl3A
kRYqHPrX9FRcvgKNDicVVYUW/+GDkBH6DJfKF1O3OBS/Ku7Wk3UCHeIWiBZ9
FxVvSA4nSDYekK0jci7giSzO5nO0NfOf/xgZnNk+jBbnT58cH278APl1+XvY
w8FMFXu0yqQ5XAa4rxu+y6fGzBi5lZGXETbgDiwlckz04XIib4oMwzTd/eRE
cOMn9DuzeFELYuRih8oEctYMS8QMpyXbYkK2RUGziISMk+SfQAhCAZeBrYPL
LfSyB31IlJmurch6qBi4vBaSzaaH5dY8wEjevsG8VOChy43YbnVtuBHYN7CN
2qC/P0WD/Hb7xByFEwIsyfvesT0z8SKgLEhuaStyZ+fnAA4GMT+LakVeM9dJ
nb+efN/Ky8slmhPxtPEA6XW9tE9YvjKoBzypnm5qoo6FSwMeAcMe4ah/SUGB
SY5mlyDOo98Lhtz7y9HhgAn4ag1cAMUeXL9X06sMBLysMgZSv0jEZYAw0Jsa
rVggQYnJlI6V9wePolkAN1Q4srZ5HQW2ziusO1KtBXxCcQUjZpsoqi0z2gwL
bDJNGzFdMCWLlUOwymqSAE6m2roiPFSgU1dlPlPupZt1KXDqy01O9l2aLa1y
1KDhJEsUnuqefZFZtcpL4Yvu/n0eD25akiQf7uOdh7E/tW8d7XoFwjjS1nTd
ATxOwwrrFMCa16tx8jOcWYryBKgecNto40TnWLrwxu3lZVnBfVmBim8YwOPx
9+NHhgO0SFyLstICix4F2qpdl3DlK+LJfERGl3Q1Gg/8ingUXAbu5jKrA9ua
L/PLRZPQ8+RxwRvAi+lwNIYa4Qf9bTGj7yYNHXkkcN061qoE1aVUXE+NDWdU
onEBd4O8DkMMaMVuXpUrUigqELlyvDzGpiY2SKTpyT08a5w6L2f3ZK2ZsYuZ
TZPdxm8LnTAkoAHGb4T+ZQ5RF43sPDc8A6pYNAe/d09tzDxKG4/qRSp8DnFN
F0KShRlKAN4V/tT8j8hA60B4I3EMcONxePa9fJyNk4do89wfMPuAC4lQiBaF
yLppLstg+687jjFSMVO1QTkzCYz4UPxVcCGvE7sUtFGwaFc8de4rfsxoC3DZ
Mrg3eDai9vszkb/ZIA34Ul0SN0uLROJI5JsajW+gYMzTiixaddbwAfSDRKTT
co1KaCPH5CgsgSCrIkqma5vJSv4YrV/O4z9s/YSxd1674hPQKrIPmvHymvFC
JMFw4MiSYC3exUL++53YwhzWU0d1FkVDOli70ijE9982KDldozug3pC5KQUR
crI1nqiG1D5kR1PWnOACOrW4rtOcLY7I0bPphpX6GZIzYUAeHgQu1s8BnsBw
nGdV4vVUlkUsTQAV/LgsawXPKJny52zNsawMAO1vFXtf6x5hLdaZYu+KkFO/
Vhc0J7Rc6ixBRRA8M0ID7YBMafUawFiC7sNQoefVM77I4Lu6yafkwJuWFU5I
VzUQButiN4y17uPBoDHAeYgHXhl1JPd/+ECAQ/ZLYvB9UReQN3+4779jXA2a
xCKt2V3krWRoGIKjmqIiyr4PgOkyX+WqrbTM9RGxg8OAU0ZbQj7dLJseGYIo
VResoM+y4i04LDy+BWOyGmBcAFF12hTc0AwAzVYiIiPsnpzLK3RWwI2qEmYJ
T/LgnifUalph06s8DlwJhrfCP01g9LQRAYa88QWJ6YwaEUxaUpp5GwanPVBM
RgMQwFVF9wCZrVji7JhDsSGTkEVeSlRHtgpXkuNXaKmftTy7QzqucPwyAKkg
XpgIdwo9d0qUo5eQqg3DhbLkOU3Yks1qefTmwIHiV5D2JVQmtoEp4Z8F+oRm
6ioi18t8niGlGouQGa0g92E590SeTlHXvocySxHIENwbxF6UeotY3CFiOryR
aKBcKQRjiKCevvPE1EzpbXUVfEjEExcNxHa1HhIRMTjhDBUz5M9uW610dgaF
BFFUJAo1akbJGu50Vj8NQkWw8QN2L3W8c3IYRo+IcBVfwfbGCPeWsm4/HgxN
8guPwMcMp7xIr4Cq8TCdw7LOPVh4MFnKZovsfQN62OXGmACE64n5BFA+oGXQ
Hpz7N/ihiMAkeTCSnwfwx6jn3/CAvPExSaJfRuHnH1oP+DcOGY39N62fj6Ca
EOZ97J/j780c7Qe+YB/yyl46SF6WnrulCPLLvMD4lrHrG/ah/Lv//wV4kr3J
gFiyrI4FaiLl5EFJm5RMBjqVFx45wkWwGBgo4+Abuh43A9b++387YPe7+/CA
nTJgZfIewHqgGrJUGz5zGzB18v+bgXkLUuglnkVI+gWw+n8B8ez6dyPeXhbh
3U5YKfaR8o+O0DFzjA9PE8qAenavh63c+4Ri9f3kT4E9niKrde4Vik8iyKAp
RKPu8uKqXBpFyTBWYtLj5LjxVgcyckZmB9RGgtQAKmWVk49x72JW/4qfXwyS
zZojOFj+I2kgFcFYpARk6kEeVImuY0cYWsuBKpK1WB0iscMLDSL2uAArEReY
Prb0WJSD90mXhelRVaCV89n4DTm/Sa/qBwDA6GS0591QvpZICiLWBTNK3RJZ
yYwi/kPPA7tS1pD8GTnFtKBRPq3fWWHUAC1v+Uc/fAiy0IgOl9SwY4zDqyke
0Ij2RpsbdgXHekH+JC9D2ahvZ8xVaJfIiw1oRxgxOfeRKiQwzzaxBGejpOEI
0JdQOwk725CCAb/QGNfoTk5rVtXgwIy5ZZpW1VaBYW4IGTUnFAuNlpxHY44N
kwCAKW2nbso1ev1kq8IK1Ean4SktBQkXCdeUlCydN12hqZ/2JXJNjN7nZUJm
eUWgOsQQfwaOz5MV6IGOTUoY/0Ia+oq0bbplexfnv75I38MVRBUa3l1TULZG
OSTLtG6iMZ3F22SPXTm4qYA4deSelAk8PgD9gINpxNBFitwqfS96BN0ZcgC0
InnfkGuxgSdHdSbzfPpERy3uuDGTtbMgyxNZS9Ci30Fq58xzoi8AeKfiEwmG
Ga8GmIsWgVijE3tVQKYTLQWCtARrNcV4TopJUSvUGNVzFTowySGs/6laUWMl
rarQwji0ZkdUXzmGIoklPaHi3roZNEJ2BUdD01JUsPzspQhIfqelIJuhOBGh
uZgvaqluYC3eBOuJd3wtiLltKKwKMOg6rWZ054DMcUAFap5DvD03jsHxX9ZK
IZYDZlwWzbuXb1FlcCPgQqRzfogNsmtL7eBylSs/s3LCvf0V5WTMsnm6WTaD
HtqbawgAnRXZOESN1824yA7yDuZFvvIQgPATBilwDMcwdk6Rvl9lf4Uh48hJ
ujEcPoA2NzFPsW7N65qxVXoJx25JntzyoDEnyS/IZXhiuOz5arMy5i5HVjOZ
SigoGruvcyFXAawcuvdoVQ/IGBRF5BChILIEt0ypwIf7LerixLYgokwPmokB
2199WIpEJG5bJo4S3b9jd1hS0pJwYrTbELPpHF6VBT9dCBfiAA7v8HYtAt4i
2kFKG4rVwrsDoliBCYbXOW9TohB5OmIf78zyJYpXwmPKIuPbUqKpEf2es3Bd
NAIrGOODheS6jLZKtE+uCUaxZr9t2DVYKNcgRCiE/4WYbPVSrdkd7WmQLJis
Qhp9GvnZlBmtKKkMaQmMhskNhXf6tDKckOlmYspBUFRMvr1/9IpjfBltmB7J
HOIiLPmkW5FaLri/cXoQ1tisLjJnkakNvo65aF7LcpGgAEvJnSDAr2tAgdj6
W2eNyYQIsRhRaIeGZGgsTy0cueXKlvu0j97wspiJ4XZTMxENx8inJ7cXwzsB
KsrUB7xFGcFAMOwVDnJbpCsKofNuIkkpTGfpmiHclgoVOHKEO2yPelV+nV4M
KByuInt1SvTGMO9wMizyqUBnRkIJBdMwMDkgJzeYm6bL6WaZNppSAJeA9Cdd
nMTKihREUf4tliBiv3jsFG/49eRZoqfcOgl/6MVQ+fEVxZPgGnMfzw0sgN34
HlipxgjD+e2YbHpBcZwYCYoscche3Yx5So9gRw5MoFSYREYheZO6rCb0vqav
MPGUwG7JSgpwpZOTZEK6nYtsueawIw7dZszyqEF+/jlIfwh1ZfrOuuk0Eu6y
QK90vZnNshDQkPNJYgJYRjLs+a+AtYAbHlEEBSbGL5qyeZr0OVkOQzi5gMEu
EoojTOEiv8+UR5F/jon1/sOHq/piYLeE6nFEM2hhCHDEYVKIOeoEhq/Z4A1X
BROqYMXoegO0g5N+muiq4fwe4b4eJDwbHOI8CVtqXVbn6QfT2uhBGH7KpDY8
RWscOxuAaCgsTcnB9pRRQAAjriVmd1ZNKWHFxxg6m4xiUj/FMauRh/UUxHKg
ejUH1oTbi+4PJWAk+lL6DbFayfLJ3qMfk9P3iAqO/KgK8zmqbFW5RvzMIvcp
8QVBqj/UbcRPl9fo+0L815CqJDAzjr9n8mLexduBAU3J1IgERFL49kZpGKzn
epnVBdE6jAi3poRFUuAHsXvGkUgOv05zcdqjn8J6xL2kqYwZT0lQvvY6C/mA
shkjoreANOm7jLkG3X8fW79SIZ6JZESrEb0EdcfJgcSwstPKcEbKAtTIWX/N
LIFT2heuZ0M5f34WEfZY2rVh8W8JLbxz+TYPYTtqjUQopOKxPONTo0gLpAPO
iwUHpNtQNWHJnmkEXiasRSQ0CvzIC2eC+9LlFsDJ+7pPj5tt9bjXrLVONNys
wOeF84vT1FtHxO2pdgejKNRi/UqqDea0oSyP24RzhEetjBd029gPSxIr6sRl
4vme33QrJjPVsL/Ci2TtM3AxguarSPjcLXTawA/1izqverLthUHUdx2HETlg
SRJ+QZnfEwsTjuJiCVhuki4F704h2TJTKnqCSBfoiF7uyBVIP8/6fz72f/wP
0avJV/4nGMpfTepgKTcPPGu9qtaAr3aYzL3lovtqPKu1nY9unPXvd2x2x4+z
74YfdCMyIRzJ2WFgxB1guuPnDjCNvA//22AqJ/lFMN2BPzthOhmIvWkkPAZh
2nJCnIUqFywFkS7kL9xAPBL3k1/S5XzUoWg24qFRVihJSvIFa1diyhFfXLOp
Cm9o8JPVTgl322gSxSHf01TwezTavZANfo+IFVIeoJlo+XYkqIpSxqRoofuI
A+6PJTuDmF0nhC0KW2sZ1SzFQlJt7GRi14keR8kyJ4O6awe5dU1tGFMiYa6t
JX8mpYt38OWULshdPh+fEopDQn6tqaEUp9ss4gRrk1gFerbdwjChWFf9E9Pm
BGuvaiUN8JnfsdXT8Qv5+KpOwmdh7JVWZgg5aGy3A3UD6/NkGko3CyGasbHE
hJmhHKXny1aWOQxRVvXdWcFd6NPHXvp0O3UCEtNHne5A7z/20vu7UPs+EmRo
uj81vX07SFb0cxfQJZ8DupjIJp8DvM6rdwdf+9Xen8+CK9B1j/ltuLbIO1Lt
5M40HmvopKPnnEXeofX87Sx8q76ZOEVQvIP4gLdhJuxnpjgh1B7Y/OyLTszJ
3kIqacUiqNL6vDXnkOiWsQKla2I35dyFeDplLLm4DAKDYTpJydBYv4q8aVj+
JC0yIskJJUCBBl5zFaqMftWd6Xo5A091HlhwH2QC9eiQXa8PeRq6h64yT0MH
LTbWJis7cOWmq/Ks/6XogTZSJ4zS/2BQL/qkh0I86ydJ0aVqfdJDoPrW8vd8
veyVsZ/0rqX/UvkH7i659tzCPuIWn1qyp5eyHtxK7m46mnh/PQfR/aSfeP8O
R9O3ls8/mh0/PQfSB3kgf+yAa106Y3hD0yO7NFs/9WZC9fhsftekvMpaZ9cm
o/EFb5PTFh489fdaKSvCVA1UB+qxY+G5nb1gQ3WSbqiOd28BDXqXYfmrit12
rMqiq89X/uiEB4RIfJU8xa+BIwdBiCN1XTAdr9G71CrQRhlamyL3tBVW6TdB
9j9vJU3r7WqVYd1hqoFCZdI2a7Io+/Jlzq6T4vfR5Bev/lqLK/F7VJ9GZen+
PBGVwDEIviULW6l01SftJqPkz8bFFUwVMJjKzdZVh/mgYjHq2EzGycWfLziD
DeEniSGJ8YgGg3zgG2SJUpsk84wQZs2QCQZ7GM0aVaz9MFak2ENx8Wegj/sP
/2siDkp0Gc5jlQI3d1cVDjGo9ubjHOt0M44GUxLjZTgaSXmqrQ20VXuClzrZ
WtYe+3rguGb1ArSXQRelki9CqRuiHlSbE0xyyd+OSxaT6AQ9Ltl0Di/sCZi8
CivxWC1hEAbSJ4bBkxS0mpBjsINMeOrQtrP7XB1B/LyYLze+gNR12xzPqRJd
AW2chIR9jCsjkGzXRCyiQjF0FbgMQqtSCJaT47vvFU4NHQDYYlp+16z8NGQS
P7DGZfoUT9cUP1AiXSccTWfLI5LLhm7EKqqCxTWW6AAtNTKhf5Hgiq6ushRj
xwRN81FWmYQuKbpIiU3BZHEmAgymeavYjRyNeN9n4mKJbOdmHYArsorcJEim
UcpDGFtCV/xaog35zcCY5Kx5z4EmJks14+IJmDz1pZUTKPMqMt24v7VUAtKr
v71UAqyL6iSAICaxCsttGAQ9abx22ZDXHhDo50/plXtsjT+nTEN49p51dBBH
DbVvQvCqSQILmWS2ei0OpUF6VYN/aQbfV8lrmbl+TbmcnAAez2uIkddX/JAw
44cPnAgaBj2RQemgyY+6c0RTZswuM17kmYxnwgIl97RvvX1wet0F0I6ZsVdC
tJ2TNsJJ+CGRPCCwr5ntnUSFb4LDUxJz9fgZRbgww945rcrEV2iRAj1SDMqQ
OhRmS3Xy+sEJTfr6wZmTGsGmdEXkrFmjdr4p2LOlxS5QquM0VCqg5MNojfAZ
vK1c7z2jfEhbJJbDhH2BYIyzoHoD5jMtAUcrJClzjx/ZTFicxRvN5UdRCDaF
5VAg4XJedGnIZYo7ofO1q6CCZDimeKSWSz6IPQwcWHOh6RNODNTE2TSZZhX5
YkEwoSA2yeQ2lQWkZNp7jkagYsG8gQmH71CtHilH0rrQtrpeh1oxOyFqjyub
S5J1KpWg56gBlMT2KS6RFghzhIBkTGzh3Ntz4mRAbc4C1VDSSnG1/qqz47FF
XDo3EngZudREwejCxEPDcUxfv12Xk/RYAiO/dCBEJjUwOeiUrQ7G2iDuSWFZ
k/jN2d0bERapX4lISbxgJ+Wnfep8zX5aE2LP3nIfED30MYzyvS9m51oVMmPh
k3WnkkpoLz1wQqIkMWor3XJwjrrvC67iizjsk77ONZFgn5wJmLhs4xZRnU0l
Cg3QJS/M6fzRz6ZQJHmY6wgQKE31dWFcXk4xQw59RgvO5kuBsXiOKvZaQqck
Uqy9Ds93UfShIiSpRhdHK9cCB1QvwJYpCDD4YwuAn7Ulu7zePakbwe4JBIjq
87YUQeGz9vQFx2SWNwRgkvSMiwg5SLuPa15uMBLg1r0RjtXt6e6ytbFWXa+J
uxSXRungkzcpyHv8CfOQAEIk0loXG99r50GFxGBkqJ1peCib6rzHm+BQiACB
QRLP005MIOvGLRUmdtOgxNMgdyMN8suspdBLABUrm7B0LSCrgZmihNrN1OY8
h3GEFindIXwC6b0qdxybaMPBTRXPLuFzMeHjGDIKWGHenKVc6SfkC7ELmPks
5rlEbBBQDM9OUS2wD09HfaVfrisYv651TzkP/yzmbBQRzMKDFoGgHJxc4k2M
N4Dj3LxPcHjzIeo1pBuR14mJDxXuECAdygiW11lIquCyVpIwAzdnJAkycboM
Hp28ECKENIcm5va602YRN9GgYGgp/6Elsru1HMl4E/i65ei9JpmW19kbvPwp
qkhNq3S0SmnFQKLJ3tn56ckg4UIxNZqz0OvKVoDrfIm13SokWkQQys/hxiRT
R/UcbJn7/4zR+Zyfz4jROT35zyCdOyHQ5wTpAFB3R+nYWu59jlwnhZzQIoXt
07Zs4DT1nCSS5/Qk0hQ1HqPly2w9RVF511REkCvkwy1tG7v/MwjCnu/uIIjW
3dnxcxfY/WcURBuwt4RB3HqJ2hjc/tmx0FvP6baf/jEM8Fogv7sjGL3qYZQv
dQTHo7TWcmdHcDTKnX76MePmUb7Yv493to1aRAl7nPunJ7d4929CiS8+zL/9
IP/2Q/xM0Ldh3O/FByDf5sa/wYUfHdFdffgRLWgdu3fgvzEqb5+9DdbySlOR
VQvGrFUr4veb4cSKuMMKPLJlWUtvWxXFr8fYtRf5Lc6j3IABKFMHyb01lkG4
R575BovicU6jy1brZksF60ZSOhBroqpKwHaJRepr3pvUY4IV1xTcgLopi0Tz
pjooWxo0m86M8K6zsE0TdQ7dvJMsM3q+4kJnFF1aRKpIXHDV2LGTeybHoinf
ZcU90d01XFmg869ZVUo+r+uU76gzLqlADu6aKziLeT+qihJKxKnBxO3JAQEo
NgX/LrmWqmGheBat2JQ8E9v7PbYRS5EjWKVZbbfYiKw2hknOmWsLSgPEBknp
ppguJFxOjAgtXOLIXmwUWLqOH9kfP5fw6Jhqoj3KwvUo0GUaT6V5T3jBbexC
Cx3rP3Yq0GqKvynhys0ucKiew8cojOC/bBbdQgh2mCpr+FbuGI58wUXJf/WM
3S5Qw8VGoroEihV4OaN08mANal/Kes2yOI0V55LbIhCKPWTmL5bl9J3UD6Z0
cfoSl6b5ZTRa61y4egBq5hM/MnyNOn/FZViA3GHEvpy5T9QykMIogBIdYlTs
wEB8zXUzGxye64TSEnxYPDrJRJm3FU0RAkTdirK1XK074yuQ43DyRqtObogj
57rSSrKUEpkcfynPFnYfZnuuFj1UuSQYgHbFnqgeDOAggTYOdIn1QylP0n+a
NcKMRtlJiiLIaOUPOLLHMHDH3NlzV/3yurd1SDPPMpk5dC3pLNV75+xm45Uh
EvJWdoxR4QDwPJI8XmjPrZbuYpHE0C6F5VFgZk6NvwEkuM6Wy91XkAaka9i6
gmbFN12/cPko8VCPjvM6O5gVTpXuJ0ZmPIlvWvKIQbHmjlu6PW+ItYVL/Hpk
r4LPgWv34b95NZwVWz65iA7WmuCPFZtz5Tjt4/GACCGF03S9ZnhQ4SWGOaXl
S1sHkPLEQaaJ4VUm3V19jBb5BtV0/Ifa2lgleASncyE9nWoHia+bUEWBg0WX
sYVafL2PlZNzrxYEq8PeAqFixf4FeQq6sZvJPSUHEQdP2hy8I0+42y+xobKa
edXPA/EidNdBybx1juy1vyaRHcJf8rp/NOJ/FJzRNw/ucScf7OWBNuIsxZii
nMuaPaJ4tz1KWjIllQdexOy77CnOMcvK+TxCa3h3ipVdWQ5qy8/eERM9ptV4
td9BFmo7xCFrXCThbe0JjFR9txKTW4dOHZEJLkRNLbdCzb/ljV88uogY/cW/
PbpwlvTgA8xPB0PPii7+bf/rxxe9PnzvJ0X/RGVcRNIoiDQXVFCm5RX1NDrE
+C5263dgjaUFONzwWloV6RZbkTO0pSf8qOkcQW3EcbFPosVKpB8vMUqK45t5
TcnN0v3Rl+3xPYDRSbRAOkMUg7peUfEo26+b6+I4IhlMZ7DMIpegGCaTjS+D
FfdTkhpIvtYFlZ/xIYoONTjk6sBSVFKpMIxDkShq49KKDz8pLzGgFtC6rWe+
ITWQSWzXJ4nXru6T4FVnrE3um4j8k60LAbNtUTvZs+rh4CaRK7vF3yOJQn0J
4AtxqQuzDVqEC8ym5aFVVnMswQu+dZovY2FEreDoFdkPKAgHCPlqPk6WFyqf
i7MV5U/5rid4ZvC0ZSY0GpD/YZYdfsw2zAM4xK89P8mNf7Y+dEl/pdSPN/7Z
+pAKoz7cp38e4n/34Z+H+F/88yH9Tv/4Bx7qA/sP/TOu139hUFksGnJgaGQJ
ZP+bNhKHftNBKAd04YDyJ+ZrL6/IraKpDilC55ILZfEVSs5zkrvEPqNUDjn5
dDtdemTsN9UQDQxl1zSM/RFV3sBXDQ6vOWghfHfWksak+Bsg5WmQ5OpgmNnn
dLLC+bJKKA3HpdisGYm80thZi/PuqAnatzy7KUGGfmOSibQMehz0X/ju9r7R
QZ9aWGI0eC2iJobzapEk28+nc6+DFKqxdHgbg7jnet5uQ22s25eyZrxKXo4Y
hog6stEERLc6kASu64YMhYj+XrNdSxPXg8M/E8+hXiYmacVXthkM3cWjr7+9
wFJBwFcHPifGm9xYT+YwehOvLESWWdftS056lox1VGXNsArYAJPZM/j7673H
X+HX4ZPBxV2X5sLSqGxPaFrtG14jWBjRTPyAj2tpjyfs0izXBEWI4tVKG6Ii
6D78ESRDgC5sSaY4zaqD6bvBhW2sHATw6KELQt8rLNmPvcy0Mzc2Nmuzb0K/
bX9fNQyufK3BlRIYzS1OQmSw1ATmL6kLBYUYD7jgDqF0gSFVqpBGzXICGcOV
wcXhyztOjOuWalhqd3Mc4E69t9WJ+1oii4X1MQ+7pyV2y2Wp+oi6hSX+05re
Jqizkok5MikHIYLGqeNVmw6XHGyrTU7x+BEYbhK1pQJw2/WbFACkiaYemeDz
Tij4sCdHYU8Z6YZsNV6WbDOB5ZMhITJlajEwVLgocY3JmXzsOlGwrHbLpP6A
7Bi28Yb1LaD52Kc819mlNg/yEKLidCCvbYvpoiqxJpqtd1dKMjORBmk7q6Nw
CJo1MvmYbdWPKMBPm2LQyfJOSNFcZsUlCpNzQh7+2sdYcaPRTuEvbOaDFZ+s
AjOviIZPtyI6N07zrSk4JxSfu4TLkMICpT19hRBIAqIQoknwIiXW4YqkKw/l
ZceNnPK63mgZSEF9jxW7+wtTvkodcGTECBJwyvnjVSTpxkR7AxcBTavjoR6H
Hy4kUDSdXaWsSbLTobnhnhTUEH4XElQeg6Q/SS1NkKkU5k7cSzdNWZQrjstD
6IJc4LCJtRxo1Mf65gb3zCfo2DYV9hVWZLTzRYVKKCafcYpkNY+OHXDaDMIi
w+hCpOWNpudJbo5yT7bqEDqUcX1Xsia9T6eC6twa3ocGxr2W+69yz9LaVNxL
XC6i5/SYxyQhW4SUT0X/bdtCokzI1853MDQdmELV+ZnUmac+ojBcMPZpvfOX
wZaROmVfBAbEK2SEW2Rv+MnAC1KvsU2umMkfffUSoPSq05SRsMsHjEa5QBnV
zLlOZdd364Im0bObYEHu3q9cPI/eJyArH7p2TuCHD7oiXJA0KLuvzycnTOJ8
SWHpiKmEL/GEz5eIuEvl2YSTPcimv7vyrG5P18Kz3lhTlkv28eo6ZWXvVkrW
3VxKlpG/XUo2qgJrVpQ57j5myunmjergaN9OG8JBEZXVsEiv5NzPjWyrSMw5
UfAlikwED8f7HMTyjn8l5L5og13b1K2UbFAM8mRTRDAavkwAIfJ3ZGejtIxy
hdmSmqBnEJwNxZOMOtI1ZQkiKlBHToQxmezdnnKwmq+pzyKW1hYJGCdGswEM
Q7VBNWi9XmDfdE75wchjpFrbPMMqlShozzdLf6lcm4omdlQu5SqGuhjrtaO3
l5BfGqO71yq/fSL6FwUFX/OVeyTcS06dLZIkHgLL9RYqorPFXISrGKPjVohU
tpCJivqliXp6aVcrxpvQxGgWpeYhScp3Pg2NybH2cAW/VcgppFqoQAar2ir6
M2SO5xYvPQ9ecAdLJEzsKi+oaaI4MOCs3mVcjUGCqWeYdYs0hPXrGAgR6puK
wi+ffftk6JVwbxjWkgwO+S/1IEYWV+VM1OikRzXop0gpEFWarBa7HqEOPHZZ
ljMJmgHudhAokKZWy1oQ5QjecgFT0M6KGagnhAGjcj56BNgS59M56VXtU+8X
KRUmgAPdiDG4hQJ0TJdM/xaS1xx6fDuywtKB+rYqvDgkulzQIsZe1EiatOB0
uZRGLrSHJhH4t8qHyNrz4X50H5z7iQUPGmsvXusgUneszZDyQqLmwi7qBvya
zYRsedQy7eyOYh5C00VqEzXeEX7dHSsYdJDSK7QDGIZUBr4vDyVK4AikMuLO
LCCYKgqeELxsmXHj19hAcrHBPy7IiovW0lVebPhwU7Gs9bLtNICi3a7ZkfT3
WnscX2B19FnOBYkBlC91zmf7o/Tqcm89+PrlxaBtqSqybKZ5mlptoimX3Jy2
S6g1mdxNlhvpYsONZi1p8n23u51PAU2FWdK2SL5oBYneGv/ZF6S7I2vAvnX3
2Pbdc92UKxBH5mHwY160Av3x3hfZMtmjc/l1s45iHnuDj/sD9/9d9rUjXP8L
yg114hQxTBFNglGEfgsaWLhr0LZ4v7U3iUKKqcCa8DTESCVGP6GVGYSmjCIG
23imSXXt/sDqX2t1r1WvnkVnqj6dzmZU1QxZTyuLR5jUsizfEZXtdFefbioy
+Lw23dU3a7xw/+xzo9ap9MiJeshIzxV0wGPRNzMAC5qewv0ztnS+pzYdBsy5
Vse5N7R17ENtlZdfP7rQIDcv9P2zNXuRXXGWjawLGL7L8RynW+6nYWU5F3/J
hQEOuM47S107lugNrNoQAaMGsJzbZuoFBFJY1jn3zoaTIeGEak8r1Q6LUQMK
lUtHw4cWqJuWIAvU08CvyMLIOfTLLExFxTznGcp2+hmZy9n2T0X16+Sbh/+V
24SXq/CqMFZAVpSYUec6U6AQkf1pgwd8wlofYOzrCX6ArJa+EHUQcTSlgA4Y
OE5MkyIyY3EKUPLXpP3uJHNcEIkjsBLpb700tcZhNyRf28YW2MZtsszrRVAV
napbIP1JNFlLZjEs6pItGJLoQqsaJgtg8pr8FhoYSPLgMps3Pr6NOp2l13j3
ymDn56rVOYPTbDWgIpfJj4b2NfLT0Aze78g0o2cJT0JXWhtLpYrYTOufUKXF
sAB2Akkiu07ODXwaU7g9iNxkz6oy6ZjXms5IBv6MJpHC22lfFIkyYuSh5Ym1
hrQ+f+HJd8voTaWhhua7/UffR0a51tJgHFB65IEB3mlzDHhUWFVSai9EUqH4
wq+lwRyG3QEio2d6g/0rcpOM6DezR7G+s9Bsacalp0QbQluont5rFx3YNWqR
rGUMxBNxop4Ikm+PyObF3oi4vIP5mrqkkxuxSN4WvnAGPaGhWBqrFJbv7QZ3
NRSUvlRzPPcwHk7a+VAB0CDwWwWPLpyxr+c1d5Rk1hBcUhRdDij4+u3x4ZCq
0nEQBz2Jh35+eMpu3sPz02QvoNAa7aHk3sObiSqf1vsaOAnBIhNi74yI9G+f
88DHp1dPvob/fCtsZxd0e0x2pkwMdY6PTIFqPJWris3kjQvjhlk0kivZO3m2
r9EsPd/L7M8ectTcdV5nHVPBLVP5ULD+oHdHvJ5WQW14m88c3gaykhJ6ZbvN
q0nMF2KC1QAVzGpCnqFoo1iBjCpBxV5XwF60S9KSLWZyEdjax7D5wU0Rc5hi
mksMih8Vk76ZoFIgNMou/iB2XzjONTdQNLWmaRqJ2j/WQIclVacS0Ye7a5GB
qsguuTVT7wBedAjxT+iVBVmAw5/GkiLaCmmg1uk+p7P9JapAh2Vx9P7Tp2Ei
pXX05rtAdXydHlVh2QofFER71cWjC9frCMQ3hhYGbdvJ4hFRpjCVxVrDTraN
2PeNH3vo7zASh70PH+D/Pn2ivnzq/jTepKt8yoZbKUJAbaTFyyaeY96lb5kU
2nSkcZ1MnwmCa6NWTQ3VMZD+hdYwsyF5Y6rNT3YgkJDpeZz7pJSDnOgEhr26
vAUJYyTSWnL9t9j7Q4Xc6sZ8KVGcc3AHfwFhQ1xzSwr7tYooOG+EUC/xkN2k
4iiIogPzuq/mAlNZbfLj9rsVBEmhb0r4T+QtOIIFnpejo0LglohKFp7sZbba
a9A2Qyhv3DrbViZb19kWH4DRtOCc2d+z37WBkeQWhnY6dF5q4JpFl3iKZ/tC
odO63qy4tyU5M3IN/mjZkDg6uzXIQ2Es+47ALdURSaHQyl3UdpdPN82Xo1lV
rlm8ju+ddEIUOgnXDkUQb8DFKtvWevuH2lbiRxdaVZIqQGHiWRTIjG9wiCcj
M+MeOVD8dNb+y17liXpX4jbCCjynVTGlsUDqG3exkZRkbQzYFoOblRC1QRCh
0WlVztE9cNgqwCsS3mjN338O5plavnIMMkgwQGNTHfSOAK8Q7PAuth5MDN2F
0INPaqjW6dCqQ53xdBimzaJ87/vOUPjbKwUyWuwdl/0bmTQ/CjxWy2gwX4rd
WnyM2mmMJD2/XCdVtFSeit8xvmr1zoThJ95kLFtwfZAIQ5vrQVGorGN2RlGD
9cmD11ygVGX6bucrqe4nRTIPqfSf/VyKCEqD0077qxv8sDaUnbt9bKRWn6hs
XLUsuvpP5cpF7Tc4XbbXBUUjmI4gPIbt1SEKbTxKeMOO06Kbdi3xKHFC6Iyj
6QivkIi3yL1EM9ur0SmAreuKLiGuiq7uoWIpgPmI13gk9Zlij0Si99jitXOR
fZCppNTSmcVutCjkcpazIIjEipUDF1Ppva5DUJcXuK63Z7SnNS4Ck3/jPSM+
p8iTYCOOS/3kYPOQa9tmfLmmgaLm5k/LNmfGOxPTiz0JVSSR38vN3ug123A3
dyxQjP6TJdpCSXcdGFKzJ+I7D+JkkJS0GNDDBtxBj8rAsUgdVztl8ktxC1Qr
PuWUAjaETLIk6PoT0oxsP8NQp9qtMKjlMlM9l1pcqpwgEVfER5ZbNRi18AGB
xJSHkix4fNN1s8RcgOIqIxszBw97b2YQhnF/PqdSqC8mAFDV0wGaQkIFYL2f
+AF/P3a26G6fU0YqT4njXQuXa0xpzaFstoWQ6xWQrOHQKkNoeOjxVS2zdCaa
R/946KiLkmwIv7wCaAtXbwo15frzoZLbkhRI1UbDgpCQrrj2e9t1X1ONSG7A
pOYkm3v/xLQrlWBkmsknz+sdUbepLNbc3B5QqIl3p+wZXnc98rAUK5f6m+yn
DBFCFNrA0QyySG/Ddl3XGz/CgmXEP4ZtmVy/FZkcjoX8FaLF7vBbpDNKH7od
JHCUK+SMvfAYYoY0WxNtSglMvMxJqzw2DQ1CbHGkXcJG0fIkuqUPL+AWDbE1
yh0c/jnowdHtjuqza4u0kiwOTAvUmuXFE+6DyyEACEhvfY2BoAUPJDab7I/+
0ZYSQb6COgV2056NTGgk0+no7Wj8uGK4YxBy4vlmurCquW98H1dWLOZ5teLl
dvaqkIivRqeV3G2o4gyq9F4PivtAZOkikkrvz4OI4zl9S4hx7qeM1J+2POTV
KQlpxICMmzh9FBg03H2r9y4y8dZzP9i6l5lxPb3g2W+1cLPDzfSROrnY2x/R
GwP4hT4fPNsf8Xye3fMLz/boY3n8a//ihcLOB/ow5D7cj64+ZuIoKZxlaKQL
nUdjaZf5Ss3xqVIvtTaqZZOuHauXDNZVTkHEpjigL4NKzVYwXIWkAvuSMDOM
g+IGrwSwqMy2tFWn0W1yXORZUflHZSRn02iiIbRo4avoVcWZHtoWBdyyjkcW
wI2EODurHmqPP6pATS7C/rgNNtDjIRjHba3iQkfOPN+FlNHirPAJPJa2hKUn
Wz4UxnO/k7ydK6t8eId5wwUzUOh+3UNwaJHs3BFvJUYr+2xZNmk4kYBaOoSI
hCjzEFQDH+o5oJkEk+7mQHDFXIsfdvVhAkTbpdcDOGo4AOzussgbbFGQx20Y
g8uZ+RctXcsACnVBLbbZqpkx3lLwwfYE3iatGDROXkJWmmIYgeuBju/k3tmb
dZR3RIuhEzvsVnUCPbmoNLBXg6WCOzmyRHnAYG+UzxyFcKYhBDPh5pWtnBek
qRgc0GobKb66M1+SPSSsvfnNJBBF3QWcO2s3ADDEjuqZogdYI8TeFsv8XdYN
76BrzIV+LYu26fUo53tzBAe4Y9Jtu9xtoAJuV6sF73/lyM2iJyGHHxxQ8k5W
dwoHAaOrNkstj+6r+chyucwSEXosMMGkiIsmDDlREE1aUrWJrqct6W0Siamr
jTqBuf0G2gvEzKnGa1+Xhuty5/OhWqTa62l8fDgScPEAaT0bPzIuplVXK5lj
peYQhtFTDseum+bAYZA8rmepBE1Psijizr6h47ejBFRl7R4lU8SdaQV1YkQ2
nOFMnJauN39BM8B3T9OUl5eaJOhDhLhhWajmxCDxp2+g1e7N5OumRJjp9nzL
G+Ulja0PYhrhvNbeGn3Y7/x0PqYe1sBRTbooClkc2u4JmgJC0RoKCBdfHTYY
Eyy0FMLFi2frC5Ov0fBEA7EO4BWQ3fmSEeEivwgvSnpu2OIZZyNSiW/KnyBc
weZUTopm224qtKt7yd6ZpoUw5rwwR4jnpPgYeX89Locj45D8/mOytdGGRtFi
KIOUBUL5UwdwoeTrPY7/HGiYF1YyWKHDKLngb7ir1m2RqBK9IOr3UK8g9eAM
SV5SsMmHUPkLFWzmnVJrGhonkJNldohZoQ/w1BzZk8088ODotc621vqjKzNw
/oL09CiJKTyhlydRngQxMcSwcef3LAfLcUmgWG+oK4qk4VmDjezyhSYkhTrt
Pj4kwjgO9ojysCYhvJGEbEEKT6Q44QQDgn3aXCik0R96a6IB8f5Rk57ynfGz
nHEYSm97wshDyZ6blszBXrSeauNi2d8UXu/USND1chPEepvP7UICsI97wYs4
tnXbDa2rpapU1Eg8yK3B7RLXjTpznRGIAna62EU1qvBFcy0NPjnvSrU1lTRW
Wkrah4IsyUs4PxT18kgYnZn8L1F75F31vmnvnE74Yge3LdhNtRptxxNukrlo
PYN0VyZWpuhYo4YJ7WX3jKH7UF/hmUk7aBS9iWdrga6l9y9KoAbT1pgEqKLm
2O8L3GC5HXXorXddk9tRlSMFg+S9HYZLzSRqEwp5EqWlequbgrdje9i9iAiC
SdCWdFzbpY3aFZE0gV1CpLhPNIVKFlwUDjnIC0uNhxSOxWwMs2RDw4zdVMk3
sfG8xBLj3CcyYwxQdkUb4z34rEPgshfVr8BQLgyDyYueed0LkXbwHeFWuP6L
F9UzZkgPaKA/JsrAXlSDPyb02bMX1ejFRahi4MtlhGoGsoi89rELyUM53h3B
uBIcfuZVIrbMGxNll1J3YvlsvJMEYSLbidQJzwwx4wm9xTjfULFXY1uraHES
UmJMwZNsi4mF12KJ9FE0fOLaRtFqwa4/9aL3YAHp6BrpRq2U3GLU4vTlVGPW
CA216NZeFEVElI+d0lDhTFE/2rU3BvnAIO1b2SPh0rx+Y25GBYjmRP3JTpj7
JNqObqL766yZxHwUH7mVOadLW7tXfHd0VbaqDp/8+PPCws9uCws/6w8L1yg0
biCz4KjRrY8ldztiyc9D0zVfsE8SXyl/g0Hy4YNEq38iSrTVoBUKR6V9EZb2
RWhzSa5W60lpyXK7R/8s8ugz6ycfmCRo47ddDYr9/EguRINCCyaa3hnnfPaW
s93uvIbFeJJHhXQ4aMRmNzEbGnAAOmeYuZY9fiNdkroiKAayIiVXksIoB5uJ
EtmcTWS7IWltl9xlWw8lB0Vreb7pcrDSRDjSaojEYbViUhQPn7Y57o2X0CtH
DgaskBm1C5BeQ9FLphV2TzjFblHkaRAho/poLDmGXtZdSfamSIx7FLE/QozC
iiD3bN1tDqnondVHV0i9ULOSjkBm4BVLwmZA7pZmd9KzjZ2g6YsFuWkd/Zvi
ZmlhXz2b6orMwGzirlEhzp/kOq4SJS2+TEdyY0RBlHFGBkcgDRg1+nqDtJu3
7jghfpUatt0E0Ba+0qx9jTPuNms/+rUad++YtRMT1LutnaNHp7dH4J2q2NKa
bqA5TOeE+68F90EM9qivjqfmN3E5HcUklCgs09GJmjW4HkejzmxM+RXDprBd
t2c0kcBKa4nehh1uyYDNHHUQVSp0UfO0MyrFKHYdSubS2hI2tKzmAL9rLl3E
9lDy674ESvnnnanE/S3tLFV2LapMTqoqaAXXi3JpLkuvHtzRfTlnMG9dc6nA
wCOMkwNfsyi0+OYrxtrXRUzOLtrkTB2XfK6UtuxQjvq90pbPfNpyE6ctX7y8
8NNK5nKjmctRpvCOJiQhU/iz+ovZt74go/azuor5tz6rodjn5Bcz+NoJxp8z
220J13fpKPal7cQ+Izn59gY4d2uGdHOCsoCzN0P5PLpH7Wt0T+KNg2agfA5V
uStf2Y5qv1DveqqVqIwgLmTStsyzR0tIdDvmXojDK6UtzwMjPrq7AKCREL+G
LztBEe420ciSETJM3CTH2RrKIbKCwybaSxn4iAigFDKFj3R2nZU/k4Psjado
VSH4P7XIwO2I/TeSjsyg+hfRji+kHP9bSxp8xt3PPCVtXXxz4SI87ki+Wrbg
fmL6p5nOoz1RkyqPqUbVkstMTNuwpYMFPQ5zce+1JNJ7PWGVAB360IsZJsbF
RSrMHjF2zpsJjd6UWIGwigF6WulrEoRYpBFdsMBF/bmrBw53rXnvYsGt2C+w
u7GnP3emPb/qCoCc2LiL/sV1KLAOphSpNQRDxdCudqCXLD4QqrAeQ7HkKSVU
/pnbKdatl/HLGkN+WVfIL2sJeRun3tUDsq1xJXsCxl+n5c1N5e4EuC/vCvml
LSE/A3h/u/yzqwHkbqiWdYcWthtD8gs9HSH7Ij7/XSlgOx4zIn1sL5fo7LZZ
BA020e0f2sxeshzITOzR6cm9oW5lNAcRNdcharuloS655Ixc8UNTurQGicrB
MGnwNCNQi/BRj6Bz90vxhVfiyy7El12Hng6UuyWdWZ+O9H/qxsJbd6m3dItM
M9utzjyP74vILsmRhuQdHb4cUZ65L6GBrrJ8qSWI8xVWEJyX0414RWyxYCp9
hqZpboESldaF20apMdjRBHSjQmOL2dnBedg2V1UDzMirweU+pmQmdJQZG0rh
tlKW/wfs4H8Cy+XmP2jap5FDsQosn+f8NudZNiO5hiqRAJGYVtu1hgDkvmEA
rJFtU8HoOtk6dotyiDTXJaZK3zJ3Wr/TlK1Znl4WDBR53km0NOXAai8WdgdQ
XhaHdxl4GEJHoTKuawAUR19OBZUoF3/JeTDmXTOird9I3jWqVC37tl+Kn41B
4bPQCiyWlYshnxXVr5Kjp9x6LEaje1r1QLu2IeHcTzrNEk0+PgwAGE9DSFb+
sO2QwShVjnyZckLWuNuEtIvOvT1IP9yXMTr1SvwAWhuAzxlriGnYN/vFdtQS
cHscn8wZYb4oRN5oKxo1n8HlQCE8aP+KWATtwyMnziNE+TbcutjshX0V7tUZ
7B/dVdICHthR0WLsX3bGJ15QnZmEnIIzyc/qmgy9X1x2w220qEi2C1eTInfP
D0+1b1C3OLksZkTlKRThuUAJ+oUPamz+2fQ8KylIHkDyqkaF+iRCrdcptc1b
kx8cHr49Ozg/GgEkPL6x65IpKNpkTyX1AqF1pjhxGO6ddXsi4i1GG8x1pHQO
T026rsXIzgoQnAIZDYZ/Xx+CFB4vcxwejdTpaJpMLLe7K1FQxLK3ceMePF4b
CcoS6p7qDDuKTsDwR1HNiUSLK+xcMIVmhnmj9djKBlzrD1HQWdLFpWcN/WuN
P05OqQgeFyI40pRxLMPP2exYZ9zmAmtC6zU3zoOpsPnNusJatyG7tY6KixLv
61tC7asmkzcaCZqvch6lOUk9JmJb03SNorAg3wuNCTtSpznWlOip68LVoOrN
mtih75Dcpm98J32PKPdGzm//8fjJeB+39eEDDjU6Pzt4+eb01dk53EO9JXUY
N+qscHR4vvdwMHT4//sDjtPDiQ+PqD7WJOOq2Lq2VvrbKmyRjkfYEUZfDbV8
MvFKG/TX3heCK3mzWZH4ArvgvN1Urakalf+CY2uEWGo8RE3v5f+atat8dQNx
YoloqBkHILJQG4UUk0KX77i4VQN3v8h/20gxc6VJFFamgMRwQawpg1ngFQbf
uqa8ZOd8p9cEptgYNYK3GGUVtavyhNpkPstZSnXjZySvOcqqOOhEiVbwdJ8r
3+7CayMPRvHPA/+fvp/eLx645KMcjwrBH+8DFH1PrgNtKazfRgLzxwQfxsZd
7c5eHxGp5EMG2Qsx4fN7x6t1mlesUH4kcI77RsH/PNi1iwchCmjrV7ZrFPzP
2yJ/nlfyx0/m99azN47i0+KiP3aNcvsZPdjxu/8Lz+jNU8Yl5IY0/j7+BzO1
/YzvH4XfkeaFv8ibfBNczCdsk8Bx2zuiPKrfb0fPnwpe8JZu2xHNrn+tslm+
Wf3NO/q9z+i5OaT/BuM/uvuO4jMKgPnqP/CMHC73TYgyIabTDq1A3f0n/IyY
CElZecE0FO72cvvHqDzQ1BdQoHR3rQBDWrinlZGxiVIQQjkIYEwclLYpfLNz
r4zfn+eXvzJX2f763Ovm9PIhdymq2bGgxPykZdwackRZxToQxV4R7SMGbUc/
+fTJRaV+2UwWsTDh+RSixhQ2DCjtMbLaxZI9QVFy8ryVfJGlM6kAG1q8e5co
ydYuvTMrGSYmeiUIBDa2MZnnqDg1WxGCsa1sP9N5sJPf7P6my3Q+/rSL33w8
hW+saH9AfZnqpIdEf8zlbwmDNOym2o37nVEayykiRoHf/KyQoa8Yt/rWUreY
Q/i9bN1m8/vN0H2w85vOjs6fmgauH/8LUqF+IgTfSGkS+vPfvlV6JTsiUBKF
/rgfLVWJEP4ORIpa8SHqx+y6C914w61v9r9+TOoLdeBbp9TjsBe6N46yfqdl
Tx5F1Pd3g+7rp6YzH8LF11OKofuVQLcUaeElL+3zdxRehD+o+nDy7ZPB544S
Xvx3wrqTp6ZCHMLl6NGRn9/A5f5HacS6SNcZkoK8eCr8zMmNa+62I+rHgz0n
cZT0/VOqtfR7nvSJP+oHycdHO08a/jf6BwzCTF7Tn2/XT+UvPSMBzJieDebi
Nlx0lI8n8NgrVEjqpwZfKNBbZ9wB3bCWEw8y/ut3hMvZneES3YAuXM6y+Th5
8xvD5fHXT4RStUd5ifSAb8GtcPk7D5gIRnAb93huFCTgNR3z9ntkzwu/QUHo
5UCgK4PePoqhmG2JLoz5e50RCWbJAdaTUBbvQFlLsOKj2AXZwIdEm4QXX7GY
fSJ7ZKnB7H7u2Beq4cRPD1zyX+gcuZVgSjIgDqrynEv+LkmEHXfKnLWDOEnm
vF3oxIMTK/PoNKtGB5i2jpfmDZ1FPg8IqXVPTC2HP8Jd8JWo+6XHE5Ue6d7G
wiOnoZiOrmiGpKTaVMKNf8IalVo3EbdpjWca1H9dsiyIPtgSi2Tn3lYxyzhi
Tat8urpcbtiDS6fyOGH7WT7OxsnrEzyl12dwE99Q7bQh/vfJrkeeDx0XHl6k
lG8iVeclbJgbnLFS3bTzTc69+bhclpeYVNuy0ZgEo1pdzr4cBFmhyGHTcKye
0xQqiVXPqX0uv503GwbmuNVWjUDn11GzYZX1DQy15Yhf6T1nKmXNg/UNoUEV
Xah3FZ+TFKibbNCaIwHuKeBGVG9LIrB9aS21rJWVOrK0Q9gJpwADwCWFExOo
3BW3dNOzJNvZEa+JLJsHLJYTkiQf7qfhT678a32C1jbIpUOs+C7A8cW4pcR8
aISHFc0x5VyhqA1EfLoe+QTZIhabLjkXjErslnN7Eu6Gdqd7hIWmYTHVyRf6
MGB9rsm5FARl3f3j8ej5OM+aORagyeA/6Xq0XnF5F23fMMnFTDf3tRtD8ip5
T/LahTr90fK8/fW78ZN+66v2v0xnM18nK3NeRxXyJSH6W5OfTJXptE61KG7L
jO8a3nlUGdnTiYZlqoK0aZC0olZMvMQs7tH4Uf/yMK4biTvvGF0C9XRT133A
D8l09nS51fg0q+ebpeO0J1a4Pb0lEOJBnR+e8i00GBn6ktuKAkRYSKNdlUUu
KbgCGKpwFcLM0EhPBWaodvg0Iy/g3nEBpGL0/HAw1KwMZ76v6QEg9/RACmib
AQjQf2mCUKhRDjeti3p71xw5R6uzG4mx+Ears0TMYMVqvURmr1okUaKWk5o1
fa7kQ4FxVcqdiBrNyjZ31vmW1OeWgsWtw5Hrgnpch5T8iC6S8YDs3JrEYA+W
OIc9VLp3klFbT8t1Jq+ZPWPKW9zKE5YwD3ytQ2kj0LZ6bwqOEsx27KuVLocX
kO1KPfRJohADjSf15ibacTxvgUiXH+d1en+deg3wUa7nIl2HqeGsLcRIPDoC
U2vv0gEruU63fMXaSTC1QCgFdnS5QZtY47Pxa6pi6QGYLPNV3mhrcs0U1x7y
EnLhs4VcmIHybGhRsPirdJnPtEkXsiIVDJNXpnVlS7ShYnm2syVQIbHhhdAs
6Ysdx0GYdtOhFk9ouk3BF1tnIUrtuvG41upL5EoEplZ6sJvxzcupNAgQYOnZ
6DqTaHiM3LOZ91dxJpimvMLl1Aqsyb1LaUJ5r+00/8eznw+//+7hPnKLfN5u
EYKgRahr1xcYZSb9pLmELquvBM7toIWZlMJkulmUfC+1SALTY12YqWA2JUmO
W1BFucyICSdSP8xzMT/AnVhiy4e5Y7u8FuxSOpMKhmlUKI9PyvQVgSWVs8zd
gD6U0ovxNwDBYaB017priX/xrVg55RcIvsasAGpFNPIGUcWOIzUHHU9EnVj5
rlmXaAuF7LoRb1eIRUWJbmzAQqAhLrQLU/pgSqmpx7pbLVD3qxX/JhljFNaa
h/epW8BGWqfW7JfN4GaiqbKtnpzfid/dILkn67LBMB2qTxjnQiKo/UsjAE1W
GTqZEZEkeQxhSy+RaM4BYqaqNAv+dVhoS1nQtEuihZh7U67IwU+NklBIgJs+
dB1n7o0Ma4z9DjnKpIWNJiqsNgJV3HUljlkjUDPFosAHrNEwTDAKRAP5bsB4
ES99jwpRORywEa7LpUcLdH8Ke2WeEkJ+fHiDVGbw1c4lxuFYKjFOfJBG1JTg
NZcE4MviRcySrqvEgxC5jpYsvvZuQJ/2fe/Es2iJALyhLhRFpXZ5Xp28wwpJ
OkDmuMS6k5oBytpPIw29uuErdAWLq7wqC198kiom0+dcaorjnpjaSgsGvqs6
W81yLX5Ej4ZCG3wUf+AODa6nHZRZH7+KGF7Om4zrsIPOoG1ppJ67ZuuC5hxq
Nu/qQ4L0qc680h6VJNh54+WI+bgQz0Lk0V+5UiolA1vUxCqvtDqlCHA9sH5y
/BScUrbkWiLIALGxkcShM2xj+UvpOo6USYPjJG0aXEzFqcitcjIuanxE8hIv
mXALeChKDKgZ6qQHG8y9aVTKMTEj3JOF4mCkXA6VBltXuVRmBumsAlXnEskN
YUsdKjTwIpH8SkXiIFa0r08i5gAEcwj8QwpKY7Dygsh1iRedShPV2L5ruu0e
KrfnrkOBpB3UHIcrZp5/SMlic6q+dPBP3nAA59egA7NAQOXazJibg+Ig3bAX
ULuj21ZTGBG2n/aJ1tI3VcrGGPwT0wopGVQSQ+m1IdOBN4ZabeYA8RqFJg9U
aYWFZy3QgQVaNoUefSCaQrdJHHLhcU9rDbGgxqw79KK0y2TcDVqRagYcVkre
TWRAlsJbARxvP9W58y06dba6TXu4oGZjpgs7NHsZu8i+s2ti6mtJ0W6RrUHF
xkcYxeZ6otjI1CMP/WAFy5M3KDebTqOMSTl5V2GslAFB4oZwZaUBPuFD6Yux
BcgVRIbvzwEnDNG1JB3dT16tkbCSSINW7QN6D6NF4SSzAnvUyxUHfOp9dthv
U3q0TwJ0DyxQiL0ql1cUsSZlCbg1EJrU3uXrtYnvZ92mDmWxXGrKh/hWI31v
4AUlIYWbZMSFlIjekg9EQs/pIvOFZaFACS2rkK3BqUkorZULV4pGTHjJLyzS
mUhH04brGy2pMxweZFplUn2PqyXV6Tzzcq+fuCmd6aUyiLp9svfGGypk+mE8
AF0Qts3Jvp0vSYk6cNyINwRUq9GvorOpzaAAoIybLOFYihgsuY3gKKX/Yi83
RlNduJTaCGHFEntNxXu98NyPaaG5HAkTcm7CSohBvvZmVe69Sg+OuLxo76K0
q7Ujg6UWdfG9thkyGjPv1Ww9eOWzghUtzdCjsi9pFCERy2twFZAjkFAe1WjF
2NN2a9K6hE8rqnbEIfVtqqhUHoeTApwgJ7ANIU1kj1RykndGwchOGv+stGUV
LhyvcgvnPVsqAJnqOq1ybpBDfRcRuWWZtvi9yjC+088yNJ9UZUQ7k5MhyIRH
p5jTA2RFmmPFQNdDYfrBpCzEi9H76Ep/NZkDboWai4BtklYxFH2jY/NScxdW
lJFOaxlpaVIrC3usYWKNCluSH2UKrXBhIlMI+Pyc2vnQI6gZkrCM0XskKotm
68wbfZmqIxyGarO07C/w+ej07PgvB4f/IqxEjMsOIRDtDwnGZVbC2Sv/01qy
5HyomVABFcQivdxA8UpqDlHNM7hJcCOPT8MgyPJBRJtQV9PkuFFXD7qwUuFi
UsQZVhNbGPfwwb9itb9qYAgCdeIUwYm65tbqE1SpEW3ml4smCGy9HF0FAbPJ
wB/ppIyq4nzG2B6ITxtv0qgHie+cuIjKoDn3EhEXPsUgviECSxM+Vmn9jqkm
0X7btCgMMDRx1MiG0uVlCRLHYuUrmS5xk9gWrpxhkBwuInLhCQq3kAYJgjMl
CGVicQ2x74/stlyE3nPeKRZoL7iIIpcmpkKIYvbBtk5cpbcHdampAp+sd0Jp
J0Zv54G/l1gFSJOFDkKCFwMhVBQO0oA2VVfw811DAv8OGAaWa6rVyoniNRwH
tgUPhZO4JOS0orBEDfU37hcp8s31l2vfT7KV9ck4mnDT8To4LhAz51jKsbMX
4P6OnU0gQlVUVjISL7m0fuc1LmvkqaZWNJ9RCWrf6osXBzo1XESVm7lZLsp0
z0F6zoVWtSeQ/Ltf8tnMx5N6nYFbq4d2lk7jUvuaflD/tXIF6jVf5VYWOBd2
kHLeeE+rdMS2qXYStXeKcOPKzCBrLN2CgM7Xa0Uy0ya0YvB3iK9UtDuUBzzj
Ess7rckU3xWsMncG60IAOsIp7O2vyM0B0nAK+AME+CxbcYlKUvHCkyg/0i1B
SyR2Ek49OQ+SA7sbIhCYwjzslVM6gBSmbMR6vHtT2jMlxBf/AWMpmPSGixlO
E4+OWQ17c+CBwuTytOws2XtGrZmpBOxMnYyMHHx5vWAlil0o+RVWEe0YXEtf
nRjDdIuGtWlATjIGIvWg8uSmV14wHASDG+Vp5lMgmfStyEujEbmiQGmhGmnX
KW2+XrDCH/RwzOf58OHv0GfxzTffU57dSzTxeP0X9WLydJPuYJRY3tRlmWrb
LKlOqt4JFLedVHKnM+tYwv2Z4c0BYSAnaZ76TtnROXPR04o+bZLvKJ0MTm1q
6h0/92rhCnCGo7ZTe2JUKg9RjkVpuEXLfIFBID29nbCZTV5QIBPiOBkHs2tX
byYj9mBo2w8kh9KvKfLef7MrrwtFGdZIW07Q2L6Plk9uCOSTvigWPm+U5KkJ
pJH4FbdnyCLQ3LfPTxM8ooE0wYuBZVybcUsNkmaE+ZEb1PcYuirzWeJ7heMb
u1p9qwsr9OST2vDc3srbVszqNdQs+j5aMdqt2QOPq2K7FCY8kLSgliktA48I
FmxC6oO7xujtrXS64YrfoUdHaBDZYLcKsW/NYeSsAjQtooYN8EiOZSrSS+Dr
P20a09xY6zNisFsmXftg2IrkRabUZmmAMyuh6aTCIIoRa89FJCWCKn2836Nm
SL09+dZUeU3WxohBMAB4FSEAIFg/vTZZZ76rcBlxHIBLJwNfmLPx/OAqkGAj
VZPu2VQwUqfBboHLdMrl1F3OdcHpjW2CoqbIWQTo0D9QuGDO3V7mPo0R7d1o
UeXUv+5igKaoqBY23bJ4FtMFrjFmrki4jw9eHvS4yaz9FN1/cqp4biQP4Gvk
ajtEvRq5OBalRwNLqFy3zso1J1qwsu79XlN9hzRY9fDqfFSg9UVaYUWI4wWo
vMPkCPMZamQOK/p8nOPnP2by8RhoK77030EBSQ6qd+9K+8pf4dNxip92Xjha
YSGKN022BroyTF5VSF2GSYYfj2v++MeSPtVXnq9yWHtynr9blEV5NUxOQPB6
s0ZCcY6oLfGBIKc38siPwJXRupnNEPd5nPvJQatlrvSE3wBv8A5PlnZKkqf5
6CiI5Z/+pIajvIphOUwOF9QaCyS5XzYw7SqlR6Na9OxAOmEWC2hHxqR8WoKc
NEX9CM175EuEyf+8Kf6VzFSOT1H8LlgPgm2UGPSYXbMzD7Si9XyzBKniUqwu
cEH/F/vKVSp7LgEA

-->
</rfc>