1. Introduction

Questa sezione conserva il testo RFC su UDPSTP, includendo One-Way IP Capacity metrics, Control and Data phases, Load and Status Feedback PDUs, KDF/HMAC authentication, optional checksum handling, IANA registries e security considerations.

Testo RFC originale

1.  Introduction

   The performance community has seen the development of informative
   Bulk Transport Capacity (BTC) definitions in "A Framework for
   Defining Empirical Bulk Transfer Capacity Metrics" [RFC3148] and
   "Defining Network Capacity" [RFC5136] as well as experimental metric
   definitions and methods in "Model-Based Metrics for Bulk Transport
   Capacity" [RFC8337].

   This document specifies the UDP Speed Test Protocol (UDPSTP) to
   enable the measurement of One-Way IP Capacity metrics as defined by
   [RFC9097].  The Method of Measurement discussed in that RFC deploys a
   feedback channel from the receiver to control the sender's
   transmission rate in near real-time.  Section 8.1 of [RFC9097]
   specifies requirements for this method.

   UDPSTP supports measurement features that weren't available via TCP-
   based speed tests and standard measurement protocols, such as the
   One-Way Active Measurement Protocol (OWAMP) [RFC4656], Two-Way Active
   Measurement Protocol (TWAMP) [RFC5357], and Simple Two-Way Active
   Measurement Protocol (STAMP) [RFC8762], prior to this work.  The
   controlled BTC measurement or Speed Test, respectively, is based on
   UDP rather than TCP.  The bulk measurement load is unidirectional.
   These specifications did support the creation of asymmetric traffic
   in combination with some two-way communication, as supported by TWAMP
   and STAMP, when work on UDPSTP started.  Further, two-way
   communications of TWAMP and STAMP are limited to reflection or
   unidirectional load properties, but they lack support for closed loop
   feedback operation.  The latter enables limiting congestion of a
   bottleneck, whose capacity is measured, to a short time range.
   Support of such a control loop is the main purpose of UDPSTP.

   Apart from measurement functionality, a Key Derivation Function (KDF)
   has been added to provide cryptographic separation of key material
   for authentication of protocol messages in a standardized and
   cryptographically secure manner.  This is a secondary improvement
   reached by UDPSTP and may simplify its reuse for other measurement
   purposes.  Additionally, because the protocol uses synthetic payload
   data and contains no direct user information, a decision was made to
   forgo encryption support.  This is also expected to increase the
   number of low-end devices that can support the test methodology.