rfc9506.original.xml   rfc9506.xml 
<?xml version='1.0' encoding='utf-8'?> <?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc [ <!DOCTYPE rfc [
<!ENTITY nbsp "&#160;"> <!ENTITY nbsp "&#160;">
<!ENTITY zwsp "&#8203;"> <!ENTITY zwsp "&#8203;">
<!ENTITY nbhy "&#8209;"> <!ENTITY nbhy "&#8209;">
<!ENTITY wj "&#8288;"> <!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. <rfc xmlns:xi="http://www.w3.org/2001/XInclude" ipr="trust200902" docName="draft
2) --> -ietf-ippm-explicit-flow-measurements-07" number="9506" submissionType="IETF" ca
<?rfc rfcedstyle="yes"?> tegory="info" consensus="true" tocDepth="6" tocInclude="true" sortRefs="true" sy
<?rfc tocindent="yes"?> mRefs="true" updates="" obsoletes="" xml:lang="en" version="3">
<?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" submissionType="IETF"
tocDepth="6" tocInclude="true" sortRefs="true" symRefs="true" version="3">
<!-- xml2rfc v2v3 conversion 3.17.4 -->
<front> <front>
<title abbrev="Delay and Loss bits">Explicit Host-to-Network Flow Measuremen <title abbrev="Host-to-Network Flow Measurements">Explicit Host-to-Network F
ts Techniques</title> low Measurements Techniques</title>
<seriesInfo name="Internet-Draft" value="draft-ietf-ippm-explicit-flow-measu <seriesInfo name="RFC" value="9506"/>
rements-07"/>
<author initials="M." surname="Cociglio" fullname="Mauro Cociglio"> <author initials="M." surname="Cociglio" fullname="Mauro Cociglio">
<organization>Telecom Italia - TIM</organization> <organization>Telecom Italia - TIM</organization>
<address> <address>
<postal> <postal>
<street>Via Reiss Romoli, 274</street> <street>Via Reiss Romoli, 274</street>
<city>Torino</city> <city>Torino</city>
<code>10148</code> <code>10148</code>
<country>Italy</country> <country>Italy</country>
</postal> </postal>
<email>mauro.cociglio@outlook.com</email> <email>mauro.cociglio@outlook.com</email>
skipping to change at line 94 skipping to change at line 86
<address> <address>
<email>isabelle.hamchaoui@orange.com</email> <email>isabelle.hamchaoui@orange.com</email>
</address> </address>
</author> </author>
<author initials="R." surname="Sisto" fullname="Riccardo Sisto"> <author initials="R." surname="Sisto" fullname="Riccardo Sisto">
<organization>Politecnico di Torino</organization> <organization>Politecnico di Torino</organization>
<address> <address>
<email>riccardo.sisto@polito.it</email> <email>riccardo.sisto@polito.it</email>
</address> </address>
</author> </author>
<date/> <date year="2023" month="October" />
<area>Transport</area> <area>tsv</area>
<workgroup>IPPM</workgroup> <workgroup>ippm</workgroup>
<keyword>Internet-Draft</keyword> <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> <abstract>
<?line 108?>
<t>This document describes protocol independent methods called Explicit <t>This document describes protocol-independent methods called Explicit
Host-to-Network Flow Measurement Techniques that can be applicable to Host-to-Network Flow Measurement Techniques that can be applicable to
transport-layer protocols between client and server. These methods employ just a transport-layer protocols between the client and server. These methods employ ju st a
few marking bits inside the header of each packet for performance measurements few marking bits inside the header of each packet for performance measurements
and require collaborative client and server. Both endpoints cooperate by marking and require the client and server to collaborate. Both endpoints cooperate by ma rking
packets and, possibly, mirroring the markings on the round-trip connection. The packets and, possibly, mirroring the markings on the round-trip connection. The
techniques are especially valuable when applied to protocols that encrypt techniques are especially valuable when applied to protocols that encrypt
transport headers, since they enable loss and delay measurements by passive transport headers since they enable loss and delay measurements by passive,
on-path network devices. This document describes several methods that can be on-path network devices. This document describes several methods that can be
used separately or jointly, depending of the availability of marking bits, used separately or jointly depending of the availability of marking bits,
desired measurements, and properties of the protocol to which the methods are desired measurements, and properties of the protocol to which the methods are
applied.</t> applied.</t>
</abstract> </abstract>
</front> </front>
<middle> <middle>
<?line 123?> <?line 123?>
<section anchor="introduction"> <section anchor="introduction">
<name>Introduction</name> <name>Introduction</name>
<t>Packet loss and delay are hard and pervasive problems of day-to-day net work <t>Packet loss and delay are hard and pervasive problems of day-to-day net work
operation. Proactively detecting, measuring, and locating them is crucial to operation. Proactively detecting, measuring, and locating them is crucial to
maintaining high QoS and timely resolution of end-to-end throughput issues.</t> 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 <t>Detecting and measuring packet loss and delay allows network operators to
independently confirm trouble reports and, ideally, be proactively notified of independently confirm trouble reports and, ideally, be proactively notified of
developing problems on the network. Locating the cause of packet loss or 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> excessive delay is the first step to resolving problems and restoring QoS.</t>
<t>Traditionally, network operators wishing to perform quantitative measur ement of <t>Network operators wishing to perform quantitative measurement of
packet loss and delay have been heavily relying on information present in the packet loss and delay have been heavily relying on information present in the
clear in transport-layer headers (e.g. TCP sequence and acknowledgment clear in transport-layer headers (e.g., TCP sequence and acknowledgment
numbers). By passively observing a network path at multiple points within one's 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 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 problem within their network or reliably attribute it to an upstream or
downstream network.</t> downstream network.</t>
<t>With encrypted protocols, the transport-layer headers are encrypted and passive <t>With encrypted protocols, the transport-layer headers are encrypted and passive
packet loss and delay observations are not possible, as also noted in packet loss and delay observations are not possible, as also noted in
<xref target="TRANSPORT-ENCRYPT"/>. Nevertheless, accurate measurement of packet loss and <xref target="RFC9065"/>. Nevertheless, accurate measurement of packet loss and
delay experienced by encrypted transport-layer protocols is highly desired, delay experienced by encrypted transport-layer protocols is highly desired,
especially by network operators who own or control the infrastructure between especially by network operators who own or control the infrastructure between th e
client and server.</t> client and server.</t>
<t>The measurement of loss and delay experienced by connections using an e ncrypted <t>The measurement of loss and delay experienced by connections using an e ncrypted
protocol cannot be based on a measurement of loss and delay experienced by protocol cannot be based on a measurement of loss and delay experienced by
connections between the same or similar endpoints that use an unencrypted connections between the same or similar endpoints that use an unencrypted
protocol, since different protocols may utilize the network differently and be protocol because different protocols may utilize the network differently and be
routed differently by the network. Therefore, it is necessary to directly routed differently by the network. Therefore, it is necessary to directly
measure the packet loss and delay experienced by users of encrypted protocols.</ t> measure the packet loss and delay experienced by users of encrypted protocols.</ t>
<t>The Alternate-Marking method <xref target="AltMark"/> defines a consoli dated method to <t>The Alternate-Marking method <xref target="RFC9341"/> defines a consoli dated method to
perform packet loss, delay, and jitter measurements on live traffic. However, perform packet loss, delay, and jitter measurements on live traffic. However,
as mentioned in <xref target="IPv6AltMark"/>, <xref target="AltMark"/> mainly ap as mentioned in <xref target="RFC9343"/>, <xref target="RFC9341"/> mainly applie
plies to a network layer s to a network-layer-controlled
controlled domain managed with a Network Management System (NMS), where the CPE domain managed with a Network Management System (NMS), where the Customer Premis
or the PE routers are the starting or the ending nodes. <xref target="AltMark"/> es Equipment (CPE)
provides or the Provider Edge (PE) routers are the starting or the ending nodes. <xref ta
rget="RFC9341"/> provides
measurement within a controlled domain in which the packets are measurement within a controlled domain in which the packets are
marked. Therefore, applying <xref target="AltMark"/> to end-to-end transport-lay er marked. Therefore, applying <xref target="RFC9341"/> to end-to-end transport-lay er
connections is not easy because packet identification and marking by network connections is not easy because packet identification and marking by network
nodes is prevented when encrypted transport-layer headers (e.g. QUIC, TCP with nodes is prevented when encrypted transport-layer headers (e.g., QUIC, TCP with
TLS) are being used.</t> TLS) are being used.</t>
<t>This document defines Explicit Host-to-Network Flow Measurement Techniq ues that <t>This document defines Explicit Host-to-Network Flow Measurement Techniq ues that
are specifically designed for encrypted transport protocols. According to the are specifically designed for encrypted transport protocols. According to the
definitions of <xref target="IPPM-METHODS"/>, these measurement methods can be c lassified as definitions of <xref target="RFC7799"/>, these measurement methods can be classi fied as
Hybrid. They are to be embedded into a transport-layer protocol and are 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 explicitly intended for exposing delay and loss rate information to on-path
measurement devices. Unlike <xref target="AltMark"/>, most of these methods requ ire measurement devices. Unlike <xref target="RFC9341"/>, most of these methods requ ire
collaborative endpoint nodes. Since these measurement techniques make performanc e collaborative endpoint nodes. Since these measurement techniques make performanc e
information directly visible to the path, they do not rely on an external NMS.</ t> 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 t his <t>The Explicit Host-to-Network Flow Measurement Techniques described in t his
document are applicable to any transport-layer protocol connecting a client and a document are applicable to any transport-layer protocol connecting a client and a
server. In this document the client and the server are also referred to as the server. In this document, the client and the server are also referred to as the
endpoints of the transport-layer protocol.</t> endpoints of the transport-layer protocol.</t>
<t>The different methods described in this document can be used alone or i n <t>The different methods described in this document can be used alone or i n
combination. Each technique uses few bits and exposes a specific measurement. combination. Each technique uses few bits and exposes a specific measurement.
It is assumed that the endpoints are collaborative in the sense of the It is assumed that the endpoints are collaborative in the sense of the
measurements, indeed both client and server needs to cooperate.</t> measurements, indeed both the client and server need to cooperate.</t>
<t>Following the recommendation in <xref target="RFC8558"/> of making path signals explicit, <t>Following the recommendation in <xref target="RFC8558"/> of making path signals explicit,
this document proposes adding some dedicated measurement bits to the clear this document proposes adding some dedicated measurement bits to the clear
portion of the transport protocol headers. These bits can be added to an portion of the transport protocol headers. These bits can be added to an
unencrypted portion of a transport-layer header, e.g. UDP surplus space (see unencrypted portion of a transport-layer header, e.g., UDP surplus space (see
<xref target="UDP-OPTIONS"/> and <xref target="UDP-SURPLUS"/>) or reserved bits <xref target="I-D.ietf-tsvwg-udp-options"/> and <xref target="I-D.herbert-udp-sp
in a QUIC v1 header, as ace-hdr"/>) or reserved bits in a QUIC v1 header, as
already done with the latency Spin bit (see Section 17.4 of already done with the latency Spin bit (see
<xref target="QUIC-TRANSPORT"/>). Note that this document does not recommend the <xref target="RFC9000" sectionFormat="of" section="17.4"/>). Note that this docu
use of any ment does not recommend the use of any
specific bits, as these would need to be chosen by the specific protocol specific bits, as these would need to be chosen by the specific protocol
implementations (see <xref target="applications"/>).</t> implementations (see <xref target="applications"/>).</t>
<t>The Spin bit, Delay bit and loss bits explained in this document are in <t>The Spin bit, Delay bit, and loss bits explained in this document are i
spired by nspired by
<xref target="AltMark"/>, <xref target="QUIC-MANAGEABILITY"/>, <xref target="QUI <xref target="RFC9341"/>, <xref target="RFC9312"/>, <xref target="I-D.trammell-q
C-SPIN"/>, <xref target="I-D.trammell-tsvwg-spin"/> uic-spin"/>, <xref target="I-D.trammell-tsvwg-spin"/>,
and <xref target="I-D.trammell-ippm-spin"/>.</t> and <xref target="I-D.trammell-ippm-spin"/>.</t>
<t>Additional details about the Performance Measurements for QUIC are desc ribed in <t>Additional details about the performance measurements for QUIC are desc ribed in
the paper <xref target="ANRW19-PM-QUIC"/>.</t> the paper <xref target="ANRW19-PM-QUIC"/>.</t>
</section> </section>
<section anchor="latency-bits"> <section anchor="latency-bits">
<name>Latency Bits</name> <name>Latency Bits</name>
<t>This section introduces bits that can be used for round trip latency <t>This section introduces bits that can be used for round-trip latency
measurements. Whenever this section of the specification refers to packets, it measurements. Whenever this section of the specification refers to packets, it
is referring only to packets with protocol headers that include the latency is referring only to packets with protocol headers that include the latency
bits.</t> bits.</t>
<t>In section 17.4, <xref target="QUIC-TRANSPORT"/> introduces an explicit per-flow <t>In <xref target="RFC9000" sectionFormat="comma" section="17.4"/> introd uces an explicit, per-flow
transport-layer signal for hybrid measurement of RTT. This signal consists of a 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"/> disc usses an Spin bit that toggles once per RTT. <xref target="I-D.trammell-quic-spin" sectio nFormat="of" section="4"/> discusses an
additional two-bit Valid Edge Counter (VEC) to compensate for loss and additional two-bit Valid Edge Counter (VEC) to compensate for loss and
reordering of the Spin bit and increase fidelity of the signal in less than reordering of the Spin bit and to increase fidelity of the signal in less than
ideal network conditions.</t> ideal network conditions.</t>
<t>This document introduces a stand-alone single-bit delay signal that can be used <t>This document introduces a standalone single-bit delay signal that can be used
by passive observers to measure the RTT of a network flow, avoiding the Spin bit 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> ambiguities that arise as soon as network conditions deteriorate.</t>
<section anchor="spinbit"> <section anchor="spinbit">
<name>Spin Bit</name> <name>Spin Bit</name>
<t>This section is a small recap of the Spin bit working mechanism. For a <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 comprehensive explanation of the algorithm, see
<xref target="QUIC-MANAGEABILITY"/>.</t> <xref target="RFC9312" sectionFormat="of" section="3.8.2"/>.</t>
<t>The Spin bit is an Alternate-Marking <xref target="AltMark"/> generat <t>The Spin bit is a signal generated by Alternate-Marking <xref target=
ed signal, where the "RFC9341"/>, where the
size of the alternation changes with the flight size each RTT.</t> size of the alternation changes with the flight size each RTT.</t>
<t>The latency Spin bit is a single bit signal that toggles once per RTT , <t>The latency Spin bit is a single-bit signal that toggles once per RTT ,
enabling latency monitoring of a connection-oriented communication enabling latency monitoring of a connection-oriented communication
from intermediate observation points.</t> from intermediate observation points.</t>
<t>A "spin period" is a set of packets with the same Spin bit value sent <t>A "Spin bit period" is a set of packets with the same Spin bit value
during one sent during one
RTT time interval. A "spin period value" is the value of the Spin bit shared by RTT time interval. A "Spin bit period value" is the value of the Spin bit shared
all packets in a spin period.</t> by
<t>The client and server maintain an internal per-connection spin value all packets in a Spin bit period.</t>
(i.e. 0 or <t>The client and server maintain an internal per-connection spin value
(i.e., 0 or
1) used to set the Spin bit on outgoing packets. Both endpoints initialize the 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> spin value to 0 when a new connection starts. Then:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>when the client receives a packet with the packet number larger th an any <li>when the client receives a packet with the packet number larger th an any
number seen so far, it sets the connection spin value to the opposite value number seen so far, it sets the connection spin value to the opposite value
contained in the received packet;</li> contained in the received packet; and</li>
<li>when the server receives a packet with the packet number larger th an any <li>when the server receives a packet with the packet number larger th an any
number seen so far, it sets the connection spin value to the same value number seen so far, it sets the connection spin value to the same value
contained in the received packet.</li> contained in the received packet.</li>
</ul> </ul>
<t>The computed spin value is used by the endpoints for setting the spin <t>The computed spin value is used by the endpoints for setting the Spin
bit on outgoing packets. This mechanism allows the endpoints bit on outgoing packets. This mechanism allows the endpoints
to generate a square wave such that, by measuring the distance in time to generate a square wave such that, by measuring the distance in time
between pairs of consecutive edges observed in the same direction, a between pairs of consecutive edges observed in the same direction, a
passive on-path observer can compute the round trip network delay of that passive on-path observer can compute the round-trip network delay of that
network flow.</t> network flow.</t>
<t>Spin bit enables round trip latency measurement by observing a single direction <t>Spin bit enables round-trip latency measurement by observing a single direction
of the traffic flow.</t> of the traffic flow.</t>
<t>Note that packet reordering can cause spurious edges that require heu ristics to <t>Note that packet reordering can cause spurious edges that require heu ristics to
correct. The Spin bit performance deteriorates as soon as network impairments correct. The Spin bit performance deteriorates as soon as network impairments
arise as explained in <xref target="delaybit"/>.</t> arise as explained in <xref target="delaybit"/>.</t>
</section> </section>
<section anchor="delaybit"> <section anchor="delaybit">
<name>Delay Bit</name> <name>Delay Bit</name>
<t>The Delay bit has been designed to overcome accuracy limitations expe rienced by <t>The Delay bit has been designed to overcome accuracy limitations expe rienced by
the Spin bit under difficult network conditions:</t> the Spin bit under difficult network conditions:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>packet reordering leads to generation of spurious edges and errors in delay <li>packet reordering leads to generation of spurious edges and errors in delay
estimation;</li> estimation;</li>
<li>loss of edges causes wrong estimation of spin periods and therefor <li>loss of edges causes wrong estimation of Spin bit periods and ther
e wrong RTT efore wrong RTT
measurements;</li> measurements; and</li>
<li>application-limited senders cause the Spin bit to measure the appl ication <li>application-limited senders cause the Spin bit to measure the appl ication
delays instead of network delays.</li> delays instead of network delays.</li>
</ul> </ul>
<t>Unlike the Spin bit, which is set in every packet transmitted on the network, <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> 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 De lay bit) <t>When the Delay bit is used, a single packet with a marked bit (the De lay bit)
bounces between a client and a server during the entire connection lifetime. bounces between a client and a server during the entire connection lifetime.
This single packet is called "delay sample".</t> This single packet is called the "delay sample".</t>
<t>An observer placed at an intermediate point, observing a single direc tion of <t>An observer placed at an intermediate point, observing a single direc tion of
traffic, tracking the delay sample and the relative timestamp, can measure the traffic and tracking the delay sample and the relative timestamp, can measure th
round trip delay of the connection.</t> e
round-trip delay of the connection.</t>
<t>The delay sample lifetime comprises two phases: initialization and re flection. <t>The delay sample lifetime comprises two phases: initialization and re flection.
The initialization is the generation of the delay sample, while the The initialization is the generation of the delay sample, while the
reflection realizes the bounce behavior of this single packet between the two reflection realizes the bounce behavior of this single packet between the two
endpoints.</t> endpoints.</t>
<t>The next figure describes the elementary Delay bit mechanism.</t> <t>The next figure describes the elementary Delay bit mechanism.</t>
<figure> <figure>
<name>Delay bit mechanism</name> <name>Delay Bit Mechanism</name>
<artwork><![CDATA[ <artwork><![CDATA[
+--------+ - - - - - +--------+ +--------+ - - - - - +--------+
| | -----------> | | | | -----------> | |
| Client | | Server | | Client | | Server |
| | <----------- | | | | <----------- | |
+--------+ - - - - - +--------+ +--------+ - - - - - +--------+
(a) No traffic at beginning. (a) No traffic at beginning.
+--------+ 0 0 1 - - +--------+ +--------+ 0 0 1 - - +--------+
| | -----------> | | | | -----------> | |
| Client | | Server | | Client | | Server |
| | <----------- | | | | <----------- | |
+--------+ - - - - - +--------+ +--------+ - - - - - +--------+
(b) The Client starts sending data and (b) The Client starts sending data and sets
sets the first packet as Delay Sample. the first packet as the delay sample.
+--------+ 0 0 0 0 0 +--------+ +--------+ 0 0 0 0 0 +--------+
| | -----------> | | | | -----------> | |
| Client | | Server | | Client | | Server |
| | <----------- | | | | <----------- | |
+--------+ - - - 1 0 +--------+ +--------+ - - - 1 0 +--------+
(c) The Server starts sending data (c) The Server starts sending data
and reflects the Delay Sample. and reflects the delay sample.
+--------+ 0 1 0 0 0 +--------+ +--------+ 0 1 0 0 0 +--------+
| | -----------> | | | | -----------> | |
| Client | | Server | | Client | | Server |
| | <----------- | | | | <----------- | |
+--------+ 0 0 0 0 0 +--------+ +--------+ 0 0 0 0 0 +--------+
(d) The Client reflects the Delay Sample. (d) The Client reflects the delay sample.
+--------+ 0 0 0 0 0 +--------+ +--------+ 0 0 0 0 0 +--------+
| | -----------> | | | | -----------> | |
| Client | | Server | | Client | | Server |
| | <----------- | | | | <----------- | |
+--------+ 0 0 0 1 0 +--------+ +--------+ 0 0 0 1 0 +--------+
(e) The Server reflects the Delay Sample (e) The Server reflects the delay sample
and so on. and so on.
]]></artwork> ]]></artwork>
</figure> </figure>
<section anchor="generation-phase"> <section anchor="generation-phase">
<name>Generation Phase</name> <name>Generation Phase</name>
<t>Only client is actively involved in the generation phase. It mainta ins an <t>Only the client is actively involved in the Generation Phase. It ma intains an
internal per-flow timestamp variable (<tt>ds_time</tt>) updated every time a del ay internal per-flow timestamp variable (<tt>ds_time</tt>) updated every time a del ay
sample is transmitted.</t> sample is transmitted.</t>
<t>When connection starts, the client generates a new delay sample ini tializing the <t>When connection starts, the client generates a new delay sample ini tializing the
Delay bit of the first outgoing packet to 1. Then it updates the <tt>ds_time</t t> Delay bit of the first outgoing packet to 1. Then it updates the <tt>ds_time</t t>
variable with the timestamp of its transmission.</t> variable with the timestamp of its transmission.</t>
<t>The server initializes the Delay bit to 0 at the beginning of the c onnection, <t>The server initializes the Delay bit to 0 at the beginning of the c onnection,
and its only task during the connection is described in <xref target="reflection -phase"/>.</t> 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 b <t>In absence of network impairments, the delay sample should bounce b
etween client etween the client
and server continuously, for the entire duration of the connection. That is and server continuously for the entire duration of the connection. However, tha
t is
highly unlikely for two reasons:</t> highly unlikely for two reasons:</t>
<ol spacing="normal" type="1"><li>the packet carrying the Delay bit mi <ol spacing="normal" type="1"><li>The packet carrying the Delay bit mi
ght be lost;</li> ght be lost.</li>
<li>an endpoint could stop or delay sending packets because the appl <li>An endpoint could stop or delay sending packets because the appl
ication is ication is
limiting the amount of traffic transmitted.</li> limiting the amount of traffic transmitted.</li>
</ol> </ol>
<t>To deal with these problems, the client generates a new delay sampl e if more <t>To deal with these problems, the client generates a new delay sampl e if more
than a predetermined time (<tt>T_Max</tt>) has elapsed since the last delay samp le than a predetermined time (<tt>T_Max</tt>) has elapsed since the last delay samp le
transmission (including reflections). Note that <tt>T_Max</tt> should be greater than 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 d etails.</t> the max measurable RTT on the network. See <xref target="tmax-selection"/> for d etails.</t>
</section> </section>
<section anchor="reflection-phase"> <section anchor="reflection-phase">
<name>Reflection Phase</name> <name>Reflection Phase</name>
<t>Reflection is the process that enables the bouncing of the delay sa mple between <t>Reflection is the process that enables the bouncing of the delay sa mple between
a client and a server. The behavior of the two endpoints is almost the same.</t > a client and a server. The behavior of the two endpoints is almost the same.</t >
<ul spacing="normal"> <ul spacing="normal">
<li>Server side reflection: when a delay sample arrives, the server marks the <li>Server-side reflection: When a delay sample arrives, the server marks the
first packet in the opposite direction as the delay sample.</li> first packet in the opposite direction as the delay sample.</li>
<li>Client side reflection: when a delay sample arrives, the client marks the <li>Client-side reflection: When a delay sample arrives, the client marks the
first packet in the opposite direction as the delay sample. It also updates 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 forward ed.</li> the <tt>ds_time</tt> variable when the outgoing delay sample is actually forward ed.</li>
</ul> </ul>
<t>In both cases, if the outgoing delay sample is being transmitted wi th a delay <t>In both cases, if the outgoing delay sample is being transmitted wi th a delay
greater than a predetermined threshold after the reception of the incoming delay greater than a predetermined threshold after the reception of the incoming delay
sample (1ms by default), the delay sample is not reflected, and the outgoing sample (1 ms by default), the delay sample is not reflected, and the outgoing
Delay bit is kept at 0.</t> Delay bit is kept at 0.</t>
<t>By doing so, the algorithm can reject measurements that would overe stimate the <t>By doing so, the algorithm can reject measurements that would overe stimate the
delay due to lack of traffic on the endpoints. Hence, the maximum estimation delay due to lack of traffic at the endpoints. Hence, the maximum estimation
error would amount to twice the threshold (e.g. 2ms) per measurement.</t> error would amount to twice the threshold (e.g., 2 ms) per measurement.</t>
</section> </section>
<section anchor="tmax-selection"> <section anchor="tmax-selection">
<name>T_Max Selection</name> <name><tt>T_Max</tt> Selection</name>
<t>The internal <tt>ds_time</tt> variable allows a client to identify delay sample losses. <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 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 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> 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 <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 measu re. or equal than <tt>T_Max</tt>, then these cannot be used to produce a delay measu re.
Therefore, the value of <tt>T_Max</tt> must also be known to the on-path network probes.</t> 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 the <tt>T_Max</tt> value so th at both client and <t>There are two alternatives to 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 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 imp lements (<tt>T_Max_p</tt>) and therefore set within the protocol specifications that imp lements
the marking mechanism (e.g. 1 second which usually is greater than the max the marking mechanism (e.g., 1 second, which usually is greater than the max
expectable RTT). The second alternative requires a dynamic mechanism able to 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_M ax_c</tt>).</t> adapt the duration of the <tt>T_Max</tt> to the delay of the connection (<tt>T_M ax_c</tt>).</t>
<t>For instance, client and observers could use the connection RTT as a basis for <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 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. 1 second) and then, when a valid RTT is so that <tt>T_Max = T_Max_p</tt> (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 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 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 connection delay. This also helps to prevent the mechanism from failing when the
observer cannot recognize sudden changes in RTT exceeding T_max.</t> observer cannot recognize sudden changes in RTT exceeding <tt>T_Max</tt>.</t>
<t><tt>T_Max_c</tt> could be computed as two times the measured <tt>RT T</tt> plus a fixed amount <t><tt>T_Max_c</tt> could be computed as two times the measured <tt>RT T</tt> plus a fixed amount
of time (<tt>100ms</tt>) to prevent low <tt>T_Max</tt> values in case of very sm of time (100 ms) to prevent low <tt>T_Max</tt> values in the case of very small
all RTTs. RTTs.
The resulting formula is: <tt>T_Max_c = 2RTT + 100ms</tt>. If <tt>T_Max_c</tt> i The resulting formula is: <tt>T_Max_c = 2RTT + 100 ms</tt>. If <tt>T_Max_c</tt>
s greater than is greater than
<tt>T_Max_p</tt> then <tt>T_Max_c</tt> is forced to <tt>T_Max_p</tt> value. <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 is provided as an example, and it may be chosen Note that the value of 100 ms is provided as an example, and it may be chosen
differently depending on the specific scenarios. For instance, an implementer ma y differently depending on the specific scenarios. For instance, an implementer ma y
consider using existing protocol-specific values if appropriate.</t> 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 <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 actu ally client's <tt>T_Max</tt> to avoid considering as a valid measurement what is actu ally
the client's <tt>T_Max</tt>. To obtain this result, the client waits for two 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 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, 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> observers have already measured a valid RTT and then computed their <tt>T_Max_c< /tt>.</t>
</section> </section>
<section anchor="delay-measurement-using-delay-bit"> <section anchor="delay-measurement-using-delay-bit">
<name>Delay Measurement Using Delay Bit</name> <name>Delay Measurement Using the Delay Bit</name>
<t>When the Delay bit is used, a passive observer can use delay sample s directly <t>When the Delay bit is used, a passive observer can use delay sample s directly
and avoid inherent ambiguities in the calculation of the RTT as can be seen in and avoid inherent ambiguities in the calculation of the RTT as can be seen in
Spin bit analysis.</t> Spin bit analysis.</t>
<section anchor="rtt-measurement"> <section anchor="rtt-measurement">
<name>RTT Measurement</name> <name>RTT Measurement</name>
<t>The delay sample generation process ensures that only one packet marked with the <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 Delay bit set to 1 runs back and forth between two endpoints per round-trip
time. To determine the RTT measurement of a flow, an on-path passive observer 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 computes the time difference between two delay samples observed in a single
direction.</t> direction.</t>
<t>To ensure a valid measurement, the observer must verify that the distance in <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> time between the two samples taken into account is less than <tt>T_Max</tt>.</t>
<figure> <figure>
<name>Round-trip time (both direction)</name> <name>Round-Trip Time (Both Directions)</name>
<artwork><![CDATA[ <artwork><![CDATA[
=======================|======================> =======================|======================>
= ********** -----Obs----> ********** = = ********** -----Obs----> ********** =
= * Client * * Server * = = * Client * * Server * =
= ********** <------------ ********** = = ********** <------------ ********** =
<============================================== <==============================================
(a) client-server RTT (a) client-server RTT
==============================================> ==============================================>
skipping to change at line 432 skipping to change at line 441
<section anchor="half-rtt-measurement"> <section anchor="half-rtt-measurement">
<name>Half-RTT Measurement</name> <name>Half-RTT Measurement</name>
<t>An observer that is able to observe both forward and return traff ic directions <t>An observer that is able to observe both forward and return traff ic directions
can use the delay samples to measure "upstream" and "downstream" RTT components, 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 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 between a delay sample observed in one direction and the delay sample previously
observed in the opposite direction.</t> observed in the opposite direction.</t>
<t>As with RTT measurement, the observer must verify that the distan ce in time <t>As with RTT measurement, the observer must verify that the distan ce in time
between the two samples taken into account is less than <tt>T_Max</tt>.</t> 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 e ndpoints and <t>Note that upstream and downstream sections of paths between the e ndpoints and
the observer, i.e. observer-to-client vs client-to-observer and the observer (i.e., observer-to-client vs. client-to-observer and
observer-to-server vs server-to-observer, may have different delay observer-to-server vs. server-to-observer) may have different delay
characteristics due to the difference in network congestion and other factors.</ t> characteristics due to the difference in network congestion and other factors.</ t>
<figure> <figure>
<name>Half Round-trip time (both direction)</name> <name>Half Round-Trip Time (Both Directions)</name>
<artwork><![CDATA[ <artwork><![CDATA[
=======================> =======================>
= ********** ------|-----> ********** = ********** ------|-----> **********
= * Client * Obs * Server * = * Client * Obs * Server *
= ********** <-----|------ ********** = ********** <-----|------ **********
<======================= <=======================
(a) client-observer half-RTT (a) client-observer half-RTT
=======================> =======================>
********** ------|-----> ********** = ********** ------|-----> ********** =
* Client * Obs * Server * = * Client * Obs * Server * =
********** <-----|------ ********** = ********** <-----|------ ********** =
<======================= <=======================
(b) observer-server half-RTT (b) observer-server half-RTT
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="intra-domain-rtt-measurement"> <section anchor="intra-domain-rtt-measurement">
<name>Intra-Domain RTT Measurement</name> <name>Intra-domain RTT Measurement</name>
<t>Intra-domain RTT is the portion of the entire RTT used by a flow to traverse the <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 network of a provider. To measure intra-domain RTT, two observers capable of
observing traffic in both directions must be employed simultaneously at ingress observing traffic in both directions must be employed simultaneously at the ingr
and egress of the network to be measured. Intra-domain RTT is difference ess
and egress of the network to be measured. Intra-domain RTT is the difference
between the two computed upstream (or downstream) RTT components.</t> between the two computed upstream (or downstream) RTT components.</t>
<figure> <figure>
<name>Intra-domain Round-trip time (client-observer: upstream)</na me> <name>Intra-domain Round-Trip Time (Client-Observer: Upstream)</na me>
<artwork><![CDATA[ <artwork><![CDATA[
=========================================> =========================================>
= =====================> = =====================>
= = ********** ---|--> ---|--> ********** = = ********** ---|--> ---|--> **********
= = * Client * Obs Obs * Server * = = * Client * Obs Obs * Server *
= = ********** <--|--- <--|--- ********** = = ********** <--|--- <--|--- **********
= <===================== = <=====================
<========================================= <=========================================
(a) client-observer RTT components (half-RTTs) (a) client-observer RTT components (half-RTTs)
==================> ==================>
********** ---|--> ---|--> ********** ********** ---|--> ---|--> **********
* Client * Obs Obs * Server * * Client * Obs Obs * Server *
********** <--|--- <--|--- ********** ********** <--|--- <--|--- **********
<================== <==================
(b) the intra-domain RTT resulting from the (b) the intra-domain RTT resulting from the
subtraction of the above RTT components subtraction of the above RTT components
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
</section> </section>
<section anchor="observers-algorithm"> <section anchor="observers-algorithm">
<name>Observer's Algorithm</name> <name>Observer's Algorithm</name>
<t>An on-path observer maintains an internal per-flow variable to keep track of <t>An on-path observer maintains an internal per-flow variable to keep track of
time at which the last delay sample has been observed. The flow characterization the time at which the last delay sample has been observed. The flow characteriza tion
should be part of the protocol.</t> should be part of the protocol.</t>
<t>A unidirectional observer or in case of asymmetric routing, upon de tecting a <t>If the observer is unidirectional or in case of asymmetric routing, then upon detecting a
delay sample:</t> delay sample:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>if a delay sample was also detected previously in the same direc tion and the <li>if a delay sample was also detected previously in the same direc tion and the
distance in time between them is less than <tt>T_Max - K</tt>, then the two dela y distance in time between them is less than <tt>T_Max - K</tt>, then the two dela y
samples can be used to calculate RTT measurement. <tt>K</tt> is a protection 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 variatio ns threshold to absorb differences in <tt>T_Max</tt> computation and delay variatio ns
between two consecutive delay samples (e.g. <tt>K = 10% T_Max</tt>).</li> between two consecutive delay samples (e.g., <tt>K = 10% T_Max</tt>).</li>
</ul> </ul>
<t>If the observer can observe both forward and return traffic flows, and it is <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. by able to determine which direction contains the client and the server (e.g., by
observing the connection handshake), upon detecting a delay sample:</t> observing the connection handshake), then upon detecting a delay sample:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>if a delay sample was also detected in the opposite direction an d the distance <li>if a delay sample was also detected in the opposite direction an d the distance
in time between them is less than <tt>T_Max - K</tt>, then the two delay samples can 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 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> half-RTT, according to the direction of the last delay sample observed.</li>
</ul> </ul>
<t>Note that the accuracy can be influenced by what the observer is ca pable of <t>Note that the accuracy can be influenced by what the observer is ca pable of
observing. Additionally, the type of measurement differs, as described in the observing. Additionally, the type of measurement differs, as described in the
previous sections.</t> previous sections.</t>
</section> </section>
<section anchor="two-bits-delay-measurement-spin-bit-delay-bit"> <section anchor="two-bits-delay-measurement-spin-bit-delay-bit">
<name>Two Bits Delay Measurement: Spin Bit + Delay Bit</name> <name>Two Bits Delay Measurement: Spin Bit + Delay Bit</name>
<t>Spin and Delay bit algorithms work independently. If both marking m ethods are <t>The Spin and Delay bit algorithms work independently. If both marki ng methods are
used in the same connection, observers can choose the best measurement between used in the same connection, observers can choose the best measurement between
the two available:</t> the two available:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>when a precise measurement can be produced using the Delay bit, observers <li>when a precise measurement can be produced using the Delay bit, observers
choose it;</li> choose it; and</li>
<li>when a Delay bit measurement is not available, observers choose the <li>when a Delay bit measurement is not available, observers choose the
approximate Spin bit one.</li> approximate Spin bit one.</li>
</ul> </ul>
</section> </section>
</section> </section>
</section> </section>
<section anchor="loss-bits"> <section anchor="loss-bits">
<name>Loss Bits</name> <name>Loss Bits</name>
<t>This section introduces bits that can be used for loss measurements. <t>This section introduces bits that can be used for loss measurements.
Whenever this section of the specification refers to packets, it is Whenever this section of the specification refers to packets, it is
referring only to packets with protocol headers that include the loss referring only to packets with protocol headers that include the loss
bits -- the only packets whose loss can be measured.</t> bits -- the only packets whose loss can be measured.</t>
<ul spacing="normal"> <dl>
<li>T: the "round Trip loss" bit is used in combination with the Spin bi <dt>T:</dt>
t to <dd>The "round-Trip loss" bit is used in combination with the Spin bit t
measure round-trip loss. See <xref target="rtlossbit"/>.</li> o
<li>Q: the "sQuare signal" bit is used to measure upstream loss. See measure round-trip loss. See <xref target="rtlossbit"/>.</dd>
<xref target="squarebit"/>.</li> <dt>Q:</dt>
<li>L: the "Loss event" bit is used to measure end-to-end loss. See <xre <dd>The "sQuare" bit is used to measure upstream loss. See
f target="lossbit"/>.</li> <xref target="squarebit"/>.</dd>
<li>R: the "Reflection square signal" bit is used in combination with Q <dt>L:</dt>
bit to <dd>The "Loss Event" bit is used to measure end-to-end loss. See <xref t
measure end-to-end loss. See <xref target="refsquarebit"/>.</li> arget="lossbit"/>.</dd>
</ul> <dt>R:</dt>
<dd>The "Reflection square" bit is used in combination with the Q bit to
measure end-to-end loss. See <xref target="refsquarebit"/>.</dd>
</dl>
<t>Loss measurements enabled by T, Q, and L bits can be implemented by tho se loss <t>Loss measurements enabled by T, Q, and L bits can be implemented by tho se loss
bits alone (T bit requires a working Spin bit). Two-bit combinations Q+L and Q+R bits alone (T bit requires a working Spin bit). Two-bit combinations Q+L and Q+R
enable additional measurement opportunities discussed below.</t> enable additional measurement opportunities discussed below.</t>
<t>Each endpoint maintains appropriate counters independently and separate ly for <t>Each endpoint maintains appropriate counters independently and separate ly for
each separately identifiable flow (each sub-flow for multipath connections).</t> each identifiable flow (or each sub-flow for multipath connections).</t>
<t>Since loss is reported independently for each flow, all bits (except fo <t>Since loss is reported independently for each flow, all bits (except fo
r L bit) r the L bit)
require a certain minimum number of packets to be exchanged per flow before any 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 signal can be measured. Therefore, loss measurements work best for flows that
transfer more than a minimal amount of data.</t> transfer more than a minimal amount of data.</t>
<section anchor="rtlossbit"> <section anchor="rtlossbit">
<name>T Bit -- Round Trip Loss Bit</name> <name>T Bit -- Round-Trip Loss Bit</name>
<t>The round Trip loss bit is used to mark a variable number of packets <t>The round-Trip loss bit is used to mark a variable number of packets
exchanged exchanged
twice between the endpoints realizing a two round-trip reflection. A passive twice between the endpoints realizing a two round-trip reflection. A passive
on-path observer, observing either direction, can count and compare the number on-path observer, observing either direction, can count and compare the number
of marked packets seen during the two reflections, estimating the loss rate of marked packets seen during the two reflections, estimating the loss rate
experienced by the connection. The overall exchange comprises:</t> experienced by the connection. The overall exchange comprises:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>the client selects and consequently sets the T bit to 1 in order t o identify <li>the client selects and consequently sets the T bit to 1 in order t o identify
a first train of packets;</li> a first train of packets;</li>
<li>the server, upon receiving each packet included in the first train , reflects <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 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> first train received;</li>
<li>the client, upon receiving each packet included in the second trai <li>upon receiving each packet included in the second train, the clien
n, reflects t sets the T bit to 1 and reflects
to the server a respective third train of packets of the same size as the 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> second train received; and</li>
<li>the server, upon receiving each packet included in the third train <li>upon receiving each packet included in the third train, the server
, finally sets the T bit to 1 and finally
reflects to the client a respective fourth train of packets of the same size 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> as the third train received.</li>
</ul> </ul>
<t>Packets belonging to the first round trip (first and second train) <t>Packets belonging to the first round trip (first and second train)
represent the Generation Phase, while those belonging to the second represent the Generation Phase, while those belonging to the second
round trip (third and fourth train) represent the Reflection Phase.</t> 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 <t>A passive on-path observer can count and compare the number of marked
packets seen during the two round trips (i.e. the first and third packets seen during the two round trips (i.e., the first and third
or the second and the fourth trains of packets, depending on which or the second and the fourth trains of packets, depending on which
direction is observed) and estimate the loss rate experienced by the direction is observed) and estimate the loss rate experienced by the
connection. This process is repeated continuously to obtain more connection. This process is repeated continuously to obtain more
measurements as long as the endpoints exchange traffic. These measurements as long as the endpoints exchange traffic. These
measurements can be called Round Trip losses.</t> measurements can be called round-trip losses.</t>
<t>Since packet rates in two directions may be different, the number of <t>Since the packet rates in two directions may be different, the number
marked of marked
packets in the train is determined by the direction with the lowest packet rate. 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> See <xref target="tbit-details"/> for details on packet generation.</t>
<section anchor="round-trip-loss"> <section anchor="round-trip-loss">
<name>Round Trip Loss</name> <name>Round-Trip Loss</name>
<t>Since the measurements are performed on a portion of the traffic ex changed <t>Since the measurements are performed on a portion of the traffic ex changed
between the client and the server, the observer calculates the end-to-end Round between the client and the server, the observer calculates the end-to-end Round-
Trip Packet Loss (RTPL) that, statistically, will correspond to the loss rate Trip
Packet Loss (RTPL) that, statistically, will correspond to the loss rate
experienced by the connection along the entire network path.</t> experienced by the connection along the entire network path.</t>
<figure> <figure>
<name>Round-trip packet loss (both direction)</name> <name>Round-Trip Packet Loss (Both Directions)</name>
<artwork><![CDATA[ <artwork><![CDATA[
=======================|======================> =======================|======================>
= ********** -----Obs----> ********** = = ********** -----Obs----> ********** =
= * Client * * Server * = = * Client * * Server * =
= ********** <------------ ********** = = ********** <------------ ********** =
<============================================== <==============================================
(a) client-server RTPL (a) client-server RTPL
==============================================> ==============================================>
= ********** ------------> ********** = = ********** ------------> ********** =
= * Client * * Server * = = * Client * * Server * =
= ********** <----Obs----- ********** = = ********** <----Obs----- ********** =
<======================|======================= <======================|=======================
(b) server-client RTPL (b) server-client RTPL
]]></artwork> ]]></artwork>
</figure> </figure>
<t>This methodology also allows the Half-RTPL measurement and <t>This methodology also allows the half-RTPL measurement and
the Intra-domain RTPL measurement in a way similar to RTT measurement.</t> the Intra-domain RTPL measurement in a way similar to RTT measurement.</t>
<figure> <figure>
<name>Half Round-trip packet loss (both direction)</name> <name>Half Round-Trip Packet Loss (Both Directions)</name>
<artwork><![CDATA[ <artwork><![CDATA[
=======================> =======================>
= ********** ------|-----> ********** = ********** ------|-----> **********
= * Client * Obs * Server * = * Client * Obs * Server *
= ********** <-----|------ ********** = ********** <-----|------ **********
<======================= <=======================
(a) client-observer half-RTPL (a) client-observer half-RTPL
=======================> =======================>
********** ------|-----> ********** = ********** ------|-----> ********** =
* Client * Obs * Server * = * Client * Obs * Server * =
********** <-----|------ ********** = ********** <-----|------ ********** =
<======================= <=======================
(b) observer-server half-RTPL (b) observer-server half-RTPL
]]></artwork> ]]></artwork>
</figure> </figure>
<figure> <figure>
<name>Intra-domain Round-trip packet loss (observer-server)</name> <name>Intra-domain Round-Trip Packet Loss (Observer-Server)</name>
<artwork><![CDATA[ <artwork><![CDATA[
=========================================> =========================================>
=====================> = =====================> =
********** ---|--> ---|--> ********** = = ********** ---|--> ---|--> ********** = =
* Client * Obs Obs * Server * = = * Client * Obs Obs * Server * = =
********** <--|--- <--|--- ********** = = ********** <--|--- <--|--- ********** = =
<===================== = <===================== =
<========================================= <=========================================
(a) observer-server RTPL components (half-RTPLs) (a) observer-server RTPL components (half-RTPLs)
==================> ==================>
********** ---|--> ---|--> ********** ********** ---|--> ---|--> **********
* Client * Obs Obs * Server * * Client * Obs Obs * Server *
********** <--|--- <--|--- ********** ********** <--|--- <--|--- **********
<================== <==================
(b) the intra-domain RTPL resulting from the (b) the intra-domain RTPL resulting from the
subtraction of the above RTPL components subtraction of the above RTPL components
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="tbit-details"> <section anchor="tbit-details">
<name>Setting the Round Trip Loss Bit on Outgoing Packets</name> <name>Setting the Round-Trip Loss Bit on Outgoing Packets</name>
<t>The round Trip loss signal requires a working Spin-bit signal to se <t>The round-Trip loss signal requires a working Spin bit signal to se
parate trains parate trains
of marked packets (packets with T bit set to 1). A "pause" of at least one of marked packets (packets with T bit set to 1). A "pause" of at least one
empty spin-bit period between each phase of the algorithm serves as such empty Spin bit period between each phase of the algorithm serves as such a
separator for the on-path observer. The connection between T Bit and Spin-bit separator for the on-path observer. The connection between T bit and Spin bit
helps the correlations on the observer.</t> helps the observer correlate packet trains.</t>
<t>The client maintains a "generation token" count that is set to zero at the <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 beginning of the session and is incremented every time a packet is received
(marked or unmarked). The client also maintains a "reflection counter" that (marked or unmarked). The client also maintains a "reflection counter" that
starts at zero at the beginning of the session.</t> starts at zero at the beginning of the session.</t>
<t>The client is in charge of launching trains of marked packets and d oes so <t>The client is in charge of launching trains of marked packets and d oes so
according to the algorithm:</t> according to the algorithm:</t>
<ol spacing="normal" type="1"><li>Generation Phase. The client starts generating marked packets for two <ol spacing="normal" type="1"><li>Generation Phase. The client starts generating marked packets for two
consecutive spin-bit periods; when the client transmits a packet and a consecutive 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" is available, the client marks the packet and retires a
"generation token". If no token is available, the outgoing packet is "generation token". If no token is available, the outgoing packet is
transmitted unmarked. At the end of the first spin-bit period spent in transmitted unmarked. At the end of the first Spin bit period spent in
generation, the reflection counter is unlocked to start counting incoming generation, the reflection counter is unlocked to start counting incoming
marked packets that will be reflected later;</li> marked packets that will be reflected later.</li>
<li>Pause Phase. When the generation is completed, the client pauses till it has <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 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 period is used by the observer as a separator between generated and
reflected packets. During this marking pause, all the outgoing packets are reflected packets. During this marking pause, all the outgoing packets are
transmitted with T bit set to 0. The reflection counter is still transmitted with T bit set to 0. The reflection counter is still
incremented every time a marked packet arrives;</li> incremented every time a marked packet arrives.</li>
<li>Reflection Phase. The client starts transmitting marked packets, <li>Reflection Phase. The client starts transmitting marked packets,
decrementing the reflection counter for each transmitted marked packet until decrementing the reflection counter for each transmitted marked packet until
the reflection counter reached zero. The "generation token" method from the the reflection counter has reached zero. The "generation token" method from the
generation phase is used during this phase as well. At the end of the first Generation Phase is used during this phase as well. At the end of the first
spin-period spent in reflection, the reflection counter is locked to avoid Spin bit period spent in reflection, the reflection counter is locked to avoid
incoming reflected packets incrementing it;</li> incoming reflected packets incrementing it.</li>
<li>Pause Phase 2. The pause phase is repeated after the reflection <li>Pause Phase 2. The Pause Phase is repeated after the Reflection
phase and Phase and
serves as a separator between the reflected packet train and a new packet serves as a separator between the reflected packet train and a new packet
train.</li> train.</li>
</ol> </ol>
<t>The generation token counter should be capped to limit the effects of a <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 subsequent sudden reduction in the other endpoint's packet rate that could
prevent that endpoint from reflecting collected packets. It is recommended a prevent that endpoint from reflecting collected packets. A
cap value of <tt>1</tt>.</t> cap value of 1 is recommended.</t>
<t>A server maintains a "marking counter" that starts at zero and is i ncremented <t>A server maintains a "marking counter" that starts at zero and is i ncremented
every time a marked packet arrives. When the server transmits a packet and the 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" is positive, the server marks the packet and decrements the
"marking counter". If the "marking counter" is zero, the outgoing packet is "marking counter". If the "marking counter" is zero, the outgoing packet is
transmitted unmarked.</t> transmitted unmarked.</t>
<t>Note that a choice of 2-RTT (two spin periods) for the generation p <t>Note that a choice of 2 RTT (two Spin bit periods) for the Generati
hase is a on Phase is a
tradeoff between the percentage of marked packets (i.e. the percentage of trade-off between the percentage of marked packets (i.e., the percentage of
traffic monitored) and the measurement delay. Using this value the algorithm traffic monitored) and the measurement delay. Using this value, the algorithm
produces a measurement approximately every 6-RTT (<tt>2</tt> generation, <tt>~2< produces a measurement approximately every 6 RTT (2 generations, ~2
/tt> reflections, 2 pauses), marking ~1/3 of packets exchanged in the slower
reflection, <tt>2</tt> pauses), marking <tt>~1/3</tt> of packets exchanged in th direction (see <xref target="tbit-losscov"/>). Choosing a Generation Phase of 1
e slower RTT, we would
direction (see <xref target="tbit-losscov"/>). Choosing a generation phase of 1- produce measurements every 4 RTT, monitoring ~1/4 of packets in the
RTT, we would
produce measurements every 4-RTT, monitoring just <tt>~1/4</tt> of packets in th
e
slower direction.</t> slower direction.</t>
<t>It is worth mentioning that problems can happen in some cases espec <t>It is worth mentioning that problems can happen in some cases, espe
ially if the cially if the
rate suddenly changes, but in the implementation, the mechanism here described rate suddenly changes, but the mechanism described here
worked well with normal traffic conditions.</t> worked well with normal traffic conditions in the implementation.</t>
</section> </section>
<section anchor="observers-logic-for-round-trip-loss-signal"> <section anchor="observers-logic-for-round-trip-loss-signal">
<name>Observer's Logic for Round Trip Loss Signal</name> <name>Observer's Logic for Round-Trip Loss Signal</name>
<t>The on-path observer counts marked packets and separates different trains by <t>The on-path observer counts marked packets and separates different trains by
detecting spin-bit periods (at least one) with no marked packets. The Round detecting Spin bit periods (at least one) with no marked packets. The Round-Tri
Trip Packet Loss (RTPL) is the difference between the size of the Generation p Packet Loss (RTPL) is the difference between the size of the Generation
train and the Reflection train.</t> train and the Reflection train.</t>
<t>In the following example, packets are represented by two bits (firs t one <t>In the following example, packets are represented by two bits (firs t one
is the Spin bit, second one is the round Trip loss bit):</t> is the Spin bit, second one is the round-Trip loss bit):</t>
<figure> <figure>
<name>Round Trip Loss signal example</name> <name>Round-Trip Loss Signal Example</name>
<artwork><![CDATA[ <artwork><![CDATA[
Generation Pause Reflection Pause 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 01 01 00 01 11 10 11 00 00 10 10 10 01 00 01 01 10 11 10 00 00 10
]]></artwork> ]]></artwork>
</figure> </figure>
<t>Note that 5 marked packets have been generated of which 4 have been reflected.</t> <t>Note that 5 marked packets have been generated, of which 4 have bee n reflected.</t>
</section> </section>
<section anchor="tbit-losscov"> <section anchor="tbit-losscov">
<name>Loss Coverage and Signal Timing</name> <name>Loss Coverage and Signal Timing</name>
<t>A cycle of the round Trip loss signaling algorithm contains 2 RTTs <t>A cycle of the round-Trip loss signaling algorithm contains 2 RTTs
of Generation of Generation
phase, 2 RTTs of Reflection phase, and two Pause phases at least 1 RTT in phase, 2 RTTs of Reflection Phase, and 2 Pause Phases at least 1 RTT in
duration each. Hence, the loss signal is delayed by about 6 RTTs since the loss duration each. Hence, the loss signal is delayed by about 6 RTTs since the loss
events.</t> events.</t>
<t>The observer can only detect loss of marked packets that occurs aft <t>The observer can only detect the loss of marked packets that occurs
er its after its
initial observation of the Generation phase and before its subsequent initial observation of the Generation Phase and before its subsequent
observation of the Reflection phase. Hence, if the loss occurs on the path that observation of the Reflection Phase. Hence, if the loss occurs on the path that
sends packets at a lower rate (typically ACKs in such asymmetric scenarios), sends packets at a lower rate (typically ACKs in such asymmetric scenarios),
<tt>2/6</tt> (<tt>1/3</tt>) of the packets will be sampled for loss detection.</ t> 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, <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 los s <tt>lowPacketRate/(3*highPacketRate)</tt> of the packets will be sampled for los s
detection. For protocols that use ACKs, the portion of packets 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 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, <tt>1/(3*packetsPerAck)</tt>, where the value of <tt>packetsPerAck</tt> can vary by protocol,
by implementation, and by network conditions.</t> by implementation, and by network conditions.</t>
</section> </section>
</section> </section>
<section anchor="squarebit"> <section anchor="squarebit">
<name>Q Bit -- sQuare Bit</name> <name>Q Bit -- sQuare Bit</name>
<t>The sQuare bit (Q bit) takes its name from the square wave generated by its <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="AltMa signal. This method is based on the Alternate-Marking method <xref target="RFC93
rk"/> and 41"/>, and
the Q bit represents the "packet color" that allows to mark consecutive blocks the Q bit represents the "packet color" that 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 of packets with different colors. This method does not require cooperation from
both endpoints.</t> both endpoints.</t>
<t><xref target="AltMark"/> introduces two variations of the Alternate-M arking method depending <t><xref target="RFC9341"/> introduces two variations of the Alternate-M arking method depending
on whether the color is switched according to a fixed timer or after a fixed on whether the color is switched according to a fixed timer or after a fixed
number of packets. The method based on fixed timer can measure packet loss on a number of packets. Cooperating and synchronized observers on either end of a net
network segment by cooperating and synchronized observers on both ends of the work
segment comparing packets counters for the same packet blocks. The time length o segment can use the fixed-timer method to measure packet loss on the
f segment by comparing packet counters for the same packet blocks. The time lengt
h of
the blocks can be chosen depending on the desired measurement frequency, but it 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 erro rs must be long enough to guarantee the proper operation with respect to clock erro rs
and network delay issues.</t> and network delay issues.</t>
<t>The Q bit method described in this document chooses the color-switchi ng method <t>The Q bit method described in this document chooses the color-switchi ng method
based on a fixed number of packets for each block. This approach has the 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 advantage that it does not require cooperating or synchronized observers or
network elements. Each probe can measure packet loss autonomously without network elements. Each probe can measure packet loss autonomously without
relying on an external Network Management System (NMS). For the purpose of the relying on an external NMS. For the purpose of the
packet loss measurement, all blocks have the same number of packets, and it is 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 necessary to detect only the loss event and not to identify the exact block with
losses.</t> losses.</t>
<t>Following the method based on fixed number of packets, the square wav e signal is <t>Following the method based on fixed number of packets, the square wav e signal is
generated by the switching of the Q bit: every outgoing packet contains the Q 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 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> 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 <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, of the traffic flow and counting the number of packets in each observed Q Block,
as described in <xref target="upstreamloss"/>.</t> as described in <xref target="upstreamloss"/>.</t>
<section anchor="q-block-length-selection"> <section anchor="q-block-length-selection">
<name>Q Block Length Selection</name> <name>Q Block Length Selection</name>
<t>The length of the block must be known to the on-path network probes . There are <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 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 the length is known a priori and therefore set within the protocol
specifications that implements the marking mechanism. The second requires the specifications that implement the marking mechanism. The second requires the
sender to select it.</t> sender to select it.</t>
<t>In this latter scenario, the sender is expected to choose N (Q Bloc k <t>In this latter scenario, the sender is expected to choose N (Q Bloc k
length) based on the expected amount of loss and reordering on the length) based on the expected amount of loss and reordering on the
path. The choice of N strikes a compromise -- the observation could path. The choice of N strikes a compromise -- the observation could
become too unreliable in case of packet reordering and/or severe loss 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 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> 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 requ irement allows <t>The value of N should be at least 64 and be a power of 2. This requ irement allows
an Observer to infer the Q Block length by observing one period of the square an observer to infer the Q Block length by observing one period of the square
signal. It also allows the Observer to identify flows that set the loss bits to signal. It also allows the observer to identify flows that set the loss bits to
arbitrary values (see <xref target="ossification"/>).</t> arbitrary values (see <xref target="ossification"/>).</t>
<t>If the sender does not have sufficient information to make an infor med decision <t>If the sender does not have sufficient information to make an infor med decision
about Q Block length, the sender should use N=64, since this value has been 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. 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, 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 increasing the chances of using a Q Block length that gives the best signal for
some flows.</t> some flows.</t>
<t>The sender must keep the value of N constant for a given flow.</t> <t>The sender must keep the value of N constant for a given flow.</t>
</section> </section>
<section anchor="upstreamloss"> <section anchor="upstreamloss">
skipping to change at line 821 skipping to change at line 832
<t>Blocks of N (Q Block length) consecutive packets are sent with the same <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 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 inverted value of the Q bit. Hence, knowing the value of N, an
on-path observer can estimate the amount of upstream loss after 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 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 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> 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 ca n <t>The observer needs to be able to tolerate packet reordering that ca n
blur the edges of the square signal, as explained in <xref target="endmarkingblo ck"/>.</t> blur the edges of the square signal, as explained in <xref target="endmarkingblo ck"/>.</t>
<figure> <figure>
<name>Upstream loss</name> <name>Upstream Loss</name>
<artwork><![CDATA[ <artwork><![CDATA[
=====================> =====================>
********** -----Obs----> ********** ********** -----Obs----> **********
* Client * * Server * * Client * * Server *
********** <------------ ********** ********** <------------ **********
(a) in client-server channel (uloss_up) (a) in client-server channel (uloss_up)
********** ------------> ********** ********** ------------> **********
* Client * * Server * * Client * * Server *
skipping to change at line 848 skipping to change at line 859
</section> </section>
<section anchor="endmarkingblock"> <section anchor="endmarkingblock">
<name>Identifying Q Block Boundaries</name> <name>Identifying Q Block Boundaries</name>
<t>Packet reordering can produce spurious edges in the square signal. To address <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 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 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> "Marking Block Threshold", should be less than <tt>N/2</tt>.</t>
<t>The choice of X represents a trade-off between resiliency to reorde ring and <t>The choice of X represents a trade-off between resiliency to reorde ring and
resiliency to loss. A very large Marking Block Threshold will be able to 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 reconstruct Q Blocks despite a significant amount of reordering, but it may
erroneously coalesce packets from multiple Q Blocks into fewer Q Blocks, if loss erroneously coalesce packets from multiple Q Blocks into fewer Q Blocks if loss
exceeds 50% for some Q Blocks.</t> exceeds 50% for some Q Blocks.</t>
<section anchor="Qburst"> <section anchor="Qburst">
<name>Improved Resilience to Burst Losses</name> <name>Improved Resilience to Burst Losses</name>
<t>Burst losses can affect Q measurements accuracy. Generally, burst losses can be <t>Burst losses can affect the accuracy of Q measurements. Generally , burst losses can be
absorbed and correctly measured if smaller than the established Q Block absorbed and correctly measured if smaller than the established Q Block
length. If entire Q Block length of packets get lost in a burst, however, the length. If the entire Q Block length of packets is lost in a burst, however, the
observer may be left completely unaware of the loss.</t> observer may be left completely unaware of the loss.</t>
<t>To improve burst loss resilience, an observer may consider a rece ived Q Block <t>To improve burst loss resilience, an observer may consider a rece ived Q Block
larger than the selected Q Block length as an indication of a burst loss 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 Q Block length event. The observer would then compute the loss as three times the Q Block lengt h
minus the measured block length. By doing so, the observer can detect burst 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 Q Block length 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 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 remain unnoticed by the observer (or underestimated if a period longer than Q
Block length were formed).</t> Block length were formed).</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="lossbit"> <section anchor="lossbit">
<name>L Bit -- Loss Event Bit</name> <name>L Bit -- Loss Event Bit</name>
<t>The Loss Event bit uses an Unreported Loss counter maintained by the protocol <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 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 must allow the sender to identify lost packets. This is true of protocols such
as QUIC, partially true for TCP and SCTP (losses of pure ACKs are not detected) as QUIC, partially true for TCP and Stream Control Transmission Protocol (SCTP) (losses of pure ACKs are not detected),
and is not true of protocols such as UDP and IPv4/IPv6.</t> and is not true of protocols such as UDP and IPv4/IPv6.</t>
<t>The Unreported Loss counter is initialized to 0, and L bit of every o utgoing <t>The Unreported Loss counter is initialized to 0, and the L bit of eve ry outgoing
packet indicates whether the Unreported Loss counter is positive (L=1 if the packet indicates whether the Unreported Loss counter is positive (L=1 if the
counter is positive, and L=0 otherwise).</t> counter is positive, and L=0 otherwise).</t>
<t>The value of the Unreported Loss counter is decremented every time a packet <t>The value of the Unreported Loss counter is decremented every time a packet
with L=1 is sent.</t> with L=1 is sent.</t>
<t>The value of the Unreported Loss counter is incremented for every pac ket that <t>The value of the Unreported Loss counter is incremented for every pac ket that
the protocol declares lost, using whatever loss detection machinery the protocol the protocol declares lost, using whatever loss detection machinery the protocol
employs. If the protocol is able to rescind the loss determination later, a employs. If the protocol is able to rescind the loss determination later, a
positive Unreported Loss counter may be decremented due to the rescission. 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 happ en In general, it should not become negative due to the rescission, but it can happ en
in few cases.</t> in few cases.</t>
<t>This loss signaling is similar to loss signaling in <xref target="Con <t>This loss signaling is similar to loss signaling in <xref target="RFC
Ex"/>, except the Loss 7713"/>, except that the Loss
Event bit is reporting the exact number of lost packets, whereas Echo Loss bit Event bit is reporting the exact number of lost packets, whereas the signal mech
in <xref target="ConEx"/> is reporting an approximate number of lost bytes.</t> anism
<t>For protocols, such as TCP (<xref target="TCP"/>), that allow network in <xref target="RFC7713"/> is reporting an approximate number of lost bytes.</t
devices to change data >
<t>For protocols, such as TCP <xref target="RFC9293"/>, that allow netwo
rk devices to change data
segmentation, it is possible that only a part of the packet is lost. In these segmentation, it is possible that only a part of the packet is lost. In these
cases, the sender must increment Unreported Loss counter by the fraction of the cases, the sender must increment the Unreported Loss counter by the fraction of
packet data lost (so Unreported Loss counter may become negative when a packet the
packet data lost (so the Unreported Loss counter may become negative when a pack
et
with L=1 is sent after a partial packet has been lost).</t> 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 <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 upstream endpoint, by counting packets in this direction with the L bit equal to
1, as described in <xref target="endtoendloss"/>.</t> 1, as described in <xref target="endtoendloss"/>.</t>
<section anchor="endtoendloss"> <section anchor="endtoendloss">
<name>End-To-End Loss</name> <name>End-To-End Loss</name>
<t>The Loss Event bit allows an observer to estimate the end-to-end lo ss rate by <t>The Loss Event bit allows an observer to estimate the end-to-end lo ss rate by
counting packets with L bit value of 0 and 1 for a given flow. The end-to-end counting packets with L bit values of 0 and 1 for a given flow. The end-to-end
loss ratio is the fraction of packets with L=1.</t> 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 <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 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 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 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> that they have a greater chance of arriving at the observer.</t>
<section anchor="loss-profile"> <section anchor="loss-profile">
<name>Loss Profile Characterization</name> <name>Loss Profile Characterization</name>
<t>The Loss Event bit allows an observer to characterize loss profil <t>The Loss Event bit allows an observer to characterize the loss pr
e, since the ofile, since the
distribution of observed packets with L bit set to 1 roughly corresponds to the distribution of observed packets with the L bit set to 1 roughly corresponds to
distribution of packets lost between 1 RTT and 1 RTO before (see the
<xref target="loss-correlation"/>). Hence, observing random single instances of distribution of packets lost between 1 RTT and 1 retransmission timeout (RTO) be
L bit set fore (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 to 1 indicates random single packet loss, while observing blocks of packets
with L bit set to 1 indicates loss affecting entire blocks of packets.</t> with the L bit set to 1 indicates loss affecting entire blocks of packets.</t>
</section> </section>
</section> </section>
<section anchor="lq-bits-loss-measurement-using-l-and-q-bits"> <section anchor="lq-bits-loss-measurement-using-l-and-q-bits">
<name>L+Q Bits -- Loss Measurement Using L and Q Bits</name> <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 <t>Combining L and Q bits allows a passive observer watching a single direction of
traffic to accurately measure:</t> traffic to accurately measure:</t>
<ul spacing="normal"> <dl>
<li>upstream loss: sender-to-observer loss (see <xref target="upstre <dt>upstream loss:</dt>
amloss"/>)</li> <dd>sender-to-observer loss (see <xref target="upstreamloss"/>)</dd>
<li>downstream loss: observer-to-receiver loss (see <xref target="do <dt>downstream loss:</dt>
wnstreamloss"/>)</li> <dd>observer-to-receiver loss (see <xref target="downstreamloss"/>)<
<li>end-to-end loss: sender-to-receiver loss on the observed path (s /dd>
ee <dt>end-to-end loss:</dt>
<xref target="endtoendloss"/>) with loss profile characterization (see <xref tar <dd>sender-to-receiver loss on the observed path (see
get="loss-profile"/>)</li> <xref target="endtoendloss"/>) with loss profile characterization (see <xref tar
</ul> get="loss-profile"/>)</dd>
</dl>
<section anchor="loss-correlation"> <section anchor="loss-correlation">
<name>Correlating End-to-End and Upstream Loss</name> <name>Correlating End-to-End and Upstream Loss</name>
<t>Upstream loss is calculated by observing packets that did not suf fer the <t>Upstream loss is calculated by observing packets that did not suf fer the
upstream loss (<xref target="upstreamloss"/>). End-to-end loss, however, is calc ulated by upstream loss (<xref target="upstreamloss"/>). End-to-end loss, however, is calc ulated by
observing subsequent packets after the sender's protocol detected the loss. 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 Hence, end-to-end loss is generally observed with a delay of between 1 RTT (loss
declared due to multiple duplicate acknowledgements) and 1 RTO (loss declared declared due to multiple duplicate acknowledgments) and 1 RTO (loss declared
due to a timeout) relative to the upstream loss.</t> due to a timeout) relative to the upstream loss.</t>
<t>The flow RTT can sometimes be estimated by timing protocol handsh ake <t>The flow RTT can sometimes be estimated by timing the protocol ha ndshake
messages. This RTT estimate can be greatly improved by observing a dedicated messages. This RTT estimate can be greatly improved by observing a dedicated
protocol mechanism for conveying RTT information, such as the Spin bit (see protocol mechanism for conveying RTT information, such as the Spin bit (see
<xref target="spinbit"/>) or Delay bit (see <xref target="delaybit"/>).</t> <xref target="spinbit"/>) or Delay bit (see <xref target="delaybit"/>).</t>
<t>Whenever the observer needs to perform a computation that uses bo th upstream and <t>Whenever the observer needs to perform a computation that uses bo th upstream and
end-to-end loss rate measurements, it should use upstream loss rate leading the end-to-end loss rate measurements, it should consider the upstream loss rate lea ding the
end-to-end loss rate by approximately 1 RTT. If the observer is unable to 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 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> 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 <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 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="observer loss"/>. If packet reordering or there is observer loss, described in <xref target="observer loss"/>. If
this happens, the observer should adjust the calculated upstream loss rate to this happens, the observer should adjust the calculated upstream loss rate to
match end-to-end loss rate, unless the following applies.</t> 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 l osses of pure <t>In case of a protocol, such as TCP or SCTP, that does not track l osses of pure
ACK packets, observing a direction of traffic dominated by pure ACK packets 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 could result in measured upstream loss that is higher than measured end-to-end
loss, if said pure ACK packets are lost upstream. Hence, if the measurement is 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 applied to such protocols, and the observer can confirm that pure ACK packets
dominate the observed traffic direction, the observer should adjust the dominate the observed traffic direction, the observer should adjust the
calculated end-to-end loss rate to match upstream loss rate.</t> calculated end-to-end loss rate to match upstream loss rate.</t>
</section> </section>
<section anchor="downstreamloss"> <section anchor="downstreamloss">
<name>Downstream Loss</name> <name>Downstream Loss</name>
<t>Because downstream loss affects only those packets that did not s uffer upstream <t>Because downstream loss affects only those packets that did not s uffer upstream
loss, the end-to-end loss rate (<tt>eloss</tt>) relates to the upstream loss rat e loss, the end-to-end loss rate (<tt>eloss</tt>) relates to the upstream loss rat e
(<tt>uloss</tt>) and downstream loss rate (<tt>dloss</tt>) as <tt>(1-uloss)(1-dl oss)=1-eloss</tt>. (<tt>uloss</tt>) and downstream loss rate (<tt>dloss</tt>) as <tt>(1-uloss)(1-dl oss)=1-eloss</tt>.
Hence, <tt>dloss=(eloss-uloss)/(1-uloss)</tt>.</t> Hence, <tt>dloss=(eloss-uloss)/(1-uloss)</tt>.</t>
</section> </section>
<section anchor="observerloss"> <section anchor="observerloss">
<name>Observer Loss</name> <name>Observer Loss</name>
<t>A typical deployment of a passive observation system includes a n etwork tap <t>A typical deployment of a passive observation system includes a n etwork tap
device that mirrors network packets of interest to a device that performs 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 analysis and measurement on the mirrored packets. The observer loss is the loss
that occurs on the mirror path.</t> that occurs on the mirror path.</t>
<t>Observer loss affects upstream loss rate measurement, since it ca uses the <t>Observer loss affects the upstream loss rate measurement since it causes the
observer to account for fewer packets in a block of identical Q bit values (see 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, i s unaffected <xref target="upstreamloss"/>). The end-to-end loss rate measurement, however, i s unaffected
by the observer loss, since it is a measurement of the fraction of packets with by the observer 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 the L bit value of 1, and the observer loss would affect all packets equally
(see <xref target="endtoendloss"/>).</t> (see <xref target="endtoendloss"/>).</t>
<t>The need to adjust the upstream loss rate down to match end-to-en d loss rate as <t>The need to adjust the upstream loss rate down to match the end-t o-end loss rate as
described in <xref target="loss-correlation"/> is an indication of the observer loss, whose 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 magnitude is between the amount of such adjustment and the entirety of the
upstream loss measured in <xref target="upstreamloss"/>. Alternatively, a high a pparent upstream loss measured in <xref target="upstreamloss"/>. Alternatively, a high a pparent
upstream loss rate could be an indication of significant packet reordering, upstream loss rate could be an indication of significant packet reordering,
possibly due to packets belonging to a single flow being multiplexed over possibly due to packets belonging to a single flow being multiplexed over
several upstream paths with different latency characteristics.</t> several upstream paths with different latency characteristics.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="refsquarebit"> <section anchor="refsquarebit">
<name>R Bit -- Reflection Square Bit</name> <name>R Bit -- Reflection Square Bit</name>
<t>R bit requires a deployment alongside Q bit. Unlike the square signal for which <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 packets are transmitted in blocks of fixed size, the number of packets in
Reflection square signal blocks (also an Alternate-Marking signal) varies Reflection square blocks (also an Alternate-Marking signal) varies
according to these rules:</t> according to these rules:</t>
<ul spacing="normal"> <ul spacing="normal">
<li>when the transmission of a new block starts, its size is set equal <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> to the size of the last Q Block whose reception has been completed; and</li>
<li>if, before transmission of the block is terminated, the reception <li>if the reception of at least one further Q Block is completed befo
of at least one further Q Block is completed, the size of the block re 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> is updated to be the average size of the further received Q Blocks.</li>
</ul> </ul>
<t>The Reflection square value is initialized to 0 and is applied to the R bit of <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 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 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 (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 reflectio n detected within this first Q Block (<tt>p</tt>), is used to generate a reflectio n
square signal that toggles every <tt>M=p</tt> packets (at first). This new signa l square signal that toggles every <tt>M=p</tt> packets (at first). This new signa l
produces blocks of M packets (marked using the R bit) and each of them is produces blocks of M packets (marked using the R bit) and each of them is
called "Reflection Block" (R Block).</t> called "Reflection Block" (Reflection Block).</t>
<t>The M value is then updated every time a completed Q Block in the <t>The M value is then updated every time a completed Q Block in the
incoming square signal is received, following this formula: incoming square signal is received, following this formula:
<tt>M=round(avg(p))</tt>.</t> <tt>M=round(avg(p))</tt>.</t>
<t>The parameter <tt>avg(p)</tt>, the average number of packets in a mar king <t>The parameter <tt>avg(p)</tt>, the average number of packets in a mar king
period, is computed based on all the Q Blocks received since the period, is computed based on all the Q Blocks received since the
beginning of the current R Block.</t> beginning of the current Reflection Block.</t>
<t>The transmission of an R Block is considered complete (and the signal <t>The transmission of a Reflection Block is considered complete (and th
toggled) e signal toggled)
when the number of packets transmitted in that block is at least the latest when the number of packets transmitted in that block is at least the latest
computed M value.</t> computed M value.</t>
<t>To ensure a proper computation of the M value, endpoints implementing the R bit <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 must identify the boundaries of incoming Q Blocks. The same approach described
in <xref target="endmarkingblock"/> should be used.</t> in <xref target="endmarkingblock"/> should be used.</t>
<t>Looking at the R bit, unidirectional observation points have an indic ation of <t>By looking at the R bit, unidirectional observation points have an in dication of
loss experienced by the entire unobserved channel plus the loss on the path loss experienced by the entire unobserved channel plus the loss on the path
from the sender to them.</t> from the sender to them.</t>
<t>Since the Q Block is sent in one direction, and the corresponding ref lected R <t>Since the Q Block is sent in one direction, and the corresponding ref lected R
Block is sent in the opposite direction, the reflected R signal is transmitted 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 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 is the slowest, there can be multiple Q Blocks transmitted in the unobserved
direction before a complete R Block is transmitted in the observed direction. If direction before a complete Reflection Block is transmitted in the observed dire ction. If
the unobserved direction is the slowest, the observed direction can be sending R 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 Blocks of the same size repeatedly before it can update the signal to account
for a newly-completed Q Block.</t> for a newly completed Q Block.</t>
<section anchor="enhancement-of-r-block-length-computation"> <section anchor="enhancement-of-r-block-length-computation">
<name>Enhancement of R Block Length Computation</name> <name>Enhancement of Reflection Block Length Computation</name>
<t>The use of the rounding function used in the M computation introduc es errors <t>The use of the rounding function used in the M computation introduc es errors
that can be minimized by storing the rounding applied each time M is computed, that can be minimized by storing the rounding applied each time M is computed
and using it during the computation of the M value in the following R Block.</t> and using it during the computation of the M value in the following Reflection B
<t>This can be achieved introducing the new <tt>r_avg</tt> parameter i lock.</t>
n the computation of <t>This can be achieved by introducing the new <tt>r_avg</tt> paramete
r in the computation of
M. The new formula is <tt>Mr=avg(p)+r_avg; M=round(Mr); r_avg=Mr-M</tt> where t he M. The new formula is <tt>Mr=avg(p)+r_avg; M=round(Mr); r_avg=Mr-M</tt> where t he
initial value of <tt>r_avg</tt> is equal to 0.</t> initial value of <tt>r_avg</tt> is equal to 0.</t>
</section> </section>
<section anchor="improved-resilience-to-packet-reordering"> <section anchor="improved-resilience-to-packet-reordering">
<name>Improved Resilience to Packet Reordering</name> <name>Improved Resilience to Packet Reordering</name>
<t>When a protocol implementing the marking mechanism is able to detec t when <t>When a protocol implementing the marking mechanism is able to detec t when
packets are received out of order, it can improve resilience to packet packets are received out of order, it can improve resilience to packet
reordering beyond what is possible using methods described in reordering beyond what is possible by using methods described in
<xref target="endmarkingblock"/>.</t> <xref target="endmarkingblock"/>.</t>
<t>This can be achieved by updating the size of the current R Block wh <t>This can be achieved by updating the size of the current Reflection
ile it is Block while it is
being transmitted. The reflection block size is then updated every time an being transmitted. The Reflection Block size is then updated every time an
incoming reordered packet of the previous Q Block is detected. This can be 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 is in done if and only if the transmission of the current Reflection Block is in
progress and no packets of the following Q Block have been received.</t> progress and no packets of the following Q Block have been received.</t>
<section anchor="Rburst"> <section anchor="Rburst">
<name>Improved Resilience to Burst Losses</name> <name>Improved Resilience to Burst Losses</name>
<t>Burst losses can affect R measurements accuracy similarly to how <t>Burst losses can affect the accuracy of R measurements similar to
they affect Q how they affect
measurements accuracy. Therefore, recommendations in section <xref target="Qburs accuracy of Q measurements. Therefore, recommendations in <xref target="Qburst"/
t"/> apply > apply
equally to improving burst loss resilience for R measurements.</t> equally to improving burst loss resilience for R measurements.</t>
</section> </section>
</section> </section>
<section anchor="rq-bits-loss-measurement-using-r-and-q-bits"> <section anchor="rq-bits-loss-measurement-using-r-and-q-bits">
<name>R+Q Bits -- Loss Measurement Using R and Q Bits</name> <name>R+Q Bits -- Loss Measurement Using R and Q Bits</name>
<t>Since both sQuare and Reflection square bits are toggled at most ev ery N packets <t>Since both sQuare and Reflection square bits are toggled at most ev ery N packets
(except for the first transition of the R bit as explained before), an on-path (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 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 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 observer can calculate different measurements depending on whether it is able to
observe a single direction of the traffic or both directions.</t> observe a single direction of the traffic or both directions.</t>
<t>Single directional observer:</t> <dl newline="true" spacing="normal">
<ul spacing="normal"> <dt>Single directional observer:</dt>
<li>upstream loss in the observed direction: the loss between the se <dd><dl newline="false" spacing="normal">
nder and the <dt>upstream loss in the observed direction:</dt>
observation point (see <xref target="upstreamloss"/>)</li> <dd>the loss between the sender and the
<li>"three-quarters" connection loss: the loss between the receiver observation point (see <xref target="upstreamloss"/>)</dd>
and <dt>"three-quarters" connection loss:</dt>
<dd>the loss between the receiver and
the sender in the unobserved direction plus the loss between the the sender in the unobserved direction plus the loss between the
sender and the observation point in the observed direction</li> sender and the observation point in the observed direction</dd>
<li>end-to-end loss in the unobserved direction: the loss between th <dt>end-to-end loss in the unobserved direction:</dt>
e <dd>the loss between the
receiver and the sender in the opposite direction</li> receiver and the sender in the opposite direction</dd>
</ul> </dl></dd>
<t>Two directions observer (same metrics seen previously applied to bo <dt>Two directions observer (same metrics seen previously applied to b
th oth
direction, plus):</t> direction, plus):</dt>
<ul spacing="normal"> <dd><dl>
<li>client-observer half round-trip loss: the loss between the clien <dt>client-observer half round-trip loss:</dt>
t <dd>the loss between the client
and the observation point in both directions</li> and the observation point in both directions</dd>
<li>observer-server half round-trip loss: the loss between the <dt>observer-server half round-trip loss:</dt>
observation point and the server in both directions</li> <dd>the loss between the
<li>downstream loss: the loss between the observation point and the observation point and the server in both directions</dd>
receiver (applicable to both directions)</li> <dt>downstream loss:</dt>
</ul> <dd>the loss between the observation point and the
receiver (applicable to both directions)</dd>
</dl></dd></dl>
<section anchor="tqloss"> <section anchor="tqloss">
<name>Three-Quarters Connection Loss</name> <name>Three-Quarters Connection Loss</name>
<t>Except for the very first block in which there is nothing to refl ect <t>Except for the very first block in which there is nothing to refl ect
(a complete Q Block has not been yet received), packets are (a complete Q Block has not been yet received), packets are
continuously R-bit marked into alternate blocks of size lower or equal continuously R-bit marked into alternate blocks of size lower or equal
than N. Knowing the value of N, an on-path observer can estimate the than N. By knowing the value of N, an on-path observer can estimate the
amount of loss occurred in the whole opposite channel plus the loss 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 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</t t>) is previous metric, the <tt>three-quarters</tt> connection loss rate (<tt>tqloss</t t>) is
one minus the average number of packets in a block of packets with the 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 > same R value (<tt>t</tt>) divided by <tt>N</tt> (<tt>tqloss=1-avg(t)/N</tt>).</t >
<figure> <figure>
<name>Three-quarters connection loss</name> <name>Three-Quarters Connection Loss</name>
<artwork><![CDATA[ <artwork><![CDATA[
=======================> =======================>
= ********** -----Obs----> ********** = ********** -----Obs----> **********
= * Client * * Server * = * Client * * Server *
= ********** <------------ ********** = ********** <------------ **********
<============================================ <============================================
(a) in client-server channel (tqloss_up) (a) in client-server channel (tqloss_up)
============================================> ============================================>
skipping to change at line 1125 skipping to change at line 1145
<t>The following metrics derive from this last metric and the upstre am <t>The following metrics derive from this last metric and the upstre am
loss produced by the Q bit.</t> loss produced by the Q bit.</t>
</section> </section>
<section anchor="end-to-end-loss-in-the-opposite-direction"> <section anchor="end-to-end-loss-in-the-opposite-direction">
<name>End-To-End Loss in the Opposite Direction</name> <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 <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 obse rved "three-quarters" connection loss (<tt>tqloss</tt>) and upstream loss in the obse rved
direction (<tt>uloss</tt>) as <tt>(1-eloss_unobserved)(1-uloss)=1-tqloss</tt>. Hence, direction (<tt>uloss</tt>) as <tt>(1-eloss_unobserved)(1-uloss)=1-tqloss</tt>. Hence,
<tt>eloss_unobserved=(tqloss-uloss)/(1-uloss)</tt>.</t> <tt>eloss_unobserved=(tqloss-uloss)/(1-uloss)</tt>.</t>
<figure> <figure>
<name>End-To-End loss in the opposite direction</name> <name>End-To-End Loss in the Opposite Direction</name>
<artwork><![CDATA[ <artwork><![CDATA[
********** -----Obs----> ********** ********** -----Obs----> **********
* Client * * Server * * Client * * Server *
********** <------------ ********** ********** <------------ **********
<========================================== <==========================================
(a) in client-server channel (eloss_down) (a) in client-server channel (eloss_down)
==========================================> ==========================================>
********** ------------> ********** ********** ------------> **********
skipping to change at line 1154 skipping to change at line 1174
<name>Half Round-Trip Loss</name> <name>Half Round-Trip Loss</name>
<t>If the observer is able to observe both directions of traffic, it is able to <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 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 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</t t>) opposite direction. For both directions, "half round-trip" loss (<tt>hrtloss</t t>)
relates to "three-quarters" connection loss (<tt>tqloss_opposite</tt>) measured in the 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 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, direction as <tt>(1-uloss)(1-hrtloss)=1-tqloss_opposite</tt>. Hence,
<tt>hrtloss=(tqloss_opposite-uloss)/(1-uloss)</tt>.</t> <tt>hrtloss=(tqloss_opposite-uloss)/(1-uloss)</tt>.</t>
<figure> <figure>
<name>Half Round-trip loss (both direction)</name> <name>Half Round-Trip Loss (Both Directions)</name>
<artwork><![CDATA[ <artwork><![CDATA[
=======================> =======================>
= ********** ------|-----> ********** = ********** ------|-----> **********
= * Client * Obs * Server * = * Client * Obs * Server *
= ********** <-----|------ ********** = ********** <-----|------ **********
<======================= <=======================
(a) client-observer half round-trip loss (hrtloss_co) (a) client-observer half round-trip loss (hrtloss_co)
=======================> =======================>
skipping to change at line 1178 skipping to change at line 1198
<======================= <=======================
(b) observer-server half round-trip loss (hrtloss_os) (b) observer-server half round-trip loss (hrtloss_os)
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
<section anchor="downstream-loss"> <section anchor="downstream-loss">
<name>Downstream Loss</name> <name>Downstream Loss</name>
<t>If the observer is able to observe both directions of traffic, it is able to <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 calculate two downstream loss measurements using either end-to-end loss and
upstream loss, similar to the calculation in <xref target="downstreamloss"/> or using "half upstream loss, similar to the calculation in <xref target="downstreamloss"/>, or "half
round-trip" loss and upstream loss in the opposite direction.</t> round-trip" loss and upstream loss in the opposite direction.</t>
<t>For the latter, <tt>dloss=(hrtloss-uloss_opposite)/(1-uloss_oppos ite)</tt>.</t> <t>For the latter, <tt>dloss=(hrtloss-uloss_opposite)/(1-uloss_oppos ite)</tt>.</t>
<figure> <figure>
<name>Downstream loss</name> <name>Downstream Loss</name>
<artwork><![CDATA[ <artwork><![CDATA[
=====================> =====================>
********** ------|-----> ********** ********** ------|-----> **********
* Client * Obs * Server * * Client * Obs * Server *
********** <-----|------ ********** ********** <-----|------ **********
(a) in client-server channel (dloss_up) (a) in client-server channel (dloss_up)
********** ------|-----> ********** ********** ------|-----> **********
* Client * Obs * Server * * Client * Obs * Server *
skipping to change at line 1206 skipping to change at line 1226
(b) in server-client channel (dloss_down) (b) in server-client channel (dloss_down)
]]></artwork> ]]></artwork>
</figure> </figure>
</section> </section>
</section> </section>
</section> </section>
<section anchor="e-bit-ecn-echo-event-bit"> <section anchor="e-bit-ecn-echo-event-bit">
<name>E Bit -- ECN-Echo Event Bit</name> <name>E Bit -- ECN-Echo Event Bit</name>
<t>While the primary focus of this document is on exposing packet loss a nd <t>While the primary focus of this document is on exposing packet loss a nd
delay, modern networks can report congestion before they are forced to delay, modern networks can report congestion before they are forced to
drop packets, as described in <xref target="ECN"/>. When transport protocols ke ep drop packets, as described in <xref target="RFC3168"/>. When transport protocol s keep
ECN-Echo feedback under encryption, this signal cannot be observed by ECN-Echo feedback under encryption, this signal cannot be observed by
the network operators. When tasked with diagnosing network the network operators. When tasked with diagnosing network
performance problems, knowledge of a congestion downstream of an performance problems, knowledge of a congestion downstream of an
observation point can be instrumental.</t> observation point can be instrumental.</t>
<t>If downstream congestion information is desired, this information can be <t>If downstream congestion information is desired, this information can be
signaled with an additional bit.</t> signaled with an additional bit.</t>
<ul spacing="normal"> <dl>
<li>E: The "ECN-Echo Event" bit is set to 0 or 1 according to the Unre <dt>E:</dt>
ported ECN <dd>The "ECN-Echo Event" bit is set to 0 or 1 according to the Unrepor
Echo counter, as explained below in <xref target="ecnbit"/>.</li> ted ECN-Echo
</ul> counter, as explained below in <xref target="ecnbit"/>.</dd>
</dl>
<section anchor="ecnbit"> <section anchor="ecnbit">
<name>Setting the ECN-Echo Event Bit on Outgoing Packets</name> <name>Setting the ECN-Echo Event Bit on Outgoing Packets</name>
<t>The Unreported ECN-Echo counter operates identically to Unreported Loss counter <t>The Unreported ECN-Echo counter operates identically to Unreported Loss counter
(<xref target="lossbit"/>), except it counts packets delivered by the network wi th CE (<xref target="lossbit"/>), except it counts packets delivered by the network wi th Congestion Experienced (CE)
markings, according to the ECN-Echo feedback from the receiver.</t> 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"/>. ECN-Echo <t>This ECN-Echo signaling is similar to ECN signaling in <xref target ="RFC7713"/>. The ECN-Echo
mechanism in QUIC provides the number of packets received with CE marks. For mechanism in QUIC provides the number of packets received with CE marks. For
protocols like TCP, the method described in <xref target="ConEx-TCP"/> can be em protocols like TCP, the method described in <xref target="RFC7786"/> can be empl
ployed. As oyed. As
stated in <xref target="ConEx-TCP"/>, such feedback can be further improved usin stated in <xref target="RFC7786"/>, such feedback can be further improved using
g a method a method
described in <xref target="ACCURATE-ECN"/>.</t> described in <xref target="I-D.ietf-tcpm-accurate-ecn"/>.</t>
</section> </section>
<section anchor="ech-usage"> <section anchor="ech-usage">
<name>Using E Bit for Passive ECN-Reported Congestion Measurement</nam e> <name>Using E Bit for Passive ECN-Reported Congestion Measurement</nam e>
<t>A network observer can count packets with CE codepoint and determin e the <t>A network observer can count packets with the CE codepoint and dete rmine the
upstream CE-marking rate directly.</t> upstream CE-marking rate directly.</t>
<t>Observation points can also estimate ECN-reported end-to-end conges tion by <t>Observation points can also estimate ECN-reported end-to-end conges tion by
counting packets in this direction with an E bit equal to 1.</t> 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 <t>The upstream CE-marking rate and end-to-end ECN-reported congestion can provide
information about downstream CE-marking rate. Presence of E bits along with L information about the downstream CE-marking rate. The presence of E bits along w ith L
bits, however, can somewhat confound precise estimates of upstream and bits, however, can somewhat confound precise estimates of upstream and
downstream CE-markings in case the flow contains packets that are not downstream CE markings if the flow contains packets that are not
ECN-capable.</t> ECN capable.</t>
</section> </section>
<section anchor="multiple-e-bits"> <section anchor="multiple-e-bits">
<name>Multiple E Bits</name> <name>Multiple E Bits</name>
<t>Some protocols, such as QUIC, support separate ECN-Echo counters. F or example, <t>Some protocols, such as QUIC, support separate ECN-Echo counters. F or example,
Section 13.4.1 of <xref target="QUIC-TRANSPORT"/> describes separate counters fo r ECT(0), <xref 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 ECT(1), and ECN-CE. To better support such protocols, multiple E bits can be
used, one per a corresponding ECN-Echo counter.</t> used, one per a corresponding ECN-Echo counter.</t>
</section> </section>
</section> </section>
</section> </section>
<section anchor="summary-of-delay-and-loss-marking-methods"> <section anchor="summary-of-delay-and-loss-marking-methods">
<name>Summary of Delay and Loss Marking Methods</name> <name>Summary of Delay and Loss Marking Methods</name>
<t>This section summarizes the marking methods described in this document, which <t>This section summarizes the marking methods described in this document, which
proposes a toolkit of techniques that can be used separately, partly or all proposes a toolkit of techniques that can be used separately, partly, or all
together depending on the need.</t> together depending on the need.</t>
<t>For the Delay measurement, it is possible to use the Spin bit and/or th e delay <t>For the delay measurement, it is possible to use the Spin bit and/or th e Delay
bit. A unidirectional or bidirectional observer can be used.</t> bit. A unidirectional or bidirectional observer can be used.</t>
<figure anchor="fig_summary_D"> <table anchor="fig_summary_D">
<name>Delay Comparison</name> <name>Delay Comparison</name>
<artwork><![CDATA[ <thead>
+---------------+----+------------------------+--------------------+ <tr>
| Method |# of| Available | | # of | <th rowspan="2" colspan="1">Method</th>
| |bits| Delay Metrics | Impairments | meas.| <th rowspan="2" colspan="1" align="center"># of bits</th>
| | +------------+-----------+ Resiliency | | <th rowspan="1" colspan="2" align="center">Available Delay Metric
| | | UniDir | BiDir | | | s</th>
| | | Observer | Observer | | | <th rowspan="2" colspan="1" align="center">Impairments Resiliency
+---------------+----+------------+-----------+-------------+------+ </th>
|S: Spin Bit | 1 | RTT | x2 | low | very | <th rowspan="2" colspan="1" align="center"># of meas.</th>
| | | | Half RTT | | high | </tr>
+---------------+----+------------+-----------+-------------+------+ <tr>
|D: Delay Bit | 1 | RTT | x2 | high |medium| <th align="center">UniDir Observer</th>
| | | | Half RTT | | | <th align="center">BiDir Observer</th>
+---------------+----+------------+-----------+-------------+------+ </tr>
|SD: Spin Bit & | 2 | RTT | x2 | high | very | </thead>
| Delay Bit *| | | Half RTT | | high | <tbody>
+---------------+----+------------+-----------+-------------+------+ <tr>
<td>S: Spin Bit</td>
x2 Same metric for both directions <td align="center">1</td>
* Both bits work independently; an observer could use less accurate <td align="center">RTT</td>
Spin bit measurements when Delay bit ones are unavailable <td align="center">x2, Half RTT</td>
]]></artwork> <td align="center">low</td>
</figure> <td align="center">very high</td>
<t>For the Loss measurement, each row in the table of <xref target="fig_su </tr>
mmary_L"/> <tr>
represents a loss marking method. For each method the table specifies <td>D: Delay Bit</td>
<td align="center">1</td>
<td align="center">RTT</td>
<td align="center">x2, Half RTT</td>
<td align="center">high</td>
<td align="center">medium</td>
</tr>
<tr>
<td>SD: Spin Bit &amp; Delay Bit *</td>
<td align="center">2</td>
<td align="center">RTT</td>
<td align="center">x2, Half 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</dd>
<dt>*</dt>
<dd>Both bits work independently; an observer could use less accurate S
pin bit measurements when Delay bit ones are unavailable.</dd>
</dl>
<t>For the Loss measurement, each row in <xref target="fig_summary_L"/>
represents a loss-marking method. For each method, the table specifies
the number of bits required in the header, the available metrics using the number of bits required in the header, the available metrics using
a unidirectional or bidirectional observer, applicable protocols, a unidirectional or bidirectional observer, applicable protocols,
measurement fidelity and delay.</t> measurement fidelity, and delay.</t>
<figure anchor="fig_summary_L"> <table anchor="fig_summary_L">
<name>Loss Comparison</name> <name>Loss Comparison</name>
<artwork><![CDATA[ <thead>
+-------------+-+-----------------------+-+------------------------+ <tr>
| Method |B| Available |P| Measurement Aspects | <th rowspan="2" colspan="1">Method</th>
| |i| Loss Metrics |r+------------+-----------+ <th rowspan="2" colspan="1" align="center">Bits</th>
| |t| UniDir | BiDir |t| Fidelity | Delay | <th rowspan="1" colspan="2" align="center">Available Loss Metrics
| |s| Observer | Observer |o| | | </th>
+-------------+-+-----------+-----------+-+------------+-----------+ <th rowspan="2" colspan="1" align="center">Prto</th>
|T: Round Trip|$| RT | x2 | | Rate by | ~6 RTT | <th rowspan="1" colspan="2" align="center">Measurement Aspects</t
| Loss Bit |1| | Half RT |*| sampling +-----------+ h>
| | | | | | 1/3 to 1/(3*ppa) of | </tr>
| | | | | | pkts over 2 RTT | <tr>
+-------------+-+-----------+-----------+-+------------+-----------+ <th align="center">UniDir Observer</th>
|Q: sQuare Bit|1| Upstream | x2 |*| Rate over | N pkts | <th align="center">BiDir Observer</th>
| | | | | | N pkts | (e.g. 64) | <th align="center">Fidelity</th>
| | | | | | (e.g. 64) | | <th align="center">Delay</th>
+-------------+-+-----------+-----------+-+------------+-----------+ </tr>
|L: Loss Event|1| E2E | x2 |#| Loss shape | Min: RTT | </thead>
| Bit | | | | | (and rate) | Max: RTO | <tbody>
+-------------+-+-----------+-----------+-+------------+-----------+ <tr>
|QL: sQuare + |2| Upstream | x2 | | -> see Q | Up: see Q | <td>T: Round-Trip Loss Bit</td>
| Loss Ev. | | Downstream| x2 |#| -> see Q|L | Others: | <td align="center">$1</td>
| Bits | | E2E | x2 | | -> see L | see L | <td align="center">RT</td>
+-------------+-+-----------+-----------+-+------------+-----------+ <td align="center">x2, Half RT</td>
|QR: sQuare + |2| Upstream | x2 | | Rate over | Up: see Q | <td align="center">*</td>
| Ref. Sq. | | 3/4 RT | x2 | | N*ppa pkts | Others: | <td>Rate by sampling 1/3 to 1/(3*ppa) of pkts over 2 RTT</td>
| Bits | | !E2E | E2E |*| (see Q bit | N*ppa pk | <td>~6 RTT</td>
| | | | Downstream| | for N) | (see Q | </tr>
| | | | Half RT | | | for N) | <tr>
+-------------+-+-----------+-----------+-+------------+-----------+ <td>Q: sQuare Bit</td>
<td align="center">1</td>
* All protocols <td align="center">Upstream</td>
# Protocols employing loss detection <td align="center">x2</td>
(with or without pure ACK loss detection) <td align="center">*</td>
$ Require a working Spin bit <td>Rate over N pkts (e.g., 64)</td>
! Metric relative to the opposite channel <td>N pkts (e.g., 64)</td>
x2 Same metric for both directions </tr>
ppa Packets-Per-Ack <tr>
Q|L See Q if Upstream loss is significant; L otherwise <td>L: Loss Event Bit</td>
]]></artwork> <td align="center">1</td>
</figure> <td align="center">E2E</td>
<td align="center">x2</td>
<td align="center">#</td>
<td>Loss shape (and rate)</td>
<td>Min: RTT, Max: RTO</td>
</tr>
<tr>
<td rowspan="3" colspan="1">QL: sQuare + Loss Ev. 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 + Ref. Sq. 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 (see Q bit for
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 bit for 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 d
etection)</dd>
<dt>$</dt>
<dd>Require a working Spin bit</dd>
<dt>!</dt>
<dd>Metric relative to the opposite channel</dd>
<dt>x2</dt>
<dd>Same metric for both directions</dd>
<dt>ppa</dt>
<dd>Packets-Per-Ack</dd>
<dt>Q|L</dt>
<dd>See Q if Upstream loss is significant; L otherwise</dd>
<dt>E2E</dt>
<dd>End to end</dd>
</dl>
<section anchor="implementation-considerations"> <section anchor="implementation-considerations">
<name>Implementation Considerations</name> <name>Implementation Considerations</name>
<t>By combining the information of the two tables above, it can be deduc ed that the <t>By combining the information of the two tables above, it can be deduc ed that the
solutions with 3 bits, i.e. QL or QR + S or D, or 4 bits, i.e. QL or QR + SD, solutions with 3 bits (i.e., QL or QR + S or D) or 4 bits (i.e., QL or QR + SD)
allow having more complete and resilient measurements.</t> allow having more complete and resilient measurements.</t>
<t>The methodologies described in the previous sections are transport ag nostic and <t>The methodologies described in the previous sections are transport ag nostic and
can be applied in various situations. The choice of the the methods also depends can be applied in various situations. The choice of the methods also depends
on the specific protocol, for example QL is a good combination, but, in the case on the specific protocol. For example, QL is a good combination; however, if
of a protocol which does not support or cannot set the L bit, QR is the only a protocol does not support, or cannot set, the L bit, QR is the only
viable solution.</t> viable solution.</t>
</section> </section>
</section> </section>
<section anchor="applications"> <section anchor="applications">
<name>Examples of Application</name> <name>Examples of Application</name>
<t>This document describes several measurement methods, but it is not expe cted that <t>This document describes several measurement methods, but it is not expe cted that
all methods will be implemented together. For example, only some of the methods all methods will be implemented together. For example, only some of the methods
described in this document (i.e. sQuare bit and Spin bit) are utilized in described in this document (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 Q UIC is <xref target="I-D.ietf-core-coap-pm"/>. Also, the binding of a delay signal to Q UIC is
partially described in Section 17.4 of <xref target="QUIC-TRANSPORT"/>, which ad ds only the partially described in <xref 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 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> for future use (see <xref target="RFC9000" sectionFormat="of" section="17.2.2"/>
<t>All signals discussed in this document have been implemented in succesf ).</t>
ul <t>All signals discussed in this document have been implemented in success
ful
experiments for both QUIC and TCP. The application scenarios considered allow experiments for both QUIC and TCP. The application scenarios considered allow
the monitoring of the interconnections inside data center (Intra-DC), between the monitoring of the interconnections inside a data center (Intra-DC), between
data centers (Inter-DC), as well as end-to-end large scale data transfers. For data centers (Inter-DC), as well as end-to-end large-scale data transfers. For
the application of the methods described in this document, it is assumed that the application of the methods described in this document, it is assumed that
the monitored flows follow stable paths and traverse the same measurement the monitored flows follow stable paths and traverse the same measurement
points.</t> points.</t>
<t>The specific implementation details and the choice of the bits used for the <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 experiments with QUIC and TCP are out of scope for this document. A
specification defining the specific protocol application is expected to discuss specification defining the specific protocol application is expected to discuss
the implementation details depending on which bits will be implemented in the the implementation details depending on which bits will be implemented in the
protocol, e.g. <xref target="I-D.ietf-core-coap-pm"/>. If bits used for specific protocol, e.g., <xref target="I-D.ietf-core-coap-pm"/>. If bits used for specifi c
measurements can also be used for other purposes by a protocol, the measurements can also be used for other purposes by a protocol, the
specification is expected to address ways for on-path observers to disambiguate specification is expected to address ways for on-path observers to disambiguate
the signals or to discuss limitations on the conditions under which the the signals or to discuss limitations on the conditions under which the
observers can expect a valid signal.</t> observers can expect a valid signal.</t>
</section> </section>
<section anchor="ossification"> <section anchor="ossification">
<name>Protocol Ossification Considerations</name> <name>Protocol Ossification Considerations</name>
<t>Accurate loss and delay information is not required for the operation o f any <t>Accurate loss and delay information is not required for the operation o f any
protocol, though its presence for a sufficient number of flows is important for protocol, though its presence for a sufficient number of flows is important for
the operation of networks.</t> the operation of networks.</t>
<t>The delay and loss bits are amenable to "greasing" described in <xref t arget="RFC8701"/>, if <t>The delay and loss bits are amenable to "greasing" described in <xref t arget="RFC8701"/> if
the protocol designers are not ready to dedicate (and ossify) bits used for loss 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 reporting to this function. The greasing could be accomplished similarly to the
Latency Spin bit greasing in Section 17.4 of <xref target="QUIC-TRANSPORT"/>. Fo r example, latency Spin bit greasing in <xref target="RFC9000" sectionFormat="of" section=" 17.4"/>. For example,
the protocol designers could decide that a fraction of flows should not encode the protocol designers could decide that a fraction of flows should not encode
loss and delay information and, instead, the bits would be set to arbitrary loss and delay information, and instead, the bits would be set to arbitrary
values. Setting any of the bits described in this document to arbitrary values values. Setting any of the bits described in this document to arbitrary values
would make the corresponding delay and loss information resemble noise rather 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 than the expected signal for the flow, and the observers would need to be ready
to ignore such flows.</t> to ignore such flows.</t>
</section> </section>
<section anchor="security-considerations"> <section anchor="security-considerations">
<name>Security Considerations</name> <name>Security Considerations</name>
<t>The methods described in this document are transport agnostic and poten tially <t>The methods described in this document are transport agnostic and poten tially
applicable to any transport-layer protocol, especially valuable for encrypted applicable to any transport-layer protocol, and especially valuable for encrypte
protocols. These methods can be applied to both limited domains and Internet, d
protocols. These methods can be applied to both limited domains and the Internet
,
depending on the specific protocol application.</t> depending on the specific protocol application.</t>
<t>Passive loss and delay observations have been a part of the network ope rations <t>Passive loss and delay observations have been a part of the network ope rations
for a long time, so exposing loss and delay information to the network does not 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> 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 <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 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 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 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 state. The L bit signal discloses internal state of the protocol's loss-detectio
detection machinery, but this state can often be gleaned by timing packets and n
observing congestion controller response.</t> machinery, but this state can often be gleaned by timing packets and
<t>The measurements described in this document do not imply new packets in observing the congestion controller response.</t>
jected <t>The measurements described in this document do not imply that new packe
into the network causing potential harm to the network itself and to data ts injected
into the network can cause potential harm to the network itself and to data
traffic. The measurements could be harmed by an attacker altering the marking traffic. The measurements could be harmed by an attacker altering the marking
of the packets or injecting artificial traffic. Authentication techniques may be of the packets or injecting artificial traffic. Authentication techniques may be
used where appropriate to guard against these traffic attacks.</t> used where appropriate to guard against these traffic attacks.</t>
<t>Hence, loss bits do not provide a viable new mechanism to attack data i ntegrity <t>Hence, loss bits do not provide a viable new mechanism to attack data i ntegrity
and secrecy.</t> and secrecy.</t>
<t>The measurement fields introduced in this document are intended to be i ncluded <t>The measurement fields introduced in this document are intended to be i ncluded
into the packets. But it is worth mentioning that it may be possible to use this in the packets. However, it is worth mentioning that it may be possible to use t his
information as a covert channel.</t> information as a covert channel.</t>
<t>The current document does not define a specific application, and the de scribed <t>This document does not define a specific application, and the described
techniques can generally apply to different communication protocols operating in techniques can generally apply to different communication protocols operating in
different security environments. A specification defining a specific protocol different security environments. A specification defining a specific protocol
application is expected to address the respective security considerations and application is expected to address the respective security considerations and
must consider specifics of the protocol and its expected operating environment. must consider specifics of the protocol and its expected operating environment.
For example, security considerations for QUIC, discussed in Section 21 of For example, security considerations for QUIC, discussed in
<xref target="QUIC-TRANSPORT"/> and Section 9 of <xref target="QUIC-TLS"/>, cons <xref target="RFC9000" sectionFormat="of" section="21"/> and <xref target="RFC90
ider a possibility of 01" sectionFormat="of" section="9"/>, consider a possibility of
active and passive attackers in the network as well as attacks on specific QUIC active and passive attackers in the network as well as attacks on specific QUIC
mechanisms.</t> mechanisms.</t>
<section anchor="optimistic-ack-attack"> <section anchor="optimistic-ack-attack">
<name>Optimistic ACK Attack</name> <name>Optimistic ACK Attack</name>
<t>A defense against an Optimistic ACK Attack, described in Section 21.4 <t>A defense against an optimistic ACK attack, described in
of <xref target="RFC9000" sectionFormat="of" section="21.4"/>, involves a sender ra
<xref target="QUIC-TRANSPORT"/>, involves a sender randomly skipping packet numb ndomly skipping packet numbers to detect
ers to detect
a receiver acknowledging packet numbers that have never been received. The Q bit 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 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 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 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 at least an entire Q Block of packets, which renders the attack ineffective
against a delay-sensitive congestion controller.</t> against a delay-sensitive congestion controller.</t>
<t>A protocol that is more susceptible to an Optimistic ACK Attack with <t>A protocol that is more susceptible to an optimistic ACK attack with
the loss the loss
signal provided by Q bit and uses a loss-based congestion controller, should signal provided by the Q bit and that uses a loss-based congestion controller sh
ould
shorten the current Q Block by the number of skipped packets numbers. For exampl e, shorten the current Q Block by the number of skipped packets numbers. For exampl e,
skipping a single packet number will invert the square signal one outgoing skipping a single packet number will invert the square signal one outgoing
packet sooner.</t> packet sooner.</t>
<t>Similar considerations apply to the R bit, although a shortened R Blo ck along <t>Similar considerations apply to the R bit, although a shortened Refle ction Block along
with a matching skip in packet numbers does not necessarily imply a lost 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 packet, since it could be due to a lost packet on the reverse path along with a
deliberately skipped packet by the sender.</t> deliberately skipped packet by the sender.</t>
</section> </section>
<section anchor="delay-bit-with-rtt-obfuscation"> <section anchor="delay-bit-with-rtt-obfuscation">
<name>Delay Bit with RTT Obfuscation</name> <name>Delay Bit with RTT Obfuscation</name>
<t>Theoretically, delay measurements can be used to roughly evaluate the distance <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 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 (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 RTT measurements for geolocating endpoints are usually inferior to even the
most basic IP geolocation databases. It is the variability within RTT most basic IP geolocation databases. It is the variability within RTT
measurements (the jitter) that is most informative, as it can provide insight 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 into the operating environment of the endpoints as well as the state of the
networks (queuing delays) used by the connection.</t> networks (queuing delays) used by the connection.</t>
<t>Nevertheless, to further mask the actual RTT of the connection, the D elay bit <t>Nevertheless, to further mask the actual RTT of the connection, the D elay bit
algorithm can be slightly modified by, for example, delaying the client-side algorithm can be slightly modified by, for example, delaying the client-side
reflection of the delay sample by a fixed randomly chosen time value. This reflection of the delay sample by a fixed, randomly chosen time value. This
would lead an intermediate observer to measure a delay greater than the real would lead an intermediate observer to measure a delay greater than the real
one.</t> one.</t>
<t>This Additional Delay should be randomly selected by the client and k ept <t>This Additional Delay should be randomly selected by the client and k ept
constant for a certain amount of time across multiple connections. This ensures 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 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 been inserted. For example, a new Additional Delay value could be generated
whenever the client's IP address changes.</t> whenever the client's IP address changes.</t>
<t>Despite the Additional Delay, this Hidden Delay technique still allow s an <t>Despite the Additional Delay, this Hidden Delay technique still allow s an
accurate measurement of the RTT components (observer-server) and all the accurate measurement of the RTT components (observer-server) and all the
intra-domain measurements used to distribute the delay in the network. intra-domain measurements used to distribute the delay in the network.
Furthermore, unlike the Delay bit, the Hidden Delay bit does not require the Furthermore, unlike the Delay bit, the Hidden Delay bit does not require the
use of the client reflection threshold (1ms by default). Removing this use of the client reflection threshold (1 ms by default). Removing this
threshold may lead to increasing the number of valid measurements produced by threshold may lead to increasing the number of valid measurements produced by
the algorithm.</t> the algorithm.</t>
<t>Note that Hidden Delay bit does not affect an observer's ability to m easure <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 accurate RTT using other means, such as timing packets exchanged during the
connection establishment.</t> connection establishment.</t>
</section> </section>
</section> </section>
<section anchor="privacy-considerations"> <section anchor="privacy-considerations">
<name>Privacy Considerations</name> <name>Privacy Considerations</name>
<t>To minimize unintentional exposure of information, loss bits provide an explicit <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> 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 <t>New protocols commonly have specific privacy goals, and loss reporting must
ensure that loss information does not compromise those privacy goals. For ensure that loss information does not compromise those privacy goals. For
example, <xref target="QUIC-TRANSPORT"/> allows changing Connection IDs in the m iddle of a example, <xref target="RFC9000"/> allows changing Connection IDs in the middle o f a
connection to reduce the likelihood of a passive observer linking old and new 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"/> ). A QUIC sub-flows to the same device (see <xref target="RFC9000" sectionFormat="of" sect ion="5.1"/>). A QUIC
implementation would need to reset all counters when it changes the destination 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 (IP address or UDP port) or the Connection ID used for outgoing packets. It
would also need to avoid incrementing Unreported Loss counter for loss of 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> 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, <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. an endpoint that uses them may be fingerprinted based on their usage.
But, since there is no release of user data, the techniques seem unlikely to However, since there is no release of user data, the techniques seem unlikely to
substantially increase the existing privacy risks.</t> substantially increase the existing privacy risks.</t>
<t>Furthermore, if there is experimental traffic with these bit set on the network, <t>Furthermore, if there is experimental traffic with these bits set on th e network,
a network operator could potentially prioritize this marked traffic by placing i t a network operator could potentially prioritize this marked traffic by placing i t
in a priority queue. This may result in the delivery of better service, which 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> could potentially mislead an experiment intended to benchmark the network.</t>
</section> </section>
<section anchor="iana-considerations"> <section anchor="iana-considerations">
<name>IANA Considerations</name> <name>IANA Considerations</name>
<t>This document makes no request of IANA.</t> <t>This document has no IANA actions.</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, Ch
ristian
Huitema for implementing Q and L bits in his picoquic stack, and Ike Kunze for
providing constructive reviews and helpful suggestions.</t>
</section> </section>
</middle> </middle>
<back> <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> <references>
<name>References</name> <name>References</name>
<references> <references>
<name>Normative References</name> <name>Normative References</name>
<reference anchor="TCP">
<front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9293.xml"
<title>Transmission Control Protocol (TCP)</title> />
<author fullname="W. Eddy" initials="W." role="editor" surname="Eddy <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.3168.xml"
"/> />
<date month="August" year="2022"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7799.xml"
<abstract> />
<t>This document specifies the Transmission Control Protocol (TCP) <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9000.xml"
. TCP is an important transport-layer protocol in the Internet protocol stack, a />
nd it has continuously evolved over decades of use and growth of the Internet. O <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8558.xml"
ver 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 doc
ument 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 11
22, and it should be considered as a replacement for the portions of those docum
ents dealing with TCP requirements. It also updates RFC 5961 by adding a small c
larification in reset handling while in the SYN-RECEIVED state. The TCP header c
ontrol 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="Ramakrishn
an"/>
<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 Congesti
on 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 per
formance 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 de
scribes 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="I
yengar"/>
<author fullname="M. Thomson" initials="M." role="editor" surname="T
homson"/>
<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 communica
tion, low-latency connection establishment, and network path migration. QUIC inc
ludes security measures that ensure confidentiality, integrity, and availability
in a range of deployment circumstances. Accompanying documents describe the int
egration 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="Ha
rdie"/>
<date month="April" year="2019"/>
<abstract>
<t>This document discusses the nature of signals seen by on-path e
lements 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 pa
th between the two nodes setting up the transport connection, they are often use
d 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 confidentia
l channels. Where the endpoints desire that network elements along the path rece
ive 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>
</references> </references>
<references> <references>
<name>Informative References</name> <name>Informative References</name>
<reference anchor="QUIC-TLS">
<front>
<title>Using TLS to Secure QUIC</title>
<author fullname="M. Thomson" initials="M." role="editor" surname="T
homson"/>
<author fullname="S. Turner" initials="S." role="editor" surname="Tu
rner"/>
<date month="May" year="2021"/>
<abstract>
<t>This document describes how Transport Layer Security (TLS) is u
sed 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, Netwo
rk 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 encrypt
ion and authentication are now also starting to be applied to the transport prot
ocol headers. This helps avoid transport protocol ossification by middleboxes, m
itigate attacks against the transport protocol, and protect metadata about the c
ommunication. Current operational practice in some networks inspect transport he
ader information within the network, but this is no longer possible when those t
ransport headers are encrypted.</t>
<t>This document discusses the possible impact when network traffi
c uses a protocol with an encrypted transport header. It suggests issues to cons
ider 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 pro
tocol 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 r
ely 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 Explicit Passive Measurability of Two-Way Latency to t
he QUIC Transport Protocol</title>
<author fullname="Brian Trammell" initials="B." surname="Trammell">
<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." 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", intend
ed 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> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9001.xml"
</abstract> />
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9065.xml"
<seriesInfo name="Internet-Draft" value="draft-trammell-quic-spin-03"/ />
> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9312.xml"
</reference> />
<reference anchor="I-D.trammell-quic-spin" target="https://datatracker.ietf.org/
doc/html/draft-trammell-quic-spin-03">
<front>
<title>
Adding Explicit Passive Measurability of Two-Way Latency to the QUIC Transport P
rotocol
</title>
<author fullname="Brian Trammell" initials="B." 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." 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"/>
</front>
<seriesInfo name="Internet-Draft" value="draft-trammell-quic-spin-03"/>
</reference>
<reference anchor="RTT-PRIVACY"> <reference anchor="RTT-PRIVACY">
<front> <front>
<title>Revisiting the Privacy Implications of Two-Way Internet Laten cy Data</title> <title>Revisiting the Privacy Implications of Two-Way Internet Laten cy Data</title>
<author fullname="Brian Trammell" initials="B." surname="Trammell"> <author fullname="Brian Trammell" initials="B." surname="Trammell">
<organization/> <organization/>
</author> </author>
<author fullname="Mirja Kühlewind" initials="M." surname="Kühlewind" > <author fullname="Mirja Kühlewind" initials="M." surname="Kühlewind" >
<organization/> <organization/>
</author> </author>
<date year="2018"/> <date year="2018" month="March"/>
</front> </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="DOI" value="10.1007/978-3-319-76481-8_6"/>
<seriesInfo name="ISBN" value="[&quot;9783319764801&quot;, &quot;97833 <seriesInfo name="ISBN" value="9783319764801"/>
19764818&quot;]"/> <refcontent>Passive and Active Measurement, pp. 73-84, Springer Intern
<refcontent>Springer International Publishing</refcontent> ational Publishing</refcontent>
</reference>
<reference anchor="UDP-OPTIONS">
<front>
<title>Transport Options for UDP</title>
<author fullname="Dr. Joseph D. Touch" initials="J. D." surname="Tou
ch">
<organization>Independent Consultant</organization>
</author>
<date day="9" month="June" year="2023"/>
<abstract>
<t> Transport protocols are extended through the use of transpor
t 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>
<reference anchor="UDP-SURPLUS"> <reference anchor="I-D.ietf-tsvwg-udp-options" target="https://datatracker.ietf.
<front> org/doc/html/draft-ietf-tsvwg-udp-options-23">
<title>UDP Surplus Header</title> <front>
<author fullname="Tom Herbert" initials="T." surname="Herbert"> <title>Transport Options for UDP</title>
<organization>Intel</organization> <author fullname="Dr. Joseph D. Touch" initials="J." surname="Touch">
</author> <organization>Independent Consultant</organization>
<date day="8" month="July" year="2019"/> </author>
<abstract> <date day="15" month="September" year="2023"/>
<t> This specification defines the UDP Surplus Header that is an </front>
extensible and generic format applied to the UDP surplus space. The <seriesInfo name="Internet-Draft" value="draft-ietf-tsvwg-udp-options-23"/>
UDP surplus space comprises the bytes between the end of the UDP </reference>
datagram, as indicated by the UDP Length field, and the end of the IP <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.herbert-
packet, as indicated by IP packet or payload length. The UDP Surplus udp-space-hdr.xml"/>
Header can be either a protocol trailer of the UDP datagram, or a <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-tcp
protocol header which effectively serves as an extended UDP header. m-accurate-ecn.xml"/>
</t> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9341.xml"
</abstract> />
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9343.xml"
<seriesInfo name="Internet-Draft" value="draft-herbert-udp-space-hdr-0 />
1"/>
</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="Sche
ffenegger">
<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 perf
orm 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"/>
</reference>
<reference anchor="ANRW19-PM-QUIC"> <reference anchor="ANRW19-PM-QUIC">
<front> <front>
<title>Performance measurements of QUIC communications</title> <title>Performance measurements of QUIC communications</title>
<author fullname="Fabio Bulgarella" initials="F." surname="Bulgarell a"> <author fullname="Fabio Bulgarella" initials="F." surname="Bulgarell a">
<organization>Politecnico di Torino</organization> <organization>Politecnico di Torino</organization>
</author> </author>
<author fullname="Mauro Cociglio" initials="M." surname="Cociglio"> <author fullname="Mauro Cociglio" initials="M." surname="Cociglio">
<organization>Telecom Italia</organization> <organization>Telecom Italia</organization>
</author> </author>
<author fullname="Giuseppe Fioccola" initials="G." surname="Fioccola "> <author fullname="Giuseppe Fioccola" initials="G." surname="Fioccola ">
<organization>Huawei Technologies</organization> <organization>Huawei Technologies</organization>
</author> </author>
<author fullname="Guido Marchetto" initials="G." surname="Marchetto" > <author fullname="Guido Marchetto" initials="G." surname="Marchetto" >
<organization>Politecnico di Torino</organization> <organization>Politecnico di Torino</organization>
</author> </author>
<author fullname="Riccardo Sisto" initials="R." surname="Sisto"> <author fullname="Riccardo Sisto" initials="R." surname="Sisto">
<organization>Politecnico di Torino</organization> <organization>Politecnico di Torino</organization>
</author> </author>
<date month="July" year="2019"/> <date month="July" year="2019"/>
</front> </front>
<seriesInfo name="Proceedings of the Applied Networking Research" valu e="Workshop"/>
<seriesInfo name="DOI" value="10.1145/3340301.3341127"/> <seriesInfo name="DOI" value="10.1145/3340301.3341127"/>
<refcontent>ACM</refcontent> <refcontent>Proceedings of the Applied Networking Research Workshop (A
</reference> NRW '19), Association for Computing Machinery</refcontent>
<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 s
ame flow. Today, network elements at any layer may signal congestion to the rece
iver by dropping packets or by Explicit Congestion Notification (ECN) markings,
and the receiver passes this information back to the sender in transport-layer f
eedback. The mechanism described here enables the sender to also relay this cong
estion information back into the network in-band at the IP layer, such that the
total amount of congestion from all elements on the path is revealed to all IP e
lements 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 6
789), 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 for Congestion Exposure (ConEx)</title>
<author fullname="M. Kuehlewind" initials="M." role="editor" surname
="Kuehlewind"/>
<author fullname="R. Scheffenegger" initials="R." surname="Scheffene
gger"/>
<date month="May" year="2016"/>
<abstract>
<t>Congestion Exposure (ConEx) is a mechanism by which senders inf
orm the network about expected congestion based on congestion feedback from prev
ious packets in the same flow. This document describes the necessary modificatio
ns to use ConEx with the Transmission Control Protocol (TCP).</t>
</abstract>
</front>
<seriesInfo name="RFC" value="7786"/>
<seriesInfo name="DOI" value="10.17487/RFC7786"/>
</reference> </reference>
<reference anchor="I-D.trammell-tsvwg-spin">
<front>
<title>A Transport-Independent Explicit Signal for Hybrid RTT Measur
ement</title>
<author fullname="Brian Trammell" initials="B." surname="Trammell">
<organization>ETH Zurich</organization>
</author>
<date day="2" month="July" year="2018"/>
<abstract>
<t> This document defines an explicit per-flow transport-layer s
ignal 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> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7713.xml"
</abstract> />
</front> <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.7786.xml"
<seriesInfo name="Internet-Draft" value="draft-trammell-tsvwg-spin-00" />
/>
</reference>
<reference anchor="I-D.trammell-ippm-spin">
<front>
<title>An Explicit Transport-Layer Signal for Hybrid RTT Measurement
</title>
<author fullname="Brian Trammell" initials="B." surname="Trammell">
<organization>ETH Zurich</organization>
</author>
<date day="9" month="January" year="2019"/>
<abstract>
<t> This document defines an explicit per-flow transport-layer s
ignal 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> <reference anchor="I-D.trammell-tsvwg-spin" target="https://datatracker.ietf.org
</abstract> /doc/html/draft-trammell-tsvwg-spin-00">
</front> <front>
<seriesInfo name="Internet-Draft" value="draft-trammell-ippm-spin-00"/ <title>
> A Transport-Independent Explicit Signal for Hybrid RTT Measurement
</reference> </title>
<reference anchor="I-D.ietf-core-coap-pm"> <author fullname="Brian Trammell" initials="B." surname="Trammell" role="editor"
<front> >
<title>Constrained Application Protocol (CoAP) Performance Measureme <organization>ETH Zurich</organization>
nt Option</title> </author>
<author fullname="Giuseppe Fioccola" initials="G." surname="Fioccola <date day="2" month="July" year="2018"/>
"> </front>
<organization>Huawei</organization> <seriesInfo name="Internet-Draft" value="draft-trammell-tsvwg-spin-00"/>
</author> </reference>
<author fullname="Tianran Zhou" initials="T." surname="Zhou">
<organization>Huawei</organization> <reference anchor="I-D.trammell-ippm-spin" target="https://datatracker.ietf.org/
</author> doc/html/draft-trammell-ippm-spin-00">
<author fullname="Mauro Cociglio" initials="M." surname="Cociglio"> <front>
<organization>Telecom Italia</organization> <title>
</author> An Explicit Transport-Layer Signal for Hybrid RTT Measurement
<author fullname="Fabio Bulgarella" initials="F." surname="Bulgarell </title>
a"> <author fullname="Brian Trammell" initials="B." surname="Trammell" role="editor"
<organization>Telecom Italia</organization> >
</author> <organization>ETH Zurich</organization>
<author fullname="Massimo Nilo" initials="M." surname="Nilo"> </author>
<organization>Telecom Italia</organization> <date day="9" month="January" year="2019"/>
</author> </front>
<author fullname="Fabrizio Milan" initials="F." surname="Milan"> <seriesInfo name="Internet-Draft" value="draft-trammell-ippm-spin-00"/>
<organization>Telecom Italia</organization> </reference>
</author>
<date day="19" month="April" year="2023"/> <xi:include href="https://bib.ietf.org/public/rfc/bibxml3/reference.I-D.ietf-cor
<abstract> e-coap-pm.xml"/>
<t> This document specifies a method for the Performance Measure
ment of <xi:include href="https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8701.xml"
the Constrained Application Protocol (CoAP). A new CoAP option is />
defined in order to enable network telemetry both end-to-end and hop-
by-hop. The endpoints cooperate by marking and, possibly, mirroring
information on 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 in the TLS
ecosystem. It reserves a set of TLS protocol values that may be advertised to e
nsure peers correctly handle unknown values.</t>
</abstract>
</front>
<seriesInfo name="RFC" value="8701"/>
<seriesInfo name="DOI" value="10.17487/RFC8701"/>
</reference>
</references> </references>
</references> </references>
<section anchor="acknowledgments" numbered="false">
<name>Acknowledgments</name>
<t>The authors would like to thank the QUIC WG for their contributions,
<contact fullname="Christian Huitema"/> for implementing Q and L bits in his pic
oquic 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 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> </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> </rfc>
 End of changes. 225 change blocks. 
1506 lines changed or deleted 795 lines changed or added

This html diff was produced by rfcdiff 1.48.