<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-morton-ippm-pipe-dream-01"
     ipr="trust200902" updates="">
  <front>
    <title abbrev="Dream-Pipe or Pipe-Dream">Dream-Pipe or Pipe-Dream: What Do
    Users Want (and how can we assure it)?</title>

    <author fullname="Al Morton" initials="A." surname="Morton">
      <organization>AT&amp;T Labs</organization>

      <address>
        <postal>
          <street>200 Laurel Avenue South</street>

          <city>Middletown</city>

          <region>NJ</region>

          <code>07748</code>

          <country>USA</country>
        </postal>

        <phone>+1 732 420 1571</phone>

        <facsimile>+1 732 368 1192</facsimile>

        <email>acm@research.att.com</email>

        <uri/>
      </address>
    </author>

    <date day="6" month="September" year="2021"/>

    <abstract>
      <t>This memo addresses the problem of defining relevant properties and
      metrics with the goal of improving Internet access for all users. Where
      the fundamental metrics are well-defined, a framework to standardize new
      metrics exists and been used with success. Users consider reliability to
      be important, as well as latency and capacity; it really depends who you
      ask and their current experiences.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>This memo addresses the problem of defining relevant properties and
      metrics with the goal of improving Internet access for all users. Much
      has already been done, and it's important to have a common foundation as
      we move forward. There is certainly more to understand about the problem
      and the approaches to a solution.</t>

      <section title="What's happening with users today?">
        <t>Part of the motivation for examining metrics in greater detail at
        this time is the belief that "Internet speed" is no longer the only
        service dimension that matters to users. A small sample of recent
        surveys follows.</t>

        <t>In a 2021 UK <xref target="EY-Study"/> EY study (Summary in
        Advanced Television), Decoding the digital home, Chapter 2, a survey
        of 2500 subscribers found that "Fifty-eight per cent of UK households
        believe broadband reliability is more important than speed". Also,
        "the appetite for a consistent connection aligns with perceptions that
        broadband reliability declined during the pandemic &ndash; 29 per cent
        across all households, rising to 46 per cent in households with
        children aged up to 11 years." If the family is on-line more-often,
        they will notice more outages.</t>

        <t>Reliability is surely important, but other factors come into play:
        "...nearly half (47 per cent) don&rsquo;t think upgrading to
        higher-speed packages is worth the cost. Meanwhile, 29 per cent say
        they don&rsquo;t understand what broadband speed means in practice."
        <xref target="EY-Study"/> Price trade-off and knowledge about the
        communication details play a role when discussing speed. Reliability
        issues are experienced by everyone.</t>

        <t>All the findings above are predicated on the current "speeds" being
        delivered. For example, "Fifty-two percent of rural users are
        frustrated that the fastest speeds are not available in their area,
        and only 52 per cent believe they are getting value for money from
        their current broadband package." <xref target="EY-Study"/> The
        proportion of Urban users was 10-15% higher when asked about value.
        Broadband speed available often defines the development gap in
        world-wide surveys, and users in under-served areas are likely glad to
        see increases.<xref target="N-Africa"/></t>

        <t>Another survey described in <xref target="DontKnow"/> found that
        36% of Americans *don't* know their Internet speed. A higher
        percentage of females did not know (47%) than males (25%). Older
        Americans (55+) and those in lower income households are other
        demographics where service speed was an above-overall-average gap in
        their Internet knowledge. Those who did not know their speed tended to
        be satisfied with the speed they receive, about 20% of these indicated
        dissatisfaction.</t>

        <t>Latency wasn't mentioned in <xref target="EY-Study"/>, but "While
        the survey indicates that most households ultimately want &lsquo;the
        basics&rsquo; to work well, those that do consider additional features
        as part of a broadband bundle favour privacy and security (48 per
        cent), reflecting wider anxieties and concerns relating to data
        protection experienced during the pandemic." Many users want their
        service provider to provide all the services.</t>
      </section>

      <section title="User expectations and how they can change">
        <t>User expectations are greatly influenced by their current
        experiences, and by what is technologically feasible at the time.
        Users have a view of the levels of availability, quality, and utility
        that constitute the overall experience in their situation of use
        (e.g., stationary in their home).</t>

        <t>When we insert a communication network as an integral part of an
        activity (a task or form of entertainment), then the expectation
        doesn't change or make allowances without a trade-off between the new
        features and the new situation For example, take the home but add the
        ability to travel: a stretch limousine fills some of the need but with
        reduced capabilities (the refrigerator is smaller, no beds or
        lavatory; there is less of everything). But we have a TV!</t>

        <t>Let's assume the TV uses analog transmission for this discussion.
        The TV is smaller and experiences reception outages, so we are
        suddenly aware of radio characteristics like fading and multipath
        (especially with earlier analog transmissions, there is no buffering
        at all). The limo is really nicely appointed, but it's not all we
        dreamed-of (or possibly even expected), especially the TV reception
        because we wanted to watch a play-off game on this trip!</t>

        <t>Where did they go wrong providing the TV in the Limo? They made the
        communication channel a much more obvious part of the viewing
        experience. And the first-time users didn't expect it. They inserted
        unexpected impairments in the communication channel by adding
        mobility. The TV designer might not have been aware of the moving use
        case; their "portable TV" means you can pick-up the TV easily, not
        watch TV at high speed, so needed features were not provided (a
        tracking antenna, to start with...).</t>

        <t>Since the goal of the workshop is to improve Internet Access for
        *all* users, then we have set a difficult task. Some users might want
        a dedicated pipe to communicate in the ways they choose or access
        content that they have identified. Other users are willing to share a
        pool of communication resources to communicate only when and where
        they want, for the potential benefits of being able to communicate
        more widely, spontaneously, and possibly for less cost than the
        dedicated pipe. It seems that we should focus on the subset of
        performance attributes that will benefit as many users as possible,
        and over-which our constituent organizations have some control.</t>
      </section>

      <section title="How fast can you go?">
        <t>To some, the maximum bit rate remains the primary goal.</t>

        <t>The Internet Speed record previously held by the University College
        of London (178 Tbps) was topped in July 2021 by a team of researchers
        from the National Institute of Information and Communications
        Technology (NICT) in Japan. The new world record for Internet speed,
        is 319 Tbps, using 4-core fiber <xref target="WorldRecord"/>.</t>

        <t>Higher link rates and subscriber rates may not be everything to
        users, but there can be a cross-over dependency to latency
        performance. Packet serialization time is reduced at higher link
        speeds, directly proportional to the increased rate. Bursts of large
        packets arriving for one stream affect the buffer time for packets in
        other streams that arrive behind them in a single FIFO queue, but
        again the problem is relieved by using higher link rates. For example,
        early VoIP used very low bit rate codecs: 8kbps was common, and so were
        10 Mbps LANs. But mixing bursty and periodic traffic meant unreliable
        delivery and delay variation for the latter. Packet marking,
        prioritization of multiple queues and queue management methods helped.
        More rate headroom and adaptation for the network impairments was also
        welcome.</t>

        <t>Instead of providing more capacity for a single user, today's
        Gigabit services support more users efficiently on the same access
        service. So higher rates can improve the other important dimensions of
        performance.</t>
      </section>
    </section>

    <section title="Dream-Pipe/Pipe-Dream">
      <t>Perhaps the ideal view of point-to-point communications is a pipe
      that illustrates many fundamental communication properties. A
      dream-pipe, so to speak.<list style="symbols">
          <t>The pipe is always ready to support communications when the user
          desires.</t>

          <t>Material that enters the pipe leaves the pipe in a sufficiently
          unadulterated form.</t>

          <t>The pipe has sufficient and dedicated capacity to deliver
          information at the same rate at which it entered (once the diameter
          of the pipe has been chosen).</t>
        </list>The apparent rigidity of the pipe model helps identify
      additional properties that are needed:<list style="symbols">
          <t>The capacity requirement may change/increase over time, even from
          session to session, so a user might anticipate a growing need for
          communications or anticipate use by more than one user by choosing a
          larger capacity pipe than they currently need.</t>

          <t>When we say, "delivered in sufficiently unadulterated form", we
          could mean:<list style="numbers">
              <t>a perfect reproduction (the communication of all messages
              with the same timing and order in which they started), or</t>

              <t>a reliable byte stream delivery, or</t>

              <t>communication of most messages with sufficient timeliness to
              reconstruct the original messages,or</t>

              <t>even a perceptual interpretation of a portion of the decoded
              messages delivered in a sufficiently timely way (for
              human-to-human voice communication: the users understood what
              was said, the conversation was sufficiently interactive as though they
              were in the same room (imperceptible latency), and each user can
              identify the remote speaker's voice. But the overall tolerance
              for imperfections in the pipe depends on the particular use case
              and many design choices.</t>
            </list></t>

          <t>The pipe itself must be ready for use, and the systems at the
          source and destination ends of the pipe must be equally ready and
          operational; all the systems required between users are responsible
          for success.</t>

          <t>The pipe may be invisible! Radio access has its own advantages
          and challenges.</t>
        </list></t>

      <t>So, a short list of network properties that contribute to good user
      experience are:<list style="numbers">
          <t>Available always when needed</t>

          <t>Sufficient Capacity when needed</t>

          <t>No apparent loss</t>

          <t>No apparent latency (which implies both low and consistent
          latency).</t>
        </list></t>

      <t>Networking and geographic reality tells us that we are unlikely to
      see all properties at once, for all time, AOE (anywhere on Earth);
      that's the extreme Pipe-Dream.</t>

      <t>But attaining a good user experience level in different communication
      activities/scenarios likely implies different demands among the four
      properties above, and places different relative importance on each of
      these properties.</t>

      <t>Author's Note: I'm positing a rigid pipe as the object of an
      idealistic idea, or "dream pipe". I hope there won't be any confusion
      about the play on words with "pipe dream; the dream pipe is a pipe
      dream, especially when the dream includes zero latency between any two
      points. I'm not talking about a hose or flexible pipe, either.</t>
    </section>

    <section title="Metrics to Assess Fundamental Properties">
      <t>The IETF has been working the problem of standardizing metrics for
      the Internet and the communication streams it transports for well over
      20 years. Many other organizations have been successfully working in
      this area as well, and hopefully they will identify their literature and
      key results for review.</t>

      <t>The IETF's efforts to define IP-Layer and Transport-Layer performance
      metrics and methods have largely been carried-out in the IPPM working
      group (IP-Performance Metrics, and later, called IP-Performance
      Measurements). Beginning as a somewhat joint effort with the
      performance-focused Benchmarking Methodology Working Group (BMWG), IPPM
      was chartered individually in 1997. IPPM has extensive literature
      relevant to Internet measurement. The IPPM working group has a strong
      foundation in its Framework <xref target="RFC2330"/> that has been
      updated over time, with <xref target="RFC7312"/> and <xref
      target="RFC8468"/>. What we can *standardize and measure*, we have as a
      basis to evaluate and determine whether we have made it better (or
      not).</t>

      <t>The problem that initiated the IPPM work turned-out to be the most
      difficult to solve (Bulk Transfer Capacity, BTC <xref
      target="RFC3148"/>), and has taken the longest. Meanwhile, the standards
      for fundamental metrics other than BTC turned-out to be sufficiently
      challenging.</t>

      <t>Here is a list of fundamental packet transfer metrics, specified in
      RFCs:<list style="symbols">
          <t>Connectivity <xref target="RFC2678"/></t>

          <t>One-Way Loss <xref target="RFC7679"/>, STD 81</t>

          <t>One-Way Delay <xref target="RFC7680"/>, STD 82</t>

          <t>Round-Trip Delay <xref target="RFC2681"/></t>

          <t>Round-Trip Loss <xref target="RFC6673"/></t>

          <t>Reordering <xref target="RFC4737"/></t>

          <t>Duplication <xref target="RFC5560"/></t>
        </list></t>

      <t>The metrics and methods above were specified with considerable
      flexibility, so that they could be applied in a range of specific
      circumstances.</t>

      <t>One of the most flexible metrics is IP Packet Delay Variation, <xref
      target="RFC3393"/> which is a "derived metric", in that it requires
      One-Way Delay measurements for assessment. The powerful feature of <xref
      target="RFC3393"/> is the selection function, which permits comparing
      the delays of any pair of packets in the stream. Fortunately, the
      performance community predominantly uses one of two forms of delay
      variation, the inter-packet delay variation and the packet delay
      variation forms. These forms are defined and compared in efficacy for
      measurement uses in <xref target="RFC5481"/> along with many other
      considerations and measurement forms/processing.</t>

      <t>It is possible to create new derived metrics at the IP-layer, and to
      measure similar quantities (loss, delay, reordering) at other layers
      <xref target="ForAll"/> <xref target="RFC6390"/> <xref
      target="RFC6076"/>.</t>

      <t>Another example of a derived metric uses loss instead of delay. This
      metric that does not have a direct parallel in the IETF literature is
      the Stream Block metric found in ITU-T Recommendation Y.1540 <xref
      target="Y.1540"/> (virtually all the IP-layer metrics are found in one
      standard). This metric assigns consecutive packets into multi-packet
      blocks, and assesses the number of lost packets in a block as a
      surrogate for a higher-layer process's ability to maintain good
      communication. For example, a Forward Error Correction process might be
      able to replace 2 lost packets in any order, but not 3. There is a
      parallel to retransmission rate limits when attempting to maintain a
      continued loss-free ratio with buffering to allow for the retransmission
      time.</t>

      <t>Network and Bulk Transport Capacity have been chartered and
      progressed over twenty years. The performance community has seen
      development of Informative definitions in <xref target="RFC3148"/> for
      Framework for Bulk Transport Capacity (BTC), <xref target="RFC5136"/>
      for Network Capacity, Maximum IP-layer Capacity (in RFC9097-to-be), and the
      Experimental metric definitions and methods in <xref target="RFC8337"/>,
      Model-Based Metrics for BTC.</t>

      <t>One quantity that could be measured without too much controversy is
      the Maximum IP-Layer Capacity (judging by the adoption in standards
      bodies, RFC9097-to-be) <xref
      target="I-D.ietf-ippm-capacity-metric-method"/>. This is the basis for
      many service specifications (and there is a technology or
      configuration-limited "ground truth" for the measurement), and can be
      tested simply with minimal reliance on end systems. The method deploys a
      feedback channel from the receiver to control the sender's transmission
      rate in near-real-time, and search for the maximum.</t>

      <t>The "invisible" radio dream pipe presents a challenge in terms of
      results variability for all metrics and adds at least one critical input
      parameter: location. It may be that the variability with location and
      time are key metrics to help users understand radio coverage (in
      addition to signal strength portrayed by the "number of "bars").</t>

      <t>A network property that is very high on the list in Section 2 is
      Availability. There is treatment of this important property as a metric
      in IETF (Connectivity <xref target="RFC2678"/>) and somewhat different
      details in an alternate definition (ITU-T Point-to-Point IP Service
      Availability <xref target="Y.1540"/>), but not much deployment for such
      an important pre-requisite to the rest of the metrics. Both Connectivity
      and Availability rely on packet loss measurements, in fact they can be
      considered *derived metrics*, adding time constraints and/or loss ratio
      thresholds to the fundamental loss measurements on a packet stream.</t>

      <t>Sometimes the end systems decide whether the path is available or
      not. In one on-line gaming system, reception of ICMP Destination
      Unreachable caused complete and immediate termination of the session
      with loss of all progress and resources accumulated. Customer service
      centers sometimes experienced call-in overload from users seeking to
      restore their player environment. But the Destination Unreachable
      condition was temporary and resolved by routing updates in a few
      seconds. The ultimate fix was to delay the session's reaction to
      Destination Unreachable for a few seconds, and recovery was automatic.
      So, when end systems play a role in the definition of connectivity or
      availability, they must also be cognizant that all automatic failure
      detection and restoration requires some amount of time. Since failures
      are inevitable, the dream-pipe heals itself, too (and doesn't confuse
      end-systems or users with error messages that "sound final").</t>

      <t>Most measurement systems begin their process with a
      Source-Destination packet exchange prior to actual measurements. If this
      pre-measurement exchange fails, then the test is not conducted (and
      re-tried later). But the most useful information to assess continuous
      connectivity/Availability is the record of test set-up success or
      failure over time. Measurement systems that make this info readily
      available do a more complete job of network characterization than
      others.</t>

      <t>We cannot leave the topic of metrics without mentioning the equally
      important topic of measurement streams for Active Metrics and
      Measurements <xref target="RFC7799"/>. When attempting to measure
      characteristics of VoIP streams, the IETF agreed on ways to produce
      periodic streams in an acceptable way <xref target="RFC3432"/>. Many
      measured results completely depend on the stream characteristics, and
      inter-packet delay variation is a great example. If the stream contains
      packet bursts, are the bursts preserved in transit? We would ask
      later-on whether preserving burst spacing matters to the communication
      quality or to the user's experience. The answer is likely a matter of degree, and
      dependent on the communications activity itself.</t>

      <t>When we consider the topic of new test streams in the context of
      Gigabit and higher access speeds intended to support multiple users, we
      might consider the notion of a "standard single user's stream set". Then
      we might measure how many simultaneous standard users can be supported
      with sufficient network performance: an indicator of each user's experience in the
      "dream-pipe". Of course, that details of a standard user's traffic would
      change over time, so we couldn't argue over the current year's
      definition for a year... The facility to register the new standard user
      test streams would be a key part of such a solution.</t>
    </section>

    <section title="Interpreting the Measurements">
      <t>If we had measured only the fundamental metrics, we might ask, "we
      saw a small proportion of packet losses; did this matter to users? Did
      losses affect their satisfaction during their activity in any way? Did
      any users experience an outage at this loss level?"</t>

      <t>The likely role for derived metrics is to improve results
      interpretation by measuring a new quantity, possibly in the context of a
      newly-defined packet stream, thereby making the process of
      results-interpretation easier to perform.</t>

      <t>For example, Delay Variation metrics had many possible formulations,
      but two main forms emerged. RFC 5481 <xref target="RFC5481"/> compared
      the IPDV and PDV forms with tasks that network and application designers
      were facing at the time. The RFC describes measurement considerations
      and results interpretation from a purely objective point of view. The
      most useful result interpretation was to show how PDV (a
      characterization of the delay distribution from minimum to a high
      percentile) could be used to determine the size of the de-jitter buffer
      needed for the tested path.</t>

      <t>For other fundamental IP-Layer metrics, there is some amount of
      discussion of best practices and interpretation in each of the IETF IPPM
      Metric RFCs.</t>

      <t>Many researchers (working in ITU-T Study Group 12 and elsewhere) take
      the information that can be derived from packet-layer measurements, plus
      higher layers when available, and produce objective estimates of user
      satisfaction by modeling user Mean Opinion Score (MOS) variation over a
      range of conditions. The process determines the user MOS through formal
      subjective testing in laboratories (or more recently prompted by
      COVID-19 conditions, in crowd-sourced scenarios). The corresponding
      objective models of user satisfaction are often determined through
      competition among several candidates, where the goal is to seek the most
      accurate model possible at the time. The modeling efforts often produce
      new derived metrics that facilitate automated interpretation. The main
      drawback is that the process described above takes significant time when
      conducted in the context of an industry standards body. So, user
      activities that are not particularly demanding of network performance do
      not receive much attention from researchers doing modeling; their
      performance is assumed to come-along for the ride (but in a system with
      multiple queues or other categorizations, each activities' requirements
      need to be quantified). Nevertheless, a process to take-in network
      measurements and produce a measure of user satisfaction is
      well-understood and used. The output of these objective models can
      rightly be called Quality of Experience (QoE), because a set of users'
      opinions is an inherent part of the result (without users, you don't
      have QoE! That's how QoE is defined and differs from QoS and network
      performance).</t>
    </section>

    <section title="Work together, as always!">
      <t>"What are the best ways to communicate these properties to service
      providers and network operators?" Work together with service providers
      and network operators. Everyone has a stake in our future.</t>

      <t>There are quite a few networking professionals whose day-job is
      network operation, and who are participating now.</t>
    </section>

    <section title="Displaying or Reporting Results">
      <t>Whether we present a single figure of merit, or a set of relevant
      measurements on a dashboard summary, each numer requires a frame of
      reference. This is true for everyone, not just everyday users.</t>

      <t>One example of a solid reference for results comes from the
      fundamental benchmarking specification, <xref target="RFC2544"/>. The
      measured Throughput (as defined in <xref target="RFC2544"/> ) must be
      compared to the maximum theoretical frame rate on the layer-2 technology
      (accounting for frame size, inter-frame gap, preamble, etc.). Tests with
      small frame size may not achieve the maximum frame rate due to header
      processing rate limitations, and tabulating the maximum with the results
      makes this fact very clear. Other reference levels can be made
      available, such as the capacity required to support 4k video (~25Mbps),
      etc.</t>

      <t>Some people will simply want to know whether the measurement result
      is good, bad, or somewhere in-between. We can follow common practice
      here to use colors (green, red, yellow in-between), or present the numer
      on a gauge with suitable color cues. But we need to know the use case or
      the service specification accurately to do this.</t>

      <t>In fact, a portion of user testing is prompted by subscribing to a
      new service provider, a new level of service (higher speed?), or a
      perception that poor-performance and trouble-shooting may be necessary;
      even an apparent outage may prompt test attempts using alternate devices
      and networks.</t>

      <t>This last testing scenario is the most interesting: how can we help
      users when they encounter a problem? It's usually most important to
      isolate the problem in the complex network, and when user to network
      host results are failing, can the next step remove some of the
      components and check them in isolation (while keeping in mind that the
      acceptance level for a sub-network is a part of the end-to-end budget
      for performance!). Is it impossible to reach a particular far-end host?
      Does the access network appear to be unavailable, or is the problem
      related to interference on the WiFi radio network? With test hosts
      placed at strategic points in the path, it may be possible to segment
      the problem a user is experiencing.</t>
    </section>

    <section title="Summary">
      <t>When all components that comprise a user's activity work
      well-together, then there are no surprises. Given that a large
      proportion of user expectations are met at some point in time, then the
      metrics and performance levels that characterize the network's
      contribution to overall satisfaction are what we want to describe and
      maintain. Users consider reliability to be important, as well as latency
      and capacity; it really depends who you ask and their current
      experiences. End-system designers have a role to play in the process by
      recognizing the realities of packet networks and compensating for them:
      the dream-pipe absolutes are still a pipe-dream today.</t>

      <t>There are many fundamental metrics already-defined. But we might find
      that we need new metrics that make interpreting the results easier! The
      notion of *derived metrics* has been applied successfully. Test streams
      with a known bias toward a particular class of user streams can also be
      useful basis for performance measurement. Where the fundamental metrics
      are well-defined, a framework to standardize new metrics and active test
      streams exists and been used with success. Metrics can be defined that
      immediately improve our understanding of the performance presented to
      users, but to understand user satisfaction requires that user opinions
      are part of the development process.</t>

      <t>All users, both knowledgeable and newcomers, need a frame of
      reference to understand what numerical measurements are telling them.
      The clues from the expected measurement range, the results from the
      recent past, or the theoretical maximum value all have their place. If
      users are willing, measurements should help them isolate their current
      issue to one or more networks and/or components in the user-to-X
      path.</t>

      <t>If we break the problem down by specific communications activities
      and look for specific metrics for each one, it could take a long time to
      complete. Perhaps a categorization of the performance metrics, numeric
      criteria, and reliability of a "pseudo-dream-pipe" for a set of
      communication activities that have similar needs is a way to move
      ahead.</t>
    </section>

    <section title="Security Considerations">
      <t>Active metrics and measurements have a long history of security
      considerations. The security considerations that apply to any active
      measurement of live paths are relevant here. See <xref
      target="RFC4656"/> and <xref target="RFC5357"/>.</t>

      <t>When considering privacy of those involved in measurement or those
      whose traffic is measured, the sensitive information available to
      potential observers is greatly reduced when using active techniques
      which are within this scope of work. Passive observations of user
      traffic for measurement purposes raise many privacy issues. We refer the
      reader to the privacy considerations described in the Large Scale
      Measurement of Broadband Performance (LMAP) Framework <xref
      target="RFC7594"/>, which covers active and passive techniques.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo makes no requests of IANA.</t>
    </section>

    <section title="Acknowledgments">
      <t>Thanks to all the folks who have worked on performance metric
      development, many of whom are the authors of the references. Many more
      have provided their insights along the way. It's rewarding to travel
      with others (even for a short time), and to meet new people on the
      journey.</t>
    </section>
  </middle>

  <back>
    <references title="References">
      <?rfc include='reference.RFC.2330'?>

      <?rfc include='reference.I-D.ietf-ippm-capacity-metric-method'?>

      <?rfc ?>

      <?rfc ?>

      <?rfc include="reference.RFC.3432"?>

      <?rfc include='reference.RFC.3393'?>

      <?rfc ?>

      <?rfc include='reference.RFC.2678'?>

      <?rfc include='reference.RFC.6673'?>

      <?rfc include='reference.RFC.4737'?>

      <?rfc include='reference.RFC.5560'?>

      <?rfc include='reference.RFC.7680'?>

      <?rfc include='reference.RFC.7679'?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>

      <?rfc include='reference.RFC.6076'?>

      <?rfc include='reference.RFC.6390'?>

      <?rfc include='reference.RFC.2681'?>

      <?rfc include='reference.RFC.4656'?>

      <?rfc include='reference.RFC.5357'?>

      <?rfc include='reference.RFC.5481'?>

      <?rfc ?>

      <?rfc ?>

      <?rfc ?>
    </references>

    <references title="More References">
      <?rfc include='reference.RFC.2544'?>

      <?rfc include='reference.RFC.3148'?>

      <?rfc include='reference.RFC.5136'?>

      <?rfc ?>

      <?rfc include='reference.RFC.8468'?>

      <?rfc include='reference.RFC.7312'?>

      <?rfc include='reference.RFC.7594'?>

      <?rfc include='reference.RFC.7799'?>

      <?rfc include='reference.RFC.8337'?>

      <reference anchor="Y.1540"
                 target="https://www.itu.int/rec/T-REC-Y.1540-201912-I/en">
        <front>
          <title>Internet protocol data communication service - IP packet
          transfer and availability performance parameters</title>

          <author fullname="ITU-T Recommendation Y.1540" surname="">
            <organization>ITU-T</organization>
          </author>

          <date month="December" year="2019"/>
        </front>
      </reference>

      <reference anchor="EY-Study"
                 target="https://advanced-television.com/2021/06/25/study-uk-homes-favour-broadband-reliability-over-speed/">
        <front>
          <title>Study: UK homes favour broadband reliability over
          speed</title>

          <author fullname="" surname="Advanced Television">
            <organization>https://advanced-television.com/2021/06/25/study-uk-homes-favour-broadband-reliability-over-speed/</organization>
          </author>

          <date day="25" month="June" year="2021"/>
        </front>
      </reference>

      <reference anchor="WorldRecord"
                 target="https://www.fibre-systems.com/news/internet-speed-record-319tbs-reached?utm_source=Adestra&amp;utm_medium=email&amp;utm_content=Internet%20speed%20record%20of%20319Tb%2Fs%20reached&amp;utm_campaign=FS%20July%202021%20Newsline&amp;utm_term=Fibre%20Systems">
        <front>
          <title>Internet speed record of 319Tb/s reached</title>

          <author fullname="" surname="Fiber Systems">
            <organization>https://www.fibre-systems.com/news/internet-speed-record-319tbs-reached?utm_source=Adestra&amp;utm_medium=email&amp;utm_content=Internet%20speed%20record%20of%20319Tb%2Fs%20reached&amp;utm_campaign=FS%20July%202021%20Newsline&amp;utm_term=Fibre%20Systems</organization>
          </author>

          <date day="19" month="July" year="2021"/>
        </front>
      </reference>

      <reference anchor="DontKnow"
                 target="https://advanced-television.com/2021/06/25/survey-just-36-of-us-know-their-broadband-speed/">
        <front>
          <title>Survey: Just 36% of US know their broadband speed (title is
          incorrect)</title>

          <author fullname="" surname="Advanced Television">
            <organization>https://advanced-television.com/2021/06/25/survey-just-36-of-us-know-their-broadband-speed/</organization>
          </author>

          <date day="25" month="June" year="2021"/>
        </front>
      </reference>

      <reference anchor="N-Africa"
                 target="https://www.libyaherald.com/2021/06/08/internet-speeds-improved-in-north-africa-over-last-four-quarters/">
        <front>
          <title>Internet speeds improved in North Africa over last four
          quarters</title>

          <author fullname="" surname="Libya Herald">
            <organization>https://www.libyaherald.com/2021/06/08/internet-speeds-improved-in-north-africa-over-last-four-quarters/</organization>
          </author>

          <date day="8" month="June" year="2021"/>
        </front>
      </reference>

      <reference anchor="ForAll"
                 target="https://ieeexplore.ieee.org/document/5167273">
        <front>
          <title>"Performance Metrics for All," in IEEE Internet Computing,
          vol. 13, no. 4, pp. 82-86, doi: 10.1109/MIC.2009.87.</title>

          <author fullname="Al Morton" initials="A." surname="Morton">
            <organization>AT&amp;T Labs</organization>
          </author>

          <date day="1" month="July" year="2009"/>
        </front>
      </reference>

      <?rfc ?>

      <?rfc ?>
    </references>
  </back>
</rfc>
