4. Protocol Overview
Dieser Abschnitt bewahrt den RFC-Text zu UDPSTP, einschliesslich One-Way IP Capacity metrics, Control and Data phases, Load and Status Feedback PDUs, KDF/HMAC authentication, optional checksum handling, IANA registries und security considerations.
Originaler RFC-Text
4. Protocol Overview
All messages defined by this document SHALL use UDP transport
[RFC0768].
The remainder of this section gives an informative overview of the
communication protocol between two test endpoints (without expressing
requirements or elaborating on the authentication aspects).
One endpoint takes the role of server, listening for connection
requests on a standard UDP Speed Test Protocol port number from the
other endpoint, the client.
The client requires configuration of a test direction parameter
(upstream or downstream test, where the client performs the role of
sender or receiver, respectively) as well as the hostname or IP
address(es) of the server(s) in order to begin the setup and
configuration exchanges with the server(s). By default, the client
uses the single, standard UDPSTP port number per connection (see
Section 6). If the default port number is not used, the client may
require configuration of the control port number used by each server.
This would be the case if multiple server instances (processes)
operate on one or more machines.
Additionally, multi-connection (multi-flow) testing is supported by
the protocol. Each connection is independent and attempts to
maximize its own individual traffic rate. For multi-connection
tests, a single client process would replicate the connection setup
and test procedure multiple times (once for each flow) to one or more
server instances. The server instance(s) would process each
connection independently, as if they were coming from separate
clients. It is the responsibility of the client process to manage
the inter-related connections such as handling the individual
connection setup successes and failures, cleaning up connections
during a test (should some fail), and aggregating the individual test
results into an overall set of performance statistics. Fields in the
Setup Request (i.e., mcIndex, mcCount, and mcIdent; see Section 6.1)
are used to both differentiate and associate the multiple connections
that comprise a single test.
The protocol uses UDP transport with two connection phases (Control
and Data). As shown below, exchanges 1 and 2 constitute the Control
phase, while exchanges 3 and 4 constitute the Data phase. In this
document, the term "message" and the term "Protocol Data Unit", or
"PDU" [RFC5044], are used interchangeably.
1. Test Setup Request and Response: If a server instance is
identified with a host name that resolves to both IPv4/IPv6
addresses, it is recommended to use the first address returned in
the name resolution response, regardless of whether it is IPv4 or
IPv6. Thus, the decision on the preferred IP address family is
left to the name resolver's default behavior. Support for
separate IPv4 and IPv6 measurements or an IPv4 and IPv6 multi-
connection setup are left for future improvement. The client
then requests to begin a test by communicating its UDPSTP
protocol version, intended security mode, and datagram size
support. The server either confirms matching a configuration or
rejects the connection request. If the request is accepted, the
server provides a unique ephemeral port number for each test
connection, allowing further communication. In a multi-
connection setup, distinct UDP port numbers may be assigned with
each Setup Response from a server instance. Distinct UDP port
numbers will be assigned if all Setup Response messages originate
from the same server in that case.
2. Test Activation Request and Response: After having received a
confirmation of the configuration by a server, the client
composes a request conveying parameters such as the testing
direction, the duration of the test interval and test Sub-
Intervals, and various thresholds (for a detailed discussion, see
[RFC9097] and [TR-471]). The server then chooses to accept,
ignore, or modify any of the test parameters and communicates the
set that will be used unless the client rejects the
modifications. Note that the client assumes that the Test
Activation exchange has opened any co-located firewalls and
network address/port translators for the test connection (in
response to the Request packet on the ephemeral port number) and
the traffic that follows. See [RFC9097] for a more detailed
discussion of firewall and NAT-related features. If the Test
Activation Request is rejected or fails, the client assumes that
the firewall will close the address/port number pinhole entry
after the firewall's configured idle traffic timeout.
3. Test Stream Transmission and Measurement Feedback Messages:
Testing proceeds with one endpoint sending the Load PDUs and the
other endpoint receiving the Load PDUs and sending frequent
status messages to communicate the status and reception
conditions. The data in the feedback messages, whether received
from the client or when being sent to the client, is input to a
load rate adjustment algorithm at the server, which controls
future sending rates at either end. The choice to locate the
load rate adjustment algorithm at the server, regardless of
transmission direction, means that the algorithm can be updated
more easily at a host within the network and at a fewer number of
hosts than the number of clients. Note that the status messages
also help keep the pinhole (or mapping, respectively) active at
on-path stateful devices. UDPSTP is at least partially compliant
to Section 3.1 of [RFC8085] if the bottleneck is congested, but
pending congestion is avoided by limiting the duration of that
congestion to the minimum required to determine the bottleneck
capacity.
4. Stopping the Test: When the specified test duration has been
reached, the server initiates the exchange to stop the test by
setting a STOP indication in its outgoing Load PDUs or Status
Feedback messages. After being received, the client acknowledges
it by also setting a STOP indication in its outgoing Load PDUs or
Status Feedback messages. A graceful connection termination at
each end then follows. Since the Load PDUs and Status Feedback
messages are used, this exchange is considered a sub-exchange of
3 above. If the test traffic stops or the communication path
fails, the client assumes that the firewall will close the
address/port number combination after the firewall's configured
idle traffic timeout.
5. Both the client and server react to unexpected interruptions in
the Control or Data phase, respectively. Watchdog timers limit
the time a server or client will wait before stopping all traffic
and terminating a test.
Figure 1 provides an example exchange of control and measurement PDUs
for both downstream and upstream UDP Speed Tests (always client
initiated):
=========== Downstream Test ===========
+---------+ +---------+
| Client | Test Setup Request -----> | Server |
+---------+ +---------+
<----- Test Setup Response (Accept)
<----- Null Request PDU
Test Activation Request ----->
<----- Test Activation Response (Accept)
<----- Load PDUs
Status Feedback PDUs ----->
After expiry of server's test duration timer...
<----- Load PDU (TEST_ACT_STOP)
Status Feedback PDU (TEST_ACT_STOP) ----->
============ Upstream Test ============
+---------+ +---------+
| Client | Test Setup Request -----> | Server |
+---------+ +---------+
<----- Test Setup Response (Accept)
<----- Null Request PDU
Test Activation Request ----->
<----- Test Activation Response (Accept)
Load PDUs ----->
<----- Status Feedback PDUs
After expiry of server's test duration timer...
<----- Status Feedback PDU (TEST_ACT_STOP)
Load PDU (TEST_ACT_STOP) ----->
Figure 1: Successful UDPSTP Message Exchanges
4.1. Fixed-Rate Testing
A network operator who is certain of the IP-Layer Capacity to be
validated can execute a fixed-rate test of the IP-Layer Capacity and
avoid activating the measurement load rate adjustment algorithm (see
Section 8.1 of [RFC9097]). Fixed-rate testing SHOULD only be
activated for operation and maintenance purposes by operators within
their local network domain.
If a subscriber requests a diagnostic test from the network operator,
it strongly implies that there is no certainty on the bottleneck
capacity and initiating a UDP Speed Test based on the load adjustment
algorithm is RECOMMENDED. To protect against misuse, a client (and
in general, a consumer) MUST NOT be able to initiate a fixed-rate
test. A network operator may conduct a fixed-rate test for a stable
measurement at or near the maximum determined by the load rate
adjustment algorithm for debugging purposes. This may be valuable
for post-installation or post-repair verification.
4.2. Handling of and Safeguards Required by Self-Induced Congestion
Active capacity measurement requires inducing intentional congestion.
On paths where the capacity bottleneck is not shared with other
flows, this self-congestion will be observed as loss and/or delay.
However, when a path is shared by other flows, the measurement
traffic can congest the bottleneck on the path and therefore degrade
the performance of other flows. Unrestricted use of UDPSTP could
lead to traffic starvation and significant issues.
Measurements that generate traffic on shared paths (including Wi-Fi
and Internet paths) need to consider the impact on other traffic.
Fixed-rate testing operates without congestion control and therefore
must not be executed over other operators' network segments. Fixed-
rate testing, therefore, is limited to paths within a domain entirely
managed and operated section-wise and end-to-end by the network
operator performing the measurement. When the risks of disruption to
other flows has been considered, testing could be extended to include
adjacent operational domains for which there is also a testing
agreement.
Concurrent tests that congest a common bottleneck will impair the
measurement and result in additional congestion. Concurrent
measurements to measure the maximum capacity on a single path are
counterproductive. The number of concurrent independent tests of a
path SHALL be limited to one, regardless of the number of flows.
A load rate adjustment algorithm (see Section 5.1) is required to
mitigate the impact of this congestion and to limit the duration of
any congestion by terminating the test when sudden impairments or a
loss of connectivity is detected.