<?xml version="1.0" encoding="UTF-8"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc2629 version 1.2.8 -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
]>

<?rfc toc="yes"?>
<?rfc sortrefs="yes"?>
<?rfc symrefs="yes"?>

<rfc ipr="trust200902" docName="draft-trammell-quic-spin-03" category="info">

  <front>
    <title abbrev="Spin Bits">Adding Explicit Passive Measurability of Two-Way Latency to the QUIC Transport Protocol</title>

    <author initials="B." surname="Trammell" fullname="Brian Trammell" role="editor">
      <organization>ETH Zurich</organization>
      <address>
        <email>ietf@trammell.ch</email>
      </address>
    </author>
    <author initials="P." surname="De Vaere" fullname="Piet De Vaere">
      <organization>ETH Zurich</organization>
      <address>
        <email>piet@devae.re</email>
      </address>
    </author>
    <author initials="R." surname="Even" fullname="Roni Even">
      <organization>Huawei</organization>
      <address>
        <email>roni.even@huawei.com</email>
      </address>
    </author>
    <author initials="G." surname="Fioccola" fullname="Giuseppe Fioccola">
      <organization>Telecom Italia</organization>
      <address>
        <email>giuseppe.fioccola@telecomitalia.it</email>
      </address>
    </author>
    <author initials="T." surname="Fossati" fullname="Thomas Fossati">
      <organization>Nokia</organization>
      <address>
        <email>thomas.fossati@nokia.com</email>
      </address>
    </author>
    <author initials="M." surname="Ihlar" fullname="Marcus Ihlar">
      <organization>Ericsson</organization>
      <address>
        <email>marcus.ihlar@ericsson.com</email>
      </address>
    </author>
    <author initials="A." surname="Morton" fullname="Al Morton">
      <organization>AT&amp;T Labs</organization>
      <address>
        <email>acmorton@att.com</email>
      </address>
    </author>
    <author initials="E." surname="Stephan" fullname="Emile Stephan">
      <organization>Orange</organization>
      <address>
        <email>emile.stephan@orange.com</email>
      </address>
    </author>

    <date year="2018" month="May" day="14"/>

    
    <workgroup>QUIC</workgroup>
    <keyword>Internet-Draft</keyword>

    <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>

  <middle>


<section anchor="introduction" title="Introduction">

<t>The QUIC transport protocol <xref target="QUIC-TRANS"/> is a
UDP-encapsulated protocol integrated with Transport Layer Security (TLS)
<xref target="TLS"/> to encrypt most of its protocol internals, beyond
those handshake packets needed to establish or resume a TLS session, and
information required to reassemble QUIC streams (the packet number) and to
route QUIC packets to the correct machine in a load-balancing situation (the
connection ID). In contrast to TCP, QUIC’s wire image (see
<xref target="WIRE-IMAGE"/>) exposes much less information about
transport protocol state than TCP’s wire image. Specifically, the fact that
sequence and acknowledgement numbers and timestamps (available in TCP) cannot
be seen by on-path observers in QUIC means that passive TCP loss and latency
measurement techniques that rely on this information (e.g. <xref target="CACM-TCP"/>,
<xref target="TMA-QOF"/>) cannot be easily ported to work with QUIC.</t>

<t>This document proposes a solution to this problem by adding a “latency spin
bit” to the QUIC short header. This bit is designed solely for explicit
passive measurability of the protocol. It provides one RTT sample per RTT to
passive observers of QUIC traffic. This document describes the mechanism, how
it can be added to QUIC, and how it can be used by passive measurement
facilities to generate RTT samples. It explores potential corner cases and
shortcomings of the mechanism, and proposes an extention called the Valid Edge
Counter (VEC) to mitigate them. It further details findings on privacy risk
researched by the QUIC RTT Design Team, which was tasked by the IETF QUIC
Working Group to determine the risk/utility tradeoff for the spin bit.</t>

<t>Appendices summarize experimental results to date with an implementation of
the spin bit built atop a recent QUIC implementation, describe use cases for
passive RTT measurement at the resolution provided by the spin bit, explore
alternatives to the spin bit for passive latency measurement of QUIC flows,
and discuss the necessity of “greasing” the spin bit.</t>

<t>The spin bit has low overhead, presents negligible privacy risk, and has clear
utility in providing passive RTT measurability of QUIC that is far superior to
QUIC’s measurability without the spin bit, and equivalent to or better than
TCP passive measurability.</t>

<section anchor="about-this-document" title="About This Document">

<t><xref target="QUIC-SPIN-EXP"/> specifies the addition of the spin bit to the QUIC transport
protocol for experimental purposes. This document provides background for that
specification, documents work done in the development of the spin bit
proposal, and extends it with the VEC signal for loss, reordering, and delay
compensation without relying on the QUIC packet number.</t>

<t>This document is maintained in the GitHub repository
https://github.com/britram/draft-trammell-quic-spin, and the editor’s copy is
available online at https://britram.github.io/draft-trammell-quic-spin.
Current open issues on the document can be seen at
https://github.com/britram/draft-trammell-quic-spin/issues. Comments and
suggestions on this document can be made by filing an issue there, or by
contacting the editor.</t>

</section>
</section>
<section anchor="mechanism" title="The Spin Bit Mechanism">

<t>The latency spin bit enables latency monitoring from observation points on the
network path. Each endpoint, client and server, maintains a spin value, 0 or
1, for each QUIC connection, and sets the spin bit on packets it sends for
that connection to the appropriate value (below). It also maintains the
highest packet number seen from its peer on the connection. The value is then
determined at each endpoint as follows:</t>

<t><list style="symbols">
  <t>The server initializes its spin value to 0. When it receives a packet from
the client, if that packet has a short header and if it increments the
highest packet number seen by the server from the client, it sets the spin
value to the spin bit in the received packet.</t>
  <t>The client initializes its spin value to 0. When it receives a packet from
the server, if the packet has a short header and if it increments the
highest packet number seen by the client from the server, it sets the spin
value to the opposite of the spin bit in the received packet.</t>
</list></t>

<t>This procedure will cause the spin bit to change value in each direction once
per round trip. Observation points can estimate the network latency by
observing these changes in the latency spin bit, as described in <xref target="usage"/>.
See <xref target="illustration"/> for an illustration of this mechanism in action.</t>

<t>The defails of the addition of the spin bit to the QUIC short header are given
in <xref target="QUIC-SPIN-EXP"/>.</t>

</section>
<section anchor="usage" title="Using the Spin Bit for Passive RTT Measurement">

<t>When a QUIC flow is sending at full rate (i.e., neither application nor flow
control limited), the latency spin bit in each direction changes value once
per round-trip time (RTT). An on-path observer can observe the time difference
between edges in the spin bit signal in a single direction to measure one
sample of end-to-end RTT. Note that this measurement, as with passive RTT
measurement for TCP, includes any transport protocol delay (e.g., delayed
sending of acknowledgements) and/or application layer delay (e.g., waiting for
a request to complete). It therefore provides devices on path a good
instantaneous estimate of the RTT as experienced by the application. A simple
linear smoothing or moving minimum filter can be applied to the stream of RTT
information to get a more stable estimate.</t>

<t>An on-path observer that can see traffic in both directions (from client to
server and from server to client) can also use the spin bit to measure
“upstream” and “downstream” component RTT; i.e, the component of the
end-to-end RTT attributable to the paths between the observer and the server
and the observer and the client, respectively. It does this by measuring the
delay between a spin edge observed in the upstream direction and that observed
in the downstream direction, and vice versa.</t>

<section anchor="limitations" title="Limitations and Workarounds">

<t>Application-limited and flow-control-limited senders can have application and
transport layer delay, respectively, that are much greater than network RTT.
Therefore, the spin bit provides network latency information only when the
sender is neither application nor flow control limited. When the sender is
application-limited by periodic application traffic, where that period is
longer than the RTT, measuring the spin bit provides information about the
application period, not the RTT. Simple heuristics based on the observed data
rate per flow or changes in the RTT series can be used to reject bad RTT
samples due to application or flow control limitation.</t>

<t>Since the spin bit logic at each endpoint considers only samples on packets
that advance the largest packet number seen, signal generation itself is
resistant to reordering. However, reordering can cause problems at an observer
by causing spurious edge detection and therefore low RTT estimates, if reordering
occurs across a spin bit flip in the stream. This can
be probabilistically mitigated by the observer also tracking the low-order
bits of the packet number, and rejecting edges that appear out-of-order <xref target="RFC4737"/>.</t>

<t>All of these limitations are addressed by an enhancement to the spin bit, the
Valid Edge Counter, described in detail in <xref target="vec"/>.</t>

</section>
<section anchor="illustration" title="Illustration">

<t>To illustrate the operation of the spin bit, we consider a simplified model of
a single path between client and server as a queue with slots for five
packets, and assume that both client and server sent packets at a constant
rate. If each packet moves one slot in the queue per clock tick, note that
this network has a RTT of 10 ticks.</t>

<t>Initially, during connection establishment, no packets with a spin bit are
in flight, as shown in <xref target="illus0"/>.</t>

<figure title="Initial state, no spin bit between client and server" anchor="illus0"><artwork><![CDATA[
+--------+   -  -  -  -  -   +--------+
|        |     -------->     |        |
| Client |                   | Server |
|        |     <--------     |        |
+--------+   -  -  -  -  -   +--------+
]]></artwork></figure>

<t>Either the server, the client, or both can begin sending packets with short
headers after connection establishment, as shown in <xref target="illus1"/>; here, no spin
edges are yet in transit.</t>

<figure title="Client and server begin sending packets with spin 0" anchor="illus1"><artwork><![CDATA[
+--------+   0  0  -  -  -   +--------+
|        |     -------->     |        |
| Client |                   | Server |
|        |     <--------     |        |
+--------+   -  -  0  0  0   +--------+
]]></artwork></figure>

<t>Once the server’s first 0-marked packet arrives at the client, the client sets
its spin value to 1, and begins sending packets with the spin bit set, as
shown in <xref target="illus2"/>. The spin edge is now in transit toward the server.</t>

<figure title="The bit begins spinning" anchor="illus2"><artwork><![CDATA[
+--------+   1  0  0  0  0   +--------+
|        |     -------->     |        |
| Client |                   | Server |
|        |     <--------     |        |
+--------+   0  0  0  0  0   +--------+
]]></artwork></figure>

<t>Five ticks later, this packet arrives at the server, which takes its spin
value from it and reflects that value back on the next packet it sends, as
shown in <xref target="illus3"/>. The spin edge is now in transit toward the client.</t>

<figure title="Server reflects the spin edge" anchor="illus3"><artwork><![CDATA[
+--------+   1  1  1  1  1   +--------+
|        |     -------->     |        |
| Client |                   | Server |
|        |     <--------     |        |
+--------+   0  0  0  0  1   +--------+
]]></artwork></figure>

<t>Five ticks later, the 1-marked packet arrives at the client, which inverts its
spin value and sends the inverted value on the next packet it sends, as shown
in <xref target="illus4"/>.</t>

<figure title="Client inverts the spin edge" anchor="illus4"><artwork><![CDATA[
      obs. points  X  Y
+--------+   0  1  1  1  1   +--------+
|        |     -------->     |        |
| Client |                   | Server |
|        |     <--------     |        |
+--------+   1  1  1  1  1   +--------+
                      Y
]]></artwork></figure>

<t>Here we can also see how measurement works. An observer watching the signal at
single observation point X in <xref target="illus4"/> will see an edge every 10 ticks, i.e.
once per RTT. An observer watching the signal at a symmetric observation point
Y in <xref target="illus4"/> will see a server-client edge 4 ticks after the client-server
edge, and a client-server edge 6 ticks after the server-client edge, allowing
it to compute component RTT.</t>

<t><xref target="illus5"/> shows how this mechanism works in the presence of reordering. Here,
packet C carries the spin edge, and packet B is reordered on the way to the
client. In this case, the client will begin sending spin 1 after the arrival
of C, and ignore the spin bit flip to 1 on packet B, since B &lt; C; i.e. it does
not increment the highest packet number seen.</t>

<figure title="Handling reordering" anchor="illus5"><artwork><![CDATA[
+--------+   0  0  0  0  0   +--------+
|        |     -------->     |        |
| Client |                   | Server |
|        |     <--------     |        |
+--------+   1  0  1  0  0   +--------+
    PN=      A  C  B  D  E
]]></artwork></figure>

</section>
</section>
<section anchor="vec" title="The Valid Edge Counter">

<t>This mechanism is indented to provide additional information about the validity
of the passively observed spin edges without using information from a
cleartext packet number.</t>

<t>A one-bit spin signal is resistent to reordering during signal generation,
since the spin value is only updated at each endpoint on a packet that
advances the packet counter. However, without using the packet number, a
passive observer can neither detect reordered nor lost edges, and it must use
heuristics to reject delayed edges.</t>

<t>The Valid Edge Counter (VEC) addresses these issues with two additional
bits added to each packet, encoding values from 0 to 3, indicating that
an edge was considered to be valid when send out by the sender, and
providing a possibility to detect invalid edges due to reordering and edge loss.</t>

<section anchor="proposed-short-header-format-including-spin-bit-and-vec" title="Proposed Short Header Format Including Spin Bit and VEC">

<t>As of the current editor’s version of <xref target="QUIC-TRANS"/>, this proposal specifies
using bit 0x04 of the first octet in the short header for the spin bit, and
the bits 0x03 for the valid edge counter. Note that these values are subject
to change as the layout of the first octet is finalized.</t>

<figure title="Short Header Format Spin Bit and VEC" anchor="fig-vec-header"><artwork><![CDATA[
0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+
|0|K|1|1|0|S|VEC|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                Destination Connection ID (0..144)           ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                      Packet Number (8/16/32)                ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                     Protected Payload (*)                   ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

]]></artwork></figure>

<t>S: The Spin bit is set 0 or 1 depending on the stored spin value that is
updated on packet reception as explained in <xref target="mechanism"/>.</t>

<t>VEC: The Valid Edge Counter is set as defined in <xref target="vec-bits"/>. If the spin bit
field does not contain an edge, the VEC is set to 0.</t>

</section>
<section anchor="vec-bits" title="Setting the Valid Edge Counter (VEC)">

<t>The VEC is set by each endpoint as follows; unlike the spin bit, note that
there is no difference between client and server handling of the VEC:</t>

<t><list style="symbols">
  <t>By default, the VEC is set to 0.</t>
  <t>If a packet contains an edge (transition 0-&gt;1 or 1-&gt;0) in the spin signal,
and that edge is delayed (sent more than a configured delay since the edge
was received, defaulting to 1ms), the VEC is set to 1.</t>
  <t>If a packet contains an edge in the spin signal, and that edge is not
delayed, the VEC is set to the value of the VEC that accompanied the last
incoming spin bit transition plus one. This counter holds at 3, instead of
cycling around. In other words, an edge received with a VEC of 0 will be
reflected as an edge with a VEC of 1; with a VEC of 1 as VEC of 2, and a VEC
of 2 or 3 as a VEC of 3.</t>
</list></t>

<t>This mechanism allows observers to recognize spurious edges due to reordering
and delayed edges due to loss, since these packets will have been sent with
VEC 0: they were not edges when they were sent. In addition, it allows senders
to signal that a valid edge was delayed because the sender was
application-limited: these edges are sent with the VEC set to 1 by the sender,
prompting the VEC to count back up over the next RTT.</t>

</section>
<section anchor="use-of-the-vec-by-a-passive-observer" title="Use of the VEC by a passive observer">

<t>The VEC can be used by observers to determine whether an edge in the spin bit
signal is valid or not, as follows:</t>

<t><list style="symbols">
  <t>A packet containing an apparent edge in the spin signal with a VEC of 0 is
not a valid edge, but may be have been caused by reordering or loss, or was
marked as delayed by the sender. It should therefore be ignored.</t>
  <t>A packet containing an apparent edge in the spin signal with a VEC of 1 can
be used as a left edge (i.e., to start measuring an RTT sample), but not as
a right edge (i.e., to take an RTT sample since the last edge).</t>
  <t>A packet containing an apparent edge in the spin signal with a VEC of 2 can
be used as a left edge, but not as a right edge. If the observation point is
symmetric (i.e, it can see both upstream and downstream packets in the
flow), the packet can also be used to take a component RTT sample on the
segment of the path between the observation point and the direction in which
the previous VEC 1 edge was seen.</t>
  <t>A packet containing an apparent edge in the spin signal with a VEC of 3 can
be used as a left edge or right edge, and can be used to compute component
RTT in either direction.</t>
</list></t>

</section>
</section>
<section anchor="privacy-and-security-considerations" title="Privacy and Security Considerations">

<t>The privacy considerations for the latency spin bit are essentially the same
as those for passive RTT measurement in general.</t>

<t>A concern was raised during the discussion of this feature within the QUIC
working group and the QUIC RTT Design Team that high-resolution RTT
information might be usable for geolocation. However, an evaluation based on
RTT samples taken over 13,780 paths in the Internet from RIPE Atlas anchoring
measurements <xref target="TRILAT"/> shows that the magnitude and uncertainty of RTT data
limit the resolution of geolocation information that can be derived from
Internet RTT to national- or continental-scale; i.e., less
resolution than is generally available from free, open IP geolocation
databases.</t>

<t>One reason for the inaccuracy of geolocation from network RTT is that Internet
backbone transmission facilities do not follow the great-circle path between
major nodes. Instead, major geographic features and the efficiency of
connecting adjacent major cities both influence the facility routing. An
evaluation of ~3500 measurements on a mesh of 25 backbone nodes in the
continental United States shows that 85% had RTT to great-circle error of 3ms
or more, making location within US State boundaries ambiguous <xref target="CONUS"/>.</t>

<t>Therefore, in the general case, when an endpoint’s IP address is known, RTT
information provides negligible additional information.</t>

<t>RTT information may be used to infer the occupancy of queues along a path;
indeed, this is part of its utility for performance measurement and
diagnostics. When a link on a given path has excessive buffering (on the order
of hundreds of milliseconds or more), such that the difference in delay
between an empty queue and a full queue dwarfs normal variance and RTT along
the path, RTT variance during the lifetime of a flow can be used to infer the
presence of traffic on the bottleneck link. In practice, however, this is not
a concern for passive measurement of congestion-controlled traffic, since any
observer in a situation to observe RTT passively need not infer the presence
of the traffic, as it can observe it directly.</t>

<t>In addition, since RTT information contains application as well as network
delay, patterns in RTT variance from minimum, and therefore application delay,
can be used to infer or fingerprint application-layer behavior. However, as
with the case above, this is not a concern with passive measurement, since the
packet size and interarrival time sequence, which is also directly observable,
carries more information than RTT variance sequence.</t>

<t>We therefore conclude that the high-resolution, per-flow exposure of RTT for
passive measurement as provided by the spin bit poses negligible marginal risk
to privacy.</t>

<t>As shown in <xref target="mechanism"/>, the spin bit can be implemented separately from the
rest of the mechanisms of the QUIC transport protocol, as it requires no
access to any state other than that observable in the QUIC packet header
itself. We recommend that implementations take advantage of this property, to
reduce the risk that errors in the implementation could leak private
transport protocol state through the spin bit.</t>

<t>Since the spin bit is disconnected from transport mechanics, a QUIC endpoint
implementing the spin bit that has a model of the actual network RTT and a
target RTT to expose can “lie” about its spin bit transitions, by anticipating
or delaying observed transitions, even without coordination with and the
collusion of the other endpoint. This is not the case with TCP, which requires
coordination and collusion to expose false information via its sequence and
acknowledgment numbers and its timestamp option. When passive measurement is
used for purposes where one endpoint might gain a material advantage by
representing a false RTT, e.g. SLA verification or enforcement of
telecommunications regulations, this situation raises a question about the
trustworthiness of spin bit RTT measurements.</t>

<t>This issue must be appreciated by users of spin bit information, but
mitigation is simple, as QUIC implementations designed to lie about RTT
through spin bit modification can easily be detected. A lying server can be
contacted by an honest client under the control of a verifying party, and the
client’s RTT estimate compared with the spin-bit exposed estimate. Though in
the general case, it is impossible to verify explicit path signals with two
complicit endpoints (see <xref target="WIRE-IMAGE"/>), a lying server/client pair may be
subject to dynamic analysis along paths with known RTTs. We consider the ease
of verification of lying in situations where this would be prohibited by
regulation or contract, combined with the consequences of violation of said
regulation or contract, to be a sufficient incentive in the general case not
to do it.</t>

</section>
<section anchor="acknowledgments" title="Acknowledgments">

<t>Many thanks to Christian Huitema, who originally proposed the spin bit as pull
request 609 on <xref target="QUIC-TRANS"/>. Thanks to Tobias Buehler for feedback on the
draft, and for Alexandre Ferrieux for input on the Valid Edge Counter. Special
thanks to the QUIC RTT Design Team for discussions leading especially to the
privacy and security considerations section.</t>

<t>This work is partially supported by the European Commission under Horizon 2020
grant agreement no. 688421 Measurement and Architecture for a Middleboxed
Internet (MAMI), and by the Swiss State Secretariat for Education, Research,
and Innovation under contract no. 15.0268. This support does not imply
endorsement.</t>

</section>


  </middle>

  <back>

    <references title='Normative References'>

<reference anchor="QUIC-SPIN-EXP" >
  <front>
    <title>The QUIC Latency Spin Bit</title>
    <author initials="B." surname="Trammell">
      <organization></organization>
    </author>
    <author initials="M." surname="Kuehlewind">
      <organization></organization>
    </author>
    <date />
  </front>
  <seriesInfo name="Internet-Draft" value="draft-ietf-quic-spin-exp"/>
</reference>


    </references>

    <references title='Informative References'>

<reference anchor="TRILAT" >
  <front>
    <title>On the Suitability of RTT Measurements for Geolocation (https://github.com/britram/trilateration/blob/paper-rev-1/paper.ipynb)</title>
    <author initials="B." surname="Trammell">
      <organization></organization>
    </author>
    <date year="2017" month="August" day="30"/>
  </front>
</reference>
<reference anchor="TOKYO-PING" >
  <front>
    <title>From Paris to Tokyo - On the Suitability of ping to Measure Latency (In Proc. ACM IMC 2014)</title>
    <author initials="C." surname="Pelsser">
      <organization></organization>
    </author>
    <author initials="L." surname="Cittadini">
      <organization></organization>
    </author>
    <author initials="S." surname="Vissicchio">
      <organization></organization>
    </author>
    <author initials="R." surname="Bush">
      <organization></organization>
    </author>
    <date year="2014" month="October" day="23"/>
  </front>
</reference>
<reference anchor="CARRA-RTT" >
  <front>
    <title>Passive Online RTT Estimation for Flow-Aware Routers Using One-Way Traffic (NETWORKING 2010, LNCS 6091, pp. 109–121)</title>
    <author initials="D." surname="Carra">
      <organization></organization>
    </author>
    <author initials="K." surname="Avrachenkov">
      <organization></organization>
    </author>
    <author initials="S." surname="Alouf">
      <organization></organization>
    </author>
    <author initials="A." surname="Blanc">
      <organization></organization>
    </author>
    <author initials="P." surname="Nain">
      <organization></organization>
    </author>
    <author initials="G." surname="Post">
      <organization></organization>
    </author>
    <date year="2010"/>
  </front>
</reference>
<reference anchor="CONUS" >
  <front>
    <title>Comparison of Backbone Node RTT and Great Circle Distances (https://github.com/acmacm/CONUS-RTT)</title>
    <author initials="A." surname="Morton">
      <organization></organization>
    </author>
    <date year="2017" month="September" day="01"/>
  </front>
</reference>
<reference anchor="NOSPIN" >
  <front>
    <title>Description of a tool chain to evaluate Unidirectional Passive RTT measurement (and results) (https://github.com/acmacm/PassiveRTT)</title>
    <author initials="A." surname="Morton">
      <organization></organization>
    </author>
    <date year="2017" month="October" day="05"/>
  </front>
</reference>
<reference anchor="SPINBIT-REPORT" >
  <front>
    <title>Latency Spinbit Implementation Experience (https://devae.re/f/eth/quic/spinbit_report/)</title>
    <author initials="P." surname="De Vaere">
      <organization></organization>
    </author>
    <date year="2017" month="November" day="28"/>
  </front>
</reference>
<reference anchor="MINQ" >
  <front>
    <title>MINQ, a simple Go implementation of QUIC (https://github.com/ekr/minq)</title>
    <author initials="E." surname="Rescorla">
      <organization></organization>
    </author>
    <date year="2017" month="November" day="28"/>
  </front>
</reference>
<reference anchor="MOKUMOKUREN" >
  <front>
    <title>Mokumokuren, a lightweight flow meter using gopacket (https://github.com/britram/mokumokuren)</title>
    <author initials="B." surname="Trammell">
      <organization></organization>
    </author>
    <date year="2017" month="November" day="12"/>
  </front>
</reference>
<reference anchor="IMC-CONGESTION" >
  <front>
    <title>Challenges in Inferring Internet Interdomain Congestion (in Proc. ACM IMC 2014)</title>
    <author initials="M." surname="Luckie">
      <organization></organization>
    </author>
    <author initials="A." surname="Dhamdhere">
      <organization></organization>
    </author>
    <author initials="D." surname="Clark">
      <organization></organization>
    </author>
    <author initials="B." surname="Huffaker">
      <organization></organization>
    </author>
    <author initials="k." surname="claffy">
      <organization></organization>
    </author>
    <date year="2014" month="November"/>
  </front>
</reference>
<reference anchor="IMC-TCPSIG" >
  <front>
    <title>TCP Congestion Signatures (in Proc. ACM IMC 2017)</title>
    <author initials="S." surname="Sundaresan">
      <organization></organization>
    </author>
    <author initials="A." surname="Dhamdhere">
      <organization></organization>
    </author>
    <author initials="M." surname="Allman">
      <organization></organization>
    </author>
    <author initials="." surname="k claffy">
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
<reference anchor="CACM-TCP" >
  <front>
    <title>Passively Measuring TCP Round-Trip Times (in Communications of the ACM)</title>
    <author initials="S." surname="Strowes">
      <organization></organization>
    </author>
    <date year="2013" month="October"/>
  </front>
</reference>
<reference anchor="SHBAIR" >
  <front>
    <title>A multi-level framework to identify HTTPS services (in Proc. IEEE/IFIP NOMS)</title>
    <author initials="W.M." surname="Shbair">
      <organization></organization>
    </author>
    <author initials="T." surname="Cholez">
      <organization></organization>
    </author>
    <author initials="J." surname="Francois">
      <organization></organization>
    </author>
    <author initials="I." surname="Chrisment">
      <organization></organization>
    </author>
    <date year="2016" month="April"/>
  </front>
</reference>
<reference anchor="TMA-QOF" >
  <front>
    <title>Inline Data Integrity Signals for Passive Measurement (in Proc. TMA 2014)</title>
    <author initials="B." surname="Trammell">
      <organization></organization>
    </author>
    <author initials="D." surname="Gugelmann">
      <organization></organization>
    </author>
    <author initials="N." surname="Brownlee">
      <organization></organization>
    </author>
    <date year="2014" month="April"/>
  </front>
</reference>
<reference anchor="WWMM-BLOAT" >
  <front>
    <title>Impact of TCP Congestion Control on Bufferbloat in Cellular Networks (in Proc. IEEE WoWMoM 2013)</title>
    <author initials="S." surname="Alfredsson">
      <organization></organization>
    </author>
    <author initials="G." surname="Giudice">
      <organization></organization>
    </author>
    <author initials="J." surname="Garcia">
      <organization></organization>
    </author>
    <author initials="A." surname="Brunstrom">
      <organization></organization>
    </author>
    <author initials="L." surname="Cicco">
      <organization></organization>
    </author>
    <author initials="S." surname="Mascolo">
      <organization></organization>
    </author>
    <date year="2013" month="June"/>
  </front>
</reference>




<reference anchor="QUIC-TRANS">
<front>
<title>QUIC: A UDP-Based Multiplexed and Secure Transport</title>

<author initials='J' surname='Iyengar' fullname='Jana Iyengar'>
    <organization />
</author>

<author initials='M' surname='Thomson' fullname='Martin Thomson'>
    <organization />
</author>

<date month='April' day='17' year='2018' />

<abstract><t>This document defines the core of the QUIC transport protocol.  This document describes connection establishment, packet format, multiplexing and reliability.  Accompanying documents describe the cryptographic handshake and loss detection.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-quic-transport-11' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-quic-transport-11.txt' />
</reference>



<reference anchor="TLS">
<front>
<title>The Transport Layer Security (TLS) Protocol Version 1.3</title>

<author initials='E' surname='Rescorla' fullname='Eric Rescorla'>
    <organization />
</author>

<date month='March' day='20' year='2018' />

<abstract><t>This document specifies version 1.3 of the Transport Layer Security (TLS) protocol.  TLS allows client/server applications to communicate over the Internet in a way that is designed to prevent eavesdropping, tampering, and message forgery.  This document updates RFCs 4492, 5705, and 6066 and it obsoletes RFCs 5077, 5246, and 6961.  This document also specifies new requirements for TLS 1.2 implementations.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-tls-tls13-28' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-tls-tls13-28.txt' />
</reference>



<reference anchor="WIRE-IMAGE">
<front>
<title>The Wire Image of a Network Protocol</title>

<author initials='B' surname='Trammell' fullname='Brian Trammell'>
    <organization />
</author>

<author initials='M' surname='Kuehlewind' fullname='Mirja Kuehlewind'>
    <organization />
</author>

<date month='April' day='10' year='2018' />

<abstract><t>This document defines the wire image, an abstraction of the information available to an on-path non-participant in a networking protocol.  This abstraction is intended to shed light on the implications on increased encryption has for network functions that use the wire image.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-trammell-wire-image-04' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-trammell-wire-image-04.txt' />
</reference>



<reference  anchor="RFC4737" target='https://www.rfc-editor.org/info/rfc4737'>
<front>
<title>Packet Reordering Metrics</title>
<author initials='A.' surname='Morton' fullname='A. Morton'><organization /></author>
<author initials='L.' surname='Ciavattone' fullname='L. Ciavattone'><organization /></author>
<author initials='G.' surname='Ramachandran' fullname='G. Ramachandran'><organization /></author>
<author initials='S.' surname='Shalunov' fullname='S. Shalunov'><organization /></author>
<author initials='J.' surname='Perser' fullname='J. Perser'><organization /></author>
<date year='2006' month='November' />
<abstract><t>This memo defines metrics to evaluate whether a network has maintained packet order on a packet-by-packet basis.  It provides motivations for the new metrics and discusses the measurement issues, including the context information required for all metrics.  The memo first defines a reordered singleton, and then uses it as the basis for sample metrics to quantify the extent of reordering in several useful dimensions for network characterization or receiver design. Additional metrics quantify the frequency of reordering and the distance between separate occurrences.  We then define a metric oriented toward assessment of reordering effects on TCP.  Several examples of evaluation using the various sample metrics are included.  An appendix gives extended definitions for evaluating order with packet fragmentation.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4737'/>
<seriesInfo name='DOI' value='10.17487/RFC4737'/>
</reference>



<reference  anchor="RFC6049" target='https://www.rfc-editor.org/info/rfc6049'>
<front>
<title>Spatial Composition of Metrics</title>
<author initials='A.' surname='Morton' fullname='A. Morton'><organization /></author>
<author initials='E.' surname='Stephan' fullname='E. Stephan'><organization /></author>
<date year='2011' month='January' />
<abstract><t>This memo utilizes IP performance metrics that are applicable to both complete paths and sub-paths, and it defines relationships to compose a complete path metric from the sub-path metrics with some accuracy with regard to the actual metrics.  This is called &quot;spatial composition&quot; in RFC 2330.  The memo refers to the framework for metric composition, and provides background and motivation for combining metrics to derive others.  The descriptions of several composed metrics and statistics follow.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='6049'/>
<seriesInfo name='DOI' value='10.17487/RFC6049'/>
</reference>



<reference anchor="ALT-MARK">
<front>
<title>Alternate Marking method for passive and hybrid performance monitoring</title>

<author initials='G' surname='Fioccola' fullname='Giuseppe Fioccola'>
    <organization />
</author>

<author initials='A' surname='Capello' fullname='Alessandro Capello'>
    <organization />
</author>

<author initials='M' surname='Cociglio' fullname='Mauro Cociglio'>
    <organization />
</author>

<author initials='L' surname='Castaldelli' fullname='Luca Castaldelli'>
    <organization />
</author>

<author initials='M' surname='Chen' fullname='Mach Chen'>
    <organization />
</author>

<author initials='L' surname='Zheng' fullname='Lianshu Zheng'>
    <organization />
</author>

<author initials='G' surname='Mirsky' fullname='Gregory Mirsky'>
    <organization />
</author>

<author initials='T' surname='Mizrahi' fullname='Tal Mizrahi'>
    <organization />
</author>

<date month='December' day='7' year='2017' />

<abstract><t>This document describes a method to perform packet loss, delay and jitter measurements on live traffic.  This method is based on Alternate Marking (Coloring) technique.  A report is provided in order to explain an example and show the method applicability.  This technology can be applied in various situations as detailed in this document and could be considered passive or hybrid depending on the application.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-ippm-alt-mark-14' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-ippm-alt-mark-14.txt' />
</reference>



<reference  anchor="RFC7799" target='https://www.rfc-editor.org/info/rfc7799'>
<front>
<title>Active and Passive Metrics and Methods (with Hybrid Types In-Between)</title>
<author initials='A.' surname='Morton' fullname='A. Morton'><organization /></author>
<date year='2016' month='May' />
<abstract><t>This memo provides clear definitions for Active and Passive performance assessment.  The construction of Metrics and Methods can be described as either &quot;Active&quot; or &quot;Passive&quot;.  Some methods may use a subset of both Active and Passive attributes, and we refer to these as &quot;Hybrid Methods&quot;.  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-MGT">
<front>
<title>Manageability of the QUIC Transport Protocol</title>

<author initials='M' surname='Kuehlewind' fullname='Mirja Kuehlewind'>
    <organization />
</author>

<author initials='B' surname='Trammell' fullname='Brian Trammell'>
    <organization />
</author>

<date month='October' day='25' year='2017' />

<abstract><t>This document discusses manageability of the QUIC transport protocol, focusing on caveats impacting network operations involving QUIC traffic.  Its intended audience is network operators, as well as content providers that rely on the use of QUIC-aware middleboxes, e.g. for load balancing.</t></abstract>

</front>

<seriesInfo name='Internet-Draft' value='draft-ietf-quic-manageability-01' />
<format type='TXT'
        target='http://www.ietf.org/internet-drafts/draft-ietf-quic-manageability-01.txt' />
</reference>



<reference  anchor="RFC0792" target='https://www.rfc-editor.org/info/rfc792'>
<front>
<title>Internet Control Message Protocol</title>
<author initials='J.' surname='Postel' fullname='J. Postel'><organization /></author>
<date year='1981' month='September' />
</front>
<seriesInfo name='STD' value='5'/>
<seriesInfo name='RFC' value='792'/>
<seriesInfo name='DOI' value='10.17487/RFC0792'/>
</reference>



<reference  anchor="RFC4433" target='https://www.rfc-editor.org/info/rfc4433'>
<front>
<title>Mobile IPv4 Dynamic Home Agent (HA) Assignment</title>
<author initials='M.' surname='Kulkarni' fullname='M. Kulkarni'><organization /></author>
<author initials='A.' surname='Patel' fullname='A. Patel'><organization /></author>
<author initials='K.' surname='Leung' fullname='K. Leung'><organization /></author>
<date year='2006' month='March' />
<abstract><t>Mobile IPv4 (RFC 3344) uses the home agent (HA) to anchor sessions of a roaming mobile node (MN).  This document proposes a messaging mechanism for dynamic home agent assignment and HA redirection.  The goal is to provide a mechanism to assign an optimal HA for a Mobile IP session while allowing any suitable method for HA selection.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='4433'/>
<seriesInfo name='DOI' value='10.17487/RFC4433'/>
</reference>



<reference  anchor="RFC5357" target='https://www.rfc-editor.org/info/rfc5357'>
<front>
<title>A Two-Way Active Measurement Protocol (TWAMP)</title>
<author initials='K.' surname='Hedayat' fullname='K. Hedayat'><organization /></author>
<author initials='R.' surname='Krzanowski' fullname='R. Krzanowski'><organization /></author>
<author initials='A.' surname='Morton' fullname='A. Morton'><organization /></author>
<author initials='K.' surname='Yum' fullname='K. Yum'><organization /></author>
<author initials='J.' surname='Babiarz' fullname='J. Babiarz'><organization /></author>
<date year='2008' month='October' />
<abstract><t>The One-way Active Measurement Protocol (OWAMP), specified in RFC 4656, provides a common protocol for measuring one-way metrics between network devices.  OWAMP can be used bi-directionally to measure one-way metrics in both directions between two network elements.  However, it does not accommodate round-trip or two-way measurements.  This memo specifies a Two-Way Active Measurement Protocol (TWAMP), based on the OWAMP, that adds two-way or round-trip measurement capabilities.  The TWAMP measurement architecture is usually comprised of two hosts with specific roles, and this allows for some protocol simplifications, making it an attractive alternative in some circumstances.  [STANDARDS-TRACK]</t></abstract>
</front>
<seriesInfo name='RFC' value='5357'/>
<seriesInfo name='DOI' value='10.17487/RFC5357'/>
</reference>




    </references>


<section anchor="experiment" title="Experimental Evaluation">

<t>We have evaluated the effectiveness of the spin bit in an emulated network
environment. The spin bit was added to a fork of <xref target="MINQ"/>, using the mechanism
described in <xref target="mechanism"/>, but with the spin bit appearing in a measurement
byte added to the header for passive measurability experiments. Spin bit
measurement support was added to <xref target="MOKUMOKUREN"/>. Full results of these
ongoing experiments are available online in <xref target="SPINBIT-REPORT"/>, but we
summarize our findings here.</t>

<t>First, we confirm that the spin bit works as advertised: it provides one
useful RTT sample per RTT to any passive observer of the flow. This sample
tracks each sender’s local instantaneous estimate of RTT as well as the
expected RTT (i.e., defined by the emulation) fairly well. One surprising
implication of this is that the spin bit provides <spanx style="emph">more</spanx> information than is
available by local estimation to an endpoint which is mostly receiving data
frames and sending mainly ACKs, and as such can also be useful in purely
endpoint-local observations of the RTT evolution during the flow. The spin bit
also works correctly under moderate to heavy packet loss and jitter.</t>

<t>Second, we confirm that the spin bit can be easily implemented without
requiring deep integration into a QUIC implementation. Indeed, it could be
implemented completely independently, as a shim, aside from the requirement
that the spin bit value be integrity-protected along with the rest of the QUIC
header.</t>

<t>Third, we performed experiments focused on the intermittent-sender problem
described in <xref target="limitations"/>. We confirm that the spin bit does not provide
useful RTT samples after the handshake when packets are only sent
intermittently. Simple heuristics can be used to recognize this situation,
however, and to reject these RTT samples. We also find that a simple
sender-side heuristic can be used to determine whether a sample will be
useful. If a sender sends a packet more than a specified delay (e.g. 1ms)
after the last packet received by the client, it knows that any latency spin
observation of that packet will be invalid. If a second “spin valid” bit were
available, the sender could then mark that packet “spin invalid”. Our
experiments show that this simple heuristic and spin validity bit are
successful in marking all packets whose RTT samples should be rejected.</t>

<t>Fourth, we performed experiments focused on the reordering problem described
in <xref target="limitations"/>. We find that while reordering can cause spurious samples
at a naive observer, two simple approaches can be used to reject spurious RTT
samples due to reordering. First, a two-bit spin signal that always advances
in a single direction (e.g. 00 -&gt; 01 -&gt; 10 -&gt; 11) successfully rejects all
reordered samples, including under amounts of reordering that render the
transport itself mostly useless. However, adding a bit is not necessary:
having the observer keep the least significant bits of the packet number, and
rejecting samples from packets that reverse the sequence <xref target="RFC4737"/>, as
suggested in <xref target="limitations"/>, is essentially as successful as a two-bit spin
signal in mitigating the effects of reordering on RTT measurement.</t>

<t>Fifth, we performed parallel active measurements using ping, as described in
<xref target="just-ping-it"/>. In our emulated network, the ICMP packets and the QUIC
packets traverse the same links with the same treatment, and share queues at
each link, which mitigates most of the issues with ping. We find that while
ping works as expected in measuring end-to-end RTT, it does not track the
sender’s estimate of RTT, and as such does not measure the RTT experienced by
the application layer as well as the spin bit does.</t>

<t>In summary, our experiments show that the spin bit is suitable for purpose,
can be implemented with minimal disruption, and that most of the identified
problems can be easily mitigated. See <xref target="SPINBIT-REPORT"/> for more.</t>

</section>
<section anchor="use-cases" title="Use Cases for Passive RTT Measurement">

<t>This section describes use cases for passive RTT measurement. Most of these
are currently achieved with TCP, i.e., the matching of packets based on
sequence and acknowledgment numbers, or timestamps and timestamp echoes, in
order to generate upstream and downstream RTT samples which can be added to
get end-to-end RTT. These use cases could be achieved with QUIC by replacing
sequence/acknowledgement and timestamp analysis with spin bit analysis, as
described in <xref target="usage"/>.</t>

<t>In any case, the measurement methodology follows one of a few basic variants:</t>

<t><list style="symbols">
  <t>The RTT evolution of a flow or a set of flows can be compared to baseline or
expected RTT measurements for flows with the same characteristics in order
to detect or localize latency issues in a specific network.</t>
  <t>The RTT evolution of a single flow can also be examined in detail to
diagnose performance issues with that flow.</t>
  <t>The spin bit can be used to generate a large number of samples of RTT for a
flow aggregate (e.g., all flows between two given networks) without regard
to temporal evolution of the RTT, in order to examine the distribution of
RTTs for a group of flows that should have similar RTT (e.g., because they
should share the same path(s)).</t>
</list></t>

<section anchor="inter-domain-troubleshooting" title="Inter-domain Troubleshooting">

<t>Network access providers are often the first point of contact by their
customers when network problems impact the performance of bandwidth-intensive
and latency-sensitive applications such as video, regardless of whether the
root cause lies within the access provider’s network, the service provider’s
network, on the Internet paths between them, or within the customer’s own
network.</t>

<t>The network performance is currently measured by points of presence
on-the-path which extract spatial delay and loss metrics measurements
<xref target="RFC6049"/> from fields of the transport layer (e.g. TCP) or of application
layer (e.g. RTP). The information is captured in the upper layer because
neither the IP header nor the UDP layer includes fields allowing the
measurement of upstream and downstream delay and loss.</t>

<t>Local network performance problems are detected with monitoring tools which
observe the variation of upstream metrics and downstream metrics.</t>

<t>Inter-domain troubleshooting relies on the same metrics but is not a
pro-active task. It is a recursive process which hones in on the domain and
link responsible for the failure. In practice, inter-domain troubleshooting is
a communication process between the Network Operations Center (NOC) teams of
the networks on the path, because the root cause of a problem is rarely
located on a single network, and requires cooperation and exchange of data
between the NOCs.</t>

<t>One example is the troubleshooting performance degradation resulting from a
change of routing policy on one side of the path which increases the burden on
a defective line card of a device located somewhere on the path. The card’s
misbehavior introduces an abnormal reordered packets only in the traffic
exchanged at line rate.</t>

<t>Other examples are similar in terms of cooperation requirements and the need
to refer to measurements. NOCs need to share the same measurement metrics and
to measure these metrics on the same fields of the packet to enable a minimal
level of technical cooperation.</t>

<t>Experimentation with the spinbit <xref target="experiment"/> has shown ability to replace
the current RTT measurement opportunities based on clear-text transport or
application header fields with a standard approach for measuring passive
upstream and downstream RTT, which are a fundamental metric for this
diagnostic process.</t>

</section>
<section anchor="two-point-intradomain-measurement" title="Two-Point Intradomain Measurement">

<t>The spin bit is also useful as a basic signal for instantaneous measurement of
the treatment of QUIC traffic within a single network. Though the primary
design goal of the spin bit signal is to enable single-observer on-path
measurement of end-to-end RTT, the spin bit can also be used by two
cooperating observers with access to traffic flowing in the same direction as
an alternate marking signal, as described in
<xref target="ALT-MARK"/>. The only difference from alternate
marking with a generated signal is that the size of the alternation will
change with the flight size each RTT. However, these changes do not affect the
applicability of the method that works for each marking batch separately
applied between two measurement points on the same direction. This two point
measurement is an additional feature enabled “for free” by the spin bit
signal.</t>

<t>So, with more than one observer on the same direction, it can be useful to
segment the RTT and deduce the contribution to the RTT of the portion of the
network between two on-path observers. This can be easily performed by
calculating the delay between two or more measurement points on a single
direction by applying <xref target="ALT-MARK"/>. In this way, packet loss, delay and delay
variation can be measured for each segment of the network depending on the
number and distribution of the available on-path observation points. When
these observation points are applied at network borders, the alternate-marking
signal can be used to measure the performance of QUIC traffic within a network
operator’s own domain of responsibility. own portion of the network.</t>

</section>
<section anchor="bufferbloat-mitigation-in-cellular-networks" title="Bufferbloat Mitigation in Cellular Networks">

<t>Cellular networks consist of multiple Radio Access Networks (RAN) where
mobile devices are attached to base stations. It is common that base stations
from different vendors and different generations are deployed in the same
cellular network.</t>

<t>Due to the dynamic nature of RANs, base stations have typically been
provisioned with large buffers to maximize throughput despite rapid changes in
capacity. As a side effect, bufferbloat has become a common issue in such
networks <xref target="WWMM-BLOAT"/>.</t>

<t>An effective way of mitigating bufferbloat without sacrificing too much
throughput is to deploy Active Queue Management (AQM) in bottleneck routers
and base stations. However, due to the variation in deployed base-stations it
is not always possible to enable AQM at the bottlenecks, without massive
infrastructure investments.</t>

<t>An alternative approach is to deploy AQM as a network function in a more
centralized location than the traditional bottleneck nodes. Such an AQM
monitors the RTT progression of flows and drops or marks packets when the
measured latency is indicative of congestion. Such a function also has the
possibility to detect misbehaving flows and reduce the negative impact they
have on the network.</t>

</section>
<section anchor="locating-wifi-problems-in-home-networks" title="Locating WiFi Problems in Home Networks">

<t>Many residential networks use WiFi (802.11) on the last segment, and WiFi
signal strength degradation manifests in high first-hop delay, due to the fact
that the MAC layer will retransmit packets lost at that layer. Measuring the
RTT between endpoints on the customer network and parts of the service
provider’s own infrastructure (which have predictable delay characteristics)
can be used to isolate this cause of performance problems.</t>

<t>The network provider can measure the RTT and packet loss in the home gateway
or an upstream point if there is no access to home gateway. A problem in the
WiFi network is identified by seeing high delay and low packet loss.</t>

<t>These measurements are particularly useful for traffic which is latency
sensitive, such as interactive video applications. However, since high latency
is often correlated with other network-layer issues such as chronic
interconnect congestion <xref target="IMC-CONGESTION"/>, it is useful for general
troubleshooting of network layer issues in an interdomain setting.</t>

<t>In this case, multiple RTT samples per flow are useful less for observing
intraflow behavior, and more for generating sufficient samples for a given
aggregate to make a high-quality measurement.</t>

</section>
<section anchor="internet-measurement-research" title="Internet Measurement Research">

<t>As a large, distributed, engineered system with no centralized control, the
Internet has emergent properties of interest to the research community not
just for purely scientific curiosity, but also to provide applicable guidance
to Internet engineering, Internet protocol design and development, network
operations, and policy development. Latency measurements in particular are
both an active area of research as well as an important tool for certain
measurement studies (see, e.g. <xref target="IMC-TCPSIG"/>, from the most recent Internet
Measurement Conference). While much of this work is currently done with active
measurements, the ability to generate latency samples passively or using a
hybrid measurement approach (i.e., through passive observation of
purpose-generated active measurement traffic; see <xref target="RFC7799"/>) can
drastically increase the efficiency and scalability of these studies. A
latency spin bit would make these techniques applicable to QUIC, as well.</t>

</section>
</section>
<section anchor="other-bad-ideas" title="Alternate RTT Measurement Approaches for Diagnosing QUIC flows">

<t>There are three broad alternatives to explicit signaling for passive RTT
measurement of the RTT experienced by QUIC flows.</t>

<section anchor="handshake" title="Handshake RTT measurement">

<t>The first of these is handshake RTT measurement. As described in
<xref target="QUIC-MGT"/>, the packets of the QUIC handshake
are distinguishable on the wire in such a way that they can be used for one
RTT measurement sample per flow: the delay between the client initial and the
server cleartext packet can be used to measure “upstream” RTT (between the
observer and the server), and the delay between the server cleartext packet
and the next client cleartext packet can be used to measure “downstream” RTT
(between the client and the observer). When RTT measurements are used in large
aggregates (all flows traversing a large link, for example), a methodology
based on handshake RTT could be used to generate sufficient samples for some
purposes without the spin bit.</t>

<t>However, this methodology would rely on the assumption that the difference
between handshake RTT and nominal in-flow RTT is negligible. Specifically, (1)
any additional delay required to compute any cryptographic parameters must be
negligible with respect to network RTT; (2) any additional delay required to
establish state along the path must be negligible with respect to network RTT;
and (3) network treatment of initial packets in a flow must be identical to that
of later packets in the flow. When these assumptions cannot be shown to hold,
spin-bit based RTT measurement is preferable to handshake RTT measurement,
even for applications for which handshake RTT measurement would otherwise be
suitable.</t>

</section>
<section anchor="just-ping-it" title="Parallel active measurement">

<t>The second alternative is parallel active measurement: using ICMP Echo Request
and Reply <xref target="RFC0792"/> <xref target="RFC4433"/>, a dedicated measurement protocol like
TWAMP <xref target="RFC5357"/>, or a separate diagnostic QUIC flow to measure RTT.
Regardless of protocol, the active measurement must be initiated by a client
on the same network as the client of the QUIC flow(s) of interest, or a
network close by in the Internet topology, toward the server. Note that there
is no guarantee that ICMP flows will receive the same network treatment as the
flows under study, both due to differential treatment of ICMP traffic and due
to ECMP routing (see e.g. <xref target="TOKYO-PING"/>). TWAMP and QUIC diagnostic flows,
though both use UDP, have similar issues regarding ECMP. However, in
situations where the entity doing the measurement can guarantee that the
active measurement traffic will traverse the subpaths of interest (e.g.
residential access network measurement under a network architecture and
business model where the network operator owns the CPE), active measurement
can be used to generate RTT samples at the cost of at least two non-productive
packets sent though the network per sample.</t>

</section>
<section anchor="frequency-analysis" title="Frequency Analysis">

<t>The third alternative, proposed during the QUIC RTT design team process,
relies on the inter-packet spacing to convey information about the RTT, and
would therefore allow measurements confined to a single direction of
transmission, as described in <xref target="CARRA-RTT"/>.</t>

<t>We evaluated the applicability of this work to passive RTT measurement in
QUIC, and found it wanting. We assembled a toolchain, as described in
<xref target="NOSPIN"/>, that allowed evaluation of a critical aspect of the <xref target="CARRA-RTT"/>
method: extraction of inter-packet times of real packet streams and the
analysis of frequencies present in the packet stream using the Lomb-Scargle
Periodogram. Several streams were evaluated, as summarized below:</t>

<t><list style="symbols">
  <t>It seems that Carra et al. <xref target="CARRA-RTT"/> took the noisy and low-confidence
results of a statistical process (no RTT-related frequency has been detected
even after using very low alpha confidence) and added heuristics with
sliding-window averaging to infer the fundamental frequency and RTT present
in a unidirectional stream.</t>
  <t>There appear to be several limitations on the streams that are applicable.
Streams with long RTT (~50ms) are more likely to be suitable (having a
better match between packet rate and relatively low frequencies to detect).</t>
  <t>None of the TCP streams analysed (to date) possess a sufficient packet rate
such that the measured fundamental frequency or the multiples of the fundamental
are actually within the detectable range.</t>
  <t>“Ideal” interarrival time streams were simulated with uniform sampling and
period. The Lomb-Scargle Periodogram is surprisingly unable to detect the
fundamental frequency at 100 Hz from the constant 10 ms packet spacing.</t>
  <t>It is not clear if IETF QUIC protocol stream will possess the same
inter-packet arrival time features as TCP streams. Also, Carra et al. note
that their process may not work if the TCP stream encounters a bottleneck,
which would be an essential circumstance for network troubleshooting. Mobile
networks with time-slot service disciplines would likely cause similar
issues as a bottleneck, by imposing their time-slot interval on the spacing of
most packets.</t>
  <t>The Carra et al. <xref target="CARRA-RTT"/> calculation of minimum and maximum frequencies
that can be detected may not be applicable when the inter-arrival times are
(both) the signal being detected and govern the non-uniform sampling
frequency.</t>
</list></t>

</section>
</section>
<section anchor="greasing" title="Greasing">

<t>Routes, congestion levels and therefore latency between two fixed QUIC
endpoints, as well as the shape of individual application flows, fluctuate in
ways that are not totally predictable by an on path observer.  In general,
there is no a-priori pattern for the spin-bit distribution that will always
materialise on a certain flow aggregate, even for a single user.</t>

<t>There has been discussion in the QUIC working group that greasing could be a
strategy to counter an evil access provider that might gate access to its users
on a valid spin bit signal. Let’s accept for a moment this threat model and
consider the practical case of a home gateway that temporarily misbehaves, for
example draining its queues slower than it would normally do while a firmware
download is in progress. It would be ill-considered for an access provider
(even a malicious one) to block, or otherwise interfere with, QUIC flows
originating from behind that CPE solely based on the fact that RTTs are now
different from “usual”.  In fact, providing a numerical assessment of what such
“usual” RTT looks like would necessarily include many paths with different
length, and considerable RTT variability within any fixed path, which is
clearly beyond most ISPs’ reach.  But even assuming it were, there is a simple
cost-benefit counterargument here that the same effect (i.e., gating traffic
from or to a given user based on observed traffic patterns) could be achieved
with much cheaper and effective means (e.g., <xref target="SHBAIR"/>).</t>

<t>So, the potential for ossification appears to be extremely low.  Since it
depends on so much external noise, the spin-bit result variability is
self-greasing to an extent.  In fact, implementing explicit greasing around the
spin-bit might even be harmful as it would potentially erode confidence in the
veracity of the signal.</t>

<t>However, if a greasing algorithm is really needed - for example, if we want
to reuse the bit with different semantics in the future (i.e.: the spin-bit is
not included in the header invariants), one very simple implementation would be
as follows: each server will refuse to spin its bit on a per-flow basis with a
given probability p, instead leaving it stuck to a randomly chosen value, 0 or
1.  The client will then end up leaving its bit stuck to the opposite value, or
could detect this condition and also pick a randomly chosen stuck value.  The
value chosen for p must be small enough to let the spin-bit mechanics work and
large enough not to be seen as an error instead of an intentional protocol
feature.</t>

</section>


  </back>

<!-- ##markdown-source:
H4sIADRH+VoAA819bXMbyZHm9/oVHZq4G3IXgEhJ86ZZe4eiKIk7okiTHGt9
FxeOBlAAetjohrsbpGCONvwf7tNF3P05/5LLJzPrrQHK8q4d4fGMRwM0uqqy
svL1yazhcGi6oivt8+xoOi2qeXbyYVUWk6LLLvK2LW5tdmbzdt3k46Isuk1W
z7Lru3r4Pt9kb/POVpNN1tVZt7DZb346Pc6um7xqV3VDP2/qrp7UpcnH48be
Ps+uVkWVvSi61kzrSZUvachpk8+6Ydfky6Uty+Ef1sVk2NJjw4OnZkpvf24m
9P/zutk8z4pqVhtTrJrnWdes2+7JwcF3B0/MXd3czJt6vXrOEzA3dkMfTZ9n
p1Vnm8p2w5cYxJi2y6vp7/OyrmjgjW3Nqnie/U+a4iBrab6NnbX0p80Sf/hf
xuTrblE3z02WDemfjIZvn2cvRlggT5Y/bGoQzk6Lrm74A1nWi6bIq/TJupk/
z06u32T/Y90UkwV/Zpd5UdLCbDf7wdFgxN9FQ16Mspc2+21uGxuNcEE/Sj//
xAAreviHqb3N7Ygfjt5+OcpObm0VvfmyrorwGb/1zTq/s0X8xoYeGll66IcF
fzea1Mv0xa9H2auintD+59HLXxfr1q5WNv2OB7m2paW3ZKddXhZ5PNhcfzSa
6Y9+6OTZgh8dFV069DUNXbdt3hXRyNeLepm3yRc87Lv6Jh2t4wdHM3nwhwrf
by/vbJSdLso83vSzvJms2+hj2RHajLatq3iIJT85KvDkD1Yf2B7jaJSdEWPW
8e4clfFnPMLR9X+/pqM4buMh8smSH/sh77rtN5+MsqvOrhZ5/OqTZVHa5HN+
/Tkd6LmN323x4KiVB3+o+Xsew1R1sySi3VocG5zG4dXF6bvhyb9fPOcXqKB5
dO2khZMgTjQ84sf45Gf3L4+uTz7yBy0RybYQAPKerHe4nSDBSYqEiP2w4sfD
UcZfQ/33A0d66wHa6h/XdlHau6Kamr/9Cw3WFdHt+vL07dF1QrDzigXs1Zo4
Pojhy+trlc12aauuzeg12WtblzUJzaKusr1F163a548fz4tusR5jjx6PmwKi
5nHXFCWRueEnH4/Levx4la9sMyRRPTyUP4+K1aYa7//1S5YNfHJw+M3w4Nvh
0wOs6vzH350PiRteJyt71dCRv8ibooUWua5vNnU2fGC9K2gnekrX7Jln77SC
spmMsqPjs+z07BgjP/uMaR+PsgtbtsRdu79/O8qOi67LSS0Wu5+4GmW/LUhL
TiaLot79CEnYF+t2kdLl2fDwYPjkKX14fHR5eTSkrUzI4lTveVUWleWdPmm7
Yin7in1+VdZ3w6O7nOhwWa9pI9vspxYEOq8sK2fakNmsmGR7706u359f/kiU
x8gHg+ztu+Or7OuD7w4H2Wo1yg4Pvvvzn/734ZPDz6DYS6JI3jT57m9/pB24
bfLJwlY39e2DFDsq6/Vs97ck8l6UeTXZ/S2pwnd5Ue3+khTORd12KZ3Becfn
7366Sqh7XC9XYDkiJbHVi3xyMyajgFTBVEhNdkL2urF5R9vfTEgovixgPExs
u/NIkaylvx/zONjJz6BjKtrj4/Ld8OCQPnx3DsmZzPqlbSdNsWIOoGnndBTq
MpssiCI4FaTeyzW9KPupKqZFYyd4MC89K2FhyyAtsj2ssrHtuuza/U+tS1/w
X1wY8fvBV/QhlvXi9Hp4eXJxfpkyfawMxmR/ni5XJc9VuJ7sUqgB2oYwW2fU
PJ49tt3iMUT/41Z+/vvGwgx9/BmT7ptY8bQPh0++pQ/PTt/9JpksPhjQJrQF
Zpm9rrMinS5tEau4XZS1N83jZVH94TPmRqr6kja+btRW2jW38x9/wj+XJynD
nNU36yX909gKMy2L+aIjW43+P5uR9CBuILGRrVlqzOsVHQOyKT+lM5bhhf81
pUAzP3xCH5KsHtKxeX1ydX16nk7+eJGXpSXLoqW3kbqf2abBRJ3ilz9MyVaj
r49rPCg6r/hPKgPSym/Xk5vCPsjYLxf5crpwTLJTNpJBd/MgNd6sZ7P85iFl
czPKJiWJ7M2WpjhUSl0fX1ydpuqTPooXf1XMq7yj/Wl30+Gbz6ADCeirdTUl
xdLmD4jav0yLM0j5cvnQC27CUo9peljZLvVXblTXY+OxVNJ01XR4TVIwuy6W
ukqS5st1VYjN0+LcwXag137mYrumvrNtSvWnQ1YdV29eHJ1eJlM7ypYkMYth
Sd5Pmc2IwS08UEjgYkqHv5htsjfX1xdXMFpvi0myFacnJyePT1+dXpB8P7v6
jPm9H4GUV4txXjzANuTsHC/IC/3j7q//jXwhMtAnddHufuAUvyddCMGV0uDr
4cEzGG5nR8PfnL9KiHAqZsnLvMv5HM4bmGjMfaWYoWnsQDWOpwO983OP5V+0
punYvV7PLZjtAW57R0YF7XFV2p54fyYrfP/+7Gz44u15z+gm9ZNPOo53pKeM
/kg8U2b0xxd0pG1D1jPZCmBFmuWaZED2znbgiv7eZ+/r92f1GXPY53HnUTlr
7NQ7kLusHvKpp8RnD+7/a/I2iwcsNthbzbpqaT3LT9jA5HU/OMOznLRTWffP
z8HXxgyHw4z8UtIdk86Y6wUZ+dN6smZmmLI1M6bjwcc1n06LYNk8gg7PSIk/
GtA4ZBVM7ZTZympsyiz7MSl6ZtjVQ/oXLJ1BEpPqfExqpTEp2g7+j1Xd0gxy
M7UdubY0yNKSQVXRceDh8AY3FVKhbXZHG4x/55WfMZlY/kcDM4HWmvIPyR4r
ppmdzm02IblF2opnVVQTMi1by8/MSGa4FeC/SzWBWj5K5BlmpW3JNaLXQ7zQ
WJVwFr2ykvFbXksg54I0Ow2z1hH0jYaXIa/F12oJxmTTJwfZtGgn6xaEIbOj
IhNhkjOVKl4XCSJMIG8gi1k5Y5jIshxEk7Fss7FRVDoLVXeZfmUCtacwwGle
4KABD2U/5GQi2ZZfv+5ko/HFqiluc6IR7K1I6pt4s0bCfMtiOi2tMV9ASjX1
dM1GMVjxQc7I7u//lSMX15dH765+dTp8OQpRBf/4x49ZAb756eUF0W6Sr8iM
pplPw2sKFov82R1ZUlFc9G2+IZpe2cmapebe9VvSBDQq/TsM15Ut/jl8SiPB
uCem2ay6bEkeDohXkLefDNVA8g6ysd0QXxApiK8zIu20XZDFkYlt1xLzWJwk
vJAcmnFZtIuM2BxewJLOYEZTILVFkruueBNCaIL2rLFEg0Z+Dg5u7XJcKh3p
jNt8SeIOm6CWZLVejm2zL3xTmwZeqjztpqNnlLgM7kpG3sYCaoW2kKzVOp8O
xzmcQWj/tuiUdTCEIe6vxMPJTl/u0wmocCBoe4g8iCMcXwx4qC/pyNKciVdy
OoZ7LWkAovT708uT4enZ0esTJrgPP+PRIT/68eM+eJelw3I9WcgxjKmRj2k9
Zgf/EGE7KyeWppFMgDT5yk4K8spJStBBYwkAHUNPd6Yl+rJ3A4IRhar6roT0
YHEpxNRDCNOny5crond+S3Irxz4UPN4+HdaqqjszpsNgLR0Gki3VcJUTC9Zj
mCR4Cz3LG0GntmLpQvNXhQ1dV9atjOSER+w3dnRmq4Kmqj9sYKbVkAJFSqE9
O5qP6Dg5C+/jxwERX80JEFhmSjyb0esLegsIKfzFIo7PDeY56iuPILmzti7X
PBwzU8HHgsixxMJzSWiQPvFyleSDgV5J9EO7wA4ubD61DZkbeAv8T4xoITJp
TjQM1pnoIEeyLV3Eh6CnaW5JfJOY0mBOm7PXSMKR/5OOh3tZ2CTnQHYSyNGJ
7VCgIn+dCoICMDR7oi5ISzQQkuJdIlmhIcIDpCimIFa6Gt5rQ8yJRRWWz+rc
VogXxisQ5QOK1HA6VnUHE5hkfV9zGKYxYvbV3Nvo0aRFsLtdreiV/Cba10ij
/pY16gmdCXMsGjXb++3J8T4rNJrmXE6eXfKsZuuG/txkotvJLC2qqYxeeR1C
hu+NoZlbspEWQgfPFVjlS97/7JqE2yC7WxQkCe5I/Xd5exOePj25fiW5p/fE
tuC418hHsTqDiw01xg9itMdOldG2Tm09m20ZGsTtR6sVaWR2HkgyL/Om+KNN
dakGbpzKlLMCI6EfhEjUYjZeF2WX5V29olNBQheMxItNfxdUONsRsos0T8+l
/WBS3skCrT+OyvKeSMGMUm4xeclqC2Fvrwr8REEUN5g7vPGA7nAgkNEODNhH
zRZ+DykHqDE5jo/mUFe0L4/6dL6Oh1zQxiIsUtPpgywY0BqIMyrWm/OymBcQ
szHn6HGi301K4iDjtrZwywcvbJMskhRywCFG6WjPyHFo19hkcERtVIGlP8JG
k+bpm6YwmEg9k4XFMrqGWh/bDkcEqshArO+UV0SFL77IjqDNRMC8VAFjSFgn
KRyyRFpRXypzYps92bydtrfxGlKFaGDm1brhg98XcV5sjkkdztng1NMCdelU
qTKs/qgV3cH2pNqmU7jq9crxTTxVIzInL53NCV+jhXTkA8VC5+TY2c0YG7px
QIxeN6QsaH/lh2TF5xuySpZ0bls5em6joB/BB3UViJJYSFvajf6MqBZJLWge
XcTronuzHmcIarbINm/MJwJ1D6XVB86I15T1lzDxV8SwrQmGRC3OPfGkG0Ff
O9KRivrBAUbmeE3GHAhNlKD3tmvWerIPboGqedg+oZ38Tyzksbx5xMEf3nXW
Meu5+uitt0j6gy5J6kImzYj7YRvoJDHBhjwPHBtsJFGfzEvkmzyxcFIySAyX
rMzOvPty/4XXZR9FrMQWBx8KW4G6bZBmdYW3YowZkmCi+IV3VnWBNQndjHP5
YMSNshOykuG28TMDkjwFC2DaVzEcBp552DzC8PC7aG0HtDpzOJDzh7cwLwZT
eqBv6dr0OGNCarHTf7V8QqAMWG5Flrge+3yFQ9UUUEs8crY3pvN3t89amdyU
Opoh1rco5gvatvRUCHcwZdjZsfSR8lEYcsT7IYMU/LLKeJU7BQvbmFrw3Gd1
CZXx3Jh/4h8L0eiUFbBbSM+2PF6gG5Z1MMreL8DPHStN1li5m+9MYic8M96M
QVbMnFHNT0BD5ImVyZQu4MdJPEB4GMTIsk+Qw+lSmTMTJxm2S3ePXuaXkOyo
yhRdy1SHGjmaKE/9bWjiuLJQu/jvQxKdsieJH/UvkKResTy1WzrsQRJdq5Mx
sVMEUO6Kkqzd3IVbYh0IgTD37FkJL/rUHHHzxBp4AKLYuqZYjbLzbSkAwWUl
+WvVuBF54CQJCSwRHiqvYLHx0D460xdGHMtyJh6rmPv7dct+78hcWUv/Scta
I3KHmZDmh8yArIw+FZJBWXkxCM9dDqYIwamdsemtxP0sgyHlCaLwvAAYiefY
s0dYIkvWu4vlchyA7oEkSFLLQo1h7s2DGQkJAuHGagHuA20suzt7xciOBkT2
gv0Jkm8u7pRVNBJ+yxoDMeGyIEfETvcHO+m+gwvcTgmXpDwxBE+wu5/tIf06
yo6qLW+e+UP/gwfl56cFAtMIJxgyA+9wUhBL8BzhZ6SmDcdcQMnSRpOLAoVk
Txn1WreiraPsXS0xj85xRBQNRNgUxlRkCCcBBewWB2zo2JfrKft/m12ROTay
JKwwkP+wpPN1xxA3TmMmLYeeHtfpjpUcfUtedZcXrOqh03IOc1kJI8GeK0md
iOZiC4GescEuJcuSnTTWkHDAsnldI2oGuAD9bet1G86ucj0jDFxoFDvkfaRo
nrTVmlo2sMbgGSzrmoiLpTZkPPBhJzVXLNdLGDOdcsJYXyNOP281x+YUMJRE
9NinJ61Ir2vwHJt/brpwQ3dwmyh9GoikrwtNgHvGNLnAOW22x6JYxTI5M/pz
CHn+xr2u1mc4HCTWwS5ZqgxjHq1Xsp5H/KpH0/quch9gu4hNaTxa6PcZndqB
2gvucw07p9xLh53O2Xgty1eiYdFt5o4Oa4pxtISgYoz7z63vnVYmJ3IFqiCf
KbH6mh0oRJmcU6sizAhfumHVfOMUgr7e+wOODtFplYFpe9yzxjlAnkjhaTH2
wL4Zok25+IFvIb40pI7v30eR/vsvyvDtRw5SOG4dqtiT7QUySeWh/wLHFEEt
bPIiv014nW33cN6jE5oSbyCrg07gmCzceufgeqUIcQTdI0d1kDKSP7h9FRqf
CvJ/yM1eyLYbmTh0w6fkf9aT/2obCZvoC0y+g2AIvMHhn9Ipil+sJwtBJ1qK
WpP8IN5UIhmpC1eRMkg5aceat6LXvL54UBmANF3dudeOsisBuCwsvZtEwwTe
OEKGdXIspghD5Yb1JfQXE4WI0zNEOHLIYM4k/MgZhZ+RAxjnfCZV1ZCEFVMt
nuVOkudqdVwViKAnBCjrOYjb9wXo523BPMkb7gYMzo74N/n0NnevLPNmvtsM
HTg9qjFSzJNMZlvOsF3ExAwg62ShLnQwyt7Ud5bN1PAh00XsSY1kt5h70PGN
IZ7BA5wWWdGusJKBjIDrE4sCp69ALVDeifaWrfEwpqknkzWSC5OGI/9RGK4k
A8SZDCxBNEZDs0SKAVPkQBI4A0kNH4f1Si3IRch25IJvHI9CUPAcEJL3VmJC
XRFTwhz4mRgxsjOrFfQiMfKwnsl7kLy7fHX87Jun37B1eEQmnLyVyFnGsq1h
a5Q2RqPfsLGrBXZ6qQG0NMCGoxLCz9mxS+gmRrREmsWcvrUTMVC/yE4jo5ns
4jpY0VZ9EBtb1PGwd9bzqcOaIf42JY1NAhLhXW+1sZp2mmMrKsBJ64wsm7XG
ituyVsTwjISrUZ4XcpOhhnwgU5n1+vbrWo7PaVQAm8HzBI+zDCA9N5PzprtJ
BoumPzCwYymZD+TFpKwnN2S6Tm5Y/MjghpWkk9XiMoKPiUyHB/xwSxQ+FTcV
+mEq8i+KSfg8p9iiVe0nLRHzwOrEEtCXM4bJsdVKnshdJbvJO3bAG/of+Mv8
81D/+meAItK/s/Cl+cXBJeQP7otfR5/hD/TcsdDYfxb99Ut2JVT/pf++f3Ev
7L/vc+cnq7l/nn0hSxTwy68eKVElm8l0CzmEh3jsERkFJ6IjYxc8toUQXmOG
YuE/ByRB7fdkW9gHNOID0qbP2Lh9cFN3bNXhx4/fZxLR06kbkRw4+BsrDAiL
g9MAO7b0gP/+R9/SA/f3J7b00G3p8dYh/tQOYLcPsKPnXqHyj75EIq0hJXgw
XObNjY+MEGUbiQF1yY5HwRkEYsx2IOlQhA5Ppt09m9Rjtbznpr/nT+h4Zj6j
wwoR0gOOvd9sGu8ub2L7fff2H0a07ZH3H2L7Dx6eX2/7n7jtB2Xk+AqdiUgV
cmK0xa/glrM4ZYOYzyyCXDs31h1ryYZ2+U0UHTSyqRq1VdU9K+nYqs6W75HO
cfZjZT94g8pFl3du79O/cnuF6R7c3vjvf+jt7c2vt71P3fbqgBG5I0o9tMk2
O/y8UyybXVQ0BGcBWhOdYZEocBHxE3mI3ugiWp/cZpHcJmzzs0jJCm3IgBy5
WGj271n2uy1a/UPv5Sd4bcdoGdbX2+NnPQnutmFri9/AVYTJ6CIpiNEsGOkf
wm2MS5VIorPM7/JusvCOozgyyLCKYbmVmKJNSPZLYuAYK9eDCadm4220AUIx
I4PYpkO8fM74MM42y6XtGnLftiZhfvfgJFREDVXt8IyeKeuLLRFYe6g+FR5S
4zf9Rn7+9dbPt8egnyO1BH+q8OFDYN6SuNQIeXWe9FdIqNPuKGQzjaQLeljN
ZMEhTDiCmLiPMHDUdM+OadubxuXmPV8otEaeeQGRqW8ILvxd7kq4jQpN4Ok6
cfNam+hwpnJqN/BQhxFpWIbkpaHZKuKItrRuem45u5ZQ/8Hlzl7Aj8ZCX2T/
kh1zCG8EcYGImanqKDPE73o4LfQpo+4fV6sfOmm2PT88ffHuV/Kzo4x2m2iU
vcyyk760+MpJizdEec5xB5aBkJAc9rYvm91/AZ9VE1xRTgdsiMoGidNoOCmG
P+8MLAn8ueg2xrv1rqbDh4w8k7YeLSFhjfiNbEzkhhE2XaRFPHjiCG7lkC3D
COPMjI6wi+2HXZyXuBWxGZg2jR75xDJHiNarKcc1tiJJWLabFbutGjNq43CG
QsCjmE+65F2Rjy1QIEt2F4eUaE90nCuBp4g0UleeqLJctxjEmiiEFwJumkeR
32jabgdzCM7OhUxaDakovkNs9Ls6YgqJ6HjwYRQKGADMXLPkYPq2ssMHeOwp
kkBTDvQxSUBLVSmA3blQiLxz7CD2HKuFNEIsKOTIEXYVFHMAY9E+1URSxVIp
QG/CKtWj9X3QMWIZBgdhGoD/SFTnQtCK0+yKE5ZvJGH5ivmW5CdSWfilT0ri
FURE4lcf6ZooVsaDcRCJ1ziQJjsZhf7xo7PIFa0UgFhGuAfcf/Dh4Jl7s7ho
9aSzPtaS5FV3FDcwbJxdhBaveuqf2a5jSPN9YATdSXjX7XoMxjIhAZ63Gj3d
YH92zZDBmYw0mHrJbQ52SNjDHZ892fHZU/r1IX3zlBT/V6S9v8m+zb7L/orP
SDD3/md+Ofjlx18O6X8Hv1z9Qjv5y/Yzf+3/zJYWeYkYbZW7OqMAcs/2Dkaj
w2fP9qOHR6PR32MO8teFCKN3olT3vn18+PXjp0/2+4/9PeeADjJEADpjF/kG
BQHZ3j9tTeBvNodIkc6K+ZCU4VBPi3Oxdhz0/vGGhr16HmBiiiNviZKAXxGz
Te3KpaxdXL1unDLUoIgAQo3TOMFAAhxFKsAlg1x6jOD9fUCgwYOiuTx/SNPr
hBgDMgsvwIpx/OFon/ZwkiRryqlkLmGHMUAOmAFnZHaKlNRXMz6IxeSV7TyO
7kG9wqaHjK0aKLyK5PlDIK7vs3VVFje2J8ri+DE8Ig4TRIiIT0TJF85mUikF
KhozzF5sGMuyLrsHljoExfKg7B0AT7XXngYosHMHw18fMisMf32wn+AxxCIZ
kLHnU7kuzuHU9B4H3pdiTcPNw1jErmuwkGSPgxGDH9PLoDodjmng1qG9NA6X
7f6uJR3+xSXtmPj2tFGJkrnJ7xqn8/i9QHFN70zgNxFDK/i/zLm5Ay2Oiwgi
dEAg7YrsX1iDLkmlTLaoyymHNNi+IJOQJEmNDhSTzURQoJziZrenZtsKHaTY
gpKVeBSYJg0wSZrvgXOH6FUaeIF9GGiUPn74ff8DPKt/fuK8T9gIGX8CJnkq
iRt96Oloyzxnn7ONykbYcJnU8wo1A0l+cIdhYzx42faMH8E5e15qbRSRpTVz
Dn9sxfAStDRETnaABkp2k93h4EFSqHmv2XD9onVOpjMYGainS1GoAAwIV6/I
/BAbInd5OBJjG8HvJNlOX+/Ktj/XlYRUgJ+85z3H/z07EjbkchUkGbi0FgaT
cOZ6xYUDIdglvv4XAKglzI1kY9Y37IPU61XlJPsaqkmInoJF2HEYIa6DEyRE
I06izRikANghOZLp6VZENJEub3zoZPugbx0DLi7HbsebNMjGaxT1Ac8S8Qtv
Fq8tsq89sL6WzcsyDUvG+xxvCANpyKRdl3GimwaSUMN09Ddb3SHnujO/KXwe
SzvT3ys4EMzakYMaoTBoqFAotS/UYBpheXnWcCOO3jsQTk9/GIlzSED+wf7f
bnVPPrm6eNLJlL2BsB0cZF4Igbs9hmEVATPG+T+PXmL5E+BJHmcu4JuMkR6q
oNxyXXAzAo8I2dJAm6Nf7V7V2nlcApLky3cvxSG5AsSK5sWhcMU2rxp7y+IV
1DwMoklCUH+rPXr6aQ5EAa/fGNEiPWzNViCSXgYKIfqisQS3QhJZBr6tFDnh
Xb5Q+Vi9b4FQiMRy1VCT5DvvOm7hXyFzEUCoJGMvC8+X1rCPiKLluPCrX2VG
L5FoTclhnwkiyk0l9k1eYLHTAIDScrAYqDyz3ByFyVuEchyuZ+cmOFy253Z9
VxGgqCLEHYdRrVsfV7nk7eANYEwh1jQPfdmiGBDkd6iKd8AqExVYMm9XolsO
nw6++fZAsYm6AN8Ph6Mol6cXJ9lRV7INMllweUkMtm3JzJf+cj747Lx4krhk
M3TrqSR01qAteDb0mmOEF6tSfj4iAD0QrS8J33m86Bj4pIatKK4O8BOXAthM
nN68HDJsjM5LUXF12LCd5KWVWPCA67BNNLJ0RmgdXxBLhUImpsissSjrQTXS
6UU8S/QXzUFxxHPOK8s17dpcTfJYOVBR4O7e8vi9Ed5QSk/yzu+FGbuWYmyb
Lgthw6iadlqzVBVdzMMxmHE4kX5jsWwyy/xnVt9TrrYV8xVFPj8LV82bfEUi
yTG379OQWQAICz5/ZOw6+AQk0PTnnCs/5R0TmRLLZdq5UorQOUYjE94Ajd5x
xuGoMmkXh/94+tXBQZZwGIdDlxatBUi/fJV5YvASnGiPdhgdy2A4XwFr0sZs
+e1X/40sh6ljkYRGtmlo8hCPy9YwJBpoj2XOJ9nvlR71n67k7bRK7m2EBefL
MflNkN7399y7jf3m6wAd1ROmrKW5ELZkGS0m7uiXLfhKA6PgBGDQyZ7ty4QI
euprSXfH0GkSIpwjgSJGlJPnBbphic4iFiUfSXiU0VS0LqBD2cbsFt8bxO7F
9Sp4eisYKdpBwtWrssy1DY+HvU8qe6upmRYkGmqOHCuwFd3EqhvZaq7PEJZd
cFSCS29h7nFzHGzHngOLMtiPRl/QLqCvDWayJH+ChDcamrSZbiSp/BYQXy+c
Iu+dgXYot/QwadoNss03CicTN4rLN+SD6V3ezOCL0vJKMlDRnFfbLDD8G/Qy
ziTgnQsPRQqlLGaWayu4RY1AUFM96/fFxBk7B5JXGtA560piKfIZQEN2g1bo
kFNMLBfv21uPwFAPOveqLtaOvXLoiW9Q5MDXXDbvcMRiRuaVqxXimjfGFLrG
Giga1jISkCDka9A1JJPsm+M7tz6X3PHD5K2z9dy7kL5j66LcMFgv8vlkTn1m
D5GGGCIeeu+o5DWKEKdNg9RlwZJsHYtprZDwha/qKMSvlveYnXvJ8EhgrcnQ
qbos8SkZpj625NkUdZzXIfvee5SQGciJ3dpkR7Owo0lpTFI34w1/l+Ft4dFz
Ugd6RrOsUu7jeod4pEYrNrKjvDNuSepgpZIn5ihST1f3aOjeSzv33kb0w+xR
qxMOaM8mGkCgDPmQcB8VLiESMyLuI5BImvbBpgGZ9IWIRCe5h3OkDKSDA+cl
2RIdcX4lwg5FUdFeMYBuuO98wFUKJB5JTaDTh1YSwtjwPoN/mU/hPNBFyB0E
7ZmDTTdkTnAvp5rrm6RNjESbFMfvKzdcPxc/gCua5NCzEWA5SWIOTHEBtIbd
0i4OrfpFyEZ26H/j7GCkkci4Q0FFTeubriehP4XG76BcvY3ZayoxYa+7tPmN
UL2zn+qDQ7bDPEXw7YbpI8hJJruYKWokRpRV0k8QlROiOA1s/PS2ah/EWmd/
yQGm+QGStuuol5br+ZqbDgh/b5JKByBmlEdlYR9pdttDGNPoI9ovwWUiQV6s
OIMJs4SlC4c4XNY7+QV6qPtM8KQmBemyP9rRY6rWElL7EURcGMeRQOOdKly8
4JHGUyitE6nguNEkA7HD6N8flj0jCZLKh9sil8VHnYpMqLrbalSEZ32zIrLB
xflhA2KXAEDGo9VGb64lhNa/wHz0CQBxr+acf8hQz9AAqRzYfLwhptbeHZL0
laVwlQw3Jbp6e4Rcq28fATlvsdCJU6dGW8zHnSUbO0eXL9k4PkhBebL/qRD7
tldiw7cVEKPBEoUEoC307NNzcVsX4JWmBJy6l4o+OumFK6sgKjXpa6Jd4piN
0TIM9sZarSRkobSj20vU5giB38Lq3GHCuvPrR6JzFMjGpcnSu2nsyk9Q/HSU
Sc+LCLUwtq6rgi+4WNCu0vo0C7PmyC3zruuvCDuLt2kjiGAWWf5I8M/I/I4r
WzjEkTcuUu+EAaNDhK2nocARdwJgbUVltu18kUhEKMYLSGGgzMU3gBKbt9Wu
lw4EwV1A5HvHsS13HiNlFBqPffy4zz15IzI9VkKs8qJRi99oMp2Dv5sqX6KQ
iUbbtIWz8yUYwIOz5wFytKwbfOEIO4O0KBhrKdfPdAIceVJWbn3JWYFeKhD1
UuizKMZasmbCSXDOOgzYAag/5nxiMIDohSotmGPJVir94G1eTB98lyA8yEBd
qx/L6C8c6Vu7yzVjSxl0Itut48rwo0QytcaccWExqZEbVsPc97TDTR1v1rSy
ZQ45ic45BZsWaEjmMB6JVoGhQt6FcZXCXx98B+M+RWyAu9xA1/W4oB+94Kb/
Ar6YkU0dwaANNzoR5sbXR6X9kMNFyl6h77Fdf+CPi2q17pwjsZ1N1f5yeWnC
Ih+MZOF9IUbWQp9zVpoLLjU6V6szE6KBrYsG9iJ+rQ11/4X24FFvU97Vrlfa
3k1tu5M1rJBc+vdqhERkwBvagT/Sfz05eHJg5g3q5nJy/bURXj3Kvv7222dP
DpOyfsztqJksCoggGJvcsCA74waQ4/qDnYaA097Z0dnpvlYdyGSu7mgGGiK4
spPGdrCApTb9hOwjlayX2ilMGk6dVlWt8WKZuGNenuThV6ODJ19/q6pZlx8y
6BDBG1Qik53FS9CWlWAKMO9J3CDpJMRc7r8IrZM+slXOqRXX/d2HfqRo1umb
1NJSl1lbVjp/yla3RVNXPJcAtMcPEGD1UK4cRLkRiBKaoMOuDhA2byGbXnuJ
xA5HVmG7sEMK+lQe5UkjuvGmi1rZsb8RgEy7+/AFMrUjj8VIGg+4PUmWR4sK
7dRxjF9xHwhtt+aKCQ2J3ppPSxhFigr7bZR48WnTe08ByHfX3a1eN6FDHQTw
CJD9pvVFgLOiWQZ3K+wNA4V5BUCFIwr+PCvSloMwq2brcnfnQfZGtoCGDqVF
DpzjYP6h4QLOViAZkor7suVwW5k93PZAWx44Dx5CBYRjWwDfaQLMoVH0UAqH
EtPvkwFXNKjKxgVJuOGC9g4uectg62VUGzzzbvY2qTxJfg/P9/fbrm/SBosm
Icuy4eINplYwRL2vjbas5UZhAgwxRaicm4O3vjyCGzaQ0UoPHh3/6EstJdDV
y2pht2jWZAVbkRI84FAmFCWq/OFmI+jWRcWjqJXbwSg5zOMI32jrVaBbWYLB
S5K61Bon7HbjXE/fEvTnAuEWuHAcsfsL3Kk+ttqIsautPo8Rn4RpZu3Kt82V
NAKLmx0WK4JmEtYsOnVHyViKX+9ad2DUSiBX9AVqRLXxUIGYEDRY6Bmk7hEL
nO2laOmS1SmSiBmuPD5NbDEv0uKYAWeYtLcoa8dGiKYBVxikkQyZ1ZN1VF3P
kZ4lSM4FCbxHWhbeF7Bxc4aPzgB8YFu8FtIjsS0g4lKH0Ef4Tlw3rfplvwyq
HQSLZ4o+F9ttA7YK/h1IJXWlBmYRsmNxawDBbiS9R2mRzMwQnJmiRLRrihBr
yDvsJ9Gfww5AhROQDtkjlBkJFkp3QIqdPDQqRmM5YO40bjHDKCsTCMqJ/AjR
x0mxpJEVMzasV1frTjI66WEbJ6vrtNuYztxhmv3UcVy1szp/8Uj0B+5w8FJP
Q2RWzRlFV1SMxkgGkffoEI9IJq8bE/NxKzUtriFQ2+MGEYp+KtDXrgabxCHi
ZCoBMTD78LQmD0DiRHHMqwoEGVvlFYYRv6rRAPbzz1oER3E9hP0RMw8cscB4
pAvK5B2hj4MHYel0DfNplccKd8D4eSUTd9DDNUoPdcnwb9zRKiMuEFIDIsfL
tyokhLHKu3zTui4XrSl29oESLj44yIa/zg4O8f+H/OfDw/0s7BdrwJ+5+jBn
98gVJugMXYcnUEfUTb6E49KmdU2ZtpV28YAouKgtNVTdElGQDo5D767hswYU
IeKkFWzebJ4bhOpVLXpD5wZahw+lxakEbdhBBq7rk00pTGhK4XaANYlvbi6r
AHbLYdM0anZ/73tUSKWrtK3cKcgHWEaMmBCDwZ0QVmbx5prQz8uFgFwTS/YJ
+rQW9EJsa7PdOds6OAiMl6UtucFbGrhr1f5fSTvUtLOcub//ed12Q3w5LDrG
Flds7fYdEJE9p8dnF0HFRFAM4wnb5BFRycTiPFpcKY7PgCfqtD8AZM0C6spl
SDvD9it+52Kjrm9J63vss/6NClxWfKS2D73he+m8He4NW2yBB4P1r6eIlTCb
1Mzp3qDuGc+preh/6HqzeQMwaSnGQa3t1mepHZ7aBJKgE6eETCXepQeEehq5
b/mmPoW6aOzWp9T6Zp8k5YhJp0XbrFehGxW/OiG/3KhD6tT4ZjipSenbzZDF
wSG2vqvFM4KG1maBNjt23aw/2SPQDrnrtauH0/hG1HU9aYz9EGQJt6H55ZDb
CCbUqh+c5cmisB5WLD3wBAnIcBwtisXNh8r6HiD0wF0BcQSesZTRVQHJzQEZ
eeO1SGQjnXPi/u4PofNilSunptdk3iB50u8NeM12WyCXs9d7y2czn1GhqzLH
nQ9+kY/7lyGkS/EB0dC4gm0J/ZhF7EO9LjkfXW2iOtc4QLAkm7Ce1mU93zjY
LGciBABg77AfZMtItrQTSO31ljMW4AIckgLAmD7ixuWOfj5qjaAnTYUjB3yj
cOImJzJ3pn2w+oJvQpIOUXZndheVwi6yqN6N8bYTrrgKPdBE1hWRGTtxsnn0
iaWpteABEc6N1Qtc4s5IHa4JUjSJTSAnSSUhxAD7rW7Uvj/pzCHPsbn05nIl
wBxb1n5ePumc5YonzfL5vLF8WYB2gIR1KbT0gFCyxgTYohRo96OO3vO8mQo9
O7sky4Qvt4mIogJ54IkvabXc3wRAkk96DsoPBI/ZatBSYIieR5gcauFyrI+s
xAKXTHHkRBYQYeBxqZo+LUrPcwZSBXvt/r52pYLDNtQL9K5pSHSnXtQ1Jy6N
XmCVadJa/cRGvT7yZMRmlio+LYOdZZrhUV+maAwZ2F29xO/YdfSdrJ0wL+SO
LbawIm6gV43pkN8V024x5AugIFxNdCUJnGEkUdNOgqogSbVhtvVAt6rUKKhz
8jitX6OMiYlWFsp5mlXorfnLNrVQ9F636Hvjv697oMytNpJLgbiHwRyFaBQ0
wgjn7XoROv2mJyXSICoRpI+gNg2fReicakhjSAdPEdj2g0SoW2Soc9dTlQmL
CI+AtpMGrq2RpmpfHzz7DuqUQZWoBvO2cb91o3gLfBmNIPSiHTLxI5fXF/sS
m4pDcdx2YNXxsgrX7BLxSoe44V0zrgya6X3h4sGVojd/enmhz/uusjpp16SB
uaCHoXpI8aVUos15y4G4XdsTmvY1ISOqZk/o+I6rW1WHmrh3L6sSJ0X8bNyu
9GalH7MWi85yl55lXEBQhCb8LAncCxGFdogkWFhDNe5xvwlXWBSt3BOybti6
4bbXrVP+nL9lEefajC6lJnBqGB2I3p3IEjm7kAUGqQEieA/1Vnxq/ojKZkkq
3s8jhu87iXW+8kmpYys1hu/OcUcMX1ClF6I4oe6mLsi/uJIokg+s5VxIAH0F
co7KMsZUwgdeCXpBIK2PFPwzqUOLP7lmQiuj6c0cKU7WcX7sEMnQGIgHSGv7
LcLEbDdF1HTqLupqtcDP9U7woymQl2QFHUi+tolb8iFIFpdFuHY/clOdjD5e
kyLD87QbU6v5pYwtlQl6LjGVpCFy5kjTkmRzAA7/djnx+A1JzmXROggduIDv
aJMbgPKxAjZDHMGZwRx1VNGgyEPjaMr9GXhWjTQxPhekzAcX1myCAsUrbCNg
rniPokBw8EGBgjQcX5mJPk9gG7xtgpREKVCqeHs2pTvLJmqvLcFN92V8VlNZ
69pM1HqfBPJk4k0ZuZEUz/ENXRO+hckviigRpRQDwsh5crCu7u+j3OJHBk4J
ki4PDRPEPLdGdJf0L+jXadScV1tXCix37WK5hceQe3gElYGe25GP6tJ6smjX
o7HLAdqe+sCYOHXeuVbny3zCb3FuPufoshlA4Jpb1TolEVAkawLY2YkZsZeu
7+rhBRs6uEswV2EVuY2964QcBFND6xypEX8huk0mTZml2sgIe2sYo38dmLMh
+qLHo1qYW2gvyZM3gu/J5nXuIXBbDeDbiKnklcOQDZQu4H11uXXnZt9UT+q0
YBQyPEZ5MmDiGrfTHiHpFjlTXV1EByJqeN0aHkTukbI+WOzLkbdCUf969PZ6
eHZ0+WO4abFYrZZDegc3QnM95ljCRJhzEaRuIOMGUv50bsg0JqYPk3B2V3GH
7sorPn1l6SSzP4nSfVR+wyEq9qDfBFB4fLmDFpHkHNhjc0ZPUnoTnXixGrBi
pecvgHHrGCPWEKFfjWshH7tD8eYnF9T0tkXzxfiJ4DNTjF+W3p3qarKE86bZ
I/ZrG2sf9UHAGtpE6rEeOIvKZV7YLQ/sumNavggxZFi5Lf3ct5NyMNBpQMQy
osP5aYo80A60fL5IggWXz1/UE1Nt6/LF0EA5vvnQx1lx+1BeTjjz7SrZkqbw
/FIJaT2wJU4kmHBSALijLWWw1/29OwQajBWkl2DpfbJ3EBm9Um4RbFN3lZJz
Pjw/9UosHT36LS+Muul6a1vsCcsxiUAUMfXia1EER2rkROy4Oyl3KH+xCPzW
sC3RDpLjaId6EFz0vBdmiOOsPTd1t0h2kBqRdLU6d85A5gi8msZyBxt/mzJT
FHkh5RPfM30WQTt3XDltjP/IW7kM1pI4JN9eDqPyMp8WdXYkIjfcV3159G5f
EIBmWY+R03KXXDBFuy7nixI1UMUo78JdQswtF5ZLV/WXPGBYhDqR2mW3An1S
HnCfhmZczoFalfUmOIJcKzrprY9I9DLc6ONwkpXIFcR/jt4Bmx3PRgIp3Wal
XctRmS5tooBDcw6bxJSkjInV0jL/QKbjHz2sHWg80jArXCDU5KtiGvW7p2NM
x4l394ghBzCyJQkz0HfKfsLMGgNrrCXMy9rdSYZc3Zo8RL+P9/fhrnJpcF4F
rBf38eN6Kp/3iYdx0as2nzAEVN1QvkrBROsptNUACE/swW/+DddRneVVrhHY
vaPfnO3rtR+umokv+G1ajtL0eMMrsGnYpyBOOD6o+4wfDv0ukdB37qnkKWM0
rtoqNBPXrTRMpg3t1ZZqHBbVDNcDN2vBB6KJZts5zPVRMCM0pCR2ZkoMjNSG
4w0z0peFyyUqBgDVRjpZhSJEf08D7Ean+CLKaW3nFceuKoxjNFbQeo1DE5o3
1tczS2iQD09Tr6RuLgeLhCS5XmDhpXSI8/oma7c2rRxzcwgrYwtuoZit3b3T
vAsHh9NPKyorqRBrZdSuj/ZtDB9A3xw2EnVva23/9r54VaAFlEYKK+KipY3E
HKN50eNvKsnRIO7gtPOv9749eDJCkrp292AhxStKSnx0POakPryFao5rbCJn
miR9MSPq8AxQ5CQxz+GiXrk7SiKmxm3OATt0dnSsQSjGZDRWy4FD53xu15dr
oQo/OlKXwkWosPf+BiePJ6/T4KHnSOn12YS8tQYrTRTMlNKo5DDsaUAn5xiP
JeaQbJ6YAL2Mwv5WqVwLTLfieHzIZFdQrB/W1Emxvu0nM6O2pRyaVA2wABMg
dk/ywMilZN7t0wYUvHLf9yk4FfFPUaPgQzpyUJhj3NRwSHzyEeZTay22hDkg
DgfexZOU9bW97DgUGQOhYdU1AlyA+ckupzMdHJTQXbnt49sDH9OWsj+RyBzf
TkLfkZSVykGeqnsdmlhy1J4Rf2W4l14KiXTZWtSoyRg37oSUQ1VMBOKlBVqR
0CCtdHp2PDw+f/f65Or69PwdoxZYkUQLVai+6QexiFPCZTzR4AJS5iHVbGql
k5gk7aLutMGiidKT/g4aEF+nwWkAzMXflocl0QbgOReFErHA1nWYtqA8QiGC
B3xIvoYvqAtJJTYUuCEJF0X+YZ2zxEwxFi4DgyxBnHt2EHOuY9S01iBYycA8
kpAqKivImk3bEQfzThKvx9pHq2jk6hI/FFdok8SYW71GHZhhSZMxrfXmM8FD
yUxc7JWWgBILoDlcmh/wypZJwslClAbgNsWN4JvlwpeoZax6p7RV83UxhWRA
CMzPza2LYSQhhRKuf+Mghjgk/kbfQc/YluosFh4S44yeHWVvt6+SZlYLx5Mx
aNwLIa8c1oU+ytVqF4pEGAq5c5tMd7neR6831t4ZKdy8W09BatQCaR2anJzr
44ur09c4NR6KyiAIvZ/bd5WI2eS4rjQ2sQ9PCHY634nlANBOiIVUEd+IrGEW
rCppC6L+UNDtPrPqUYfuYIU2vo3ifnKz2IwbMn6Tal5nQrnmRlpIliLNXa7D
KGZkGEIp2zgjJyy/z6SaClmpb7757ruPH/nyONTQ+GuIXOzaQZ9cJwzGAtEj
aYyEjVXeHdILZqtrjVRB8ZmWhyXC+gfGEgWmJrLBHRw49pAiJB+d6qNMjgLK
DyzzUuKOIGi42Ty7/4IF9HCcT4d0hnJtkNgwU4Ko6KjUoDVm/zp1X6Um1k0h
Fxw+eAtjjCNPbyYMsxGx9cbDgftx3/svPFRY+zhql1dH5KKNwMRbUJmj7XAd
V1Sdvb4O4Tq+AnrJnojuoSvs9tmBqDLbj8bIG0hRosO6oI/GvjUUHYrG+1ok
crkduppwmyQUwLqjEpssOdmhpgJ0er4rauOhvZleq+sLGV2RZL/B9QNBiOgG
RAYARCOE1g7pHYX74d7v7Vk9MLwJeY8Pvkbzs+cYX8sITtvbQYf+xYn7Whq8
hXRRFc5BANaHQdeSNA3YDQUGCgJUfHdB+MmF864PWx7jeozPTqSM6UFKW1CT
B8wApLpMqFpW5zOOX9LpeZN094jhRSJiWKEqV/IlXKvQQ0lgI1u3uqbTBk0r
9MdkCKj0X9AORaF5gpYJzkRUDrK9w30DXyqKygqbaB4s6SHGaKlms+p84yEE
jZcA0reuXtlEjRpY4+gtjtzmKdTcf5/tPdnP/tLIxt/2pC0FpNbC5ypdjfRn
jsl8vfd033+YZFjc2Yz60Cl2yw0jXgGSa2wm5R2qavlClV7zOq28cfdAtvGO
cvgXYY2x1QwbuyfldGB8ubIw5lYLNOBSkIF0GudBeTow3Ftglt5/K8zq3L2H
BLlwI2ueu6K1UoksCE9tfv4wGpi0QAL41bSYlB/EQRYpD33oNc/VuGA88Mlk
UZNlzOW2vIGXdkUnRUyAg2++e/Lxo7v679nTpwyrRhS/kCx0EiV31iT6Bpvr
90f0dvnlV0+/YkC2gvQkFZJF2cBwUXQk6bjL52WCMgo9QARMtEUgz0rMbK4e
XsWiiZMX3q1vY8EZKzjMZ6/dj+13WYJPRkxKYO3GPmHuDeuuXrHsGey4FCtt
8I6b8diXnq9zlONa/Yr3xmEQOcDBtSzb8w9nTCNJ8iMpAoDlBY+BLxCWUIoP
COMsJgeUh3ROM7sCa3YiTvC5Qzdwtb0a2NfnP/7ufHhx+o4MbICNeMfxQyZf
tL08pYHpJHsqXSpbBhINUtidOqgCLcNwGDvyvhmEv1VMjwxXB4tzWoda2cAT
UKQ96nJC70EjWCieYuHXY8Gbxc4cI61MHCbTgIjbm/jdWpUR+C6uqAZiYYxD
iV9LO5WwOPcLl/FAlEmY9vjiBEp3ayH9KJJXsEkRmnYzURA1gmRcpoEkWIXk
EANGuugGS2np24UceATS0teKCHvVCLx4kx05APH9FzP34dDBh1V+dajbi8XX
IDQHiKotfaW9Oqsdh6UERjAwKRJLQE+ut9Mq14g8HPdbm15JHG5VccUA5q7X
+pZhbandxPV/lava3irqAcIgak+4lS5HW7yjy8ujIY3JyYb3/TLzHelm53rC
7X+wi6dRN4mbHazllpK7vOpcgQX90C45G5yzSz1ZkC+9K53/7hxwf3EAcm0g
jSKvpEUhSdamEJWdi0mgAjRZnxFr7LlDSOqPk01izLkEAryNoNfiepyQ8XB0
ROmVnbDr2pDGieHk11EB/dt6OR5eTch6La254AuZYWktUd9wy80u3IDcSdtv
iFym5srJYbrCEzHmn7hRskUInWl0nDdNnqH7fzlKKQBS38iRqYvWxzeHzEZT
NjqzuBA+lwSPuNwekrdHaoJeN3RBRn+iNM9lK4+KBLwdJooURgoJ+OIwjtuV
q4U2t+ex96XUgQsNoqJSbjyeZW3J97sM74pqih+DUnM9T6FrXQz7CfNyfQB1
g7jHPC1uXRX+rHiqj0BQ9b/l+mFpU9Lq3sR3DPvrHWS7/N3lIWIworGu3G5y
whGWLXt1//HVwZLUOt91zlc4k7kiHTkwmqu22dO0S87dgVGYLWUj3sFzRaZs
N3NWpszlMnUmcsyfPqGzz4t8p4UOWML18UXE5mBv2oQ9/IDeu89JOSv3Rgff
KBrZpK0cA2xg53YoUNRFdb0/Hz3Nzrz08EJTgACmlgUwaRrkYXklj06ndFwf
7eqaF58kUu/rKC5O2w/5KypDrwAiKssV6QISio9qFh1VKYhy/Qm4tt5Z65oy
66S39W527LLDg4PszR9DNNBdrYyqy6W/l1NVxkjPuCZK2UVHDuT05PqVdo8L
LdlY2LDl4DbNZ9WzVNYlhAq9ZduYGUbZUdnWg1Sm4PYNbo8t2100XjSgpxGm
KLHJPmvxtVDcxoaRcj47iuswxF/xzYjQg8GVRGZoB7tegj4TCdkHozPJNKAU
C3gGdKp3iULBXdEKh3wrtUP2oy1OgV23rgOSHj+t5xVDEBQTUzDvzZitbXSO
UqFeNNEgTGVQ1skH1fxcBcJxX7VknKz5lMj2UCHRVtrtUlIYwCqsl/EZd9vi
2zErOt1tzDiJ0bsMsvJFzBAck6G37cFM3pdlSA51bKWVg+uLQBOZo3e1JnrJ
ZOsfLBwEx/wcMX2NwC0XoVwCUdAO4lwTg1y9snX322vANoZIzYoPVox83z6j
HWwVPy7ylRU1Py1uiymaAsZoVPEJ6F/Ik0KGktXBOAQvzLl+s+60W1TInEqH
s1r74roQ1ygD3kpTYYPkepqcbNmibgrXzzS5oosDAglSStB8OMiCjDCuDx7c
dcaAaQqiV/GkHQclcaUmIdrJuc7HkZYO/dPjVpRpr3Sexlw3LKrsM3K9/Xzj
b8nQyypui7JfXyMvcU39OhtlbLlJMZrdGV6S3C3RQ66Osre2+/Of/k/Lv1t1
urZlrbg+xmLChVSfBXI8aY2mZQiujRhbNnGqWEWZFHo1UnQqiAfwJrqZOpz+
tNEe/5i31hq3MEm1xadPJQiynZMy2jggR6h8eYdjhdgpX3ZVSGpKgR+MsPIi
kHZ+GF2HN5NMeI+yZk/sKzrgSAXUcjnOPlsRZQ1BBUfNR3n4nM+sNsgfRIF/
oz3RQlEBrd9XQZOHl7V1CQHpo6kODCFPcHGbHJc7E9Be/KY//+n/rls6eH/+
0/+T4zHj9m/xnX3Vekm8LQY8lJYLBtxxZRzwS4/4FRIRL8mMbVliO2prB4BC
8kLct3YpXY987zw/KVMyBkTvUXBNzsaaXmbQkvo7Du1HLxJhI0UkLpMvN1Yy
tmxTc0qZRPvp1UX7JdyHyYIW+4KcOtkhRAaFcdgYGQQEg29oAh94OCbRMSv8
bZJkeqyZGOqHO8gxYi+CC3PpN9cIQKslmPJ1I56h1DninIX9i7uVcrjBtVne
367flXbHnH6cLGy+0vxDAKaRxUf2sJYq3t9fvXlxdHqJcIxAeQVJ26k+5yQL
yR3fpVAM7VZtX7hn5EeKAUs0lE6yRWcEZMpmdyuoNjwLd71kh8YOUnEqnkyy
o7Rp6C8x9AJN+z196Dg/FZgz6TjrE23+Z3KdlCR33HAi33i3+TqcZqlVAV4o
eBLQ2mxDsiryfhxGBV7GJMJ2e0h0iD7NuILUzaSc09HtFlK3ZPndKFKhjR3G
aRH+3Z1lL1yKXFwdFOc/kxNCZtKSu9yGSPdaUERgtecplQt/by+OncdxapkH
+sdI7fT+gCHc7P5pF5Re12En+kx0h5FDHcst0hKCnPHMa1ETEMSYBqsP35Ea
ZRiu5MBo+/qmHjs2WIVbwugI3+q5bLv15EYODPkW03oJexCdaPTWvgFf8GcO
iU+uQ6xWonQLAW/hkqjwRpmZfy2nwlYwGjvr3kjvk9Pm/QaG2FaSLRGPGCCL
VUHv2J6XvJvfJbMy0sRKv+Z0sI9Gt9BINEsJnNU00S7dSt+BOXNQMyNJNv2N
mELiDbNM47PDtzSES9ccqKdSt9r5JkZdDGLl/w/LcIdMkrgAAA==

-->

</rfc>

