path: root/docs/ietf/draft-ietf-bmwg-mlrsearch-07.xml

<?xml version="1.0" encoding="us-ascii"?>
  <?xml-stylesheet type="text/xsl" href="rfc2629.xslt" ?>
  <!-- generated by https://github.com/cabo/kramdown-rfc version 1.7.18 (Ruby 3.1.2) -->


<!DOCTYPE rfc  [
  <!ENTITY nbsp    "&#160;">
  <!ENTITY zwsp   "&#8203;">
  <!ENTITY nbhy   "&#8209;">
  <!ENTITY wj     "&#8288;">

<!ENTITY RFC1242 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.1242.xml">
<!ENTITY RFC2285 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2285.xml">
<!ENTITY RFC2544 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.2544.xml">
<!ENTITY RFC8219 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.8219.xml">
<!ENTITY RFC9004 SYSTEM "https://bib.ietf.org/public/rfc/bibxml/reference.RFC.9004.xml">
]>


<rfc ipr="trust200902" docName="draft-ietf-bmwg-mlrsearch-07" category="info" tocInclude="true" sortRefs="true" symRefs="true">
  <front>
    <title abbrev="MLRsearch">Multiple Loss Ratio Search</title>

    <author initials="M." surname="Konstantynowicz" fullname="Maciek Konstantynowicz">
      <organization>Cisco Systems</organization>
      <address>
        <email>mkonstan@cisco.com</email>
      </address>
    </author>
    <author initials="V." surname="Polak" fullname="Vratko Polak">
      <organization>Cisco Systems</organization>
      <address>
        <email>vrpolak@cisco.com</email>
      </address>
    </author>

    <date year="2024" month="July" day="18"/>

    <area>ops</area>
    <workgroup>Benchmarking Working Group</workgroup>
    <keyword>Internet-Draft</keyword>

    <abstract>


<?line 52?>

<t>This document proposes extensions to <xref target="RFC2544"></xref> throughput search by
defining a new methodology called Multiple Loss Ratio search
(MLRsearch). MLRsearch aims to minimize search duration,
support multiple loss ratio searches,
and enhance result repeatability and comparability.</t>

<t>The primary reason for extending <xref target="RFC2544"></xref> is to address the challenges
and requirements presented by the evaluation and testing
of software-based networking systems&#39; data planes.</t>

<t>To give users more freedom, MLRsearch provides additional configuration options
such as allowing multiple short trials per load instead of one large trial,
tolerating a certain percentage of trial results with higher loss,
and supporting the search for multiple goals with varying loss ratios.</t>



    </abstract>



  </front>

  <middle>


<?line 69?>


<section anchor="purpose-and-scope"><name>Purpose and Scope</name>

<t>The purpose of this document is to describe Multiple Loss Ratio search
(MLRsearch), a data plane throughput search methodology optimized for software
networking DUTs.</t>

<t>Applying vanilla <xref target="RFC2544"></xref> throughput bisection to software DUTs
results in several problems:</t>

<t><list style="symbols">
  <t>Binary search takes too long as most trials are done far from the
eventually found throughput.</t>
  <t>The required final trial duration and pauses between trials
prolong the overall search duration.</t>
  <t>Software DUTs show noisy trial results,
leading to a big spread of possible discovered throughput values.</t>
  <t>Throughput requires a loss of exactly zero frames, but the industry
frequently allows for small but non-zero losses.</t>
  <t>The definition of throughput is not clear when trial results are inconsistent.</t>
</list></t>

<t>To address the problems mentioned above,
the MLRsearch test methodology specification employs the following enhancements:</t>

<t><list style="symbols">
  <t>Allow multiple short trials instead of one big trial per load.
  <list style="symbols">
      <t>Optionally, tolerate a percentage of trial results with higher loss.</t>
    </list></t>
  <t>Allow searching for multiple Search Goals, with differing loss ratios.
  <list style="symbols">
      <t>Any trial result can affect each Search Goal in principle.</t>
    </list></t>
  <t>Insert multiple coarse targets for each Search Goal, earlier ones need
to spend less time on trials.
  <list style="symbols">
      <t>Earlier targets also aim for lesser precision.</t>
      <t>Use Forwarding Rate (FR) at maximum offered load
<xref target="RFC2285"></xref> (section 3.6.2) to initialize the initial targets.</t>
    </list></t>
  <t>Take care when dealing with inconsistent trial results.
  <list style="symbols">
      <t>Reported throughput is smaller than the smallest load with high loss.</t>
      <t>Smaller load candidates are measured first.</t>
    </list></t>
  <t>Apply several load selection heuristics to save even more time
by trying hard to avoid unnecessarily narrow bounds.</t>
</list></t>

<t>Some of these enhancements are formalized as MLRsearch specification,
the remaining enhancements are treated as implementation details,
thus achieving high comparability without limiting future improvements.</t>

<t>MLRsearch configuration options are flexible enough to
support both conservative settings and aggressive settings.
The conservative settings lead to results
unconditionally compliant with <xref target="RFC2544"></xref>,
but longer search duration and worse repeatability.
Conversely, aggressive settings lead to shorter search duration
and better repeatability, but the results are not compliant with <xref target="RFC2544"></xref>.</t>

<t>No part of <xref target="RFC2544"></xref> is intended to be obsoleted by this document.</t>

</section>
<section anchor="identified-problems"><name>Identified Problems</name>

<t>This chapter describes the problems affecting usability
of various performance testing methodologies,
mainly a binary search for <xref target="RFC2544"></xref> unconditionally compliant throughput.</t>

<section anchor="long-search-duration"><name>Long Search Duration</name>


<t>The emergence of software DUTs, with frequent software updates and a
number of different frame processing modes and configurations,
has increased both the number of performance tests
required to verify the DUT update and the frequency of running those tests.
This makes the overall test execution time even more important than before.</t>

<t>The current <xref target="RFC2544"></xref> throughput definition restricts the potential
for time-efficiency improvements.
A more generalized throughput concept could enable further enhancements
while maintaining the precision of simpler methods.</t>

<t>The bisection method, when unconditionally compliant with <xref target="RFC2544"></xref>,
is excessively slow.
This is because a significant amount of time is spent on trials
with loads that, in retrospect, are far from the final determined throughput.</t>

<t><xref target="RFC2544"></xref> does not specify any stopping condition for throughput search,
so users already have an access to a limited trade-off
between search duration and achieved precision.
However, each full 60-second trials doubles the precision,
so not many trials can be removed without a substantial loss of precision.</t>

</section>
<section anchor="dut-in-sut"><name>DUT in SUT</name>

<t><xref target="RFC2285"></xref> defines:
- DUT as
  - The network forwarding device to which stimulus is offered and
    response measured <xref target="RFC2285"></xref> (section 3.1.1).
- SUT as
  - The collective set of network devices to which stimulus is offered
    as a single entity and response measured <xref target="RFC2285"></xref> (section 3.1.2).</t>

<t><xref target="RFC2544"></xref> specifies a test setup with an external tester stimulating the
networking system, treating it either as a single DUT, or as a system
of devices, an SUT.</t>

<t>In the case of software networking, the SUT consists of not only the DUT
as a software program processing frames, but also of
server hardware and operating system functions,
with that server hardware resources shared across all programs including
the operating system.</t>

<t>Given that the SUT is a shared multi-tenant environment
encompassing the DUT and other components, the DUT might inadvertently
experience interference from the operating system
or other software operating on the same server.</t>

<t>Some of this interference can be mitigated.
For instance,
pinning DUT program threads to specific CPU cores
and isolating those cores can prevent context switching.</t>

<t>Despite taking all feasible precautions, some adverse effects may still impact
the DUT&#39;s network performance.
In this document, these effects are collectively
referred to as SUT noise, even if the effects are not as unpredictable
as what other engineering disciplines call noise.</t>

<t>DUT can also exhibit fluctuating performance itself, for reasons
not related to the rest of SUT. For example due to pauses in execution
as needed for internal stateful processing.
In many cases this
may be an expected per-design behavior, as it would be observable even
in a hypothetical scenario where all sources of SUT noise are eliminated.
Such behavior affects trial results in a way similar to SUT noise.
As the two phenomenons are hard to distinguish,
in this document the term &#39;noise&#39; is used to encompass
both the internal performance fluctuations of the DUT
and the genuine noise of the SUT.</t>

<t>A simple model of SUT performance consists of an idealized noiseless performance,
and additional noise effects.
For a specific SUT, the noiseless performance is assumed to be constant,
with all observed performance variations being attributed to noise.
The impact of the noise can vary in time, sometimes wildly,
even within a single trial.
The noise can sometimes be negligible, but frequently
it lowers the observed SUT performance as observed in trial results.</t>

<t>In this model, SUT does not have a single performance value, it has a spectrum.
One end of the spectrum is the idealized noiseless performance value,
the other end can be called a noiseful performance.
In practice, trial result
close to the noiseful end of the spectrum happens only rarely.
The worse the performance value is, the more rarely it is seen in a trial.
Therefore, the extreme noiseful end of the SUT spectrum is not observable
among trial results.
Also, the extreme noiseless end of the SUT spectrum
is unlikely to be observable, this time because some small noise effects
are likely to occur multiple times during a trial.</t>

<t>Unless specified otherwise, this document&#39;s focus is
on the potentially observable ends of the SUT performance spectrum,
as opposed to the extreme ones.</t>

<t>When focusing on the DUT, the benchmarking effort should ideally aim
to eliminate only the SUT noise from SUT measurements.
However,
this is currently not feasible in practice, as there are no realistic enough
models available to distinguish SUT noise from DUT fluctuations,
based on authors&#39; experience and available literature.</t>

<t>Assuming a well-constructed SUT, the DUT is likely its
primary performance bottleneck.
In this case, we can define the DUT&#39;s
ideal noiseless performance as the noiseless end of the SUT performance spectrum,
especially for throughput.
However, other performance metrics, such as latency,
may require additional considerations.</t>

<t>Note that by this definition, DUT noiseless performance
also minimizes the impact of DUT fluctuations, as much as realistically possible
for a given trial duration.</t>

<t>MLRsearch methodology aims to solve the DUT in SUT problem
by estimating the noiseless end of the SUT performance spectrum
using a limited number of trial results.</t>

<t>Any improvements to the throughput search algorithm, aimed at better
dealing with software networking SUT and DUT setup, should employ
strategies recognizing the presence of SUT noise, allowing the discovery of
(proxies for) DUT noiseless performance
at different levels of sensitivity to SUT noise.</t>

</section>
<section anchor="repeatability-and-comparability"><name>Repeatability and Comparability</name>

<t><xref target="RFC2544"></xref> does not suggest to repeat throughput search.
And from just one
discovered throughput value, it cannot be determined how repeatable that value is.
Poor repeatability then leads to poor comparability,
as different benchmarking teams may obtain varying throughput values
for the same SUT, exceeding the expected differences from search precision.</t>

<t><xref target="RFC2544"></xref> throughput requirements (60 seconds trial and
no tolerance of a single frame loss) affect the throughput results
in the following way.
The SUT behavior close to the noiseful end of its performance spectrum
consists of rare occasions of significantly low performance,
but the long trial duration makes those occasions not so rare on the trial level.
Therefore, the binary search results tend to wander away from the noiseless end
of SUT performance spectrum, more frequently and more widely than short
trials would, thus causing poor throughput repeatability.</t>

<t>The repeatability problem can be addressed by defining a search procedure
that identifies a consistent level of performance,
even if it does not meet the strict definition of throughput in <xref target="RFC2544"></xref>.</t>

<t>According to the SUT performance spectrum model, better repeatability
will be at the noiseless end of the spectrum.
Therefore, solutions to the DUT in SUT problem
will help also with the repeatability problem.</t>

<t>Conversely, any alteration to <xref target="RFC2544"></xref> throughput search
that improves repeatability should be considered
as less dependent on the SUT noise.</t>

<t>An alternative option is to simply run a search multiple times, and report some
statistics (e.g. average and standard deviation).
This can be used
for a subset of tests deemed more important,
but it makes the search duration problem even more pronounced.</t>

</section>
<section anchor="throughput-with-non-zero-loss"><name>Throughput with Non-Zero Loss</name>

<t><xref target="RFC1242"></xref> (section 3.17 Throughput) defines throughput as:
    The maximum rate at which none of the offered frames
    are dropped by the device.</t>

<t>Then, it says:
    Since even the loss of one frame in a
    data stream can cause significant delays while
    waiting for the higher level protocols to time out,
    it is useful to know the actual maximum data
    rate that the device can support.</t>

<t>However, many benchmarking teams accept a small,
non-zero loss ratio as the goal for their load search.</t>

<t>Motivations are many:</t>

<t><list style="symbols">
  <t>Modern protocols tolerate frame loss better,
compared to the time when <xref target="RFC1242"></xref> and <xref target="RFC2544"></xref> were specified.</t>
  <t>Trials nowadays send way more frames within the same duration,
increasing the chance of a small SUT performance fluctuation
being enough to cause frame loss.</t>
  <t>Small bursts of frame loss caused by noise have otherwise smaller impact
on the average frame loss ratio observed in the trial,
as during other parts of the same trial the SUT may work more closely
to its noiseless performance, thus perhaps lowering the Trial Loss Ratio
below the Goal Loss Ratio value.</t>
  <t>If an approximation of the SUT noise impact on the Trial Loss Ratio is known,
it can be set as the Goal Loss Ratio.</t>
</list></t>

<t>Regardless of the validity of all similar motivations,
support for non-zero loss goals makes any search algorithm more user-friendly.
<xref target="RFC2544"></xref> throughput is not user-friendly in this regard.</t>

<t>Furthermore, allowing users to specify multiple loss ratio values,
and enabling a single search to find all relevant bounds,
significantly enhances the usefulness of the search algorithm.</t>

<t>Searching for multiple Search Goals also helps to describe the SUT performance
spectrum better than the result of a single Search Goal.
For example, the repeated wide gap between zero and non-zero loss loads
indicates the noise has a large impact on the observed performance,
which is not evident from a single goal load search procedure result.</t>

<t>It is easy to modify the vanilla bisection to find a lower bound
for the intended load that satisfies a non-zero Goal Loss Ratio.
But it is not that obvious how to search for multiple goals at once,
hence the support for multiple Search Goals remains a problem.</t>

</section>
<section anchor="inconsistent-trial-results"><name>Inconsistent Trial Results</name>

<t>While performing throughput search by executing a sequence of
measurement trials, there is a risk of encountering inconsistencies
between trial results.</t>

<t>The plain bisection never encounters inconsistent trials.
But <xref target="RFC2544"></xref> hints about the possibility of inconsistent trial results,
in two places in its text.
The first place is section 24, where full trial durations are required,
presumably because they can be inconsistent with the results
from short trial durations.
The second place is section 26.3, where two successive zero-loss trials
are recommended, presumably because after one zero-loss trial
there can be a subsequent inconsistent non-zero-loss trial.</t>

<t>Examples include:</t>

<t><list style="symbols">
  <t>A trial at the same load (same or different trial duration) results
in a different Trial Loss Ratio.</t>
  <t>A trial at a higher load (same or different trial duration) results
in a smaller Trial Loss Ratio.</t>
</list></t>

<t>Any robust throughput search algorithm needs to decide how to continue
the search in the presence of such inconsistencies.
Definitions of throughput in <xref target="RFC1242"></xref> and <xref target="RFC2544"></xref> are not specific enough
to imply a unique way of handling such inconsistencies.</t>

<t>Ideally, there will be a definition of a new quantity which both generalizes
throughput for non-zero-loss (and other possible repeatability enhancements),
while being precise enough to force a specific way to resolve trial result
inconsistencies.
But until such a definition is agreed upon, the correct way to handle
inconsistent trial results remains an open problem.</t>

</section>
</section>
<section anchor="mlrsearch-specification"><name>MLRsearch Specification</name>

<t>This section describes MLRsearch specification including all technical
definitions needed for evaluating whether a particular test procedure
complies with MLRsearch specification.</t>


<section anchor="overview"><name>Overview</name>

<t>MLRsearch specification describes a set of abstract system components,
acting as functions with specified inputs and outputs.</t>

<t>A test procedure is said to comply with MLRsearch specification
if it can be conceptually divided into analogous components,
each satisfying requirements for the corresponding MLRsearch component.</t>

<t>The Measurer component is tasked to perform trials,
the Controller component is tasked to select trial loads and durations,
the Manager component is tasked to pre-configure everything
and to produce the test report.
The test report explicitly states Search Goals (as the Controller Inputs)
and corresponding Goal Results (Controller Outputs).</t>


<t>The Manager calls the Controller once,
the Controller keeps calling the Measurer
until all stopping conditions are met.</t>

<t>The part where Controller calls the Measurer is called the search.
Any activity done by the Manager before it calls the Controller
(or after Controller returns) is not considered to be part of the search.</t>

<t>MLRsearch specification prescribes regular search results and recommends
their stopping conditions. Irregular search results are also allowed,
they may have different requirements and stopping conditions.</t>

<t>Search results are based on load classification.
When measured enough, any chosen load either achieves of fails each search goal,
thus becoming a lower or an upper bound for that goal.
When the relevant bounds are at loads that are close enough
(according to goal precision), the regular result is found.
Search stops when all regular results are found
(or if some goals are proven to have only irregular results).</t>

</section>
<section anchor="measurement-quantities"><name>Measurement Quantities</name>

<t>MLRsearch specification uses a number of measurement quantities.</t>

<t>In general, MLRsearch specification does not require particular units to be used,
but it is REQUIRED for the test report to state all the units.
For example, ratio quantities can be dimensionless numbers between zero and one,
but may be expressed as percentages instead.</t>

<t>For convenience, a group of quantities can be treated as a composite quantity,
One constituent of a composite quantity is called an attribute,
and a group of attribute values is called an instance of that composite quantity.</t>

<t>Some attributes are not independent from others,
and they can be calculated from other attributes.
Such quantites are called derived quantities.</t>

</section>
<section anchor="existing-terms"><name>Existing Terms</name>

<t>RFC 1242 &quot;Benchmarking Terminology for Network Interconnect Devices&quot;
contains basic definitions, and
RFC 2544 &quot;Benchmarking Methodology for Network Interconnect Devices&quot;
contains discussions of a number of terms and additional methodology requirements.
RFC 2285 adds more terms and discussions, describing some known situations
in more precise way.</t>

<t>All three documents should be consulted
before attempting to make use of this document.</t>

<t>Definitions of some central terms are copied and discussed in subsections.</t>





<section anchor="sut"><name>SUT</name>

<t>Defined in <xref target="RFC2285"></xref> (section 3.1.2 System Under Test (SUT)) as follows.</t>

<t>Definition:</t>

<t>The collective set of network devices to which stimulus is offered
as a single entity and response measured.</t>

<t>Discussion:</t>

<t>An SUT consisting of a single network device is also allowed.</t>

</section>
<section anchor="dut"><name>DUT</name>

<t>Defined in <xref target="RFC2285"></xref> (section 3.1.1 Device Under Test (DUT)) as follows.</t>

<t>Definition:</t>

<t>The network forwarding device to which stimulus is offered and
response measured.</t>

<t>Discussion:</t>

<t>DUT, as a sub-component of SUT, is only indirectly mentioned
in MLRsearch specification, but is of key relevance for its motivation.</t>


</section>
<section anchor="trial"><name>Trial</name>

<t>A trial is the part of the test described in <xref target="RFC2544"></xref> (section 23. Trial description).</t>

<t>Definition:</t>

<t>A particular test consists of multiple trials.  Each trial returns
   one piece of information, for example the loss rate at a particular
   input frame rate.  Each trial consists of a number of phases:</t>

<t>a) If the DUT is a router, send the routing update to the &quot;input&quot;
   port and pause two seconds to be sure that the routing has settled.</t>

<t>b)  Send the &quot;learning frames&quot; to the &quot;output&quot; port and wait 2
   seconds to be sure that the learning has settled.  Bridge learning
   frames are frames with source addresses that are the same as the
   destination addresses used by the test frames.  Learning frames for
   other protocols are used to prime the address resolution tables in
   the DUT.  The formats of the learning frame that should be used are
   shown in the Test Frame Formats document.</t>

<t>c) Run the test trial.</t>

<t>d) Wait for two seconds for any residual frames to be received.</t>

<t>e) Wait for at least five seconds for the DUT to restabilize.</t>

<t>Discussion:</t>

<t>The definition describes some traits, it is not clear whether all of them
are REQUIRED, or some of them are only RECOMMENDED.</t>


<t>For the purposes of the MLRsearch specification,
it is ALLOWED for the test procedure to deviate from the <xref target="RFC2544"></xref> description,
but any such deviation MUST be made explicit in the test report.</t>

<t>Trials are the only stimuli the SUT is expected to experience
during the search.</t>

<t>In some discussion paragraphs, it is useful to consider the traffic
as sent and received by a tester, as implicitly defined
in <xref target="RFC2544"></xref> (section 6. Test set up).</t>

<t>An example of deviation from <xref target="RFC2544"></xref> is using shorter wait times.</t>

</section>
</section>
<section anchor="trial-terms"><name>Trial Terms</name>

<t>This section defines new and redefine existing terms for quantities
relevant as inputs or outputs of trial, as used by the Measurer component.</t>

<section anchor="trial-duration"><name>Trial Duration</name>

<t>Definition:</t>

<t>Trial duration is the intended duration of the traffic for a trial.</t>

<t>Discussion:</t>

<t>In general, this quantity does not include any preparation nor waiting
described in section 23 of <xref target="RFC2544"></xref> (section 23. Trial description).</t>

<t>While any positive real value may be provided, some Measurer implementations
MAY limit possible values, e.g. by rounding down to neared integer in seconds.
In that case, it is RECOMMENDED to give such inputs to the Controller
so the Controller only proposes the accepted values.
Alternatively, the test report MUST present the rounded values
as Search Goal attributes.</t>

</section>
<section anchor="trial-load"><name>Trial Load</name>

<t>Definition:</t>

<t>The trial load is the intended load for a trial</t>

<t>Discussion:</t>

<t>For test report purposes, it is assumed that this is a constant load by default.
This MAY be only an average load, e.g. when the traffic is intended to be busty,
e.g. as suggested in <xref target="RFC2544"></xref> (section 21. Bursty traffic),
but the test report MUST explicitly mention how non-constant the traffic is.</t>

<t>Trial load is the quantity defined as Constant Load of <xref target="RFC1242"></xref>
(section 3.4 Constant Load), Data Rate of <xref target="RFC2544"></xref>
(section 14. Bidirectional traffic)
and Intended Load of <xref target="RFC2285"></xref> (section 3.5.1 Intended load (Iload)).
All three definitions specify
that this value applies to one (input or output) interface.</t>


<t>For test report purposes, multi-interface aggregate load MAY be reported,
this is understood as the same quantity expressed using different units.
From the report it MUST be clear whether a particular trial load value
is per one interface, or an aggregate over all interfaces.</t>

<t>Similarly to trial duration, some Measurers may limit the possible values
of trial load. Contrary to trial duration, the test report is NOT REQUIRED
to document such behavior.</t>


<t>It is ALLOWED to combine trial load and trial duration in a way
that would not be possible to achieve using any integer number of data frames.</t>


</section>
<section anchor="trial-input"><name>Trial Input</name>

<t>Definition:</t>

<t>Trial Input is a composite quantity, consisting of two attributes:
trial duration and trial load.</t>

<t>Discussion:</t>

<t>When talking about multiple trials, it is common to say &quot;Trial Inputs&quot;
to denote all corresponding Trial Input instances.</t>

<t>A Trial Input instance acts as the input for one call of the Measurer component.</t>

<t>Contrary to other composite quantities, MLRsearch implementations
are NOT ALLOWED to add optional attributes here.
This improves interoperability between various implementations of
the Controller and the Measurer.</t>

</section>
<section anchor="traffic-profile"><name>Traffic Profile</name>

<t>Definition:</t>

<t>Traffic profile is a composite quantity
containing attributes other than trial load and trial duration,
needed for unique determination of the trial to be performed.</t>

<t>Discussion:</t>

<t>All its attributes are assumed to be constant during the search,
and the composite is configured on the Measurer by the Manager
before the search starts.
This is why the traffic profile is not part of the Trial Input.</t>

<t>As a consequence, implementations of the Manager and the Measurer
must be aware of their common set of capabilities, so that the traffic profile
uniquely defines the traffic during the search.
The important fact is that none of those capabilities
have to be known by the Controller implementations.</t>

<t>The traffic profile SHOULD contain some specific quantities,
for example <xref target="RFC2544"></xref> (section 9. Frame sizes) governs
data link frame size as defined in <xref target="RFC1242"></xref> (section 3.5 Data link frame size).</t>

<t>Several more specific quantities may be RECOMMENDED, depending on media type.
For example, <xref target="RFC2544"></xref> (Appendix C) lists frame formats and protocol addresses,
as recommended from <xref target="RFC2544"></xref> (section 8. Frame formats)
and <xref target="RFC2544"></xref> (section 12. Protocol addresses).</t>

<t>Depending on SUT configuration, e.g. when testing specific protocols,
additional attributes MUST be included in the traffic profile
and in the test report.</t>

<t>Example: <xref target="RFC8219"></xref> (section 5.3. Traffic Setup) introduces traffic setups
consisting of a mix of IPv4 and IPv6 traffic - the implied traffic profile
therefore must include an attribute for their percentage.</t>

<t>Other traffic properties that need to be somehow specified
in Traffic Profile include:
<xref target="RFC2544"></xref> (section 14. Bidirectional traffic),
<xref target="RFC2285"></xref> (section 3.3.3 Fully meshed traffic),
and <xref target="RFC2544"></xref> (section 11. Modifiers).</t>

</section>
<section anchor="trial-forwarding-ratio"><name>Trial Forwarding Ratio</name>

<t>Definition:</t>

<t>The trial forwarding ratio is a dimensionless floating point value.
It MUST range between 0.0 and 1.0, both inclusive.
It is calculated by dividing the number of frames
successfully forwarded by the SUT
by the total number of frames expected to be forwarded during the trial</t>

<t>Discussion:</t>

<t>For most traffic profiles, &quot;expected to be forwarded&quot; means
&quot;intended to get transmitted from Tester towards SUT&quot;.</t>

<t>Trial forwarding ratio MAY be expressed in other units
(e.g. as a percentage) in the test report.</t>

<t>Note that, contrary to loads, frame counts used to compute
trial forwarding ratio are aggregates over all SUT output interfaces.</t>

<t>Questions around what is the correct number of frames
that should have been forwarded
is generally outside of the scope of this document.</t>



</section>
<section anchor="trial-loss-ratio"><name>Trial Loss Ratio</name>

<t>Definition:</t>

<t>The Trial Loss Ratio is equal to one minus the trial forwarding ratio.</t>

<t>Discussion:</t>

<t>100% minus the trial forwarding ratio, when expressed as a percentage.</t>

<t>This is almost identical to Frame Loss Rate of <xref target="RFC1242"></xref>
(section 3.6 Frame Loss Rate),
the only minor difference is that Trial Loss Ratio
does not need to be expressed as a percentage.</t>

</section>
<section anchor="trial-forwarding-rate"><name>Trial Forwarding Rate</name>

<t>Definition:</t>

<t>The trial forwarding rate is a derived quantity, calculated by
multiplying the trial load by the trial forwarding ratio.</t>

<t>Discussion:</t>

<t>It is important to note that while similar, this quantity is not identical
to the Forwarding Rate as defined in <xref target="RFC2285"></xref>
(section 3.6.1 Forwarding rate (FR)).
The latter is specific to one output interface only,
whereas the trial forwarding ratio is based
on frame counts aggregated over all SUT output interfaces.</t>


</section>
<section anchor="trial-effective-duration"><name>Trial Effective Duration</name>

<t>Definition:</t>

<t>Trial effective duration is a time quantity related to the trial,
by default equal to the trial duration.</t>

<t>Discussion:</t>

<t>This is an optional feature.
If the Measurer does not return any trial effective duration value,
the Controller MUST use the trial duration value instead.</t>

<t>Trial effective duration may be any time quantity chosen by the Measurer
to be used for time-based decisions in the Controller.</t>

<t>The test report MUST explain how the Measurer computes the returned
trial effective duration values, if they are not always
equal to the trial duration.</t>

<t>This feature can be beneficial for users
who wish to manage the overall search duration,
rather than solely the traffic portion of it.
Simply measure the duration of the whole trial (waits including)
and use that as the trial effective duration.</t>

<t>Also, this is a way for the Measurer to inform the Controller about
its surprising behavior, for example when rounding the trial duration value.</t>


</section>
<section anchor="trial-output"><name>Trial Output</name>

<t>Definition:</t>

<t>Trial Output is a composite quantity. The REQUIRED attributes are
Trial Loss Ratio, trial effective duration and trial forwarding rate.</t>

<t>Discussion:</t>

<t>When talking about multiple trials, it is common to say &quot;Trial Outputs&quot;
to denote all corresponding Trial Output instances.</t>

<t>Implementations may provide additional (optional) attributes.
The Controller implementations MUST ignore values of any optional attribute
they are not familiar with,
except when passing Trial Output instance to the Manager.</t>

<t>Example of an optional attribute:
The aggregate number of frames expected to be forwarded during the trial,
especially if it is not just (a rounded-up value)
implied by trial load and trial duration.</t>

<t>While <xref target="RFC2285"></xref> (Section 3.5.2 Offered load (Oload))
requires the offered load value to be reported for forwarding rate measurements,
it is NOT REQUIRED in MLRsearch specification.</t>


</section>
<section anchor="trial-result"><name>Trial Result</name>

<t>Definition:</t>

<t>Trial result is a composite quantity,
consisting of the Trial Input and the Trial Output.</t>

<t>Discussion:</t>

<t>When talking about multiple trials, it is common to say &quot;trial results&quot;
to denote all corresponding trial result instances.</t>

<t>While implementations SHOULD NOT include additional attributes
with independent values, they MAY include derived quantities.</t>

</section>
</section>
<section anchor="goal-terms"><name>Goal Terms</name>

<t>This section defines new and redefine existing terms for quantities
indirectly relevant for inputs or outputs of the Controller component.</t>

<t>Several goal attributes are defined before introducing
the main component quantity: the Search Goal.</t>

<section anchor="goal-final-trial-duration"><name>Goal Final Trial Duration</name>

<t>Definition:</t>

<t>A threshold value for trial durations.</t>

<t>Discussion:</t>

<t>This attribute value MUST be positive.</t>

<t>A trial with Trial Duration at least as long as the Goal Final Trial Duration
is called a full-length trial (with respect to the given Search Goal).</t>

<t>A trial that is not full-length is called a short trial.</t>

<t>Informally, while MLRsearch is allowed to perform short trials,
the results from such short trials have only limited impact on search results.</t>

<t>One trial may be full-length for some Search Goals, but not for others.</t>

<t>The full relation of this goal to Controller Output is defined later in
this document in subsections of [Goal Result] (#Goal-Result).
For example, the Conditional Throughput for this goal is computed only from
full-length trial results.</t>

</section>
<section anchor="goal-duration-sum"><name>Goal Duration Sum</name>

<t>Definition:</t>

<t>A threshold value for a particular sum of trial effective durations.</t>

<t>Discussion:</t>

<t>This attribute value MUST be positive.</t>

<t>Informally, even when looking only at full-length trials,
MLRsearch may spend up to this time measuring the same load value.</t>

<t>If the Goal Duration Sum is larger than the Goal Final Trial Duration,
multiple full-length trials may need to be performed at the same load.</t>

<t>See [TST009 Example] (#TST009-Example) for an example where possibility
of multiple full-length trials at the same load is intended.</t>

<t>A Goal Duration Sum value lower than the Goal Final Trial Duration
(of the same goal) could save some search time, but is NOT RECOMMENDED.
See [Relevant Upper Bound] (#Relevant-Upper-Bound) for partial explanation.</t>

</section>
<section anchor="goal-loss-ratio"><name>Goal Loss Ratio</name>

<t>Definition:</t>

<t>A threshold value for Trial Loss Ratios.</t>

<t>Discussion:</t>

<t>Attribute value MUST be non-negative and smaller than one.</t>

<t>A trial with Trial Loss Ratio larger than a Goal Loss Ratio value
is called a lossy trial, with respect to given Search Goal.</t>

<t>Informally, if a load causes too many lossy trials,
the Relevant Lower Bound for this goal will be smaller than that load.</t>

<t>If a trial is not lossy, it is called a low-loss trial,
or (specifically for zero Goal Loss Ratio value) zero-loss trial.</t>

</section>
<section anchor="goal-exceed-ratio"><name>Goal Exceed Ratio</name>

<t>Definition:</t>

<t>A threshold value for a particular ratio of sums of Trial Effective Durations.</t>

<t>Discussion:</t>

<t>Attribute value MUST be non-negative and smaller than one.</t>

<t>See later sections for details on which sums.
Specifically, the direct usage is only in
[Appendix A: Load Classification] (#Appendix-A:-Load-Classification)
and [Appendix B: Conditional Throughput] (#Appendix-B:-Conditional-Throughput).
The impact of that usage is discussed in subsections leading to
[Goal Result] (#Goal-Result).</t>

<t>Informally, the impact of lossy trials is controlled by this value.
Effectively, Goal Exceed Ratio is a percentage of full-length trials
that may be lossy without the load being classified
as the [Relevant Upper Bound] (#Relevant-Upper-Bound).</t>

</section>
<section anchor="goal-width"><name>Goal Width</name>

<t>Definition:</t>

<t>A value used as a threshold for deciding
whether two trial load values are close enough.</t>

<t>Discussion:</t>

<t>If present, the value MUST be positive.</t>

<t>Informally, this acts as a stopping condition,
controlling the precision of the search.
The search stops if every goal has reached its precision.</t>

<t>Implementations without this attribute
MUST give the Controller other ways to control the search stopping conditions.</t>

<t>Absolute load difference and relative load difference are two popular choices,
but implementations may choose a different way to specify width.</t>

<t>The test report MUST make it clear what specific quantity is used as Goal Width.</t>

<t>It is RECOMMENDED to set the Goal Width (as relative difference) value
to a value no smaller than the Goal Loss Ratio.
(The reason is not obvious, see [Throughput] (#Throughput) if interested.)</t>

</section>
<section anchor="search-goal"><name>Search Goal</name>

<t>Definition:</t>

<t>The Search Goal is a composite quantity consisting of several attributes,
some of them are required.</t>

<t>Required attributes:
- Goal Final Trial Duration
- Goal Duration Sum
- Goal Loss Ratio
- Goal Exceed Ratio</t>

<t>Optional attribute:
- Goal Width</t>

<t>Discussion:</t>

<t>Implementations MAY add their own attributes.
Those additional attributes may be required by the implementation
even if they are not required by MLRsearch specification.
But it is RECOMMENDED for those implementations
to support missing values by computing reasonable defaults.</t>

<t>The meaning of listed attributes is formally given only by their indirect effect
on the search results.</t>

<t>Informally, later sections provide additional intuitions and examples
of the Search Goal attribute values.</t>

<t>An example of additional attributes required by some implementations
is Goal Initial Trial Duration, together with another attribute
that controls possible intermediate Trial Duration values.
The reasonable default in this case is using the Goal Final Trial Duration
and no intermediate values.</t>

</section>
<section anchor="controller-input"><name>Controller Input</name>

<t>Definition:</t>

<t>Controller Input is a composite quantity
required as an input for the Controller.
The only REQUIRED attribute is a list of Search Goal instances.</t>

<t>Discussion:</t>

<t>MLRsearch implementations MAY use additional attributes.
Those additional attributes may be required by the implementation
even if they are not required by MLRsearch specification.</t>

<t>Formally, the Manager does not apply any Controller configuration
apart from one Controller Input instance.</t>

<t>For example, Traffic Profile is configured on the Measurer by the Manager
(without explicit assistance of the Controller).</t>

<t>The order of Search Goal instances in a list SHOULD NOT
have a big impact on Controller Output (see section [Controller Output] (#Controller-Output) ,
but MLRsearch implementations MAY base their behavior on the order
of Search Goal instances in a list.</t>

<t>An example of an optional attribute (outside the list of Search Goals)
required by some implementations is Max Load.
While this is a frequently used configuration parameter,
already governed by <xref target="RFC2544"></xref> (section 20. Maximum frame rate)
and <xref target="RFC2285"></xref> (3.5.3 Maximum offered load (MOL)),
some implementations may detect or discover it instead.</t>



<t>In MLRsearch specification, the [Relevant Upper Bound] (#Relevant-Upper-Bound)
is added as a required attribute precisely because it makes the search result
independent of Max Load value.</t>


</section>
</section>
<section anchor="search-goal-examples"><name>Search Goal Examples</name>

<section anchor="rfc2544-goal"><name>RFC2544 Goal</name>

<t>The following set of values makes the search result unconditionally compliant
with <xref target="RFC2544"></xref> (section 24 Trial duration)</t>

<t><list style="symbols">
  <t>Goal Final Trial Duration = 60 seconds</t>
  <t>Goal Duration Sum = 60 seconds</t>
  <t>Goal Loss Ratio = 0%</t>
  <t>Goal Exceed Ratio = 0%</t>
</list></t>

<t>The latter two attributes are enough to make the search goal
conditionally compliant, adding the first attribute
makes it unconditionally compliant.</t>

<t>The second attribute (Goal Duration Sum) only prevents MLRsearch
from repeating zero-loss full-length trials.</t>

<t>Non-zero exceed ratio could prolong the search and allow loss inversion
between lower-load lossy short trial and higher-load full-length zero-loss trial.
From <xref target="RFC2544"></xref> alone, it is not clear whether that higher load
could be considered as compliant throughput.</t>

</section>
<section anchor="tst009-goal"><name>TST009 Goal</name>

<t>One of the alternatives to RFC2544 is described in
<xref target="TST009"></xref> (section 12.3.3 Binary search with loss verification).
The idea there is to repeat lossy trials, hoping for zero loss on second try,
so the results are closer to the noiseless end of performance sprectum,
and more repeatable and comparable.</t>

<t>Only the variant with &quot;z = infinity&quot; is achievable with MLRsearch.</t>


<t>For example, for &quot;r = 2&quot; variant, the following search goal should be used:</t>

<t><list style="symbols">
  <t>Goal Final Trial Duration = 60 seconds</t>
  <t>Goal Duration Sum = 120 seconds</t>
  <t>Goal Loss Ratio = 0%</t>
  <t>Goal Exceed Ratio = 50%</t>
</list></t>

<t>If the first 60s trial has zero loss, it is enough for MLRsearch to stop
measuring at that load, as even a second lossy trial
would still fit within the exceed ratio.</t>

<t>But if the first trial is lossy, MLRsearch needs to perform also
the second trial to classify that load.
As Goal Duration Sum is twice as long as Goal Final Trial Duration,
third full-length trial is never needed.</t>

</section>
</section>
<section anchor="result-terms"><name>Result Terms</name>

<t>Before defining the output of the Controller,
it is useful to define what the Goal Result is.</t>

<t>The Goal Result is a composite quantity.</t>

<t>Following subsections define its attribute first, before describing the Goal Result quantity.</t>

<t>There is a correspondence between Search Goals and Goal Results.
Most of the following subsections refer to a given Search Goal,
when defining attributes of the Goal Result.
Conversely, at the end of the search, each Search Goal
has its corresponding Goal Result.</t>

<t>Conceptually, the search can be seen as a process of load classification,
where the Controller attempts to classify some loads as an Upper Bound
or a Lower Bound with respect to some Search Goal.</t>

<t>Before defining real attributes of the goal result,
it is useful to define bounds in general.</t>

<section anchor="relevant-upper-bound"><name>Relevant Upper Bound</name>

<t>Definition:</t>

<t>The Relevant Upper Bound is the smallest trial load value that is classified
at the end of the search as an upper bound
(see [Appendix A: Load Classification] (#Appendix-A:-Load-Classification))
for the given Search Goal.</t>

<t>Discussion:</t>

<t>One search goal can have many different load classified as an upper bound.
At the end of the search, one of those loads will be the smallest,
becoming the relevant upper bound for that goal.</t>

<t>In more detail, the set of all trial outputs (both short and full-length,
enough of them according to Goal Duration Sum)
performed at that smallest load failed to uphold all the requirements
of the given Search Goal, mainly the Goal Loss Ratio
in combination with the Goal Exceed Ratio.</t>


<t>If Max Load does not cause enough lossy trials,
the Relevant Upper Bound does not exist.
Conversely, if Relevant Upper Bound exists,
it is not affected by Max Load value.</t>



</section>
<section anchor="relevant-lower-bound"><name>Relevant Lower Bound</name>

<t>Definition:</t>

<t>The Relevant Lower Bound is the largest trial load value
among those smaller than the Relevant Upper Bound,
that got classified at the end of the search as a lower bound (see
[Appendix A: Load Classification] (#Appendix-A:-Load-Classification))
for the given Search Goal.</t>

<t>Discussion:</t>

<t>Only among loads smaller that the relevant upper bound,
the largest load becomes the relevant lower bound.
With loss inversion, stricter upper bound matters.</t>

<t>In more detail, the set of all trial outputs (both short and full-length,
enough of them according to Goal Duration Sum)
performed at that largest load managed to uphold all the requirements
of the given Search Goal, mainly the Goal Loss Ratio
in combination with the Goal Exceed Ratio.</t>

<t>Is no load had enough low-loss trials, the relevant lower bound
MAY not exist.</t>


<t>Strictly speaking, if the Relevant Upper Bound does not exist,
the Relevant Lower Bound also does not exist.
In that case, Max Load is classified as a lower bound,
but it is not clear whether a higher lower bound
would be found if the search used a higher Max Load value.</t>

<t>For a regular Goal Result, the distance between the Relevant Lower Bound
and the Relevant Upper Bound MUST NOT be larger than the Goal Width,
if the implementation offers width as a goal attribute.</t>


<t>Searching for anther search goal may cause a loss inversion phenomenon,
where a lower load is classified as an upper bound,
but also a higher load is classified as a lower bound for the same search goal.
The definition of the Relevant Lower Bound ignores such high lower bounds.</t>


</section>
<section anchor="conditional-throughput"><name>Conditional Throughput</name>

<t>Definition:</t>

<t>The Conditional Throughput (see section [Appendix B: Conditional Throughput] (#Appendix-B:-Conditional-Throughput))
as evaluated at the Relevant Lower Bound of the given Search Goal
at the end of the search.</t>

<t>Discussion:</t>

<t>Informally, this is a typical trial forwarding rate, expected to be seen
at the Relevant Lower Bound of the given Search Goal.</t>

<t>But frequently it is only a conservative estimate thereof,
as MLRsearch implementations tend to stop gathering more data
as soon as they confirm the value cannot get worse than this estimate
within the Goal Duration Sum.</t>

<t>This value is RECOMMENDED to be used when evaluating repeatability
and comparability if different MLRsearch implementations.</t>


</section>
<section anchor="goal-result"><name>Goal Result</name>

<t>Definition:</t>

<t>The Goal Result is a composite quantity consisting of several attributes.
Relevant Upper Bound and Relevant Lower Bound are REQUIRED attributes,
Conditional Throughput is a RECOMMENDED attribute.</t>

<t>Discussion:</t>

<t>Depending on SUT behavior, it is possible that one or both relevant bounds
do not exist. The goal result instance where the required attribute values exist
is informally called a Regular Goal Result instance,
so we can say some goals reached Irregular Goal Results.</t>


<t>A typical Irregular Goal Result is when all trials at the Max Load
have zero loss, as the Relevant Upper Bound does not exist in that case.</t>

<t>It is RECOMMENDED that the test report will display such results appropriately,
although MLRsearch specification does not prescibe how.</t>


<t>Anything else regarging Irregular Goal Results,
including their role in stopping conditions of the search
is outside the scope of this document.</t>

</section>
<section anchor="search-result"><name>Search Result</name>

<t>Definition:</t>

<t>The Search Result is a single composite object
that maps each Search Goal instance to a corresponding Goal Result instance.</t>

<t>Discussion:</t>

<t>Alternatively, the Search Result can be implemented as an ordered list
of the Goal Result instances, matching the order of Search Goal instances.</t>


<t>The Search Result (as a mapping)
MUST map from all the Search Goal instances present in the Controller Input.</t>



</section>
<section anchor="controller-output"><name>Controller Output</name>

<t>Definition:</t>

<t>The Controller Output is a composite quantity returned from the Controller
to the Manager at the end of the search.
The Search Result instance is its only REQUIRED attribute.</t>

<t>Discussion:</t>

<t>MLRsearch implementation MAY return additional data in the Controller Output.</t>


</section>
</section>
<section anchor="mlrsearch-architecture"><name>MLRsearch Architecture</name>


<t>MLRsearch architecture consists of three main system components:
the Manager, the Controller, and the Measurer.</t>

<t>The architecture also implies the presence of other components,
such as the SUT and the Tester (as a sub-component of the Measurer).</t>

<t>Protocols of communication between components are generally left unspecified.
For example, when MLRsearch specification mentions &quot;Controller calls Measurer&quot;,
it is possible that the Controller notifies the Manager
to call the Measurer indirectly instead. This way the Measurer implementations
can be fully independent from the Controller implementations,
e.g. programmed in different programming languages.</t>

<section anchor="measurer"><name>Measurer</name>

<t>Definition:</t>

<t>The Measurer is an abstract system component
that when called with a [Trial Input] (#Trial-Input) instance,
performs one [Trial] (#Trial),
and returns a [Trial Output] (#Trial-Output) instance.</t>

<t>Discussion:</t>

<t>This definition assumes the Measurer is already initialized.
In practice, there may be additional steps before the search,
e.g. when the Manager configures the traffic profile
(either on the Measurer or on its tester sub-component directly)
and performs a warmup (if the tester requires one).</t>

<t>It is the responsibility of the Measurer implementation to uphold
any requirements and assumptions present in MLRsearch specification,
e.g. trial forwarding ratio not being larger than one.</t>

<t>Implementers have some freedom.
For example <xref target="RFC2544"></xref> (section 10. Verifying received frames)
gives some suggestions (but not requirements) related to
duplicated or reordered frames.
Implementations are RECOMMENDED to document their behavior
related to such freedoms in as detailed a way as possible.</t>

<t>It is RECOMMENDED to benchmark the test equipment first,
e.g. connect sender and receiver directly (without any SUT in the path),
find a load value that guarantees the offered load is not too far
from the intended load, and use that value as the Max Load value.
When testing the real SUT, it is RECOMMENDED to turn any big difference
between the intended load and the offered load into increased Trial Loss Ratio.</t>

<t>Neither of the two recommendations are made into requirements,
because it is not easy to tell when the difference is big enough,
in a way thay would be dis-entangled from other Measurer freedoms.</t>

</section>
<section anchor="controller"><name>Controller</name>

<t>Definition:</t>

<t>The Controller is an abstract system component
that when called with a Controller Input instance
repeatedly computes Trial Input instance for the Measurer,
obtains corresponding Trial Output instances,
and eventually returns a Controller Output instance.</t>

<t>Discussion:</t>

<t>Informally, the Controller has big freedom in selection of Trial Inputs,
and the implementations want to achieve the Search Goals
in the shortest expected time.</t>

<t>The Controller&#39;s role in optimizing the overall search time
distinguishes MLRsearch algorithms from simpler search procedures.</t>

<t>Informally, each implementation can have different stopping conditions.
Goal Width is only one example.
In practice, implementation details do not matter,
as long as Goal Results are regular.</t>

</section>
<section anchor="manager"><name>Manager</name>

<t>Definition:</t>

<t>The Manager is an abstract system component that is reponsible for
configuring other components, calling the Controller component once,
and for creating the test report following the reporting format as
defined in <xref target="RFC2544"></xref> (section 26. Benchmarking tests).</t>

<t>Discussion:</t>

<t>The Manager initializes the SUT, the Measurer (and the Tester if independent)
with their intended configurations before calling the Controller.</t>

<t>The Manager does not need to be able to tweak any Search Goal attributes,
but it MUST report all applied attribute values even if not tweaked.</t>


<t>In principle, there should be a &quot;user&quot; (human or CI)
that &quot;starts&quot; or &quot;calls&quot; the Manager and receives the report.
The Manager MAY be able to be called more than once whis way.</t>


</section>
</section>
<section anchor="implementation-compliance"><name>Implementation Compliance</name>

<t>Any networking measurement setup where there can be logically delineated system components
and there are components satisfying requirements for the Measurer,
the Controller and the Manager, is considered to be compliant with MLRsearch design.</t>

<t>These components can be seen as abstractions present in any testing procedure.
For example, there can be a single component acting both
as the Manager and the Controller, but as long as values of required attributes
of Search Goals and Goal Results are visible in the test report,
the Controller Input instance and output instance are implied.</t>

<t>For example, any setup for conditionally (or unconditionally)
compliant <xref target="RFC2544"></xref> throughput testing
can be understood as a MLRsearch architecture,
assuming there is enough data to reconstruct the Relevant Upper Bound.</t>

<t>See [RFC2544 Goal] (#RFC2544-Goal) subsection for equivalent Search Goal.</t>

<t>Any test procedure that can be understood as (one call to the Manager of)
MLRsearch architecture is said to be compliant with MLRsearch specification.</t>

</section>
</section>
<section anchor="additional-considerations"><name>Additional Considerations</name>

<t>This section focuses on additional considerations, intuitions and motivations
pertaining to MLRsearch methodology.</t>


<section anchor="mlrsearch-versions"><name>MLRsearch Versions</name>

<t>The MLRsearch algorithm has been developed in a code-first approach,
a Python library has been created, debugged, used in production
and published in PyPI before the first descriptions
(even informal) were published.</t>

<t>But the code (and hence the description) was evolving over time.
Multiple versions of the library were used over past several years,
and later code was usually not compatible with earlier descriptions.</t>

<t>The code in (some version of) MLRsearch library fully determines
the search process (for a given set of configuration parameters),
leaving no space for deviations.</t>



<t>This historic meaning of MLRsearch, as a family
of search algorithm implementations,
leaves plenty of space for future improvements, at the cost
of poor comparability of results of search algoritm implementations.</t>


<t>There are two competing needs.
There is the need for standardization in areas critical to comparability.
There is also the need to allow flexibility for implementations
to innovate and improve in other areas.
This document defines MLRsearch as a new specification
in a manner that aims to fairly balance both needs.</t>

</section>
<section anchor="stopping-conditions"><name>Stopping Conditions</name>

<t><xref target="RFC2544"></xref> prescribes that after performing one trial at a specific offered load,
the next offered load should be larger or smaller, based on frame loss.</t>

<t>The usual implementation uses binary search.
Here a lossy trial becomes
a new upper bound, a lossless trial becomes a new lower bound.
The span of values between the tightest lower bound
and the tightest upper bound (including both values) forms an interval of possible results,
and after each trial the width of that interval halves.</t>

<t>Usually the binary search implementation tracks only the two tightest bounds,
simply calling them bounds.
But the old values still remain valid bounds,
just not as tight as the new ones.</t>

<t>After some number of trials, the tightest lower bound becomes the throughput.
<xref target="RFC2544"></xref> does not specify when, if ever, should the search stop.</t>

<t>MLRsearch introduces a concept of [Goal Width] (#Goal-Width).</t>

<t>The search stops
when the distance between the tightest upper bound and the tightest lower bound
is smaller than a user-configured value, called Goal Width from now on.
In other words, the interval width at the end of the search
has to be no larger than the Goal Width.</t>

<t>This Goal Width value therefore determines the precision of the result.
Due to the fact that MLRsearch specification requires a particular
structure of the result (see [Trial Result] (#Trial-Result) section),
the result itself does contain enough information to determine its
precision, thus it is not required to report the Goal Width value.</t>

<t>This allows MLRsearch implementations to use stopping conditions
different from Goal Width.</t>

</section>
<section anchor="load-classification"><name>Load Classification</name>

<t>MLRsearch keeps the basic logic of binary search (tracking tightest bounds,
measuring at the middle), perhaps with minor technical differences.</t>

<t>MLRsearch algorithm chooses an intended load (as opposed to the offered load),
the interval between bounds does not need to be split
exactly into two equal halves,
and the final reported structure specifies both bounds.</t>

<t>The biggest difference is that to classify a load
as an upper or lower bound, MLRsearch may need more than one trial
(depending on configuration options) to be performed at the same intended load.</t>

<t>In consequence, even if a load already does have few trial results,
it still may be classified as undecided, neither a lower bound nor an upper bound.</t>

<t>An explanation of the classification logic is given in the next section [Logic of Load Classification] (#Logic-of-Load-Classification),
as it heavily relies on other subsections of this section.</t>

<t>For repeatability and comparability reasons, it is important that
given a set of trial results, all implementations of MLRsearch
classify the load equivalently.</t>

</section>
<section anchor="loss-ratios"><name>Loss Ratios</name>

<t>Another difference between MLRsearch and <xref target="RFC2544"></xref> binary search is in the goals of the search.
<xref target="RFC2544"></xref> has a single goal,
based on classifying full-length trials as either lossless or lossy.</t>

<t>MLRsearch, as the name suggests, can search for multiple goals,
differing in their loss ratios.
The precise definition of the Goal Loss Ratio will be given later.
The <xref target="RFC2544"></xref> throughput goal then simply becomes a zero Goal Loss Ratio.
Different goals also may have different Goal Widths.</t>

<t>A set of trial results for one specific intended load value
can classify the load as an upper bound for some goals, but a lower bound
for some other goals, and undecided for the rest of the goals.</t>

<t>Therefore, the load classification depends not only on trial results,
but also on the goal.
The overall search procedure becomes more complicated, when
compared to binary search with a single goal,
but most of the complications do not affect the final result,
except for one phenomenon, loss inversion.</t>

</section>
<section anchor="loss-inversion"><name>Loss Inversion</name>

<t>In <xref target="RFC2544"></xref> throughput search using bisection, any load with a lossy trial
becomes a hard upper bound, meaning every subsequent trial has a smaller
intended load.</t>

<t>But in MLRsearch, a load that is classified as an upper bound for one goal
may still be a lower bound for another goal, and due to the other goal
MLRsearch will probably perform trials at even higher loads.
What to do when all such higher load trials happen to have zero loss?
Does it mean the earlier upper bound was not real?
Does it mean the later lossless trials are not considered a lower bound?
Surely we do not want to have an upper bound at a load smaller than a lower bound.</t>

<t>MLRsearch is conservative in these situations.
The upper bound is considered real, and the lossless trials at higher loads
are considered to be a coincidence, at least when computing the final result.</t>

<t>This is formalized using new notions, the [Relevant Upper Bound] (#Relevant-Upper-Bound) and
the [Relevant Lower Bound] (#Relevant-Lower-Bound).
Load classification is still based just on the set of trial results
at a given intended load (trials at other loads are ignored),
making it possible to have a lower load classified as an upper bound,
and a higher load classified as a lower bound (for the same goal).
The Relevant Upper Bound (for a goal) is the smallest load classified
as an upper bound.
But the Relevant Lower Bound is not simply
the largest among lower bounds.
It is the largest load among loads
that are lower bounds while also being smaller than the Relevant Upper Bound.</t>

<t>With these definitions, the Relevant Lower Bound is always smaller
than the Relevant Upper Bound (if both exist), and the two relevant bounds
are used analogously as the two tightest bounds in the binary search.
When they are less than the Goal Width apart,
the relevant bounds are used in the output.</t>

<t>One consequence is that every trial result can have an impact on the search result.
That means if your SUT (or your traffic generator) needs a warmup,
be sure to warm it up before starting the search.</t>

</section>
<section anchor="exceed-ratio"><name>Exceed Ratio</name>

<t>The idea of performing multiple trials at the same load comes from
a model where some trial results (those with high loss) are affected
by infrequent effects, causing poor repeatability of <xref target="RFC2544"></xref> throughput results.
See the discussion about noiseful and noiseless ends
of the SUT performance spectrum in section [DUT in SUT] (#DUT-in-SUT).
Stable results are closer to the noiseless end of the SUT performance spectrum,
so MLRsearch may need to allow some frequency of high-loss trials
to ignore the rare but big effects near the noiseful end.</t>

<t>MLRsearch can do such trial result filtering, but it needs
a configuration option to tell it how frequent can the infrequent big loss be.
This option is called the exceed ratio.
It tells MLRsearch what ratio of trials
(more exactly what ratio of trial seconds) can have a [Trial Loss Ratio] (#Trial-Loss-Ratio)
larger than the Goal Loss Ratio and still be classified as a lower bound.
Zero exceed ratio means all trials have to have a Trial Loss Ratio
equal to or smaller than the Goal Loss Ratio.</t>

<t>For explainability reasons, the RECOMMENDED value for exceed ratio is 0.5,
as it simplifies some later concepts by relating them to the concept of median.</t>

</section>
<section anchor="duration-sum"><name>Duration Sum</name>

<t>When more than one trial is intended to classify a load,
MLRsearch also needs something that controls the number of trials needed.
Therefore, each goal also has an attribute called duration sum.</t>

<t>The meaning of a [Goal Duration Sum] (#Goal-Duration-Sum) is that
when a load has (full-length) trials
whose trial durations when summed up give a value at least as big
as the Goal Duration Sum value,
the load is guaranteed to be classified either as an upper bound
or a lower bound for that goal.</t>

<t>Due to the fact that the duration sum has a big impact
on the overall search duration, and <xref target="RFC2544"></xref> prescribes
wait intervals around trial traffic,
the MLRsearch algorithm is allowed to sum durations that are different
from the actual trial traffic durations.</t>

<t>In the MLRsearch specification, the different duration values are called
[Trial Effective Duration] (#Trial-Effective-Duration).</t>

</section>
<section anchor="short-trials"><name>Short Trials</name>

<t>MLRsearch requires each goal to specify its final trial duration.
Full-length trial is a shorter name for a trial whose intended trial duration
is equal to (or longer than) the goal final trial duration.</t>

<t>Section 24 of <xref target="RFC2544"></xref> already anticipates possible time savings
when short trials (shorter than full-length trials) are used.
Full-length trials are the opposite of short trials,
so they may also be called long trials.</t>

<t>Any MLRsearch implementation may include its own configuration options
which control when and how MLRsearch chooses to use short trial durations.</t>

<t>For explainability reasons, when exceed ratio of 0.5 is used,
it is recommended for the Goal Duration Sum to be an odd multiple
of the full trial durations, so Conditional Throughput becomes identical to
a median of a particular set of trial forwarding rates.</t>

<t>The presence of short trial results complicates the load classification logic.</t>

<t>Full details are given later in section [Logic of Load Classification] (#Logic-of-Load-Classification).
In a nutshell, results from short trials
may cause a load to be classified as an upper bound.
This may cause loss inversion, and thus lower the Relevant Lower Bound,
below what would classification say when considering full-length trials only.</t>



</section>
<section anchor="throughput"><name>Throughput</name>


<t>Due to the fact that testing equipment takes the intended load as an input parameter
for a trial measurement, any load search algorithm needs to deal
with intended load values internally.</t>

<t>But in the presence of goals with a non-zero loss ratio, the intended load
usually does not match the user&#39;s intuition of what a throughput is.
The forwarding rate (as defined in <xref target="RFC2285"></xref> section 3.6.1) is better,
but it is not obvious how to generalize it
for loads with multiple trial results and a non-zero
[Goal Loss Ratio] (#Goal-Loss-Ratio).</t>

<t>The best example is also the main motivation: hard limit performance.
Even if the medium allows higher performance,
the SUT interfaces may have their additional own limitations,
e.g. a specific fps limit on the NIC (a very common occurance).</t>

<t>Ideally, those should be known and used when computing Max Load.
But if Max Load is higher that what interface can receive or transmit,
there will be a &quot;hard limit&quot; observed in trial results.
Imagine the hard limit is at 100 Mfps, Max Load is higher,
and the goal loss ratio is 0.5%. If DUT has no additional losses,
0.5% loss ratio will be achieved at 100.5025 Mfps (the relevant lower bound).
But it is not intuitive to report SUT performance as a value that is
larger than known hard limit.
We need a generalization of RFC2544 throughput,
different from just the relevant lower bound.</t>

<t>MLRsearch defines one such generalization, called the Conditional Throughput.
It is the trial forwarding rate from one of the trials
performed at the load in question.
Determining which trial exactly is defined in
[MLRsearch Specification] (#MLRsearch-Specification),
and in [Appendix B: Conditional Throughput] (#Appendix-B:-Conditional-Throughput).</t>

<t>In the hard limit example, 100.5 Mfps load will still have
only 100.0 Mfps forwarding rate, nicely confirming the known limitation.</t>

<t>Conditional Throughput is partially related to load classification.
If a load is classified as a lower bound for a goal,
the Conditional Throughput can be calculated from trial results,
and guaranteed to show an loss ratio
no larger than the Goal Loss Ratio.</t>




<t>Note that when comparing the best (all zero loss) and worst case (all loss
just below Goal Loss Ratio), the same Relevant Lower Bound value
may result in the Conditional Throughput differing up to the Goal Loss Ratio.</t>

<t>Therefore it is rarely needed to set the Goal Width (if expressed
as the relative difference of loads) below the Goal Loss Ratio.
In other words, setting the Goal Width below the Goal Loss Ratio
may cause the Conditional Throughput for a larger loss ratio to become smaller
than a Conditional Throughput for a goal with a smaller Goal Loss Ratio,
which is counter-intuitive, considering they come from the same search.
Therefore it is RECOMMENDED to set the Goal Width to a value no smaller
than the Goal Loss Ratio.</t>

<t>Overall, this Conditional Throughput does behave well for comparability purposes.</t>

</section>
<section anchor="search-time"><name>Search Time</name>

<t>MLRsearch was primarily developed to reduce the time
required to determine a throughput, either the <xref target="RFC2544"></xref> compliant one,
or some generalization thereof.
The art of achieving short search times
is mainly in the smart selection of intended loads (and intended durations)
for the next trial to perform.</t>

<t>While there is an indirect impact of the load selection on the reported values,
in practice such impact tends to be small,
even for SUTs with quite a broad performance spectrum.</t>

<t>A typical example of two approaches to load selection leading to different
Relevant Lower Bounds is when the interval is split in a very uneven way.
Any implementation choosing loads very close to the current Relevant Lower Bound
is quite likely to eventually stumble upon a trial result
with poor performance (due to SUT noise).
For an implementation choosing loads very close
to the current Relevant Upper Bound, this is unlikely,
as it examines more loads that can see a performance
close to the noiseless end of the SUT performance spectrum.</t>

<t>However, as even splits optimize search duration at give precision,
MLRsearch implementations that prioritize minimizing search time
are unlikely to suffer from any such bias.</t>

<t>Therefore, this document remains quite vague on load selection
and other optimization details, and configuration attributes related to them.
Assuming users prefer libraries that achieve short overall search time,
the definition of the Relevant Lower Bound
should be strict enough to ensure result repeatability
and comparability between different implementations,
while not restricting future implementations much.</t>


</section>
<section anchor="rfc2544-compliance"><name><xref target="RFC2544"></xref> Compliance</name>

<t>Some Search Goal instances lead to results compliant with RFC2544.
See [RFC2544 Goal] (#RFC2544-Goal) for more details
regarding both conditional and unconditional compliance.</t>

<t>The presence of other Search Goals does not affect the compliance
of this Goal Result.
The Relevant Lower Bound and the Conditional Throughput are in this case
equal to each other, and the value is the <xref target="RFC2544"></xref> throughput.</t>

</section>
</section>
<section anchor="logic-of-load-classification"><name>Logic of Load Classification</name>

<section anchor="introductory-remarks"><name>Introductory Remarks</name>

<t>This chapter continues with explanations,
but this time more precise definitions are needed
for readers to follow the explanations.</t>

<t>Descriptions in this section are wordy and implementers should read
[MLRsearch Specification] (#MLRsearch-Specification) section
and Appendices for more concise definitions.</t>

<t>The two areas of focus here are load classification
and the Conditional Throughput.</t>

<t>To start with [Performance Spectrum] (#Performance-Spectrum)
subsection contains definitions needed to gain insight
into what Conditional Throughput means.
Remaining subsections discuss load classification.</t>

<t>For load classification, it is useful to define <strong>good trials</strong> and <strong>bad trials</strong>:</t>

<t><list style="symbols">
  <t><strong>Bad trial</strong>: Trial is called bad (according to a goal)
if its [Trial Loss Ratio] (#Trial-Loss-Ratio)
is larger than the [Goal Loss Ratio] (#Goal-Loss-Ratio).</t>
  <t><strong>Good trial</strong>: Trial that is not bad is called good.</t>
</list></t>

</section>
<section anchor="performance-spectrum"><name>Performance Spectrum</name>
<t>### Description</t>

<t>There are several equivalent ways to explain the Conditional Throughput
computation. One of the ways relies on performance
spectrum.</t>

<t>Take an intended load value, a trial duration value, and a finite set
of trial results, with all trials measured at that load value and duration value.</t>

<t>The performance spectrum is the function that maps
any non-negative real number into a sum of trial durations among all trials
in the set, that has that number, as their trial forwarding rate,
e.g. map to zero if no trial has that particular forwarding rate.</t>

<t>A related function, defined if there is at least one trial in the set,
is the performance spectrum divided by the sum of the durations
of all trials in the set.</t>

<t>That function is called the performance probability function, as it satisfies
all the requirements for probability mass function
of a discrete probability distribution,
the one-dimensional random variable being the trial forwarding rate.</t>

<t>These functions are related to the SUT performance spectrum,
as sampled by the trials in the set.</t>


<t>Take a set of all full-length trials performed at the Relevant Lower Bound,
sorted by decreasing trial forwarding rate.
The sum of the durations of those trials
may be less than the Goal Duration Sum, or not.
If it is less, add an imaginary trial result with zero trial forwarding rate,
such that the new sum of durations is equal to the Goal Duration Sum.
This is the set of trials to use.</t>

<t>If the quantile touches two trials,</t>


<t>the larger trial forwarding rate (from the trial result sorted earlier) is used.</t>


<t>The resulting quantity is the Conditional Throughput of the goal in question.</t>


<t>A set of examples follows.</t>

<section anchor="first-example"><name>First Example</name>

<t><list style="symbols">
  <t>[Goal Exceed Ratio] (#Goal-Exceed-Ratio) = 0 and [Goal Duration Sum] (#Goal-Duration-Sum) has been reached.</t>
  <t>Conditional Throughput is the smallest trial forwarding rate among the trials.</t>
</list></t>

</section>
<section anchor="second-example"><name>Second Example</name>

<t><list style="symbols">
  <t>Goal Exceed Ratio = 0 and Goal Duration Sum has not been reached yet.</t>
  <t>Due to the missing duration sum, the worst case may still happen, so the Conditional Throughput is zero.</t>
  <t>This is not reported to the user, as this load cannot become the Relevant Lower Bound yet.</t>
</list></t>

</section>
<section anchor="third-example"><name>Third Example</name>

<t><list style="symbols">
  <t>Goal Exceed Ratio = 50% and Goal Duration Sum is two seconds.</t>
  <t>One trial is present with the duration of one second and zero loss.</t>
  <t>The imaginary trial is added with the duration of one second and zero trial forwarding rate.</t>
  <t>The median would touch both trials, so the Conditional Throughput is the trial forwarding rate of the one non-imaginary trial.</t>
  <t>As that had zero loss, the value is equal to the offered load.</t>
</list></t>


</section>
<section anchor="summary"><name>Summary</name>

<t>While the Conditional Throughput is a generalization of the trial forwarding rate,
its definition is not an obvious one.</t>

<t>Other than the trial forwarding rate, the other source of intuition
is the quantile in general, and the median the recommended case.</t>


</section>
</section>
<section anchor="trials-with-single-duration"><name>Trials with Single Duration</name>


<t>When goal attributes are chosen in such a way that every trial has the same
intended duration, the load classification is simpler.</t>

<t>The following description follows the motivation
of Goal Loss Ratio, Goal Exceed Ratio, and Goal Duration Sum.</t>

<t>If the sum of the durations of all trials (at the given load)
is less than the Goal Duration Sum, imagine two scenarios:</t>

<t><list style="symbols">
  <t><strong>best case scenario</strong>: all subsequent trials having zero loss, and</t>
  <t><strong>worst case scenario</strong>: all subsequent trials having 100% loss.</t>
</list></t>

<t>Here we assume there are as many subsequent trials as needed
to make the sum of all trials equal to the Goal Duration Sum.</t>

<t>The exceed ratio is defined using sums of durations
(and number of trials does not matter), so it does not matter whether
the &quot;subsequent trials&quot; can consist of an integer number of full-length trials.</t>

<t>In any of the two scenarios, best case and worst case, we can compute the load exceed ratio,
as the duration sum of good trials divided by the duration sum of all trials,
in both cases including the assumed trials.</t>

<t>Even if, in the best case scenario, the load exceed ratio is larger
than the Goal Exceed Ratio, the load is an upper bound.</t>

<t>MKP2 Even if, in the worst case scenario, the load exceed ratio is not larger
than the Goal Exceed Ratio, the load is a lower bound.</t>


<t>More specifically:</t>

<t><list style="symbols">
  <t>Take all trials measured at a given load.</t>
  <t>The sum of the durations of all bad full-length trials is called the bad sum.</t>
  <t>The sum of the durations of all good full-length trials is called the good sum.</t>
  <t>The result of adding the bad sum plus the good sum is called the measured sum.</t>
  <t>The larger of the measured sum and the Goal Duration Sum is called the whole sum.</t>
  <t>The whole sum minus the measured sum is called the missing sum.</t>
  <t>The optimistic exceed ratio is the bad sum divided by the whole sum.</t>
  <t>The pessimistic exceed ratio is the bad sum plus the missing sum, that divided by the whole sum.</t>
  <t>If the optimistic exceed ratio is larger than the Goal Exceed Ratio, the load is classified as an upper bound.</t>
  <t>If the pessimistic exceed ratio is not larger than the Goal Exceed Ratio, the load is classified as a lower bound.</t>
  <t>Else, the load is classified as undecided.</t>
</list></t>

<t>The definition of pessimistic exceed ratio is compatible with the logic in
the Conditional Throughput computation, so in this single trial duration case,
a load is a lower bound if and only if the Conditional Throughput
loss ratio is not larger than the Goal Loss Ratio.</t>


<t>If it is larger, the load is either an upper bound or undecided.</t>

</section>
<section anchor="trials-with-short-duration"><name>Trials with Short Duration</name>

<section anchor="scenarios"><name>Scenarios</name>

<t>Trials with intended duration smaller than the goal final trial duration
are called short trials.
The motivation for load classification logic in the presence of short trials
is based around a counter-factual case: What would the trial result be
if a short trial has been measured as a full-length trial instead?</t>

<t>There are three main scenarios where human intuition guides
the intended behavior of load classification.</t>

<section anchor="false-good-scenario"><name>False Good Scenario</name>

<t>The user had their reason for not configuring a shorter goal
final trial duration.
Perhaps SUT has buffers that may get full at longer
trial durations.
Perhaps SUT shows periodic decreases in performance
the user does not want to be treated as noise.</t>

<t>In any case, many good short trials may become bad full-length trials
in the counter-factual case.</t>

<t>In extreme cases, there are plenty of good short trials and no bad short trials.</t>

<t>In this scenario, we want the load classification NOT to classify the load
as a lower bound, despite the abundance of good short trials.</t>


<t>Effectively, we want the good short trials to be ignored, so they
do not contribute to comparisons with the Goal Duration Sum.</t>

</section>
<section anchor="true-bad-scenario"><name>True Bad Scenario</name>

<t>When there is a frame loss in a short trial,
the counter-factual full-length trial is expected to lose at least as many
frames.</t>

<t>In practice, bad short trials are rarely turning into
good full-length trials.</t>

<t>In extreme cases, there are no good short trials.</t>

<t>In this scenario, we want the load classification
to classify the load as an upper bound just based on the abundance
of short bad trials.</t>

<t>Effectively, we want the bad short trials
to contribute to comparisons with the Goal Duration Sum,
so the load can be classified sooner.</t>

</section>
<section anchor="balanced-scenario"><name>Balanced Scenario</name>

<t>Some SUTs are quite indifferent to trial duration.
Performance probability function constructed from short trial results
is likely to be similar to the performance probability function constructed
from full-length trial results (perhaps with larger dispersion,
but without a big impact on the median quantiles overall).</t>


<t>For a moderate Goal Exceed Ratio value, this may mean there are both
good short trials and bad short trials.</t>

<t>This scenario is there just to invalidate a simple heuristic
of always ignoring good short trials and never ignoring bad short trials,
as that simple heuristic would be too biased.</t>

<t>Yes, the short bad trials
are likely to turn into full-length bad trials in the counter-factual case,
but there is no information on what would the good short trials turn into.</t>

<t>The only way to decide safely is to do more trials at full length,
the same as in False Good Scenario.</t>

</section>
</section>
<section anchor="classification-logic"><name>Classification Logic</name>

<t>MLRsearch picks a particular logic for load classification
in the presence of short trials, but it is still RECOMMENDED
to use configurations that imply no short trials,
so the possible inefficiencies in that logic
do not affect the result, and the result has better explainability.</t>

<t>With that said, the logic differs from the single trial duration case
only in different definition of the bad sum.
The good sum is still the sum across all good full-length trials.</t>

<t>Few more notions are needed for defining the new bad sum:</t>

<t><list style="symbols">
  <t>The sum of durations of all bad full-length trials is called the bad long sum.</t>
  <t>The sum of durations of all bad short trials is called the bad short sum.</t>
  <t>The sum of durations of all good short trials is called the good short sum.</t>
  <t>One minus the Goal Exceed Ratio is called the subceed ratio.</t>
  <t>The Goal Exceed Ratio divided by the subceed ratio is called the exceed coefficient.</t>
  <t>The good short sum multiplied by the exceed coefficient is called the balancing sum.</t>
  <t>The bad short sum minus the balancing sum is called the excess sum.</t>
  <t>If the excess sum is negative, the bad sum is equal to the bad long sum.</t>
  <t>Otherwise, the bad sum is equal to the bad long sum plus the excess sum.</t>
</list></t>

<t>Here is how the new definition of the bad sum fares in the three scenarios,
where the load is close to what would the relevant bounds be
if only full-length trials were used for the search.</t>

<section anchor="false-good-scenario-1"><name>False Good Scenario</name>

<t>If the duration is too short, we expect to see a higher frequency
of good short trials.
This could lead to a negative excess sum,
which has no impact, hence the load classification is given just by
full-length trials.
Thus, MLRsearch using too short trials has no detrimental effect
on result comparability in this scenario.
But also using short trials does not help with overall search duration,
probably making it worse.</t>

</section>
<section anchor="true-bad-scenario-1"><name>True Bad Scenario</name>

<t>Settings with a small exceed ratio
have a small exceed coefficient, so the impact of the good short sum is small,
and the bad short sum is almost wholly converted into excess sum,
thus bad short trials have almost as big an impact as full-length bad trials.
The same conclusion applies to moderate exceed ratio values
when the good short sum is small.
Thus, short trials can cause a load to get classified as an upper bound earlier,
bringing time savings (while not affecting comparability).</t>

</section>
<section anchor="balanced-scenario-1"><name>Balanced Scenario</name>

<t>Here excess sum is small in absolute value, as the balancing sum
is expected to be similar to the bad short sum.
Once again, full-length trials are needed for final load classification;
but usage of short trials probably means MLRsearch needed
a shorter overall search time before selecting this load for measurement,
thus bringing time savings (while not affecting comparability).</t>

<t>Note that in presence of short trial results,
the comparibility between the load classification
and the Conditional Throughput is only partial.
The Conditional Throughput still comes from a good long trial,
but a load higher than the Relevant Lower Bound may also compute to a good value.</t>

</section>
</section>
</section>
<section anchor="trials-with-longer-duration"><name>Trials with Longer Duration</name>

<t>If there are trial results with an intended duration larger
than the goal trial duration, the precise definitions
in Appendix A and Appendix B treat them in exactly the same way
as trials with duration equal to the goal trial duration.</t>

<t>But in configurations with moderate (including 0.5) or small
Goal Exceed Ratio and small Goal Loss Ratio (especially zero),
bad trials with longer than goal durations may bias the search
towards the lower load values, as the noiseful end of the spectrum
gets a larger probability of causing the loss within the longer trials.</t>




</section>
</section>
<section anchor="iana-considerations"><name>IANA Considerations</name>

<t>No requests of IANA.</t>

</section>
<section anchor="security-considerations"><name>Security Considerations</name>

<t>Benchmarking activities as described in this memo are limited to
technology characterization of a DUT/SUT using controlled stimuli in a
laboratory environment, with dedicated address space and the constraints
specified in the sections above.</t>

<t>The benchmarking network topology will be an independent test setup and
MUST NOT be connected to devices that may forward the test traffic into
a production network or misroute traffic to the test management network.</t>

<t>Further, benchmarking is performed on a &quot;black-box&quot; basis, relying
solely on measurements observable external to the DUT/SUT.</t>

<t>Special capabilities SHOULD NOT exist in the DUT/SUT specifically for
benchmarking purposes. Any implications for network security arising
from the DUT/SUT SHOULD be identical in the lab and in production
networks.</t>

</section>
<section anchor="acknowledgements"><name>Acknowledgements</name>

<t>Some phrases and statements in this document were created
with help of Mistral AI (mistral.ai).</t>

<t>Many thanks to Alec Hothan of the OPNFV NFVbench project for thorough
review and numerous useful comments and suggestions in the earlier versions of this document.</t>

<t>Special wholehearted gratitude and thanks to the late Al Morton for his
thorough reviews filled with very specific feedback and constructive
guidelines. Thank you Al for the close collaboration over the years,
for your continuous unwavering encouragement full of empathy and
positive attitude. Al, you are dearly missed.</t>

</section>
<section anchor="appendix-a-load-classification"><name>Appendix A: Load Classification</name>

<t>This section specifies how to perform the load classification.</t>

<t>Any intended load value can be classified, according to a given [Search Goal] (#Search-Goal).</t>

<t>The algorithm uses (some subsets of) the set of all available trial results
from trials measured at a given intended load at the end of the search.
All durations are those returned by the Measurer.</t>

<t>The block at the end of this appendix holds pseudocode
which computes two values, stored in variables named
<spanx style="verb">optimistic</spanx> and <spanx style="verb">pessimistic</spanx>.</t>


<t>The pseudocode happens to be a valid Python code.</t>

<t>If values of both variables are computed to be true, the load in question
is classified as a lower bound according to the given Search Goal.
If values of both variables are false, the load is classified as an upper bound.
Otherwise, the load is classified as undecided.</t>

<t>The pseudocode expects the following variables to hold values as follows:</t>

<t><list style="symbols">
  <t><spanx style="verb">goal_duration_sum</spanx>: The duration sum value of the given Search Goal.</t>
  <t><spanx style="verb">goal_exceed_ratio</spanx>: The exceed ratio value of the given Search Goal.</t>
  <t><spanx style="verb">good_long_sum</spanx>: Sum of durations across trials with trial duration
at least equal to the goal final trial duration and with a Trial Loss Ratio
not higher than the Goal Loss Ratio.</t>
  <t><spanx style="verb">bad_long_sum</spanx>: Sum of durations across trials with trial duration
at least equal to the goal final trial duration and with a Trial Loss Ratio
higher than the Goal Loss Ratio.</t>
  <t><spanx style="verb">good_short_sum</spanx>: Sum of durations across trials with trial duration
shorter than the goal final trial duration and with a Trial Loss Ratio
not higher than the Goal Loss Ratio.</t>
  <t><spanx style="verb">bad_short_sum</spanx>: Sum of durations across trials with trial duration
shorter than the goal final trial duration and with a Trial Loss Ratio
higher than the Goal Loss Ratio.</t>
</list></t>

<t>The code works correctly also when there are no trial results at a given load.</t>

<figure><sourcecode type="python"><![CDATA[
balancing_sum = good_short_sum * goal_exceed_ratio / (1.0 - goal_exceed_ratio)
effective_bad_sum = bad_long_sum + max(0.0, bad_short_sum - balancing_sum)
effective_whole_sum = max(good_long_sum + effective_bad_sum, goal_duration_sum)
quantile_duration_sum = effective_whole_sum * goal_exceed_ratio
optimistic = effective_bad_sum <= quantile_duration_sum
pessimistic = (effective_whole_sum - good_long_sum) <= quantile_duration_sum
]]></sourcecode></figure>

</section>
<section anchor="appendix-b-conditional-throughput"><name>Appendix B: Conditional Throughput</name>

<t>This section specifies how to compute Conditional Throughput, as referred to in section [Conditional Throughput] (#Conditional-Throughput).</t>

<t>Any intended load value can be used as the basis for the following computation,
but only the Relevant Lower Bound (at the end of the search)
leads to the value called the Conditional Throughput for a given Search Goal.</t>

<t>The algorithm uses (some subsets of) the set of all available trial results
from trials measured at a given intended load at the end of the search.
All durations are those returned by the Measurer.</t>

<t>The block at the end of this appendix holds pseudocode
which computes a value stored as variable <spanx style="verb">conditional_throughput</spanx>.</t>


<t>The pseudocode happens to be a valid Python code.</t>

<t>The pseudocode expects the following variables to hold values as follows:</t>

<t><list style="symbols">
  <t><spanx style="verb">goal_duration_sum</spanx>: The duration sum value of the given Search Goal.</t>
  <t><spanx style="verb">goal_exceed_ratio</spanx>: The exceed ratio value of the given Search Goal.</t>
  <t><spanx style="verb">good_long_sum</spanx>: Sum of durations across trials with trial duration
at least equal to the goal final trial duration and with a Trial Loss Ratio
not higher than the Goal Loss Ratio.</t>
  <t><spanx style="verb">bad_long_sum</spanx>: Sum of durations across trials with trial duration
at least equal to the goal final trial duration and with a Trial Loss Ratio
higher than the Goal Loss Ratio.</t>
  <t><spanx style="verb">long_trials</spanx>: An iterable of all trial results from trials with trial duration
at least equal to the goal final trial duration,
sorted by increasing the Trial Loss Ratio.
A trial result is a composite with the following two attributes available:  <list style="symbols">
      <t><spanx style="verb">trial.loss_ratio</spanx>: The Trial Loss Ratio as measured for this trial.</t>
      <t><spanx style="verb">trial.duration</spanx>: The trial duration of this trial.</t>
    </list></t>
</list></t>

<t>The code works correctly only when there if there is at least one
trial result measured at a given load.</t>

<figure><sourcecode type="python"><![CDATA[
all_long_sum = max(goal_duration_sum, good_long_sum + bad_long_sum)
remaining = all_long_sum * (1.0 - goal_exceed_ratio)
quantile_loss_ratio = None
for trial in long_trials:
    if quantile_loss_ratio is None or remaining > 0.0:
        quantile_loss_ratio = trial.loss_ratio
        remaining -= trial.duration
    else:
        break
else:
    if remaining > 0.0:
        quantile_loss_ratio = 1.0
conditional_throughput = intended_load * (1.0 - quantile_loss_ratio)
]]></sourcecode></figure>

</section>


  </middle>

  <back>


<references title='References' anchor="sec-combined-references">

    <references title='Normative References' anchor="sec-normative-references">

&RFC1242;
&RFC2285;
&RFC2544;
&RFC8219;
&RFC9004;


    </references>

    <references title='Informative References' anchor="sec-informative-references">

<reference anchor="TST009" target="https://www.etsi.org/deliver/etsi_gs/NFV-TST/001_099/009/03.04.01_60/gs_NFV-TST009v030401p.pdf">
  <front>
    <title>TST 009</title>
    <author >
      <organization></organization>
    </author>
    <date year="n.d."/>
  </front>
</reference>
<reference anchor="FDio-CSIT-MLRsearch" target="https://csit.fd.io/cdocs/methodology/measurements/data_plane_throughput/mlr_search/">
  <front>
    <title>FD.io CSIT Test Methodology - MLRsearch</title>
    <author >
      <organization></organization>
    </author>
    <date year="2023" month="October"/>
  </front>
</reference>
<reference anchor="PyPI-MLRsearch" target="https://pypi.org/project/MLRsearch/1.2.1/">
  <front>
    <title>MLRsearch 1.2.1, Python Package Index</title>
    <author >
      <organization></organization>
    </author>
    <date year="2023" month="October"/>
  </front>
</reference>


    </references>

</references>


<?line 3102?>




  </back>

<!-- ##markdown-source:
H4sIAAAAAAAAA+S9+3MbV5Iu+Hv9FRXsmGiyB4Qo+THd2pnVypLVw9uWpZFo
a+/t7ehbBApEjQAUuqogmt7Y/30zv8w8J089QMp2xOzGnYiJlgmg6jzy5MnH
l1+en59nWVd1m/Jp/vqw6ar9psy/q9s2f1d0VZ2/L4tmsc6K6+um/ERf+e5d
K39Z1otdsaVfLZti1Z1XZbc6v97e3pxvN4185fziX7Jl0dFXnlw8+ZL+6/zx
v2RZtW+e5l1zaLsnFxd/uniSFU1ZPM3rfZvd3jzNvyl3i/W2aD5Wu5v8Qy3/
++emPuyzj7dP88tdVza7sjt/yW/NFkX3NK92qzrLFvWSvvo0P7TnRbuoqmxf
Pc3p/36XL4od/bXMi6Yp7vLTapUXm01+V7Zned3k66Jd5+uyKbM87+rFU/6A
/tnWTdeUq/YpHrEsVwUtTkvfsM/vtvIx/2dWHLp13TzNcvzfuf5vTkOjb7ye
53+pd21X7Lq7XX1bLX4On8sKvi4WVflx8kt1Q9N6UbUL2o27tiu3bfio3BbV
5mm+/Sg//T8W/K35ot6Oj+THef623hQfe+//sSm6j3Xvo/vf+qnZ8y/cS7Nd
3WxJbD6VvBTvXr14/OTLJ/rPJ0/++JX986svv9R//vHJ4z/pP/90cUF/zXg3
3UOu3l+RmMjKdkVzU9KGr7tu3z599Oj29nZedm01p7E+WpYb+knziP/w95v2
0fevfjynHz+6uHj894s//Yn+l/7/i/nFl3P6w9cXj27av+tX6JNPF19cfHnx
eD/fL1fyKjkRJ/RxTp+f0B9fvazq8xfvL6/OwyEYH9airbr5ajmv6kcLOiXt
o21J0rGsN/XNHf27aA9NuS13XfuITkfx9/2m2JV/79Yk4zfr/aF7RAfo7/L8
R8lYXr2kR+Y8gvyqbLv8dXxsfh5P5gl+FA7eF+ePL+gvb+/eXt438P3dXtZy
39T/WS66R+H7jx7Pn8wfp8MJH+b4cEavoPHs8rfF4mNxU9JRXZY/jQ0mOz8/
z4vrtmuKRZdlV+uqzWmdDrwmOb16X7dlm5c/deWurUiw+dD9VcXmb3lcqFxf
f32X0fmsdqwpinxX3uZuwen0bzblclS3qSY7DTM5m8dlzItqi1dv6cnb6ufS
Xrc8NPzr3SxrD/s9qYl8a8/e8LMb9+yynWXFbpmXu3WxW5R5U7b0XfqffUlb
f11tqu4u5y/Q6dkXjf5lzotS0lJUpAjv6NtFS+tKx0IWhfWcW5AKoyyWS3o4
/ZN+uFjznHc3pJn42U35j0OlIkcPLVv6B63I9R2+XH4qNgdMCAPpSLLo+Vm9
IhW46m5JO59fFy19n7TurerjVhTC73ljixwC3PKg6/yGziAr26bNt3VT5qum
LJf1dubWlXb4U7WkHaYhV/zeYkPT362qG11Yugv4f1paX96GltU1aUR6b1jo
ds3r3jVVsaEplQ2tfLFkHdeV9L809npHu8HiLV+aZV29KfnxkJFF2XRFteNf
LmgxWFrpN/imblGb31Yd3QvVzRpPb3Ujdcv5Mbx4OiXemjC2m5oHhZ9/ou3j
r0a54GVi8d9Wy+WmzLL/++lT2nremv8nw1F5Tj/FCuZ/aYrtsr7d8e7S+pBu
62g56y1dF81H/mCGH+i3Oz5Ft3S/0UTs+tQnt/mu7vgp12X+qWqraxokTZ7H
35A00dW3lEt8jgeaNqALZfGxpteuaPVZvT8qHn355IsnX3zxpwt88ZIuUnoy
LxAJW0UrTkOgsSxnYbz0UhvY03sf/uTij3/86k9/vJCF+Ctdxn/jBXoUFyj7
Xf720LB+gKy+X9T7Us+K/pm3MdEncjpI3BZNRfN/mBqYkYxE0R5ROV7BsLSy
flhCDOzQZO64vPzhivf9+X6/gTh8KnbVZlOMK7XrqiXVy8eAxm1PwyMyE03a
vLaktSNppcNE27lt6eI8z7+pdqwvdIxd8bHkydckfiz1fCLbcGj4oUs+Jaui
EbGijaSFp+fuugOduDuazoEVQhjanF5xBaGBPqH5Vnx25diYVsTG7IsDq/Br
WoKy3Okr6eE0WoyFRa/GBDZ9rcovee9nzWf9liS4au/SE8riv6HjjrNICpBW
jjQT6TfRACQOIupLNk8+QcrdMrPWY6XFUwp/1JnR6siRpceUP9ElRYvxc9nU
tE5kL7Wz/Jq+y3OodkuyY5s7GsmKf0tLR1+FumpFGrY8Rf76rt6d4xn8YHtx
mcvFJVpv5cdXyald0Ayb/HZtqxjUEy9PtaNz1lak9HadqF9/C5ho5HwO6AU0
/+KaFoJ0IX0a9TFr/ESg2325qFbVQvaz3O439Z08clWbJtYLDeoFsvecP5lQ
0D29zPskkzHNzYrnPH+zl9tgczfLVV3TOf8sJT0PI5HJ8VAT5SzuTP5n1tEz
+fmyWq3KZqCmeUTPd6nMwZUo6OuLLi8Leo57HJ9KurF3C34Pj+Ny15beOFjU
RcOKGkaXiEf/GTP6S7OpaDK0TiQAdHfCK+EtoWO1wdZWW1oIO1Qyzm/1V/Zs
+qBm+wUv4V/RZ3QwyFDHCeOf/EBDeVU3dMxwgN7xWp++eneWFzTk4qdqe9jS
cq9wbHiLRCerHf+3/NSU1Bfzr+dPzniMkONiw5aSnA38p40JAk8aiZaQJBcC
vSzp2/Ru7IKX5XSTZbzvSr530zNMZwQHjGdO4ig3Mv5AEg2LIMiHSgc/6b3+
BF+gDV1WbJ7KiVLrnFVb00LhQWkHdYvftOVGJ78uDw0NuVrgkmmLTyX0p5g+
vFH0QjazxApY01pDU32qq2V+2O3KBW1N0VT0AlLcDUntNatcvive11u9zMhc
S04bxgkXaYNLh/R6PMvJ0ZWD3rC3tuufWTyFHNyik0dUdMrxiRz6ZUn2EZ0Q
esKBvksHqfyEKfBSJrYqlrimzdjQJQi7aHXoDqyctmzoydtoQnGMo7aezGpT
/gSVXe54i2mtgol9TXYG/5Ik+RN8Q9qFjl/X4sIpbm5Y7/m/z2EXjP+Erw3e
CZWw7MDCZ8Yo7QbPcFORKy4CFO7pWcaqnK8wkp/exYVx0I3flql5P89ewBgi
qSG9NjLQMBrozOGDYXfSVcofJU+O95C/FHBrTIyf9uH7mm5nWlCSrcSFqHbs
WZRLtRPr65Y0cHATnEU1Zyvscsl3yqqiz9/qNaOOHPkeex6pWVy9u0iUJ4vJ
odVpsKtBhnJVH2DKQ7TZV1JPxF1NFbtTLM18ydI14q0d1nRxQtMb6s2Z7He/
IzuQXqEq+KWteGKWQ/F9R4eTtHvd0ID/Jgbqv7KZ/b+//svbJ/lff3z7t/zq
zcs3T+l59Ue5cuTWhRHRFxW6KkjSZXo05nb+r4/wsGMPJmubtxZG2UzsBtp4
Oo8dLaqsuPrAJ9EzOYlPTgxpPhp0NEkz80o7Xw8ml16MZtLEDw97VZV85LLd
YXvNV9VKr1D+Kiwk3m5Wbdi9eqk/SM49beSa1c5uwd4tixkfcB54fGpfGNgA
VsuThJSOVLUSF5bGrEMTF3Zd2tgX8Ica0rXisbGLgEfNRVq3YiM7cxTWUPlT
uTiIDc63bdTppNTojIoc0YVzXdIAS3XXF4cGSzBq1Ts7jw4r3W+LTk9GzTce
XXcZCw2/7rxckQavMPhUiT6XQdCm8Vih/d0raH0X5Z7/97DhiEPBmnR1aNRB
i7o/u11X9BEfpE6vBjmjaiBAHnAhNHr4Wp1i9E3k7zO5yB+uPiuO6yxEAfK1
ys6f7ETF7sKiQJyW3n6zwzVGjyi2JPHQV9gLvvP3vMzBBMrwEr6ZeUWLbsbH
qym7pubbkP4TV4vzctRvoTuubLbVrkx9nCzu37IuxQqXa5UjNTTmrt7vxbvW
OeO4D3zEWUY2mERCig07JXdkAHxiCaX7dAFLjp0WXJs8hKZYludkcWXmNY3d
L3IT09edNffv9S1bJzOxJlcHEuKvL85po2o+C2KBL+sDSUOb7jNGyNPbFmbn
trBwr2E11Pweu91pTw7XiE5XMIPEOXKjYF3K55DW/v0PV7qKMBVFVZGXcI4v
FC2sMBYndZF5/cwOXZKdwce9Jsmq2KChTT9sDpAPM0dpIaAn6SDt+XqPVtuo
ffp4/vgMXmX68gX5MvwduYl5NjYcGUN7dBAYAIemctZyMFk6i+U9eFxPzhJx
U+MN7ifUEI3rsJczVOwQ+2vgcNNnbCZgVIXForJBfG4mBh7/oSKdVkER+DHT
dsw4BSJ/w2/4Mtb5z/iltGg0xkuxrRdFm14W8ZUzfIGXWM14yAcLV823tWrp
TN5kPyfddkP3hb8uvIcNL6ZeZWzAlQ3MZ/yM17jeWzRPxk1yv1voxYIFY02Q
939JO1MfGt7blv7GorRoWJRZ8etgcCdtDiyMMJ/7L6LV+HPF9wFeYJOuMC95
Jhy+c9LqrL3K3aeqqXesdzPS6Gw5y0Tt3sJksDP8Ibl9pKBn4dMt7ndSV0sO
pyG8kJU/0ZAqXNxstDW4eRdlVG/9IWe0xfKKsPLxK7W6TXxty3Il3odahuEl
qh7Y1L9h32GekRMJB5+vl1lGmnGnIa+wvaQaSyjnOvgn+Yu3P9CEG41QV2Rs
miDzFY1P8C7SMByQYqnq6ADkLW0u3Hoa5Us6Z6Q7OdCFsC5t4opOHDwI1kzF
QQSCpk3TwRKyLwULlK9+1uUV/YiuOk5E6Jr/vg2KwBkgczkDzg6emW+mz+Nl
jTqF9qkpadHUWCG5ZzHhKFY5E3uiWkn43f2cjwt987Cj0S/JQuAbnI/MLYua
D7RKuIIDWxVdtDusFU0Ej+eF4WPI9wwfoPKndXVN53+1OSy6g6yyt6yqjjyT
1QyXmGQa2owH0pQbOIcI4eLoQEmyQuDAAQfG2ESg+wnqWkN+sGzVeOKhcwhD
I6OQI9ZfJCtdSfeUO/dYXlxDrGNarHTGO3Rdiurjm5yvvbI5J3uSzAP6hK5T
MshncF/J1IDZI64Le3zwI2mhMxpSka/v9ryA5KrzABZ0OMmYZ+uF9QlHIVUv
yAxlJbEnJV/QOxH195yPsPeqK9P2IlJ4G8fhyYKqNmR10NqEJ5IJJ3cwyVe+
J9OJBHNn3q+FB5biGByqlmyIqid18muyW/Lf44m/t5g7/zIomCxY02HR/ZYH
UVD3JGhnNZ7JwDywdyGroF+Qm+C5Woaw6ze2XP7hXv/T1lWI8rCpiqchhOW+
LlkVlwmSd+qpEO1SRLXxnm8seAljD4MabltaKHNjF5pS10uBd1rEQ2Qp/JD9
T12P6xLKpKNtpUtInqSbx2aDKAtbFBktnzVO9SCrQkaqaBz+F0coN0ty/DOc
eR4EBEQvYIiOPDc+Kf72mm/Ym011wypN7sQYZs4qjkTcsn0JpW/T6u8HnY7w
WbXrh9aCWsN+zvDrYPaKvWqDTddrc6ARVfydVjeoaw50O77ZsS20tAWyD5CH
4eU7Lg76YLl5VeEt7dLRTG4hP4UC6SnoPWeUyXaZJdPMFhv4fXXcMv7x2CjX
xZ6ci1aMloZO5eZOtkcCOzCf+6OlqYlMwjmTH/HKsKfCdjw2PO50A59RfkE3
GudlR8fEO+FXD7ZUUG0ZuUW7m/5uPieFP/JkrPLEo9klO+w21UcedYj96Ftm
IhtwvMw7w2UqeY3krDKOJ4/PqRfkD8fgtwg0+TKSgNXlyH7YYWxm+aopdItb
MtF7v+eA+QImeKYmS/Cc6YVe5++WrZ+o3y+b9IyvJnLj6jZecLZiteSyP7Bj
i1c6K+mlqZ9rj1KiBeAQZbvGDQQJ5wBVtc1YJ9v9EQ3heMHAZOP/9KiQ6NFl
nXrGGlrgODGHgMzIqbzEFzhgTamWBN/lG8SmNZqa4YTTYf1U0L3EP0/vmv6w
2IjwF8UsExgAe6JAO7W/z50pCjUeHr0hu4wMzAOCI89ZJcu+35abzTmUcnPA
hR4U+kuxolWAyCjJDP7gN5DutW5T7srFx2iQscUw4zQ4qwmNiwVbLsN2TCgb
WbLpMzIuOiWkVTOk3vF3rrjoLv970ulNtWBjVEENbF3tFnczmDka2OpBIloa
vIbLELllW5dNwRCSDUGlGdZvdJYZrEADsagWDpfYYJeRJ9YhBhHCZC2hikBV
AaTHrpf8TeL8PqVoWBqy8z+Vcb93sswSHM5oWhzy3QaX9vN2JpOjGkMqMZLY
v/Q4r+dDa6YDhon+YnPDMd81OdM0B759Oo3FZ0n6asQlloADjZunCld+ZjpC
cqoZI6C6ksPaNLZFfbOrfnbBuNZis85zCEgY/o4ltjnGmZ3SbH7iJ9G6nB2T
hs5FazckrRuNUJO0kePCMYzUYuXAzrsBXumFzwGNx8wONzfsMyDNwj8fri5d
WPQoaJv/PLB7sSuzI9l62Bt0yPnp16WP3zFCwFIjGz0kdjfPs7d13cuc8PLt
kHfB1u/5C0lWCxdEXKdE3XclRwn41NbXQBEZymeALpCQrnnXUHUc/SyXtoPB
r7FXsQuC9QhYqRhgG40rJ9iu068vcon7mVfCoTK6CySbruIUDDqJ1XMs78yS
2r1DYPkxRQvF9D85OGIXsaAEj+ionVV17fix9Q5Dg+DEglR6SJ3EUDDpIM7s
J96DZcA20RoKAVML7gMXFJ4J2az1TTIv+R0Ow8BES7NM5uVxrgzxwYLxU3nB
Dl+IvyRaKxtxkcJdEjByATpCj8Xfbkn1w1xgh4DzgpnGZ+Hm8tAOfPOJyoP8
JtuW5B8zAe14+VeVa5a1wkYk2+ewlBGxtyhpWcsMJ6uy5B9b/i5rjwXsJW7U
8al4/6Nu2JalbJtkQo6gYHZJ8vL5YlE3Bvg5dheYOzOWNiVXkDE5Za7xu9FL
Jjo0Th7o9pKQkr1+5BLDw9flZi/RF41FTqw/TSlJDu8YPNTpnX8P7FX3Qm6x
tvd8vWfUA66A8WOVhmkuS0aTWA7FG6S4GmUIO0mZS3peUXRw/e84nRZlI7Xw
ZxoAR86ePYWMgz0KkTgt5zdzMhJpfjdiMLJvvuSwB4ecMekzTQepYHJkQ+0N
zj9InB4JPPpJyfdxmpYThVB1LrHXT6OY6MekHv2FLGQSn6Xcdg4Qhu37vt6d
/w+GbjFmUPQw49rTYP6/uJ+dWc7D71rRCgKSD6MBbATh1GmaYcfgKJU/y3VI
PFyyDYzYa8hridhdidTLCd/hemyLO33P+4oPRCmh6jKkbAD5g+Jnv9TQ2QWf
RLrXsO7q57kcHJ0lem6OvKGATgvFeugFZxAsaABaz65e1Bs5JoArHToBq4pb
fJCLgT79uCOFzg8o2ALdhIXhIUmOpzCjN85XoiQCDKG5B6Mb8cORq5rTbXuk
sNhrnWUJFE/h2uoKMHbXJlU1BvcRWyV7XdORKCJchd8H7NtrUjbNLpm3otfi
FauqiJdBLI3oeWKJkEiNosWnIx7+W/brgpPMEOL8Sq4DWr9iyXvTsvLia0iv
lEKCT4g3BRMkQtdzS72bKbJYO/sA3n1ftzo3gWFNpUCKFKijQhPni0G+V/hj
o9e7Ww58H4IsPidiTcH7D7gujc3npqpMe7gnyQYmMa51gH0jSadhB3XKiqYL
AQKsilz/pgjZsEP0HwsJk2ZzJyi8ClDqsSim3Mf0l3WxbyUsZwuLjXJwY6zd
RsUewEEHRYbdiKUDuDov9jDrt0W8G338wPy43eib+KjxAZPt7kynshZVce+9
nl78rrwhfYz56dtoSNWS75Ra6qYsrr2NpyFWQvDRSY+XoOFFHSN93vOrZJk5
T36+4lDCkiNuo9eexsCSr+YWH28wbprAKwE8bHFhB3dJ8vAhAXU3WrIhRrsV
bJAnoUaQWMuGlq0ZPrDEUjQkCJ9YPwpsj5YhMVYVcyFLLTpv5xa2vxKcd7sf
tCpmBRsYKbB9xBrKgjWkZlAASSqa1TsD7h0Sddf8zsxZL8ADLElLFvuA7cZO
84ql2w44BvkNS8Yili7OogFjqc1I5XcsMj/L5G7UzS8/wfgUWzuMHVrb6epo
sOpMOc4NASKFB/+WzEMDDxkYP8HdyxbLQZbdDb5cAMrhhZJmZhNH7eGwDIOz
9Y1YJjoT/LC+/gTYG/uvXe2hbL1qEv4uVmONoADExx25cUkR5CcPKpqbZN5c
eqSt6Ix36udlH4AM0vXv+bSh2soyfOoiAGfFN0fmopgKJ5lpTBL58aZqPwJS
TwM4cF4KyIQ4mgWtYJbUDLiQDZtN+w2723Gjdnzvx8e1IyDiVtY9KhQ6XZxt
va7VcZSolljN7KVOwpAlF8d5u02xkExnBU/wp05cYUCG5VOJ/csgn3w50zwj
oDmpjyqGhMHaZhmHfQ5bUj13Id5Og7wz1Z2MzrkWsnsSOIjA+/gWGaBCgoYj
/Hr+hY2RJ9geFgrRwuk+x4FWrJUMV4CES670GRmxwBHZ0Oz9PBNhMKdTTHqB
GCYzszPkfkoS8K0oJANolFJ2YIGOLt7nOJin+CedjRjFSRflLKxbLima+MX+
RTpPX1TEioNf9CKzbYavQWCSzioHw47EIpFVV/W/YIWs+oNBEtXuUGbuelFz
yMcTEYHunbt59jL44O24Ez5mmBpqISRoNdfAxhJ8xSI/7CraYitNoxtoiXt1
fBDZpWRPTG8EV70XIpAyz38cCkFdyR2BpHcER7aZm4M3TESsTiPyJpQKpU60
x0yezRQ1KXavxOUcUJ1fsCh9qponLBBziXn7hORg3qyjSIdVG00P+Omy7rzh
Msr8sOdIP6z1umk4XqcvwaqW2bTyincBI+7Lnb8RXPnAe18+oIBu0xIR0D1R
bhCBU7kAaRfrHacOsqWTLIcHscJTDieuS2xEAeu8WhwAnODocQw9CahUnZqp
McxHoNt/rmvJyuGtF39kR/GOZYpuo29ef/izKO5nCaqbIdf5j2+f0oXKQWHy
5N75QCuLzjvTgqJiH72XeDcKV/lB/Lubptiv22f5aUzgJQFbKeJCIP/QAnoL
lShANi3e9x9KVAeJxAUtkZgwqCEIOM0lNoBOh0Ik49vOxqHgZBG8oWv0U0U/
yaa2Nm5+YWhJK+A2AJ6Dr2WFQPzJ0guwPE2ThERvtaNjKStJ4+Z/A12Sbjpu
qaJainKDQjm2+5mEGQ0uIHhoqWVcVmw58msZjbUrNvUNG15+0IDPiimHcH6y
U2b94eAxvBPL7Ita9EFqqrwWU8ih+hBDI5kTv19NLDOToLFfkPpualwNE7+S
yiOLVwPxzAu4jKB6fs5rmt/NkVc35blh8REgau4gRAL/4c/r5UGNTGyHhPPE
hnB/4OzFplpULNWAdLWp+XmqTqab1iU2/SyTcgC/krCW1QzNT91P3ohwnI2d
7ONFGVI28Uos+RtWAkDkCVZSt9NNZ8Zoja1CP/jy4qnx6dTL7kglRVhwErXB
nMVu7/3xY1nuBbRnYQITmEyuAXjaA6S5FamZlKGSRww3LzxhGEEKq9bQM9E0
mMPa4KOKrB+KgTWuaBOS+gY5U8OpZadAwbGx597elN2h2bVnoYI1BKAVXmLl
R34kk4qH7RbVPOTi417opWIk4Ky6mO98DtyNLN08v2ymHgEQIJdMcryA7XAY
3RwJQlgqWnZN/xYYe5H58cnzA3hCyg43DAOOtxbQJgEuLlaF5AMWnL7SXxmE
W4oAJKLGZXqC/NdJscOodXvXvCyaE4cny/u1IzNib16tHgQyam/g+GMc4lMk
oQ1Zos5VWQjeFQk/tflOC5+dgU8e0pdnFkaQ9df4Q9VKOdPcFoxXs5VQqMRX
/Net8pGdcZa8aiVYJPWQJZCPcHet0USc5Kb3lDPxgl87X/U/xI5k93NSEIFu
LRymwDu7/wgPEESdGqGzSVMpZMIM+OHsHjKYBZGg+Y+Q06Dlevftf/xw+e7b
l2MKDBdEh4zCRsKZeFIvmiOhrjhguy2X1VboVhD7k2m2wygPKQkZj4Jz6Q7Q
zGHRukrtUPPNETkk13e0M0AKMbfCDfM58SIOx+FqUgu5wVrGeJupPwPAEAii
qoPnCG9g+EWn8jiOanBOxZvGEYRPNPyX/s6A7aKvim7kRQaXDw+KWG66ekKq
Dc453A2NMHq/nl7Ie9+VS/c990SFHusr9Q06SlKtFQfNEhkkAf/WCgyvyoar
M+kay9mFy08Siq0rYCgEpcNC9b1i30G0Reu8Y4PjpVSEnHCuvoMfQeqMfBxn
2SPzh5fwZdl7iWcq+oyXRNO3VacvInp4UnkPO+wRR15Tz2VcT/74FX9bmWni
E9xrZmbpwkXlbUUAPacdV4AUR4E0ayguIKAQ2XMcOfLSAmKx7SVhSfeUy0xv
VNracrvvVFdydBwkLn32EhQ5JG45xsSHrEEhEKaAwoN9JZVRNhvJhDh34mGu
EagqEF0QGALt0jx/rp6S+UjPY4KYXXVa6MXHnJFiliM4DdWtiAyTq842ypkM
WGlrULRX7T5yXtgqm3yVQAOcnbzjTGIdYSXmPWPvC18o+62rroiIFQwP4QSF
D9HqaB0gU99MpCfJTOM/Fg0uy1NxHHUNy+V5zbleiQuUS2REJyp5vyBnkl9c
Ps0RkkhWi4UzmKaavT3PH5Jmns/nblncDyU6c+oifI8HP3Sn5cgvv5xrnCqE
s5Tl7nw8nnlaqZvuGUDO7CcMUM6/vhB/KikbDUWjEptkeZknv/JVzfmp+bv/
ONCiMn6JbJqiUQhs74cJhEd/e+yHU0v4Rf4qyTqWcSnuCZvmvbBpfurD0Phi
BRgIr6+O4bB79LCq2qNjTvkUgZx4GnaDhY9tjZMlh/BUT5yI8XQihBuai9oW
3dMTF9IwesG43c4QCc9/iCTeFrwQeOpMs7otU4jQd//PvPipao/tyRdBOKG1
9xJulVizjkFNMf+NgAi17zCaQRHqwUxDEFIDRSxFzMOzixWKz3RUL7TAJP+u
FoKb0WP7Zfo92+KXDLwA80rCxhB++JgO3zfVsmrkv8G1VHBxeFhhcVnpqis2
QsGCWCdWEVEr99DxxTq2uo/p7Zy6vwuvNVBni1iqFdeIV2Arcmn5Mb8ig+LX
r0gMLpNM2ukl/8/ZmR+Q/Oq9+9WT/I0jpclP3yQ/kvNpEfVycj++7n8zPKDH
iFMoyFpu0wn6m8f+Z40R6ZwdWdmLObnYgnSJmzUyc57xF+GrdTLz12++C+9o
SnK8HF5oVJjopT+CM0GCW4sSZqP8wM0/ugruIc+5LGZZ/ZS/OMPV1eq4RTWI
GWXwl4Am1Js+Fyh5VH4wcUdG+Me5bos+9cx+nqQc4oSezJl8pPfORKKZXdT9
ghaTzwBkOX/PiOwztjck3tWalAtWuzVkI5AjbHxuafr0j8u3n77EkOgfX9tv
pvf6TzYp1mqt3+OBVH4lCoGNIqcJR8Six7306h3JwrFvcQU8CvyOfoee9D79
TjoTukyutCo955Xrl6ifuhr1My1Sd09jete/5d88+ebz9mclMQurNuUU7f7L
f672X/N+CG9C2IAp28sZhy+V8UDIWRQcDM9uKZ+w8etj7jALxkN/nxeQ7A/j
VsF5eKGuz7PxFw3ec2mjPTD8GChKKRK+5LAE+Q351R25qc9AzoPcLNzRQF6i
ZCfzo0w2sKPFxQgBn8S5kLrBclvLOYdDaxAov5qcMtAsCszeU4D9mRnUWRRn
aoFzgtQ4hCS2OJXqeehaBWyoFBkARqJpu0pgkBf/MliJZLd+NKoZWoV7Izq6
RHgcb4bqj+ARyYp6+1VDwBXH56ob5SYxo35imr8jDx88Gy/vuZ7oXCt/c/4D
sOo4w6f027MzJGjgIbWJp/lUCW1+HUPGQ9kx+NXhvD0FAtnxSAT1q09Kh4Dk
qIvczmVlXj5sZR5rzCFZmZcPWJlfQVxy7/RRYyhrd7g+jzkcqSOY4XkIbO7E
MKR/BoJHDk5MkcHBtcdgyK29swCv5kLYC4iAvrFQwQuLZYh3rJECLhJmSjhT
enaOeBOu5Abonys5Us+Xyzwuq5RJYRUQ9A9aYUqjv/6LetPfVD8XDSkmdmgr
Dqf9vhPwlpKk+Dy6OMjNasE374z/QTLxRw468D/pspNJIUgAz39T1+w2zRmM
aTgmfgGCoPys21I0nEUnUD2aPz0biwI4fXIl2AaAejmeE0NGrh4Twbk/Y2Wu
nh/RArDpkTqFca911j7JgovaMrjxPDzEl+oLP83m+SBH7wt4YjmAoK/y/FvO
TRgYAakhfgqv074qJbIaKN9ZTFeOWyIA1w0o7wECGa6L1OFJ35dQEXhisTWT
TMh0ijPdXatALThCw0htgVQjbVEL2k05xhS2fYKXg+Ac4fdAfCvRAKvDQhyf
T3qEsdvzGArJLIAbaAF6zvVZTnaPvvWk53KehBdLwvwkvhYO7BN+wrHXhuf5
9+b5N021vImf8lPUiyhSJLmSZERbO9oFAXslOV9+xhL0fUpdFX5hoO8gl/J8
GsZ36WxZDiAogtAJ0PpC0MKaqeYLHLBw5b0F2kaZ24prAYtlYpvw/s6l/MK8
Fj0f6TorpHPt9N2S34rVXXMwWCFVuC7Etn+lD3RxW/o2+cvvDrs4VQOy8eKc
5R94z5DGcdIi1i5r57ZaslOviyHbaU6bPKN0z+DUHN0nrPs+lcnTTLIFiiTY
pp/L/qVztU6oiCPcA/qJbOyKWYmqIS2xJCo2G13LLQCClqUCuVQbmUy3uRTd
0ZX17tsXb16//vb7l9++HLttfpAQbBVpnI/bqpo/ZC5FzFoBz72gz8lwO6YI
El/p0imveJCVSapVWZvn33335kM/PRfhLLgnuNLJsTW50tk4WsmxAS/PiZ9Q
HpW//uH9FQiYimUZABih5sGjNbKrGHoEunoHnAZbJVVAi4OPT2tQmawg1PNn
WjORJOkvd3pfRfcoXtWzQfTcMv9ajyF+GlTPrrO0vQQhru+U8qxUOp9tQJZo
+CUbv7V6PqnUrzlfMS5cL+iAgSLJo6SrMQaoRWC4QTR31gPCSW0XpzVkFnr3
90x8loGYlMtCRh20lwA/MS+XwFtCSBLT90pyCCSau3vfUZamRmpaCWvkKxZw
Cx+YhaA+t1TamZ5KNITPasPxC4nW4PkoLhdiu2/E5QNMu26sYCxLzJBoe0wE
QCeNEsGp40U16tZLkBVo0bfmprXRxFIJwCIYJuE6brPXz/+7cAZEIKiWguSo
WLxmTO5BcErWkGFXooKLV5SBMjKZGtzNl8oNJ7wUlrcP6g7gCGhpQcBi+/Vm
d9iatv8XOcChPYoUzTHAjYZhZPa9xFwfIADloQ1AzBCBPGi5epEguJL8sxM5
juuO+EQRlDYQN/zRyVZPtKBr3TBN59riBUonMWSEEqXIk/CzFi4XKPbAceVd
vVa1xwgALRzjL+u+3hrYxcR/SIPMSGwmb0Lhamvh72kjehgyjyXqg51w+DmL
R0mrAxdaT4dnWj1Z5ngQ1eGlgU6nJbIjaYnZREYie0hGAiHRXxn7n/s8ukt8
a9VWFiVADnqx1+RTDYfiVNyBoFbPlLuwQI3swMj43sfEjtsXSCTaJv2CLMsR
I2NU8IVDMoxeaMNvEEHj9VLZbpQTPxIFaTyQ0/qKvoRVHkQkwnXk9ovINsMK
mVmiQ6q6YHL0bL7EDYxCiY1hUqm91oCEScwUfhbnwmFISULadwCekwJDoZFK
08s9TS4sHKK6Yy1PUN9ZYH5BjwnRpZwJHnlu/4DSBL5/cxUsWS5oCBR8racB
HI2VFLhZb8kraDkDy/wQjRK47S0iqxHSTcnVE5UsQq19eI7K4of13bPckZ1h
7JFAJHRF0GgGWAJWqkqvqxvJ00kAGsELEddvhZj9UylnF0a0Qv92uc/Tu6IK
k1d55HtxmXq31nWa+GazEDH3KCzOjbRmK3axPUvD+snhuUwMbgGIX4P7KQpj
YQzICfU6+BlFlwhppCJCgvgwRFwwlnpM2NCwq96xnrOyVP91NEi/KstNuLAi
R4HeLTGWbuFxmvmpGFLnLbc2OrsnQP+TFMTdru+werelFsjykN9YX5U8f+y7
mvWMH+PTIetp0VlZiTLBVTeelwaPMjzgZVhe954ncyE3KJdVEXv/6MFSdJK5
o+KVHNppeDD4Jvmxl8JStRCC0QU3X0CZBcqdSMq8X+qdGSmKkaHOh/mh92Vk
R3cODV/sciLSXHBVk3b/HT45j5+c4xNJ0YHIln5t2om/b/8+C/AKnCwJahjD
akX2TTnANCVb/QKoSJ9JicguPBHb4OYh8Ulw8pTQpeGHEp4uAK5qe0kdXB/6
DXZiHtKX4HtygxhCNldOqFg4UIL8lHUhrxU62SGyZoke8SXpEDGerWxEelIT
Qrf1P9tOSXyt6AR3sMpHZ5YQXACzlhT6DL9P3ssu208d2Vh7poPnLQgPiMw0
hVVKd5C6NRIB2G4GZoNhXdgzuuC+auZq5Sd+Cx5fo9kTj1dRucGcE7JQGcO3
u+W+rvhyQVZs8bEUXNBM0mp6WaB3joCGgmWFn6+Lzep8eaCj/RPdkftC+x2Q
HUVP2AkAt3ds6Jwy50PVbhVigyAWA41INArh9L6MPnwgEmm1AWE0TgKWn6VH
UoE4yT4OHU7zO+3YNWEZ3o92OIF1b4WBqMlhWnJFjTuadI1WbmgxTTyU5dfG
SDuxa9l4sHinmBHgyqMRbMhKUdvkXDb9ptifaK6T2ySV9PP86l35E3CSYPq3
SgI/bw0wh11kfBWeomlI5sLeA5/PriGc7K70MdhQH6z5avcRyUg3otzGj+oV
j3qn55VEtAH2qh/SIbk8YdFX8hCawYlIuPAs0+Ijj2qt/4wUXlVaYInOm0Nl
8WRH7IFCnJcpUcF92Q2pGxoNceAT8wcHYPFeEpEjrdGpfZqNdK5z9mLPS5XS
iGIjXOM4g71kh11EPANt30fm6YkbaHsCQ7Lk3BX0QVoElUxJkedSFjf2CZfu
tGbmq09Si829iBHZ8QCSN4Ud+7xfPW62M203IM7LFrIzwIrlUvmikuCBYjml
y4fRVeFUgYVei23NXrBOQH07pV71a6jMnLAJhiCFqNe3Tb1iuqK+1Mine/l0
SnIMg55QQbe6VEKjcczKnGWuzlULoI2usBd4qwS5dx1YF0YS4grT7FUYjDNd
54PAbSg3cPOElGoJ4NL4N4KkpFVghlmPT+Qykyb00GFtvL5Lrja3uqzwfDLS
STKoYTWQoywSs5F9TyrS+puebVkXXauLpd+uGjuDiltYFHuRMwg1QmtFNzbi
TDYrxJ3b5EsjMXE2WSKuZgXTRB2aSOeFlgZuCBkQtrJvUl+gK+6ku7cOcwuy
pQv8/t/f/PDdy1ylVbmZrQLdHeTMZ1XvR6mRlibXnE75cgSQNgKKfCiUDaVx
0kkP5QUjQ7XgrYuYzpSxTomYxb/o7vZlr7TpN8Ar/mKk4udiFEkruSkp3iW2
x0oilNoHLSxWSIbSeGPxi9MOFrHRgLzjxEqFXT2WYepIqTae/moQZbb4DBAl
4+jlOG2qiOwLo+2MiDHHmY/ZBlfDFanbYi0azeeN6O34QPoUwiYHtQxalA8Q
x2BDnTrnnXo3SuQf+SzI9iwbNXm/4LKCwwYx4HYdp302m5Qp9ueZv6gii/Ms
Cc33XdbJMP0qASwLVVjRqwFc0eUm3ULgmCg12aUGBMl2vCnDrX0xv8B2Pp5f
zISHA4vExRBzjdS4GrdrrccPNM8hpKJ0h1pKsTooyba6X9eBPz0zCEHdMbt3
7/dJGOC6dE9wGnwqE6FNkhPZo0vjZOqZJ+IHZCc+dXBTdsG7CFV9V+YT8w/R
EOYkBPQHG6Ih3hiwJUEU8wOR2uzUchK+Qe7Z+HEOzOEzcf7U8ANs34ouwKEU
W4mwqUAHKpsQF9gfFsdtYyCXFZnE3tOY7n8clBrDSqkkLKnt6pXMZCAGHomB
K/O6BCm/rjxHmTUnyS0AyLxmLhzzRjmANlZQN4jTvWXrhF0DRiLxmjyqe8EU
C8NxyKgXKjoa7MGPwM/FWkt7qqrvQMehutYeTNJzkHy8fQSPTLhwAmokGWhD
t8X22cO6R76xpNGqqBrQNTEL4aUkxLp176F4lq9gZIotZBXY5Zx5qkaxCS2T
DYaCqtXO3OKbfhMC0W1+Iq8/eZa/eH95Fagy2/zxBf2O+3EpeoV8atIjtCnJ
uB4K+/VQbImESzGPwhNWiky5rpd3z45GWV8bVLynEgQSddghMOLPkAStvw33
9wjOwtg/Lt9arIcecBPb72orprbcXjMd4nQQ3GdlA8HkUOmPMUOGoiE2U8kv
ObRRLQ4OfN8leXxx8U/3/ki7QyYl4kV6MZsDUWygdoVZeiHjOlbM47OYw2Ie
7R/DmV+ubW562RGolcGqhRCgMweODX3q1h14nBPro75nr3ybYxb+osw0xnCX
XFsh5f3wHZNL2PUvRSxK0W5SwqrMnn18hzpxYW8yBSs8sFYq2aqpWilxpDYS
fK1iGZ7JZ/9OweYyJVfJ5+TIMiDpxdQbWZ2e0nh9Le+/vsbvjC/uvzEmlTE8
tUSxCR7Y1OFSMkE9tXtmlRYhA84ytFCOI2WlcyyfvCD71qbkG3m5hN2t1J6H
X7x6Z0ElLvKXhMULlwCM1Zt4yqkyPYS79oo29JnEGiW9NtLcRA6OcPtE8/3B
gcwPSBjiHg3ROyawltaAooChWhCL1cyRUwITaSxZ3WuhvAP7w6dKMoJc5P+A
cQVOMImQ/DPdguX+n5nVRMb073QpoVPBrQE3NzHU+8yYhvInrRCu19KJBTcM
TfiLCyNDvO8yiMnco/iwMnzNI8UKqYsJ57/XCFCJlSPeJt4k8Ri6hjA9nKnq
+12MFK5KbRR02QtYOpIUxo3noUvt2MBd4zAXRYGrYtLdC/fqAQo8JZNrEvoQ
3vVWRrl5eki9LFK3iD/KPZ2F/mepdDit2elxqBbgGQMJcWhnrYzRSTj3YNS6
skKk5Y6vD4eoNRcR+k1uSLbb7PgeYtt0n4yz5Josb+5TrYTpYFgmhcwtD9q1
sFpwyE6wp9pcu8fFP8vof4PK4obzm14ckSvQJVpakV38XjgltXJGcA89JCMN
wOLx+SmfMtfPVaI0Byv4S+6N4YqB1EPaqRniDF0+FNkb9gFl18Ll1otPs37K
eAT0RTJFkZaPXSt9RA52UsAYTsnqFIYJLYAcvIAVGIiOQb7BCJEm4So8fjlF
HcYj9NO0Y2isD0iYDTiwNVMkGTKcHLnUZY2EiBvzjavCOUcwxbte30I3yw+7
LdoYG9ciPkeOe3QTDWGCu/W6mqLn6C2AdityaEOk7UpDcNOrYPyP3D33qma5
80bVsV6HEykJSY8HAqg0GZD1zdnZ9JLEdEXPIP2NM17K3PeQlJfN3OW8Lnt5
ABYlBfR6Q+LUrpGzBK56dTSYLpq1utmxW64Sgm6ldyP5qyxRl6uCbOSKcXAk
ALOM2zntO5Fn6+w8OiVTrZrHiDFWbZM6fO9TTCKC5X55kCtpWRegYMBV8Fk6
LQwHfH7Yy3KcZRaEvb7zHscw0xWw2J/J16A2ofYu9V+Ra9kKXgTgCFXUd598
z0Srv/CYvXy6GHJMk75nyeo4qmlsXROmff6eu0Zveko1tugEpfuIjnXovf/m
dZgQ8aV0vdKjW0WC5jEgxJyM+Ww/gopIyyNdgSJiUA5yrNkIK912BaFcD9q4
/1x95uaKGf9CKG9BkO5QVQzriUgqwI6h8baknQ+c+D0Xap6lxKcmFfbJLwop
5i6kqMCZQVgx/yVhxV8SHpwIDeJZR8KDJ/ddMUKjOnrFROLFcXK9Hl4izdeG
5KvXcL/ZpZEcgOOXRpfMxV0aoor62l6TpKwbQtJoLG8mPaI9aZ8ZzbgCOCJv
v58i3UPdxG9YNOSKvIOhhXrt0QKi9TiHsMu63qR1HQL/06CNkb1qLo+hO0BD
sfcRy9BNVp5KLMF3DYEIYgVeVdHJn/BAnwPmTydxYyoflnW/b8GI+9hjbAzZ
TqsEmsdiaGxoOoxYKomYirBU81SmB+4YIcF5dr4pdzfdOngZ/BJlq7NrXpqj
utU5c6PqVFHBnnDP8+9x7GkovFspOG+msToHzGmN/MBHlj37mnjFdrVIlwiO
K/jvOMZUa58am7OkdLmcTw0wa/WN/TQstJ6wQUe+gIB/NUwDaOQQZAh+XCV9
g3hCg5svr2KckQMTfBiyRBv3iA9xgTl+adbF/J/n8p9nI+1uxsNd6vvZ4ESF
7dEjHgvHK5sNBSQuWzgfQRjfH7YPOhdJtUULdOSkgf+LT42XMmlXjy6pQoKg
hVTd8ASQfLmmvwXwo+xn7+UwVNo/XMy1gJ8JjTrMtdXoz2B90BWauwW5yObk
WZ1l4bIZjhODc9H94FQOuodAY5JNe/X+6uLiT7ma6jBb8Jdz/cuAnki4uF1P
mcxzIowMadC3xNWgQWUM10P2Twid71+R7NS3OmPBPeOoMklXyydeEEPa2oq2
KdCEiCXtirSxIO/sEvoBHNLfsOHFy2J/P8ffz/F3WRzILcspx7F2Zn2HkzCZ
tho/B303dyDrzyfEnIvqduxI8UkBcbc2YcEK0tU2fmu4lJmXwWK8cVtyUzB6
+86Kevt3xOB+6B2/aoUnMFO4BK8RDGYH1T1WFXvYk+8gEt84Xm9TVYaWTiaN
a0ilnbvNRQIR1CXxe4KpFid163gtZxm95dRTJuK9Y+2v1K/sM2N6UfgWrZE/
QxgSpahdALm7zRYqfyoS/puKDB8KuYSS+g6z5+udsQEdGGX/PiGXRPgS1l1+
aDlSGpl9sr8GANvzp1IJ8SJhjOczZ185f/5/PYUjdZ5+R0Fp4UnfPJ2415KH
fUMPc187d1ydAe2oveMhQGHoU7zDuSIBSISz49dwcgK65FVe6hW8KlaBZkEt
HzbPwobzQwZyJZ5PzOPCMxxo5cwFL/XVxtfFw5LkK/oAGY+/0F3xh5+nIr38
f6iW3Xog+CKTh5CDjgdBBG0BGFVmZZmMY+lXY7YDrv5BcnhlZeGy8A8yEbDq
hkEvRjohwJ3ENtmtH/oB9Ps/XHlsMfcAIAWIziSiv9bAZRYLxsehj7hri94P
FMad8lZPhsmg7r7nJgmoipMg1kKLi2O6dEDDFg/Pr8E0o9Lgcovi3W1EbQw+
1BZr+3oPrbVY10ykphT/IyFP+gJvm+9Opj2frJPlLYvNVPYIzOJV5GspugHm
9k5JOyBfURBDy8QedUGrnbvjN9HoJcw4TvZML0WuDFCJ2tX9K2ikB+nplWSi
20FQDS1ayCpLNJcnE+bgJuftUW84P1OavHjLjkAzPOHBRFikV0XSqi8d3ehZ
NiC5sZIdtFSVfyalJ+dHLLbzESfhfGAunY/dmm9GwsjnqXpJzn0/Lv78v6OK
QyC0DExPg+oQxVHIsSpLm7blRFORDr3gk5C6/81kvDY2z/TyKFZO3Q5iPix0
1iBzW0lcXnXh9Z26bUKDy2KGMj3NZptX6qgbGUCebJ80LtFqOTHlcHHLpKsm
cPOpd5bVO69QokPo1WnPjBjJdZBoH6wNELeo1X6ImeE6xqg7AjVIjxhnfBf9
VkCk+8taqYq45DM09L5IQdzIPQSD10rEfC4FPTSgY9tYcI1DC1x/V/bjNTaB
qBX8dgUeUpShBVaf4y6RtKtN3xrWiVVGv2VVT2/0P56sIgrrWbSCJ4lRhDT3
f7UOvFj9/J483PoFJOrKRT6TYz1d7c0H/DB1iP9rT3j2KrH9rOAngECY6+MO
ObokxumKJrIChUbSQWU3bDwWFkyb0oSQzwDg/znVUaEVQWDjYpPQt43xIzlT
9QK+7skNFZYC7HkMXkvVUIG6/BibG8bHTvmStLjzXwef850Z/3j+RplSxAQ5
LjkMYlENZziG0LuZ55PdP5+hIhrLfeanlnaBvT2U/fYsu09X8S6+Ln6C9zTX
zECEcqwaaTxLIgXbJxEksJptuV5vlhUbUjrLO62Iktd9BqV7qOF4IKG7mhJj
piAXEC466TTbLoBZrDqHXzrOb5NbIgFdDazOHbmEmOY8jgwBNo0nhE46rhbd
VZ9LddY8YgsfSmn9Guhsa4jNsnjJ27X7qIjteUDHcXLJUPRrmrqmOjiZqWm3
D8+/H0vAjoG6QemsUmJwdzczzj1JvVmshjaiamt2+vKHq3MuaEYzm3ke+KaN
X4qjLDwPemzDNUdkGxf7VhG+inQKsJlrWl9Y9JHWprGSqFaDflsaL0uXwC9h
SPt0PapMzt/biKbIhy6PUAV/viPLlgHdG+alNgOb1/oluT7RVQf/pB3aRplP
wtHJDzs0iYP6oUX1uc/Izzj77atHIneGHtr2sKWVqX4Wi4GuvlRogrwIEuov
IO4NJe7QJY6Fo0Jyb0afcyvVND8/6kkZfgmB2UljxZiuuDACmR7pdycZ5zdW
hDHzrfD0pg7tBAPaPYTAkPgyJ0xKlV1XJjXL7ri4wTAmcuEgopU2SZZWnkz8
oX/R8pVXfXhbPyBIC8LBwJmS6yzYtgMbe89Yw8FgGK99p9VL4WO5qdbMJjCs
pV7U2qbnTqalyHZZdQ37yFkaRogAykWod+CFKT64lrIUo0mRrqkWj+9b+bNQ
77Wrq5abSgvwgGmIIwMCDmDXHLZz67DFyENxeHr0ScWnuloy+bCt+qY8kY3X
olE2fXgf8SAZlnEo0/RYsypQvJRpa61GbIcNIQgtzu2XARvdf+Scyahu66Y1
ykO1x3cSfXBLwsvEmVcOZrMEKv1K764TBtk06IBE5Tr0ejSAdZxnS7u/0Lbz
rXR0BpWmclhFRzG0AOMSvWpHp6tiUmfZlOu7zo6NNj7KUQqJh0soylKOSfhq
0FHZW0HWt15cC7vFJByB/GfoUabV6uqoTujGtG2W7wuVpX2hfBOvfg+v7FgA
Iv+3/OsL47Mci0aMfsEd7X/LL/5pLD4hH/hSj5SRQzjAQkv1vvjw+mcTc59Z
52v+PrbfeZ2yktWRpVOrXKbk7dDB3M+Mh5M9nc41Q8+EaQjKkQcSMx3DADNq
MqUZfXIKNTNHvj+QCW7u6HTIctLrFpZZKQNO5TksSYlYu+w+fi0HWr7hRzTI
yLxKi96LDdPdT3I/w74JyqJYZgvf9FCZvYrWdS+LBHJWRSVZVjkRb3bBayoi
mylis3Z0AACINLKZpmnTsnuuq/7GN37TjoM80U/cz8OyJJrVYEYcNbZaATsD
BZyk25g6yvQC9g5Pq437lb52NzPiVo/kQ+i9MWwI3wMl1ApfHYN7gK10vmp4
zwAOs/t2UyaX7QaF7TtFzDNtSmgNd/IznbRqh4jF3YnUCDGdHZ6RNlC/r632
jM4MxmqQFE4SWCGdNO8dGtqhO4N4Adwy4RZhBWbhB6RLjHd6TzRBb9jRjwA4
hSfakVYZkVJ0V5Hy8yzAaWjWQP9ZfqRe4UHfkWt62qCDJPtMDXuV0FU/OimI
XLALQ6BzvZWhBiuBSSIhgX4XKCTgtqU0RBYxL1F2xk+e5dW8BH0wzM+gJYUH
S67OqzWfha6dcJOSMAWL3UlDW/vkxPZbTHV/gwRN2aOwf/qrVf7jJ79Q53/F
Sl/hHaKav7ZKJmR2wlEyLaNXAKzuIB/oblzvs4gjMZC+VDDTg6RQyk6jO7qZ
FKK1DNylIXTmzfGIvP6l04BAsx9ryIprRjyOSPqkOtAVm6lZF++RYJFqmvDO
59yft+NYl+6WKzYcOO0I2IUm0SxHMGnwRThAILa9YBMlz2roxG8E7Scsu3rI
0jrBGCQydHWkdlfw4q3R6Li8rtIUD/44XtTAIh6E1yWN9QUJ7ZGZddc29NCp
tz8E9/gr0+mFA5EmRYA+rISD7Z5EU3ldt2FJVqNjRe9WmOZDXAdqVHdxmT2Z
1Ko/7jlHlvliR/Jal1YviWgLzISG0Ke11qBma3sw2eTJ/GiuVTjEEKuKsdZz
tbwWUubM/QraVpTgoFm9Vt3206ja0bhNxL2tFdbUagTchRIyIDg8ZqUPkumD
COdDqUXB6nBNof/kBp6UXfUMqsBrr9bIWNhjJG849jVDn0uOM+gOX9agd5XH
DUxss67YAY+/lq73SH/+FtCQs8yyEGNIpCSZwAaZv1ZYXHCfAY4U09KJqISU
hxs+qbxJiU6oskRgPMOjLegsg29vRz5Aot1b1NUrxF2TphUOY2+SH5ovyxYZ
ivoUzr1YOqwKnGqdZXothTTvYlE3imwZqvKzrAcv5NS7yYUY4TQcMWIOexgs
RhDqW5dbcm+oWADMVuuvnxsWxPa1kc3hYIXv+dt5zPx7Vy7W5eIjkwwJSxnt
17PxwNjT/FI7EVzXyE2A3VHCane8UFFWFbI+YedcuhhfyPhIlFBX/QjuzZ/A
8GPg6lOFStf66G/w1VBChFwT0raasLo39vi6XFZ0d0eTWWKX8AzYxsVBOQwD
lFyWiKNkJvQH3qfdqGNolQjFiHcHWKtQWMtiGb9p0MOKJSzayWMjoZgfUJ0J
FACybQ8An05nWXUQdAYW2uwivUhyVDXvhSAXhHiMP40l+IOYKc8RPOw5B8fQ
RiWQoEtMnnyKQ9O1aUBSETkuaNkP2AzpHYyknSNVHZ2HHYP2gi8UwOrBT7RX
9Z0i3zVFN0G4E6Eeha9/IT1KOrYThKNmtan2bYxkKrt0sl0+dg/A1LhZnOJA
k8U15D5vjxSIaVk1tGUA8UtI0F0AbWjUKQHQhSYF5X38VB6+mEMiJ6KXT3kb
rovFR1GsTO5zNp/QKi84G6cV1YqC3alFi4fjMVgftGWzRUyLxaR/6VqiSeFB
qQgKxApUZiO8mVYa58wJjVFxI61NBb62qftb56Z+T3KYXeg7ubrSWf5vEife
lV735adwcnD8z5yvxF6IOjTpFIfByd+NIoaPmTjeSFMTByHyEQsnK7a1ZVOG
WK8x9TvL9LbuEuvhmFWUyhUZRb8NXvazjCLGImCqYq24qXaTSlbuLVs6hZHy
Ce/pZTe9efYhhK1C0G8Ww91efCSn2/5/y+ZJZiuUEP/1Ns8lX/MypDX9fzAx
PLhdyv5GNwUdo5yRMWIS0GgghofWM45JCh88EE39UbjBWtGMHNHaLe7OJlKQ
MWVN1q+OnOzusTLgpG0NR4xhTbiuasnxCQyYWBKZ+TPTXHda/LiLbUsYfcod
BSo710caZL+HlCaM8hpaeYDtdqS4AenAvqWXtt0KVlvibA20hwJvp/oaxsB2
3Ptbi6qtRB8m2klwtPazgen4Cj5vU94A/Ov8c6sGUNiQb54xqqytEnd0HYH8
5fqd63K8cgpQULJ3VyMILgGltAIrlvVKi0bHxP2qOZRa4CfFXmz3kTIWptXN
XSrU248WHi7LrdB/6HG4aQp2HeTmPRnXFl5TnMxclFOCMyGTx4YWjprUhStd
/5SkYvsstk8L2jN6xFCAP1L0lHG+p/NBOnwXQyMmYptxAdyldwI6PaKHtc+j
3CO4AUUI9IAb6bzfy7NeTYqRUmC0Yp0jsO1eMUp8Fnp81CGpfr2pyRqrUvv0
t7d/k1vx/xfmb2rc/S9q/34P37VajrizbLG2IybrQNjHbNgJRrqhFTtRy5ui
JH+7IqmzDIkIml/RxdUZPX1TZs5kSHDYk7NXjSPsbXd7odAc4/iZ9WljOOyb
/ZJRaq7EASnlGpU6YSH1bz5JUQgzdWzROpv1Y70C0fo01tQwNXy08xtQhPH4
xaQlZxtNZGsRlI6Bxgt3XkS0tK0VgzwYmlLaDcgekw4mc0mggSlrpGeBZbGH
SDGCN2E4le2WgLQLB2QDcBSbCzFkOrkC92VlocScXWnvOEh4Y8qEfL5c9vtG
ecaQNn/eRRnA7reGSxyH6ZJs+CTDNDGJ+9bIEX1AoujeGpx5NmoL8Q6M25DN
KJnWLJvQFxiXFwJvECWncsDsHznf5ITEPnN8TyH03QiqrEemlmnDILFwgT50
qjhyS8WEzAjuUtFEeEaG6vJQuhLKet8NLdLwdCAaboX2j4laHNDQSvIumxGT
dpw3NXQ/pJkyEGDFTixAYcxaxI8E95A8zQpljrfmHK1WULNQw6L9ogXF7itT
87ANq6Rpwjj8ooPgQCuL4kn2coihTrAWjWHdVtztNOalulB7FSr16Mxyu4vW
gIPV6HpL6T6QkMMywOajOPDaDi70cwpPSjz7zlHXTJzq5+GeGd196QpT9tkC
ZfHFK5J6Bpf81/D0A3xDwd+pszdeqRgavLi1QEqJnKz9ptDG6sGo2bOr0lRo
wsigf7WbJhDScTgMO19UJGLr+nYCl8zg9fuby9I6cQ3qOWeF5vl3DBjna0aS
lAH2ySB7C+xN7MvuroMjU25aFvwbcgD5P8fPKDmBAccugtfUqMcaq3pNjRHW
Jb5KY5Jw39VgTt4Ayeeia0EM6XsW1df/ybV0WptNNn8/DZ6Q7RXTyXBfB9Rr
tDRon50OTFPl4bYODh3KX7iSg5XsMLEfK2E4hCVMkYK4OFoGdD84S45Mo52W
QvnEumi2A5l7nPQRqFqBE3JuarTgayJTN9ytU5jrtCN7cKyqwtlLHZbF98bL
gqwX+YANNzSI+pymzZje27rtmKpqSefq7aVj8+LmUtt6yUeAbaQHlqV8r4Tw
5XLQJSBZz/cpOA6IssLSVZzrGrtMjhhMg7Ktcc9mSI00ajwZPbDsSbrURuce
OmxNOh8jB9UOXCX4k4kSxofWJyLzaCyzUSbRhGooIoF/7r9q06YfHJWtBNmt
nRPAmVy+4xh31DHmRjKrTXEzcexIJOKqPedYFUeSD005mo+m9UJvJ2NxJOPx
pTe4AFdESwHtaAeOxhbp+/vYgbm6xcBQwEI9jXTrrhZG2dmrT5VWZWlTGbDI
aRCFizo6xuO1emk4CUcEkCWurVcdersVbtbSTKq9a7sSmGvRI2I/LMu2utlF
rm08ykFGAxm1/LrtmoM8EwEaa+stfT7fF1ilk7j2L/H0E98x1lMsGL0qfv0j
+ZMfax2Qqfypoisx7pKwE5k/LbgD7fcF+AMnj4/VPivLw7HGIfEZybKql6VX
PRumoP/TpYr79zRzKmPWO5mzsdaMvJXJq6SmRwvb+MuyiVI063pSqrzAXFML
kZ2qwEUpTZXkEiJD+TxSFfYaYHK0zXqxYYK8GoedmXQWc48vhXUemUA35Yor
CEJrsB5vHKzdKXtRHYs2P/HFy/TYNgzvxAAoqXvYU3okcfzy1qts1uALu2hD
mbKjjrQaUTmk4A9Jvtkr8lcrR7pv+Uq8kduj/+NZBk1H1jRi+cIGFP0k+zvL
6abY3Rxo/FZ0H/jzhzddHCqsrdAFui+X2tSdd0J9W+EhMPJZWBWRfRb/eeY8
XU1ftnDK5Tfh29qQTa6nNj4zVlXLQ62gesrIvEo1nbbxbHtbwqV+UnhcCdVC
9TNL3GVEvMzU8rPuBPG+pDUh63jQtVO3JiDd7cIPpe5ps0tru3daVjiM/TJ4
qf2G7pYjmB4+Ez4pgQ4Li7bD28M+P037ZQc+aPr1WfDoJKTBNrzx6Q262vZU
YMgVZWzY+lyRlNDwYu87ZdgIxuekTsaKjQVSq1pjCyLJMckmvGDBz+dU2joQ
7bGrv6y3ieYYbfF3MZfyhDuJKUqfca1GOMtuUBEj1H2HmxvjQT41ik0/7TN3
9WXmPjKrAa+5uS3aWmvABzNSihdINruEByBzFyxUtU5VSv9bRSIg2MT6p4hq
bopo6JrugrUFLnocyIoEl+0h+d0xYlj6jyvaCyvWBCnMA0sDiwU6cok474tu
TSebTuPSElQOqUv6iXtkl2M85ZoxZoTYqmiyoBtDG0AtS/AtJ7SW17R3mh3+
4Jt9iuQXaEk0G8HCsdFuPVGYECLSLmU+eZwMJtyZ6Tx2XaytXQ54D7lUzTSA
ntjbegBkRNO3YlnK07z8AbJr5d66ZmhOwTMo6dIK+iht0sWTElwGxyhUbGgR
7/KQgF9W7TnLKscJ1LURuyEoBxPCAa3LcW/ql94yk4QjmaQFyuXGyIdIojyz
dnCk+u1FZll9za19+9h+f/e46AKULSoTpSVUvK1GnMWJC6rPwud+yXUGvDG6
rogTkV+xsESzm1Ib20730zu32n9MitLKfnyAWa/l2mL3DOc+pKzIX5r3t+v3
bQhacYpia/X8g7Yz/OtsKUmEAycvfQ6q2NxwTGW9NYZkjDqkflETseRLsk+U
Wwzt8ACRj4bPKImc41CzxFkNSnBcDL3bvvcOo5jUFIFgv5BXS+qG3rmsrfqk
Zm6p8ThibalhcM8xyK2YgaOrOzFZaV0ysyeie+nseJwY258xsvK8hiWmOfKc
1VJQiD6WG0txRFWiVZDgN7Zo7pP1m9H1aqK/nuff2BVjLPvSmTm11tx6BEss
uCGz1Bg57Xkl4KML9vNZZqA0UISpZk6YZ4LZNr5M83RAYy0LUePJuvW2LD7K
bTfGC9YG5JN085VFRQ+evVCJDDNISu2EW4+fXk6yzqQdifKAcIlgHbsCyGy9
p1dey1knOOG6iSd5wopvG+8L63XIU8UGfKzoxquM77sp3ciK/ISx+if56fqw
RWg3f3F5Jjr/RMArJ/zHE7hvJ2nsLNoerZPLebJr2tnXNuq6tFtkK/Y6jEhk
9cRZuzcKGmt0d3fcz1RC/0X7cbQLiRsJuw7GQpLY9QJ66Tv9hui3ckeLHXHx
hAS4GJdy3tXnwKeIUekaQvXvWCg8WqFNsUiRJ8KkjomOHtzHuWelnQyYpdZs
/kIr0Ok65iwJHRqyZOTsu1Yy0rg8plRjw7NNfaMkx8uSzibu85FFUhXQCNmn
iya0NIzWLHrnlwyv/N5ShWiKhVuEn8yK61WGQn19WuCt0SPRHG0yoH7hnyr6
vnOEvndqloZrcEiaHxcqzd1AqReKeiWRyYp2cGb68SMojHiTxRZNw/x22yMd
G5ZwYh+skeOwP/ZguXsWGXhRes2cisDJtOxzyfFqiQgJMMPTTZxyn7yUguIs
ixsXhT1SJNjKW1CGsV7k+nCZFSJe43E8tgPI0dVTJekhBTkjmN6JBb+T2Odk
1tVo8L1qBQOU/Pf5n8Em30OU8A7RhvGup2ih5ypHUYgshzsys1M2hCSolaYn
6tXZVPCSA9BFde+B6PMO/s5DCF7oudJQWNrEZUW+b4sYhQ+3LJKfzPo0ndu6
qz7p42hl2ZjXLLvrmlCSc7qsScOMansO6DOx1JLWaJD1Oh6h9yF6LrKbiE9W
Wve7ZHHQAHryDTwgLchPDVIFcAr3z7rYg90lMrXh99s7R+ADHEIsGy66h8XJ
j3fDdr/6UeC5rZpMQ0NfvJkS1dmfyk29F1uRE2jL8lw5ZBgXUHDsrMjf3tEm
7XL0ZWIeCPs1TFRGsC7La47G0L8OSoOuK1op5+j+YKBJ+uzt3dtLH6STF0pR
u0SoMqn1McDOmXQxDA9RAB7/lkcsxuca/rOmQexJZ+ihWH6qN59glHNkRFyp
19aaQsHMIcdvs8QrMR38as9IHQNf3dGCqpsnrEgYBr/q0Ir7KS2Mt3vauUA9
YsUDfqZq1+L3tDSnCG0ZvppOvNs+G5hEp7mgotlyZ6XMmQ9WwH4qXQIEuqj1
LxNEj+3ZLNuUBdaHWar3hTrjJBvVNCjvZXDwGKDDzy9/AoZgA/I9D0+neV38
ceTobj9+oXB4iVhqDASgD52sJMs8k50hg8LX8To5Gx+kqDR/9bKqz1+8v7w6
d2c2iBODHJ6G9iNs1irqpOqOHbEhHoEWmk8FPX8nvdN6nUgF0p26Kra1pCy6
urkbZGn7bezeS5RT7q0tlxqDDq9cnoPpndZc6kFD5o29/EaMjhnezRw014IP
p1WWZsFmriMNsx05CXjUQPRmuY8lxg2b58+lXzPseIcoEgtYNUkMX7ElbSTP
QmwjLBLxhTgPYTyVKOFXL+dVLTcnTrQdTd5HOZGKSbH4cqqnyetlbk1h+8NQ
/qGN9Bx6FpbWisly5KaqQUpVCrjEDQjqXhbc8D75Zfd7WruPrlXuNd1raf+n
y2+vXo2lP9WPieZzEPQNxKwNchbKlvS25+KFDf2/Mbk5/m8IeHKFTCFbSHhF
IumFjv87bIisrPQARWefwZUyyIaxTmGgC9tDSF5EzbI6iNWyZSnQYKkdyEUt
OKJ97dC9IQFiqLXBCAYDmKjv/1hyGQKgAAvGw4hXovL9KEznUfq0R/2cZtsO
CnvcodXK16LaRrpMRx4FfLdgwgvlOZXOh3Y+Ag2lkojrARLNqPRQ8lguTttw
Kp/XVgwRMXhyYZC9FWGyjJqjlqoC9oiu/50wKBkDjYaByPbmZ+k7WtMa7nR8
e/W+YoKqOTNUwV3Y71afGHf+ce5XoQoetEI9I6zgRCQLNmvJGEQk+lEWIUWb
MThZN4qdUFiEurExXwKdF/kpse60cbzm6PfqQoyhxIOuhVzppW0xpRlip0nj
gbmIEA/Qj7jEP5VWFsOzBWhgRa6Ooco4uZBuWxleVHFsDBl1KAmlc2Sopl3I
/sw0nVBX7je162dc7Xb1p1A8wvInaoAjIeLKG0+8V1SB7mFqtfVLWoBEX4LJ
IWFFZ7NjZmiZrZ7RLDbo0JCB77YaJxykalIlmSLkpAtLRwk/GvWa88htxMsJ
ZYi6Jbp7l5yp/DnQLMj60051UhlS9ylbw5MQpguP62olHVxtyp8sAwvO6GG7
Bd0CcZhVqSEmL6eXRzDX5LelEK0ppjPOW92M1PmAWb4tdjursKbjBHlaFRV7
EdfFRuomGUSviwMaTou6B1A/uQPRzVbxvba+sKIRNbwlAH6jleVP423kE2gS
P9gxgirJq0XLT9PDvDVSJT4DkzqY5YUrnPHPagPDdB4Ce7hxhWcznGf/bpWG
kRtAi8kzWUJfZKhfNDLT+F1d7qTYCqirfbFzXKQ+p9jhmm3TimiL4oQPk9K3
CDLGDslD0R9uq40ROq4V2oAN0eAvRqCLZ8vWINliTTRLrVG1TlThIeuCrCJe
zx/UDYERknBB9lEDZCt+1ICkpTjDTKyxPTJCdz4yvw2FkuaIhQZlraowMldZ
F0oJnD0JahiKp5XXWHyUt4IJbDlaggnDEYpNjH1h+tg2JHQCnmczynwwxEP/
INL+M+u3FBwW501x6mqegDa1Q2wpVxZoxWKTTeSzQnMv/Jc1PfAVm5nL+45U
PY/K0UDIvARWbco3UYBy59w1clCrX6PtLvmGhN+u5rVH0k1pkOtmqWsdREur
oicgsuBhE3t0Vx8pvbbiMjcEAx3QoVaGM3NsDRuXNs5SLGr28hBay6+Khebk
pqI8AWTjO+dlEQCZPFsqJP/qC8QiyEl7tpm1dOZbzDImqNysRNK41wsfAI0+
BudToDphlvybLEySF/3QOsBACPsK4Y5Z9f31s3XFnXW0wFDY10eSsllM2UIq
kk2jG2WEW8QfjY8lQ6+gb4qW3RbOGfC6purnFAoHWqSvZXqFzGRLVcvlpjyb
8b205rIHGGa0aOxdGTWRA0+0yVmNrol0EgvqNqJCGDpJ61C3sr59gIjubTgC
dkq1NGUsB9nuyVDIyMZU9CHSkTVHhoN2juiAFbijZFc5oRKk0YCWrVwaoSb9
CtpcAgIpZqRT9HaP9yrzRfd1wubg6TxDd1ifh9P7Pztd+qq+NIgkhZHt2dG2
ssmaC0ULSmS5eJadFsuuGlWX+ipYXljmKw7q+obCwIvKLaMYwJQvwNXW7xTB
k1II7KR3bcICJt1ZQqtWUwm9Am0RawaMVxKhzIMNFEqqvzPRn6Djwefn9WqU
igdAhgr9PT5V0vy8ksC75ibT9s5JvZokZO7pUqCtpALlbExWsxBlMq/Cgobp
uiNN3lcpPk6QOb5XrbuPWZHNnWmS0MSWV13m5eTZzpk7y9ZLBhd5z6BpbRck
wt4r3Yg/WxeuuEpYEYIxasMGjmKkV3GbqxwFW7KWf995nRMK+XZFBCgC+RE6
ibMLEQJuyqogU4dTvlOMROwxoP2/tIfICL1Fn47Y2CNlIxGelkeMJtlQ3gE3
WI28aB2PNbOlazfcEprQYLeJT2EP9hOvD9h0o/IkHdF3LtiV6mfh1eLVG4rV
gE4kMldoSwikUhNDqcdtod8TRmvVGCF0F5udlNZ3RHxFNlJmcRw9/WAEiOjd
KLCmvu4KmJA6iq32QUtRWzFbaJsC/SzpvYVkXtiWzOR86yU0ZH7vCz2Hph21
b3ieBH9qxwOZXFPCKcs1O/su7JyjgOmxw7izfhk4+1n5j8phYBGCq1SpRpOk
MtZZZ+KpraOorsnpT70+C2JKK1UoTZA1OPLtwqzmrH9DgQl7l0Q/ZRBDEtsJ
OeSlQdMGFE13eiSHPDbWJxA7A0lcRrM2fuTMGhzvwEllgJRYZ4zb1LHptAyv
DaVdoTA58N4Y6Y4+geysfQkLNa1Rfpa9rKWTBK+sOAGazvJzvy3MbC02Iz+R
ZFnqj7ehWZ5vm+BX6ln2ng4BM3CVJp4GpJTIXbr+RRcId1KvKOVVcTZym3J2
iBZmK7nqDhZNRoTCvSVFovB8Y/HPYIJJn4g2K5pyCGNhh5KhWVqwyTw+Jecc
BW0b+nb2T6RZ/qExJ5dL6Dlip5rLZnDbd+vP7mJP88nSnzkeieRn+Hvo7Pzd
iGKsLC4gd67GY/WqHl4NGXbRjKzEaI+LWndhTQWYAlInttu3IF1j2Ys1RSYt
nqLqOD8Vwi/JKTnGS3WaEFPxsdUOG6Nl/ZahBZCkz57de1c2GFuMu0xRVSLQ
gSs9oV405kbPdRUrThLKQkfyKBhAXmL/S46zb7ScTcpBHkR7SRL7QdGgiUGj
Mjo1oQIsAUFnH30FamzgO4E04SweTYHwp1wjhSX6yfQn+74+tJs7s+RG4mFm
bvaikh80qiPNPzWbNwiA5OjUaUGDZBx5GIclZqzMl4nIncsUHD653Py5iQBs
aY2nrTJdTMu0xhXIBJgYjn2vu/rQoDiEgVr4DyuGkirArm7OlCvR6pi4vCEH
bxidLP4T2gztDdiBxHoKbhSLIG3bzOcDHWhiNxjAEs1ETgk02mJrZhdufqAl
Cy5uLzcKXIR9l1qZp9b/qgtUby35rEiMKd11ds3eujE6afNiWO6iSZGNTB0r
DvuNWTKhxzEDyDTKp6hqLQ1GGxwmMJJuvK4nTuxoTFsx1iRN6g7Uz3wpxTz0
XdbF3Iyx2nH3Q1I776Vrzme04jn2VhDhjIQLQpLESrwgn1gaXmdPKYo8CdSz
WNc8IjZEUewiq03PLJo4OF6gsndTs3QvtcwqEftVxQQWyP8puBvCmhWjAYtQ
gVNJK56w74vCiofCn3iAmMd1qUkcfQY6vSGeCmMo6aVy2eH5PhCH+nopnwvh
7OwUBr2Fi0a+Ym1nztzBtshk9MpidJL/do6/nWWjUVjnKEovOTVNj1xs8+x/
DEjZRXE4hhsMLV6x/RFmEgHrapcLmhxZAJbuNwXp2H7YAkrfFYRJABkAzB7V
9MX8Kwun4CqUmJq05lDYFkL4aI0u1OaW3tBj4mL8aIaqXk3SoF40/0joTEIT
Xehf2AvOzZJgJZ0w0a88vG4dytlDy3AcjF4+JHS5cZ4pMkVCXMoPXYvtEGsa
VGitIR73LBg2fi80peEnGjIb9sdzNIXTy0iyGoVRCzMELcZRzkzgb6GJu6Ql
n9Ilce8Etlz3sProSVoyaHawFGAZhnqCn195prVKMRQxBmRslHKLCw5ajdT9
YGG/rcZo4gGK3i2pepixY3Vm7aJTH99+M+vFuGKCNrstqpjiY10u7MWSC7Qm
ut0E0tNyAlafunXLHoy6ELWJtZw04kNgUjRbIPxUorjpO0ca6cZo0DLp6aoX
EgQxU232LS4B3nnb1ajVwmdB9M40yw0akyuRLXecQronHoYAS7hD5ba4UKkg
zrNXY/2ktP8bUxCw+SF2u3wq4hzPePI4zssFtXeKeGFoPXsWIj8TIyHrIXSw
TCyNAOXZddWi2hdcTxl9HGZVaQEd0TSj65ZBR9ImAj01jHOeBRN0ZClk0yDC
e+OlWiXPtw6Ad7AQ1C0wfSNtHa0HJCPiJ8k8+NeSN5c2WMwIN5p3yJSIVlSk
BjcYCpy017P0j6W+XP8QL9DHrhzhuvS3C02dbhdtr7Q0AgvfsNa8waGmUn+f
prFcBkvXLD/elf7ouMfxFJurBcEEWiMYFzaJcVuJKo8Zz9TV7hGkWobJs5H4
xTJjMsYf28kwKNIkvKg8GyvYBKlIjEontuyvypkgdV3Q7di1azK7ZjG+jHpW
J6JZymZdjFwMI742zL74y35LAvEtD9akfMqJZYeJjWWYeQJA7a0ak0xquEeC
QxPpCA4sj+EbL9WeE+yf8eI6VDIDWenkGqYkZrtAPymkWeQUpNjGYwdjWJ5/
QCMdHLSDnE1X46mgO88vMDQig5+HOY+RTqVoyx9aK4J8/PhP+cfyjuELIOd3
kI+y1HMXIckCUeZmT01ZAwFyaeFFJs/tnEW007Ms2b/rktZXwbZIvzGYMyDr
+FWC8Sy062GlLHlQCbI+rIuk6qcITypzLcpLU2ozUamKTsHCmi3bK6FVIqVO
O6PL725rBoCj5TOPb6O1fLCJbaRbWoUINFfWKIDNqymmtqHsBWa6/C9lqdgC
qX8QmWmBTAj4bq0cuu5T5D+nIzEbkx29m9LyClfmFK/IlIRByaVQu0vX47lc
jwrLuF+6rpId7pFfkZ5sy+EK3rt63PrXMXdPL+aMY97wta9LaRtddZtykub4
A4ffCzajk9vC3iTOMSCxVqhk5gSbq0zgMj7ecZNXKyMjN0kX+nb32DcUe8H3
Vag7ybwh5cpQXc5nYM2GvqPLklubAqc7zBiK19WgyjBmc7re1SbpS00rhdZj
MfE6G04kM/FzUtAthGOez/Xv21gCJzhkRLE7z6U8187nydULJEq/av/JH7/6
W7ggv5h/PX8MZ0sEod++I/Bf0gVD66PcXdXPLIRYaWstyAiaJLgWg0S7pVuJ
7K89rzy4fy7GYJgUoarQogsHpQUCMJYBPpVE3abacmA+Bprm2beKARGli6Zy
CmXS6Lv7tjg7wmRDK0ECWbYxAy35c1ekyNYj3pjQdDlI62rf6pDURfv+8gVt
iOC8+QzwZi4WpIfo5WBoYukTjpC69QX0H3f8MuW9WfYzN8Z6M7dOu75Ti05T
+VUM08lzQ+RHS+tZkZEztmtptFiGpgz5/iI/iat7QgLBCS0NJvt9Zq6j4kb5
lv2GVAizPr64yF/TksxGhhehS/Bc4lnRYMs/AfTPYck18oB+G/jLDH7ir/lf
huELJcpSxzD/6uLJVxgIh2/HmxGd6UqGQ6CHTyJRipbrxzThlictSZNAmWxh
XJV59kEVcBEPVQAIWXlwPOGzPowOia6pGSTBTcOEAxDB91/6vpkPN447Az6V
M2riK1VQbDSvVvEAuKX8SKFCap69VMCi9JWpQgA2YN28Asv+Gqf13scFWImE
j86Tj5RlrvpNe1LEQIUT9FCxDjkTIVOMAQdmYEKzLskA4OAvyZEYdpTYVYty
E5owWLZDZCjqHGlBPEGtD+dMGYsCj9iISzXnTqHFgxvkFAr2mBYWqz4nqWLf
sAscuSlahfckjaO1a5Anu0OcTWF+k5juSDmW90YkmQsu/Jmj9uPaEQ7XWTlL
avt8QAbyyCSFMA7B2aAdzjd1/dGqm9RiGKYTffoRydpgI/T7r8XHnM188Mxh
taohdie+Mn7PaO6nBnK/ufqdTE3OMWv0G7qCxUVlh1arU5ZaOXqpFYzsIojT
WHUhu+jGOs9Pv7n6YHQ08p3+fLRXp3QeSArN5PVW0sT3LENMxKwSzY3fgoL3
DDyhYSejYj2J+yfapim1wiHsNTwqqaQTtgGHbp5pulny1Em5SoBio0mCLTue
k7TN4P+XjUXRSv6qX6CokQCFHuzA87Wg3yoFQGp1tdBBLcDNee8SqCyECgde
fs29YBg+LkVV5I/rwaDT/z8dr8bf3Xr8W7Be/46J/gFPOn1M6uw8OPt/58n8
Hcf47H+OydfLN99/m//4FvW5f3ma//t2S1MPrW9mk9oF9TjgTrCYMrejcQgE
SQ8OwxtShK02EuffuW9BgetLIYeNgrKZamo5yA1baR88aXZ8/aE7Daa7Ip1I
SrhS3BEWxGZZl9rpjgHI14cbTVSY31MBM8mqs2aGXf7RCxh7ofhsLDJm5jH8
0ab6VPnuXCHZUSl6UB0eWoQTn104sa7I+OWuDunY1risUpNvqimHZwTHtYdY
Cef0HR24UnexGxywxzLdt1anWggsnVPktw0iw2xqkdDwgXj9F9JCTKhsLONV
i3C4HP0zLX11uubp2efGHGSxWEmfKIVHoLlqT4Kve1tq6voTCP0+9e4SNRSk
OHmm91E0KfWikJuJpTvf13sOqsbtC+iPw25TfSzRRZmLsbkN97Ls6fpjet4z
RwGquao6yFzMdaaY7v2h4TKGNpS1NpFeY/RGk+qsFj0Z+8RC/hbyrRxCgcJM
kT9H7t3A6qetkx4YaOEp3TTFfs03SOuysKsDMKV0JCVyKhGWGIMLPwQGO7RA
ZQQcKN6lTXvVBUoEiwjSezjgEC/xsZG6c2JgO0cz4KN1+UD+HhpAG+uXMtIE
ldPDRtHFR7TR2gxJVJlPy91hbBsT2MqjtPx1fGzf11acHlzYIrTIg7N/yjom
BEyAFFT1jq6A+Jg/kYI/iXv3zCa1laC2R0VU0N983kLXp2MSF1H0h70JztAI
DYlytWIYiKJ6VjVoOaiwYjBZuHAtAS1wgU8JeSstNsIsZzrj0SH0q+zohQEn
5V46+QSXwjiyGuIDqFHu3O3QWjIF0hXHnwN337Dkit7oDWumyTjgYg98O58H
3TlLEhqd9K3bltEycK0854Mt6pH/jmwQmt6IamQGmz5CcCgFbyQJrybWlEDV
KP9FVOmW0ULTalez0aIBrphs1SO2mfK5qeigVSiiN8YlxCi4mFQ8cf6Vr/aL
FYI+gjgz4EKXVHTEWDg597MsVEKkEYtOehDOtSWBdMVG3AXgTe0JEhhj2wxp
L/SdNmLabYHvOObbJEKqLZ3D30IKM3YYR62U4goCoyJjQu1K0XL8XSC7DEDG
VYxNuCHs9DxqGZ1ZRlWkkJVwij6lK7Wv1LWegVkGzDyPD02pIee0D1zQz+15
i+UoKG7uO4G5q4CNtZSxozdgsvCs21gEXoxpwDa0ErNINMoQwUmxEf4OjVIe
dpgCKDM5td5n5eUMeBU6tktgc1O3Iai/ODSIWI3aIvQ+WY1o0zie5bY7bBl6
cNgzvjGxOyVAD+ikX8BTLXHgyByQfmdCqSiI1QeNO5sat8MAx8agZo0ZFow3
C5E2uLDy7MDHx6W/hR9vlqzUZ+EmSUT+nRYSucVCaWSxda3xNZd9HBC7AMA/
xZLgyaZBOmrticUP4/icskB75uehScpip22qdtoQ7roqBjVOnrLCLEaRhU/F
zQEWfSrcCBfJ9aYztLIoQABmWo7osRyudaGLgLG3S7JsXI6SNd2DfEbZeqrA
XaFk2qK/RpivJQr2QMs7RvNb9HC3+m2W+h1cI7VG7ut3alWMMR48oEgSK1rq
ZeRtkvA3dqRkr5lgazTpH5wg1mDfvP7w57l0UeYVtt6rdJFpT+jU/hvSj70v
luzVT44aDlD507q6rqwTQkvz5LQip6FWZlHGxwajMcVPpwx1ySEYPqPwLSc1
CtBjaaabEeav9PdkB7ThYPXIs3bRLel1eNd+4IUlMcF63cdmDZ94tT60/eMS
4gy6W0KQVofm2Ulue2SQjJVhRtCh0XGvYI2McBCrGnkKLj9rpGS12ynT5fDB
ciJBq5Mk6z0S6lpxEA6H1GNmm4pP9Gi1Wo1TcrsuDePlcutwH29OHa/v9qx9
2qoVwjvxpAVEnZPGkpCkdegKvXkMP9dfyPyDxivomdFDDHXXDDwrpRAt2fxn
n4kFiHacZ2p+zxbcePdANiHk2R6SFaAQ+rj5QzhsUZCsvBusojM0zoyMNS62
qJWy/i+LMN4R8JjcAwlDcTgVrr40PiOzhfWtldMSqn5E9ogLVDjuK/jDAYwJ
VChGFwuDQrvr1LD2VDIZl7NOw9SEeVsZYpjckUbNG25cuhaGYqmpdhxLElZQ
h8KSrD5GDCgnNmZY+q0lk/BZYVczhkNhRcJ8i1n4JzNu2dGOhoUxfAE/kB3S
OyOxik189Ebkd/yivJ69A3ekJu1YiIPksbLuTVClCbY0GLxoycFBnAdesJHg
anZcIvihtRQmKWTorTPa3qvRxlNxfz+3v59lju5ZyV3aZFNiEIGTLnxcuXAs
QyYAgc8JQUUxBXfx3ipDsud40Oqh8ZQg7OaRTwyYp43SI+/eH/6AS0UC7X/4
Azb7D3+4LuKfnmbZOf3pG/sT/UWrOWLByzW4U3zbZC1kJB2JNoDtQ2tUcn5q
P3X4QOQJD/PPYTZxnFakjS5Vmi2VcSPDhGM6tvHoDeIOiSehM+JfR/GNakRW
JgKNPCJ32SKmBeb5m5h9xyMiwYd3OpwLccVIswF3jRG59qwTT/Ba5JBNFNhm
Qy4PiedE9KVisDShUnS+J5RUpvtXmL4fLVJrNZIuNIh5aFyM1mScR93RJYPo
GTo9aVmLpMxQpBBGG6sVJG8Uxxt65ZTdTN4ADiqwo+J5xsZRNeNgCEUCccNe
ei+Cmejx4SgC+mZL7wkIAZjTYrOdRRzEyoUzLLPjqoPi+DNdsdHV5E6iwYwq
w/K4ghOUDbqdjE/GLtG7w1akVWv+fcIpoLZ5mItWTxXcwKFigj1ttjjo4+B/
vi2Q2JNnYGxQYw23YfXfA1cxG95wc/mxtDrnS7r5dq0cooYEr+baHpoYG2iS
vp3Et4ReD/Zya//j/cojZY5Fq3nZsNpjKzpkqQdRlcTakf8aab77Cw6LJNR/
uwPDz/v1h4af8qsPzlQn4d/oOGGmv/JIafZk/FhNjf+3PWwQgM8/cDbyhxw6
TRf+6oM3vSC/4jhqFvTeI/mQvtTG3BirHHhV6L3MeYR6o7rZg1g35LnIjn7I
o0/+cW7PPAGiayMh89uGzh9nLNm+E1fnZM8wFvqf+Iu5PPqcruOP1Z6rdp5C
Vzy+uDiPQ431crxUi1L+rL8EnoB/zszTM+t5yyIg3jwbDjdsyX/EPf6PmY4l
HXbgwioSHbMXO+Ei/1f657/mj/m3u/l8ru9ed92+ffroEf0tTGBeNzeP+L8e
/YeBTBLZPB8U6gZ0OPSZDSuIzVObdHFTPksp+nvbsv34BLuCE/Lj26f5c8n7
Bsy+IpDQsrpEy3da1Xn+ouDQwm1pqCL0anSGXdAc6N/hR4/VQZbTbYyss+3e
s2S0z1tl/jF673FdcCvAX24kovGK/sarxrpfrUQO2k7h1YUCOK6mvWfD5QY0
atgVycsC2YMQXsL2vGBIdGg5Eer9enGd/wXXYILmGra9fZV1/Ui51wCdO15d
1kr+65pzjOhpWlnF5dBMupq49eQPoUZb6uWuR+lMfEnjTCtsAFIV15N/MVN0
RV4BcV70yUpwdmA/TNgaQvRg9dVgx5ZBxwH7ItvRsc0DP5JeF658XkpCGSQs
6xD2t6sPkr27rUNx69Due8EdBPpR9DRmiQDi0vNgnRx5yYlot5c1c7AobVb4
UGI0FQPbItAjPEySbHo4Jtr/IXuqzvYoPPw0ZOSTfVLJUsKvM6t6HTOF36xn
vlN8oitTq/i3Hsy9AKMP6zvDtj7j5ooVimcBpODVbivhqNS25EL2hoeFNTbr
04prm/yrC85w3rfuV2vLGvHk5HHdnYnkhPJx3IMpEn/E/wgVNjC+LTrMTVTm
+ff1rbYXaofoUteWMkQ2UnH+Tcd+7x5dtiFriyYmbaRHM55Qn8ZT0OXYGJ5x
KUpbz1ARhQOIB4vtyc90ISA8xsJA9EOj7kR4R+AWGsXvYM7SrcL2QwSdtYov
s4QDMEV1QIi1Ac2jhAv4+Uw6kaOFhfyczLgKWL+YcFixEUrmCUtpA8J0Zuuu
uNOMQ8WhfAqx1LaeRcH963TxxES9ROztpYWBAhBXD6zXU6KMLSXG5T6wfoZ1
kOi0daV+hcZf38qHHNCTyJ9niAqxP/mjRv/yfyODFIQZD2UpCfNqOPjPuuv8
CHRRoS5CxjauncS7jv6ITum9pJrcnAZTCoMfMgOslT7RjzS/46DDee5qMLeV
5LE8JFiMeofBi8yTgnQGicCRM0vT5quYX2UXpmSmFVej7+ZMvAYJKotKFzsZ
NEBdUwaKzAOLRM9v7l2jry7+aWKVKrkylRqJB/zGU+5YA88AAg3LxDkpNuVk
j/jhAcIo0y4Hlgo7J0sOFTz4aRMWlzxebw7BsOL+lyybtTe4d4smPXDTuTwk
Dhj1JsIDeN5ayMdNfJZmvxJbypdJ/LK4Vz+Fy8pYZ6FLcYJVoFmc+JUQO0gS
vpHKonTd7NDNU4soQhSj4Cj9TaxuIykREnn5OlqNKUbaZwYV2TNYtJAcjH+n
5X02la2OsNlYwBYznlwcnVSFjJFrPDAT/iFYtHKlyWFjzfzMvztRJ1sBEBu9
YMz9Tealf8enbctd+LJ766wAPx4WSE6KKzOmtL0KKeSFd6GUmcvRs+xNt/a5
ofGHibTim219aCT9HEqxLboe7DhaAB1qzP+qlEmoLWIXWDxG21AzijH2aRxp
0ygsNgyUg+MSLCdLT22VJfG6X89/uQs1CBGioD+vtAJBegzhEZLj07hsRMAI
Gc5+v7nTFF1wGUI/r1C3oDA6bQFzXPkki1NzORndRuXg9auHE9E/UOYDy63A
ozZW6MZ8P4CfF5/urD+hoD50wgbjMPqik8FKnETLTNqblcIfIlro+9AtewYL
6BmAGeEhQAiTwHL7wUpMTiR72U9hI1TGEkjdBrWbOh9+xSwQF6rRq6QPan/F
eAWwOdKuXpqLcSBF7O52Ue/LSFgxFXigw628WXKzvReGcLtnH+rsjuzT91qK
ZI2wEpaZoHpiJdH4+MCp1wdnwXSW4Ar7wIBqcRI1H7ChrhXCxQuVDdDI0/Tt
PDSAHxrNb4ZGwr5rq5mxojiC88WZrj4qfmjazMatmhiEmIrLuEzEqUZElE2J
e5VkGnM5GqWprPKfzSfyWWlH61Yz/oDo4Ta0TzilLlzhKXs6iHp4SZwRwXPC
Y5wF+uDnPL64+CfrBIbmXty2EF64ZnxA1cqabzfkckd3BsXCMBMLX7NuGd2q
3Rcnwob3Q9Pm+0gonR7aJvGnDHj3AS+jJwihE3w2U9+u93fW0jzDTPRSf2Yn
CH+idkLo+hUFwDGT+MqxCkoQYu3uvCEU9nuWx61O63ZCxFUAC2U8Jn5VZlYC
k/AdglElQEv6Gbb+V+OuAKgvSLOiBXWLD9SGWIzNS4lCZoGEeSC1s/FRR6BJ
rzAkPZvht9WQBiyDtuuPYETgjwyB9/5zh9FjjPhcM1wHrHr2V62c2Nm/cPV6
t8bEsH7xcn7W2HpLevRCuyRfX4MtItAnOvQTANKrn4xKQGCF2vVUAjrxGs6f
c+bIxWn4SWDatt4Y/AjcxSeX4uqcPCBe5hnLwP2T0FUpZ2MDRBAOrQR0pAFB
r0pLKtqnRKNaDXfA8ux9ABfu7URl0EDJDjDEpyPewz6IIYq9EPPBaJG3Rwoo
X9euSzLbnLjHJKEyDmoq3H1pDvmxyxaQ+WE6Js3q85dAoXv/8wTPfd8D8S33
RA178zOWQS/qW/P95tAmv+o9LEzfPdCacq4G3wjO0GjMxT32dl1vSv/M8Acu
QTm0wyf3hqUBLPcEKRdpO7Ko+4fcT7h3rwwGsmeI9wOeExbODUURMcdeoSba
kcGO8qBMa6LjxJPhhcemFXXgL31rqg3P8283bXnsB6FbktpMaWnNsbEaJeCm
jAE1bam2O8pVExGUYkqZHyFuSw8DCVsmK8bVPVrNcZUSyhpXR1zeLCW4mlzn
4yw3Utedn1pnKK1XFLFSTPjZvV7VgJoSax7ikFEeLQXBuzCyCXQRvWXkVGmI
4LpRz+baSB/cJTGhemOSF8uRiooRa6dNeZj50kkNB4G994lIWHQ+EXsye5Vk
zH114MwN6eQnaZUzB6PxrLCSD4+OXL4ah1UHUZUzOc6Ti6pZAdMoVXcR7tqV
EsiwgGpu+DY0nU2ynNfktq6Meto5tRrKs0uNZXtwoxgC6FnSRnvNFBwg5Aue
gLbMWB+24lgoc+HNgXapDb0vpYZHohyN1bgPoei/Q0aH5s+ngi4j2z9r7gzO
Dcy0ajT0k6+UmNOKhxDQCXTb6Hw1To/9VjuCvleuuWtUNGp8mwNkfExApQwc
8w72dp/y2T+ESa2AtKjqJTOdC4IC/kiCy7YUSPTkrBXVNe9gCWAbwq6VAAvE
DxPvCv6r3NSelttRioybHAZ1HhMjeUf5U8fYQPGhZs5r3nNG9y54Z8l7haxJ
rsTkNAhnGqvXYP7dljrRicDJ92+ukhYH9r2sf78wnrPdV+pcFtf0pyIwctaD
kYxwHINM5n6F2RmJGHkU3dqMp9t1iMDO82pORq9iACJxitwYTdV+1LCgSZBV
rUvpF47todkZCpeWUZ6BdMu44gxE9lxi6Zd0uDkiUdrRyhJDd5neAqA8l+rH
0NK+atFLwa7VsQAHzugVuQM513fEE2q9i2zysTe7FJm7kQlOuy+JIzqoVYvf
GO3atJcDn4UM71GBs2L92UAgJTArRB284kavlU0Y1PccCRL5MUn7bJnPxuR9
pB+gUKAYujKR+ixcHbEEZ35ETPork0nh5WeLgjH1h/xtjwO9resdQqAQmG+K
DQ/WC4zUJnLBaAHicD7PTNdg6YquHlPZRzF6iHOBYciYCEfyY4hyhjr2a3Bh
Vwww16jefUBA/xJpdjGU3NA2Kmk7rZYfc5Ep7ztq9TThkLT6sG3WlFJE8Wpt
+tk4GeJiXS4+GjU70yAaxmmg6x73dN3JfWt7EpKFCRDXYpt0FG8leWgsQ8zC
+YDiuDwWx2koADk8Kelk4Hn0DCY0Iogf0MALSewhEEDrmTqj4LdeknqYOXKY
jV9tI/fa/9ve1TS3kRzZO35FB+dC2CBH9o4Pq13tBE2FwowdfYRErWO9sSE1
gCbZSxCNQAPk8DK/fSvfy8yq6g+QY+vgwxwcYwpAdXVVVlZ+vneZHnB1CcMg
xGgVryI8rV6ivEPzAMVNFcwSMaPZY4OWLWhl0UIjdyoAxvxL3Xlo/LTc9R6h
xqBYEk0DQAYYy/+t+qunKmDPxuMQb6NUqOPXiwNmhHWe6hWwbjLCekNui8bq
wIVlT1enEP4VkjPSfSiGf9GWVwreSGQ5cibpwqm9xlnzlmGaC/MeMCy1mCRv
wmWHbgq/s6kXt23OgkEzfsTInzxh3jvDWG2MlglA0URJRjrd8LQ4wK+8bgY5
U5Ie9HUlZDt1eHZd6Z7BBJH36rPzKi+vh27Uf6CvsHOaB+duiOyLIoBlvTTv
TZaECrxNgJlG/WuC49YpgEAfYcODY5edEJXxVDBmVC62YmociJFJq2v1QIFR
RtOkBxpbyadrfEwy7vpwhgVjaO7vD/OBwqYf6xscMDsaAxFDYi09PVb/nA1F
C9PRpBYqBuH6CjX/fbufp8R1nEz/R72GqXknrtNjwls0JsY7GzafqwGi1nHY
/k97SyeWSCdymK1n8urZlwcm2badqF78R6hA7bibZXHDbolUVy5QriLsG8//
WYxFprNiIrRWRH8V6dETVlyV28oVPH39mPCbGGBgGtBTUKOOXu9ykjIOQXjN
/hl5qIyy1LlvI9PnWDjgIg+P8zpQrQhz1zIFjYIxKTa+80tOhn3Fy+iXWQV0
6buYrK0h1SlGPW22WbiF14tkjfqFAUwe0JoPrsuAjiIOTLx6FEylyVW+PXhZ
hb8BNrJSCkzhiDMe16xSpu74JgS+R9+X5qXT8SPEbbXS9q0x1rmJM4nH3ijJ
wFUHnMVPBCxsM0DAPC+kLJDZJ8mp9jrHHNitox/q1vDZ7G7LT7p4qiugo0os
laA/4TV3qHDbNdmOg56pp5c5TY5BesGENrdsR8wo7Z4R20SQK1Z7UrvGahy3
ZrPoN1GKJo7nNvK2JkXZRJGT77BWAdn4EA+9eg/BshMzFJKY0MMVxxF9iuaE
U/aY2E0POIDQTrnC5G5LvGDeNisHZrLMY66PJ534QN+V61yT70HeQDTzAU3U
MQYYNRw4yP8GO3ffapVotsrxLIDdNJ5jrS6JkckBkDHnPSYUGuwQK5AG0knC
cKPi+A9sSyw1BczhQcI2i9ggMNBBfxoLbTwBrVMruq+SF/BEjHyXpl7kawZW
SJMSAtL3MOpQJ0I5gMfv/IJeqNLYsAZO0ckw/MQIXkwxXFg3ebmtOo4/9dp6
INXQrdwgs2RmHM/MeehC2ohf4bW5Z0UChiOluggdy09B8WykGu4EBT8KXmPy
Rj6pzLAYmFGkQOp4JSQDMmV1HCtvXpz+aepEvZO+NQjmYJz2LqfwcVICKtVh
07C30f9kICWyYHK20eZFwLa20j2creBQSaWvMQ0+VNuU6Ml1S8oYbdeJ9exO
gqZsIxhuGh8J3zSGb47fttZhx79j2HcwGP25dReJELkpPnz1M0moBE2vuq9J
v1JV9JqMoQrfHiDcA3wrUA8jjqXg9C6Ejhgd+Zttvaj6gGyia8JOInvRhVq8
WlU/qwbo/9DDXUqQBq1kZp217AN6bzqAA9c2PaDAT395//mn18YQ3id0G4Cp
Awj9TNEe5WAGtdbspaSf5tx9Uy+HhuqPNHeLhl6UiJ9BJuNEDeWVht/LMlZU
DoTBdI28qsx7HQPhe0ZVc0Q9V9NQ2zHWxd1jcV9XD6z8/RTLeiToUxz9CkHx
XuVnyMaR5Zojx53RG4z8gndu8neLZgcLByKqFvbzGs1iGQ5JihSm6Zb6DtEg
UCNKkT+O5zxIwo0sovwhtdTNspGYRaV0ERdsxpFIOWHjpYQp1TeRTNUyPWTq
1g5IWwxr8SsVhO5NTQa9Oomg627UJBFaNz8W77dSI3YBjDS/+tFtQhSIkb7Q
fiXff374oXifFnLLFSV0iPP/E5cIyxzrxVVrfFecKw6u5VDaHw9RPRjZGrY4
7QoBM+AxsA/u0YDmpf7TmZexy5mRiBruclBnoLs0S7bpqGEpfpSuGFBKPIeE
4pJDY9/yeHoKZyu/15xFnD4OqrTeOGXQB63uL17i9i8uRSTcAJBB5LTFynyv
6AewImEtnzNpcm45yyrpIBlGx1IV2nR1b/4OkQvWT/VHPOfZuv4wgtoU8eXo
elsvjzxbbyxH7Hd/emA7U37HA2idOjkc5ut1tbSUWk3GMiXKWzRl8B4Leboe
TD3WzIC/e/2RCOEQsA/hrxRNMoIturrC9ehAASfN9kTkgmRy05RNPPIfg/CO
rAiU2pva6+aAbJImiQBwI6SCXH81Bq4IudYEG4e1MO61ZUA1N/VVmBwiArIE
8tI49KcHMEry7YPH2jLPJ49IQO1dBwvDpODP82Ww494jYvYvoN6qk3CJIKEj
M4EcGj0l6BSTDdHGt5k7Xcl7tXa4jlC+IvavhXhXj0echbjMApxjWU0/OzCh
VODFumXlpVEJzmwxt4T9SdEl2ApFu1ALZ4J8WM9LmDByCUZ30VaVkybaHhbH
9DXUgls0QSm2m4Y/iCs7HeDbybLDye77/fIcPZB0lS2N4Edko90F+88ULqxQ
Jf96kOk855i/RkuERlUMR9SwKK+aYBEBDnfdZx/5URF33so7nZMoXYqlzj5c
SMIWNWnOVfiWPio+NYAf8eyOYMMRgusOHK+IER3F51BhyPc/vjn/wx9/+CMk
IohTOCMbFYUOfZJw5L3+fKnrKz9FFVi1jrAlD2VN0l51N6UmozW7Dga3WWXw
DJKRGk3QoMQNXMz3pFgoyutrMJOBRuzghIbv7P6l/VdFiREyQK7QEhFyMWDg
Hfs13b+beoldUbiGgmsbrNBfwYDdLIlPlVUT4F9pz+0qUz5Sba5LAKMvzeUJ
xsX6UTKZpyK0YPR14idACzDgwZHelo9z2KKleatAHwsKoNr2bql34DcPi5pg
1reEOxCuAIcFIYwS8lKVagXO1tNggKmX7lPBtXcMhzhsbjnGSKf19GlV/19g
Px3l5GvtkdLliMCheVBeSZuRDlcQwgoKRwyPRstkr/xwoPDGdZjJa52ukOpe
WLb5PEe4zRi/BpcVunuZ1ZWiTgZ7UYDZcbZUBr8bsoUMl6pNDqBkcIeDxt7A
nZP7Gh5TvxNWKU9I7gy/Wj9wl0k57uzltXWQrk6j91XQUPJ7tAoxUru0iCnl
tGGPVIdDQmGtVbfvtACkNLq/EYEyc5dX2Rgif9iA26radNetu17e9aEzlQyd
hE436WrGUPhACM+O+iAnJMZkg7buBl+tU9aZ5nnVM8NCXN/stJ3a7YNYijUU
MSKvVzT5OsnhCI3FatsNrvWMaQaBOkpXFkItQUw2wK4AoddKG+bCKkW4Ia1Q
t86Dov5dceGLmreSWjAeX3xjyW5n3+n0nc6Gj7UivZAVAxFr+JyseJDoPOEK
NGTM96xsdp8tAt098WJ7IbTpV9ZMa3U2avpIMUa8GNVU0tLEbSk5Fn2GXN1X
5XZndEGDuWBc/EKDe2yRNnR1SqXvuppGgEjYaJuwOvXCDLWqs4cuAixmZe2s
ipJOiaatc8AnLAk3AuHfGwmkCckwGOSYbhJFQGHclaZojNdhGvXfaxCHi/k5
6cs7zf+eFpaQ81BSx0DodtXalFY7KMEuvRp+GVGxI9udRkpgN8uE5D3CqsnU
K5YPGXNmMEKBISSXWluBOlMGcr4dwqfLfhLGSGZ2feNwm5FPO0yU5Ts1LKR9
3d4ko0ByuJrtLslUqhGsKz6SFbgpFfXR6BUl58IC3WrtHQmsqI0B2kGYUKpp
j3wllwd35x41MHwFK7k65us7TcqqmtoehF8vqiCAflTfDpzQxJ4E+Ka5h7Iy
jxqE9qOzAaFOB4I2bfNXQqLgUgNYV/ZNGAj+9cWLH/7X9MUaak7iL4t6u9jf
KRXEzM1XtxNeq4CgrL3a7dUwilxTMh6kJ1fu8l6gHsJTbmq9fB8Myle0FXe+
bqMYUGqkjdi/Fz5+3cF0vVoJc6SZIr1jR+SXx03VxodI7sXq6psmI3FlVFpi
hRJeb2vfKb/Mq7XsaauRZFQS4N+RibP9RFSYYr9pxHRm3kLEhxEDpY0GjL+Z
Ygs1M0oLLA4cYb6hUz8RIjKcMki/3nIr4upy6x0vJazbySccqXCoy0USsNRT
WUnGFQA1TVGFFWkeUdmuB4yBUanaeBRMovmqXNyezJufs/Cp2jZKdLMQf5BZ
RmDGy4qCQCoVo10lhs9u+xjV6Mde8Oo8DV4NHx3DhMh04yxXdql+PR1Q0YJU
bIQuY2a6MWsk6fdwxVmNKswPpXUiCUU4W7gR2s7O7dcMTaiJP3Dtom8Hl66f
kZ318rgRpO7zDIJMHqCrIfvHyz8fSjAb600fFsYWwlUzNbfCB+R3UpZClZsd
dbKoBfSwWrYBEVdEvu1QUAymbBwRRWnb8nJCuzEVUDWZZfTkDL9z5CrQIN4x
9sxJ1tH8I6PFJrxp8iYDADOHU8Z8SuKKSQFCjlfTse8TV0tqSDWVzww2s58G
RWVB15SU2Wp8b6SXSr9vgSpYRgdmyXsLOzvkcwSJt6b1i87H4EjRg3TYm/NI
OgR0v2siuXhYi0WacOvUIrWtbJdKQ07/lrx69RgkXVCRGUpPue8Q/5Nb2UQk
Mn4brZJV1cDXuGlWy4QIEZdcZAInEqkM8BMTvOWycc9KS0K0NkPar672NIgX
KySamnX+egwNanXEOPGepR/KZRVVYoYcHGT5XZDlv4ksS4JcTXIyfkvYYL9x
vF43zpNMutuuQzrQ61f8uCStqokMuU2aVAb3PatjKzcok5ocDzGZC8qWDILj
mBDpfZNY1xdrhSuRoCLTZh+1daNzRXOjW+G0hAE4IhV2Vuf7GhTAWueQV0IO
a5aZ2yb+M5RZgI5txNEeKQp3j4qTSd6RRELOFxU3Y9eEhYLxE2MktpdXsWiB
flVydYzB4SPRcuXE924VJBCuzlQoislUjhGGH4xrxaWyKgDYtVo00Rml50eO
KCPRVYAQVF12bN7ZdJQCkjazcxSble5SMuvgldX5hagqu3TKWCtstQRcN+t2
2oXFKi7O3p2JPCGuoBfB5F2D4AByUWEP5DugA/tUhamIUuz+4M9pulpO7T2x
28o2+jZe1XlX3TX0yeq7mvVwk121uFlLhvsxcfIirl4p5tn3IipU9wuL7C/l
2g4Wbo2I7WRVzoXTQMjIqvV9vW3WjMLRIxBnng2rDEwHWSsXlbcSeKgsHN4Y
unXeBWN0EKQT7fnIsvRr4qaFt9nwRQxOndS+nnpAqp6OijSvv/386RLtpHPM
YO0lglJEs6iSHl8NW/FgE6mVlhiaA0sx5IWJTZbM5iLWXt0GBbGLdpupBhkh
HLmgWe8I2oefSOcBr4xZ/np1CswO2oQjt7ePRH3WwTmTnkWBh2mDMiAkcFIH
GGRpDsmmI2AFQZyO7m94/CcaKQylidSKIGlxjawTfFvbFhOLDJA+THKSzd15
qwtjC1Y9RwVoq9WaeEtHobyG94XYY3Qa827+VQJG5Vx1b7IREx0acLnF2eJ2
3TwEob3WKDD7Cjc3W7ReI8Iba17suDjFJqrPF+y5Jtcw0gASgxaOkzCVs4vi
+I7//7Ss5Zp6KzaAWIq3cAvPguESzH2Yjqp/33949+a/ivA/rJjM3UsvzIWb
hIuqrh4Khf4KKn/vXGuqS3T2xJGuHfqusqpcQ/1pPdvjWMpxx4ERcRN+gdIr
US67/dLOp70C1zrI89mqeBsuNG2rD0NO3OXkfCUdBhWBtQJankeVroIyn5eL
WyPoZZNk0LgToAGshC/5VOht1rdASz9b+XXAVgLxI6lsoKLuNeb4GGYfLGL5
LsCOlPwQC7Z+ELxWlMpZmRf2FX1gAvcqWCE3cC4nQVwZJwp3BVYhiO5qhqmU
IK9EgknAXIgvkZRavhwma7xMU2ym3rTdwnnJxwpkhflLTk6fkq3fTTsrulR5
aCT4n4QYU9oq+SdZOVWdlqtrYXa+uRPhCh4SAjNAicM9NFVF7NwR5X1Zrxic
zZpmeWzHAZHy11BvLa2k1KaOs1XGL4ViKdn74Pzst+toy1oe2W6FVSOC1RlW
onW2R7TwN221D6cgeOMTI8nVwhbBr7OKz3YnHfFynIycKBgAwSVYTr5GGJSv
kOOvCRTN16H6zb9qUl2hYz3fmgCqnKKAiXyzctoiF4lzI61L5O7Efn02OqYQ
Y9COjaiSYVkeDLpdPjv8PsnrB5OGmNc0maUajRVMbGlpCuv/ofWaR1cRcpR+
X4UAzWvdIJn44AQfOKy603qOMZtI4NM31EsAFMxfSwI/PAYBWpOoACXZGgsI
K4GQYHxFIpZBHDwquN1nKEWRZ2ByGOIoP4+wi3EMkgN5+uRkrsonQJK6WE6d
zrDnISslK0jPTMniHJU0Tiq8ihwjr4lysH00QH4V0/+LHd4v7f7uK3mmMmTG
hN54cFF8IAacvuCnOlC/2eXJgZrlFwmi6mw+dVsgtbA2LR7vZeO9gqdfBT8Y
GESkmn1LFPTocofR0DTVaUDoQzyFuc/Lf7apP2vaWHK4vf/IxC2l+TTg0rdc
7n+eaT895Ut4T0tW6basRGOEJc0WxYqzPAbRgyqc/PLLL8UGunLiXVSyFMWr
It/S4ndF73wW3xfHfzh9UZz0P5pOKoMa+YI1xpCpcBe/Dz7Rz8cvTl8AlyV5
0kmRTSUdCnarDia/zk56GLH30FnRU0/TieFmZP8cRhx6zsBrTxJQtFf9Rxb/
/qoYfMIkxa97VRwPPe6kyF5pOj5Y2LnMGv3zyzGwuScMUqv0HAl1ib73SD2g
LHyoX88C87R1i55f7+trtcwsv5pSzD50eCGYOxqgPx6zO6cTaed1X8fm4b3c
I2kFZt2G7p7fTOvEtC51QdWsDnvqdu3XpDb7S6zNHrSkzy/FmDm/PGUYX9gR
2IqNHhIkUpXX4VuYyKgbiXbyyDzjm3wbA/nXsyl9cxP5N5vwN5vwG9uEmDIn
FWZ9FlSWlB5YzZ4hKedpoG/5DpJ6iNSVnfqo7kvJ+T3LkTJRySvqTCJECaxs
PA8SPUhZJEyVvxRFFFaAiH2StMmEt/tsoNaZiud1V+t2nmYj2ZvpOJ0tMw1t
Pxy1FQmglCDzjfBfT7LlGAe8Tq3IsK/RIDMjraMMZkXXbkslfDph6aMs8Ksi
G+93B+xNt5Licoefv5PXwJISO3BdJFLJ3oLw9kO/DWshPyaVns3nP4pgr1pL
QjH4u1dFd9f963GcE/tWVv4tHDBx8HkQ19tJ/Lf66tdOJKzVZPgGCx+a/fAF
9oOv7MBIU9qaJydimC9uB+5o9jICZm4VzNv8Ika3Cb9xLt9oT4v3a+CCCD2h
hKfX1YDngtyWXKHLxlJBA/0sGPxjtQZmBttXvg/G1sn3ZqPizkNdh7cs1Vvv
aBjukPmXtEPG4PM6uWHLMgFK67qRQM6uuTvZb0ZnyeE+rwXU0XMy0VZod49S
PjjfhiUOpuKMKTP5r74JeTkUCE7QLadPPOpsuYzd4KtaovqeCj8PS1ULoVY4
z5fV9o7ko9ry+Kz+wHJT7zJGrnfVA4ZqX1rGApsq9pfVgDFb4JViYrpfaDXQ
fUOwBaXDXOTDa5kFtXzY37ta09TGs4ruFsRaP745b2XUSoHifKTKKkvIOO8C
Uu9W46KlDVhXLKPahNerZW9QnM8aCHT1SUp9ZVsIs47Z07OL6bCJ9v/XgXit
I+IBAA==

-->

</rfc>