10. Operational Considerations for the Measurement Method

This section preserves the RFC text for UDPSTP, including One-Way IP Capacity metrics, Control and Data phases, Load and Status Feedback PDUs, KDF/HMAC authentication, optional checksum handling, IANA registries, and security considerations.

Original RFC Text

10.  Operational Considerations for the Measurement Method

   The architecture of the method requires two cooperating hosts
   operating in the roles of Src (test packet sender) and Dst
   (receiver), with a measured path and return path between them.

   The nominal duration of a measurement interval at the Destination,
   parameter testIntTime, MUST be constrained in a production network,
   since this is an active test method and it will likely cause
   congestion on the Src to Dst host path during a test.

   It is RECOMMENDED to locate test endpoints as close to the intended
   measured link(s) as practical.  The testing operator MUST set a value
   for the MaxHops parameter, based on the expected path length.  This
   parameter can keep measurement traffic from straying too far beyond
   the intended path.

   It is obviously counterproductive to run more than one independent
   and concurrent test (regardless of the number of flows in the test
   stream) when attempting to measure the maximum capacity on a single
   path.  The number of concurrent, independent tests of a path SHALL be
   limited to one.

   The load rate adjustment algorithm's scope is limited to helping
   determine the Maximum IP-Layer Capacity in the context of an
   infrequent, diagnostic, short-term measurement.  It is RECOMMENDED to
   discontinue non-measurement traffic that shares a subscriber's
   dedicated resources while testing: measurements may not be accurate,
   and throughput of competing elastic traffic may be greatly reduced.

   See Section 8 of [RFC9097] for a discussion of the Method of
   Measurement beyond purely operational aspects.

10.1.  Notes on Interface Measurements

   Additional measurements may be useful in specific circumstances.  For
   example, interface byte counters measured by a client at a
   residential gateway are possible when the client application has
   access to an interface that sees all traffic to/from a service
   subscriber's location.  Adding a byte counter at the client for
   download or upload directions could be used to measure total traffic
   and possibly detect when non-test traffic is present (and using
   capacity).  The client may not have the CPU cycles available to count
   both the interface traffic and IP-Layer Capacity simultaneously, so
   this form of diagnostic measurement may not be possible.