Test Protocol for One-way IP Capacity Measurement

1.1. Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14[RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

4.1. Parameters and Definitions

For Parameters related to the Maximum IP-Layer Capacity Metric and Method, please see Section 4 of [RFC9097].¶

4.2. Security Mode Operations

There are four security modes of operation:¶

1. A REQUIRED mode with authentication during the Control phase: Test Setup and Test Activation exchanges.¶

2. An OPTIONAL mode with the additional authentication of the Status Feedback messages (not the Load PDUs) during the Data phase.¶

3. An OPTIONAL Unauthenticated mode for all messages. This mode SHALL only be permitted when all other modes requiring authentication (or Partial Encryption) are not permitted.¶

4. An OPTIONAL mode with encryption of the Control phase exchanges and the Status Feedback messages.¶

5. For full encryption, OPTIONAL operation of both Control and Data phase exchanges inside an encrypted tunnel chosen and instantiated via a bilateral agreement between the users. This is not an explicit mode of the protocol itself.¶

The requirements below refer to the PDUs in the sections that follow, primarily the authUnixTime field, the authDigest field, and the keyId field. In an attempt to be more efficient, although somewhat unconventional, the second half of the 256-bit HMAC-SHA256 hash within the authDigest is reused as the Initialization Vector (IV). The roles in this section have been generalized so that the requirements for the PDU sender and receiver can be re-used and referred to elsewhere.¶

4.3. Key Management

Section 2 of [RFC7210] specifies a conceptual database for long-lived cryptographic keys. The database is implemented as a plaintext table, to allow text editor maintenance of the key table. The key table SHALL be used with the REQUIRED authentication mode and the OPTIONAL authentication mode (using the same key). The same key table and key SHALL also be used with the OPTIONAL Partial Encryption mode, when used.¶

The Key table SHALL have (at least) the following fields, referring to Section 2 of [RFC7210]:¶

• AdminKeyName¶

• LocalKeyName¶

• AlgID¶

• Key¶

• SendLifetimeStart¶

• SendLifetimeEnd¶

• AcceptLifetimeStart¶

• AcceptLifetimeEnd¶

The LocalKeyName SHALL be determined from the corresponding protocol field in the PDUs that follow, keyId.¶

4.4. Firewall Configuration

Normal firewall configuration allows a host to open a bidirectional connection using unique source and destination addresses and port numbers by sending a packet using that set of 4-tuple values. The client's interaction with its firewall depends on this configuration.¶

The firewall at the server MUST be configured with an open pinhole for the server IP address and well-known UDP port of the server.¶

Assuming that the firewall administration at the server does not allow an open UDP ephemeral port range, then the server MUST send a Null Request to the client from the ephemeral port communicated to the client in the Test Setup Response. The Null Request may not reach the client: it may be discarded by the client's firewall.¶

If the server firewall administration allows an open UDP ephemeral port range, then the Null Request is not strictly necessary. However, the availability of an open port range policy cannot be assumed.¶

5.1. Client Generates Test Setup Request

The client SHALL begin the Control phase exchanges by sending a Test Setup Request message to the server's (well-known) control port.¶

The client SHALL simultaneously start a test initiation timer so that if the Control phase fails to complete Test Setup and Test Activation exchanges in the allocated time, the client software SHALL exit (close the UDP socket and indicate an error message to the user). Lost messages SHALL NOT be retransmitted. The test initiation timer MAY reuse the test termination timeout value.¶

As of version 9, the watchdog timeout is configured as a 1 second interval to trigger a warning message that the received traffic has stopped. The test termination timeout is based on the watchdog interval, and implements a wait time of 2 additional seconds before triggering a non-graceful termination.¶

The Setup Request/Response message PDU SHALL be organized as follows:¶

//
// Control header for UDP payload of Setup Request/Response PDUs
//
struct controlHdrSR {
#define CHSR_ID 0xACE1
        uint16_t controlId;   // Control ID
        uint16_t protocolVer; // Protocol version
        uint8_t mcIndex;  // Multi-connection index
        uint8_t mcCount;  // Multi-connection count
        uint16_t mcIdent; // Multi-connection identifier
#define CHSR_CREQ_NONE     0
#define CHSR_CREQ_SETUPREQ 1  // Setup request
#define CHSR_CREQ_SETUPRSP 2  // Setup response
        uint8_t cmdRequest;   // Command request
#define CHSR_CRSP_NONE     0  // (used with request)
#define CHSR_CRSP_ACKOK    1  // Acknowledgment
#define CHSR_CRSP_BADVER   2  // Bad version
#define CHSR_CRSP_BADJS    3  // Jumbo setting mismatch
#define CHSR_CRSP_AUTHNC   4  // Auth. not configured
#define CHSR_CRSP_AUTHREQ  5  // Auth. required
#define CHSR_CRSP_AUTHINV  6  // Auth. (mode) invalid
#define CHSR_CRSP_AUTHFAIL 7  // Auth. failure
#define CHSR_CRSP_AUTHTIME 8  // Auth. time invalid
#define CHSR_CRSP_NOMAXBW  9  // Max bandwidth required
#define CHSR_CRSP_CAPEXC   10 // Capacity exceeded
#define CHSR_CRSP_BADTMTU  11 // Trad. MTU mismatch
#define CHSR_CRSP_MCINVPAR 12 // Multi-conn. invalid params
#define CHSR_CRSP_CONNFAIL 13 // Conn. allocation failure
        uint8_t cmdResponse;  // Command response
#define CHSR_USDIR_BIT 0x8000  // Upstream direction bit
        uint16_t maxBandwidth; // Required bandwidth
        uint16_t testPort; // Test port on server
#define CHSR_JUMBO_STATUS    0x01
#define CHSR_TRADITIONAL_MTU 0x02
        uint8_t modifierBitmap; // Modifier bitmap
        uint8_t reserved1;   // reserved octet
        uint8_t padding[12]; // Padding for encryption
        //
        uint32_t authUnixTime; // Authentication time stamp
#define AUTH_DIGEST_LENGTH 32  // SHA-256 digest length
        uint8_t authDigest[AUTH_DIGEST_LENGTH] // HMAC
#define AUTH_IV_LENGTH 16 // Initialization Vector (IV)
#define AUTH_DIGEST_IV (AUTH_DIGEST_LENGTH - AUTH_IV_LENGTH)
        // IV = &authDigest[AUTH_DIGEST_IV] (not encrypted)
#define AUTHMODE_0 0 // Mode 0: Unauthenticated
#define AUTHMODE_1 1 // Mode 1: Authenticated Control
#define AUTHMODE_2 2 // Mode 2: Authenticated Control+Status
#define AUTHMODE_3 3 // Mode 3: Encrypted Control+Status
        uint8_t authMode;   // Authentication mode (not encrypted)
        uint8_t keyId;      // Key ID in shared table (not encrypted)
        uint16_t reserved;  // reserved octets (not encrypted)
};

Figure 1: Test Setup PDU¶

The UDP PDU format layout SHALL be as follows (big-endian AB):¶

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          controlId            |          protocolVer          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    mcIndex    |    mcCount    |            mcIdent            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  cmdRequest   | cmdResponse   |         maxBandwidth          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           testPort            |modifierBitmap |   reserved1   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                        padding (96 bits)                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         authUnixTime                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                      authDigest (256 bits)                    |
|                                                               |
| _     _     _     _     _     _     _     _     _     _     _ |
|                                                               |
|              Initialization Vector (128 bits)                 |
|       [Reuses second half of HMAC within authDigest]          |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   authMode    |     keyId     |          reserved             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2: Test Setup PDU Layout¶

Additional details regarding the Setup Request and Response fields are as follows:¶

mcIndex: The index (0,1,2,...) of a connection relative to all connections that make up a single test. It is used to differentiate separate connections within a multi-connection test.¶

mcCount: The total count of attempted connections.¶

mcIdent: A pseudorandom non-zero identifier (via RNG, source port number,...) that is common to all connections of a single test. It is used to associate separate connections within a multi-connection test.¶

maxBandwith: When this field is non-zero, it is a specification of the maximum bit rate the client expects to send or receive during the requested test. The server compares this value to its currently available configured limit for test admission control. This field MAY optionally be used for rate-limiting the maximum rate the server should attempt. The CHSR_USDIR_BIT bit is set to 0 by default to indicate "downstream" and has to be set to 1 to indicate "upstream".¶

testPort: The UDP ephemeral port number on the server that the client SHALL use for the Test Activation Request and subsequent Load or Status PDUs.¶

modifierBitmap: There are two bits currently assigned in this bitmap:¶

CHSR_JUMBO_STATUS

Above a sending rate of 1Gbps, allow datagram sizes that result in Jumbo Frames (with a max IP packet size of 9000 bytes). Up to a sending rate of 1Gbps, or for all sending rates if CHSR_JUMBO_STATUS is not set, datagram sizes SHALL NOT produce an IP packet size greater than 1250 bytes (unless CHSR_TRADITIONAL_MTU is also set).¶

CHSR_TRADITIONAL_MTU

Allow datagram sizes, at any sending rate, that can result in a Traditional IP packet size of 1500 bytes. Effectively increasing the default non-Jumbo maximum from 1250 bytes to 1500 bytes.¶

Other bit positions are currently undefined. A new registry will be needed for modifierBitmap assignments; see the IANA Considerations section.¶

authDigest (and Initialization Vector, IV) field: This field contains the 256-bit HMAC-SHA256 hash. In Partial Encrypted mode, the second half of the hash within this field (128 bits) is reused as the Initialization Vector (IV).¶

authMode: The authMode field currently has four values assigned:¶

AUTHMODE_0:

OPTIONAL Unauthenticated mode¶

AUTHMODE_1:

REQUIRED authentication for Control phase¶

AUTHMODE_2:

OPTIONAL authentication for Control and Data phase (Status Feedback PDU only)¶

AUTHMODE_3:

OPTIONAL partial encrypted mode¶

plus, a range of values for experimentation: 60 through 63. A new registry will be needed for mode values; see the IANA Considerations section.¶

keyId: This is a localKeyName, the numeric key identifier for a key in the shared key table.¶

5.2. Server Processes Test Setup Request and Generates Response

This section describes the processes at the server to evaluate the Test Setup Request and determine the next steps.¶

//
// Control header for UDP payload of Null Request PDU
//
struct controlHdrNR {
#define CHNR_ID 0xDEAD
        uint16_t controlId;   // Control ID
        uint16_t protocolVer; // Protocol version
        uint8_t mcIndex;  // Multi-connection index
        uint8_t mcCount;  // Multi-connection count
        uint16_t mcIdent; // Multi-connection identifier
#define CHNR_CREQ_NONE    0
#define CHNR_CREQ_NULLREQ 1  // Null request
        uint8_t cmdRequest;  // Command request
#define CHNR_CRSP_NONE 0     // (used with request)
        uint8_t cmdResponse; // Command response
        uint16_t reserved1;  // reserved octets
        //
        uint32_t authUnixTime; // Authentication time stamp
        uint8_t authDigest[AUTH_DIGEST_LENGTH] // HMAC
        // IV = &authDigest[AUTH_DIGEST_IV] (not encrypted)
        uint8_t authMode;   // Authentication mode (not encrypted)
        uint8_t keyId;      // Key ID in shared table (not encrypted)
        uint16_t reserved;  // reserved octets (not encrypted)
};

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          controlId            |          protocolVer          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    mcIndex    |    mcCount    |            mcIdent            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  cmdRequest   |  cmdResponse  |           reserved1           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         authUnixTime                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                      authDigest (256 bits)                    |
|                                                               |
| _     _     _     _     _     _     _     _     _     _     _ |
|                                                               |
|              Initialization Vector (128 bits)                 |
|       [Reuses second half of HMAC within authDigest]          |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   authMode    |     keyId     |          reserved             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.3. Setup Response Processing at the Client

When the client receives the Test Setup Response message, it SHALL:¶

• verify the size of the Setup Response message and if correct interrogate the authMode field¶

• if operating in the Partial Encryption mode, use the available keyId and IV to decrypt the Setup Response message up to the IV using the method prescribed in Section 4.2.4¶

• if operating in one of the Authenticated modes, validate the Setup Response message by checking the authDigest as prescribed in Section 4.2.2¶

and then proceed to evaluate the other fields in the protocol, beginning with the protocol version, Control ID (to validate the type of message), and cmdRequest for the role of the message (SHOULD be Test Setup Response). The value in the authUnixTime field is a 32-bit timestamp with a 5 minute tolerance window (+/- 2.5 minutes) and SHALL be used (if in one of the Authenticated modes) to distinguish a subsequent replay of the message.¶

The authUnixTime field is expected to be zeroed in Unauthenticated mode.¶

If the cmdResponse value indicates an error (values greater than CHSR_CRSP_ACKOK) the client SHALL display/report a relevant message to the user or management process and exit. If the client receives a Command Response code that is not equal to one of the codes defined above, the client MUST terminate the connection and terminate operation of the current Setup Request. If the Command Server Response code value indicates success (CHSR_CRSP_ACKOK), the client SHALL compose a Test Activation Request with all the test parameters it desires, such as the test direction, the test duration, etc., as described below.¶

7.1. Test Packet PDU and Roles

Testing proceeds with one end-point sending Load PDUs, based on transmission parameters from the Sending Rate Table, and the other end-point sending Status Feedback messages to communicate the traffic conditions at the receiver. When the server is sending Status Feedback messages, they will also contain the latest transmission parameters from the Sending Rate Table that the client SHALL use.¶

The watchdog timer at the receiver SHALL be reset each time a PDU is received. See non-graceful test stop in Section 8 for handling the watchdog timeout expiration at each end-point.¶

When the server is sending Load PDUs in the role of sender, it SHALL use the transmission parameters directly from the Sending Rate Table via the index that is currently selected (which was indirectly based on the feedback in its received Status Feedback messages).¶

However, when the client is sending Load PDUs in the role of sender, it SHALL use the discreet transmission parameters that were communicated by the server in its periodic Status Feedback messages (and not referencing a Sending Rate Table directly). This approach allows the server to control the individual sending rates as well as the algorithm used to decide when and how to adjust the rate.¶

The server uses a load rate adjustment algorithm which evaluates measurements taken locally at the Load PDU receiver. When the client is the receiver, the information is communicated to the server via the periodic Status Feedback messages. When the server is the receiver, the information is used directly (although it is also communicated to the client via its periodic Status Feedback messages). This approach is unique to this protocol; it provides the ability to search for the Maximum IP Capacity and specify specific sender behaviors that is absent from other testing tools. Although the algorithm depends on the protocol, it is not part of the protocol per se.¶

The default algorithm (B) has three paths to its decision on the next sending rate:¶

1. When there are no impairments present (no sequence errors and low delay variation), resulting in a sending rate increase.¶

2. When there are low impairments present (no sequence errors but higher levels of delay variation), the same sending rate is maintained.¶

3. When the impairment levels are above the thresholds set for this purpose and "congestion" is inferred, resulting in a sending rate decrease.¶

Algorithm B also has two modes for increasing/decreasing the sending rate:¶

• A high-speed mode (fast) to achieve high sending rates quickly, but also back-off quickly when "congestion" is inferred from the measurements. Consecutive feedback intervals that have a supra-threshold count of sequence number anomalies and/or contain an upper delay variation threshold exception in all of the consecutive intervals are sufficient to declare "congestion" within a test. The threshold of consecutive feedback intervals SHALL be configurable with a default of 3 intervals.¶

• A single-step (slow) mode where all rate adjustments use the minimum increase or decrease of one step in the sending rate table. The single step mode continues after the first inference of "congestion" from measured impairments.¶

An OPTIONAL load rate adjustment algorithm (designated C) has been defined in [TR-471]. Algorithm C operation and modes are similar to B, but C uses multiplicative increases in the fast mode to reach the Gigabit range quickly and adds the possibility to re-try the fast mode during a test (which improves the measurement accuracy in dynamic or error-prone access, such as radio access).¶

On the other hand, the test configuration MAY use a fixed sending rate requested by the client, using the field srIndexConf.¶

The client MAY communicate the desired fixed rate in its test activation request. The reasons to conduct a fixed-rate test include stable measurement at the maximum determined by the load rate adjustment algorithm, or the desire to test at a known subscribed rate without searching.¶

The Load PDU SHALL be organized as follows (followed by any payload content):¶

//
// Load header for UDP payload of Load PDUs
//
struct loadHdr {
#define LOAD_ID 0xBEEF
        uint16_t loadId; // Load ID
#define TEST_ACT_TEST  0 // Test active
#define TEST_ACT_STOP1 1 // Stop indication used locally by server
#define TEST_ACT_STOP2 2 // Stop indication exchanged with client
        uint8_t testAction;  // Test action
        uint8_t rxStopped;   // Receive traffic stopped indicator (BOOL)
        uint32_t lpduSeqNo;  // Load PDU sequence number
        uint16_t udpPayload; // UDP payload (bytes)
        uint16_t spduSeqErr; // Status PDU sequence error count
        uint32_t spduTime_sec;  // Send time in last received status PDU
        uint32_t spduTime_nsec; // Send time in last received status PDU
        uint32_t lpduTime_sec;  // Send time of this load PDU
        uint32_t lpduTime_nsec; // Send time of this load PDU
        uint16_t rttRespDelay;  // Response delay for RTT (ms)
        uint16_t reserved1;     // reserved octets
};

Figure 7: Load PDU¶

The UDP PDU format layout SHALL be as follows (big-endian AB):¶

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           loadId              |   testAction  |   rxStopped   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           lpduSeqNo                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           udpPayload          |           spduSeqErr          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          spduTime_sec                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         spduTime_nsec                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          lpduTime_sec                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         lpduTime_nsec                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         rttRespDelay          |           reserved1           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                       Payload Content...                      .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 8: Load PDU Layout¶

Specific details regarding Load PDU fields are as follows:¶

testAction: Designates the current test action as either TEST_ACT_TEST (testing in progress), TEST_ACT_STOP1 (first phase of graceful termination, used locally by server), or TEST_ACT_STOP2 (second phase of graceful termination, sent by server and reciprocated by client). See Section 8 for additional information on test termination.¶

rxStopped: A boolean (0 or 1) used to indicate to the remote end-point that local receive traffic (either Load or Status PDUs) has stopped. All outgoing Load or Status PDUs SHALL continue to assert this indication until traffic is received again, or the test is terminated. The time threshold to trigger this condition is expected to be a reasonable fraction of the watchdog timeout (a default of one second is recommended).¶

lpduSeqNo: Load PDU sequence number (starting at 1). Used to determine loss, out-of-order, and duplicates.¶

udpPayload: The total payload size of the UDP datagram including the Load PDU message header and Payload Content (i.e., what the UDP socket read function would return). This field allows the Load PDU receiver to maintain accurate receive statistics if utilizing receive truncation (only requesting the Load PDU message header octets from the protocol stack).¶

spduSeqErr: Status PDU loss count, as seen by the Load PDU sender. This is determined by the Status PDU sequence number (spduSeqNo) in the most recently received Status PDU. Used to communicate to the Load PDU receiver that return traffic (in the unloaded direction) is being lost.¶

spduTime_sec/spduTime_nsec: A copy of the most recent spduTime_sec/spduTime_nsec from the last Status PDU received. Used for RTT measurements made by the Load PDU receiver.¶

lpduTime_sec/lpduTime_nsec: The local send time of the Load PDU. Used for one-way delay variation measurements made by the Load PDU receiver.¶

rttRespDelay: RTT response delay, used to "adjust" raw RTT. On the Load PDU sender, it is the number of milliseconds from reception of the most recent Status PDU (when the latest spduTime_sec/spduTime_nsec was obtained) to the transmission of the Load PDU (where the previously obtained spduTime_sec/spduTime_nsec is returned). When the Load PDU receiver is calculating RTT, by subtracting the copied Status PDU send time (in the Load PDU) from the local Load PDU receive time, this value is subtracted from the raw RTT to correct for any response delay due to Load PDU scheduling.¶

Payload Content: All zeroes, all ones, or a pseudorandom binary sequence.¶

7.2. Status PDU

The Load PDU receiver SHALL send a Status PDU to the sender during a test at the configured feedback interval, after at least one Load PDU has been received (when there is something to provide status on). In test scenarios with long delays between client and server, it is possible for the Status PDU send timer to fire before the first Load PDU arrives. In these cases, the Status PDU SHALL NOT be sent.¶

The watchdog timer at the Load PDU sender SHALL be reset each time a Status PDU is received. See non-graceful test stop in Section 8 for handling the watchdog timeout expiration at each end-point.¶

The Status PDUs are a key part of the server-client control loop. To protect against bit errors (checksum) or on-path attacks (something stronger), there is a requirement to calculate and include/check the UDP checksum. Also, Authenticated mode 2 that covers the Status PDU and will detect bit errors or attempts to replace values in the original packets.¶

The Status Feedback message PDU (as well as the included Sub-Interval Statistics structure) SHALL be organized as follows:¶

//
// Sub-interval statistics structure for received traffic information
//
struct subIntStats {
        uint32_t rxDatagrams; // Received datagrams
        uint64_t rxBytes;     // Received bytes (64 bits)
        uint32_t deltaTime;   // Time delta (us)
        uint32_t seqErrLoss;  // Loss sum
        uint32_t seqErrOoo;   // Out-of-Order sum
        uint32_t seqErrDup;   // Duplicate sum
        uint32_t delayVarMin; // Delay variation minimum (ms)
        uint32_t delayVarMax; // Delay variation maximum (ms)
        uint32_t delayVarSum; // Delay variation sum (ms)
        uint32_t delayVarCnt; // Delay variation count
        uint32_t rttMinimum;  // Minimum round-trip time (ms)
        uint32_t rttMaximum;  // Maximum round-trip time (ms)
        uint32_t accumTime;   // Accumulated time (ms)
};
//
// Status feedback header for UDP payload of status PDUs
//
struct statusHdr {
#define STATUS_ID 0xFEED
        uint16_t statusId;  // Status ID
        uint8_t testAction; // Test action
        uint8_t rxStopped;  // Receive traffic stopped indicator (BOOL)
        uint32_t spduSeqNo; // Status PDU sequence number
        struct sendingRate srStruct; // Sending rate structure
        uint32_t subIntSeqNo;        // Sub-interval sequence number
        struct subIntStats sisSav;   // Sub-interval saved stats
        uint32_t seqErrLoss;    // Loss sum
        uint32_t seqErrOoo;     // Out-of-Order sum
        uint32_t seqErrDup;     // Duplicate sum
        uint32_t clockDeltaMin; // Clock delta minimum (ms)
        uint32_t delayVarMin;   // Delay variation minimum (ms)
        uint32_t delayVarMax;   // Delay variation maximum (ms)
        uint32_t delayVarSum;   // Delay variation sum (ms)
        uint32_t delayVarCnt;   // Delay variation count
#define STATUS_NORTT UINT32_MAX // No RTT data/value
        uint32_t rttMinimum;    // Minimum round-trip time sampled (ms)
        uint32_t rttSample;     // Last round-trip time sample (ms)
        uint8_t delayMinUpd;    // Delay minimum(s) updated (BOOL)
        uint8_t reserved1;      // reserved octet
        uint16_t reserved2;     // reserved octets
        uint32_t tiDeltaTime;   // Trial interval delta time (us)
        uint32_t tiRxDatagrams; // Trial interval receive datagrams
        uint32_t tiRxBytes;     // Trial interval receive bytes
        uint32_t spduTime_sec;  // Send time of this status PDU
        uint32_t spduTime_nsec; // Send time of this status PDU
        uint8_t padding[12];    // Padding for encryption
        //
        uint32_t authUnixTime; // Authentication time stamp
        uint8_t authDigest[AUTH_DIGEST_LENGTH] // HMAC
        // IV = &authDigest[AUTH_DIGEST_IV] (not encrypted)
        uint8_t authMode;   // Authentication mode (not encrypted)
        uint8_t keyId;      // Key ID in shared table (not encrypted)
        uint16_t reserved;  // reserved octets (not encrypted)
};

Figure 9: Status PDU¶

The UDP PDU format layout SHALL be as follows (big-endian AB):¶

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          rxDatagrams                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            rxBytes                            |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           deltaTime                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           seqErrLoss                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           seqErrOoo                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           seqErrDup                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          delayVarMin                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          delayVarMax                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          delayVarSum                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          delayVarCnt                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          rttMinimum                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          rttMaximum                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           accumTime                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0                   1                   2                   3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|          statusId             |   testAction  |   rxStopped   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           spduSeqNo                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                      srStruct (28 octets)                     .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          subIntSeqNo                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
.                      sisSav (56 octets)                       .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           seqErrLoss                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           seqErrOoo                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           seqErrDup                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         clockDeltaMin                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          delayVarMin                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          delayVarMax                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          delayVarSum                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          delayVarCnt                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          rttMinimum                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           rttSample                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  delayMinUpd  |   reserved1   |           reserved2           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                          tiDeltaTime                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         tiRxDatagrams                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                           tiRxBytes                           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         spduTime_sec                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         spduTime_nsec                         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                        padding (96 bits)                      |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         authUnixTime                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                      authDigest (256 bits)                    |
|                                                               |
| _     _     _     _     _     _     _     _     _     _     _ |
|                                                               |
|              Initialization Vector (128 bits)                 |
|       [Reuses second half of HMAC within authDigest]          |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   authMode    |     keyId     |          reserved             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 10: Status PDU Layout¶

Note that the Sending Rate structure is defined in Section 6.¶

The primary role of the Status Feedback message is to communicate to the Load PDU sender the traffic conditions at the Load PDU receiver. While the Sub-Interval Statistics structure (sisSav) covers the most recently saved (completed) sub-interval, similar fields directly in the Status PDU itself cover the most recent trial interval (the time period between Status Feedback messages, completed by this Status PDU). Both sets of statistics SHALL always be populated by the Load PDU receiver, regardless of role (client or server).¶

Details on the Status PDU measurement fields are provided in [RFC9097]. Additional information regarding fields not defined previously are as follows:¶

rxDatagrams/rxBytes/deltaTime: Sub-interval received datagram and byte counts as well as the exact duration of the sub-interval in microseconds. Used to calculate the received traffic rate for the sub-interval. The rxBytes field is a 64-bit value to prevent overflow at high speeds.¶

seqErrLoss/seqErrOoo/seqErrDup: Loss, out-of-order, and duplicate totals. Available for both the sub-interval and trial interval.¶

delayVarMin/delayVarMax/delayVarSum/delayVarCnt: The one-way delay variation measurements of all received Load PDUs (where avg = sum/cnt). For each Load PDU received, the send time (lpduTime_sec/lpduTime_nsec) is subtracted from the local receive time, which is then normalized by subtracting the current clockDeltaMin. Available for both the sub-interval and trial interval.¶

rttMinimum/rttMaximum (in sisSav): The minimum and maximum RTT delay variation (rttSample) in the sub-interval designated by the subIntSeqNo.¶

accumTime: The accumulated time of the test in milliseconds, based on the duration of each sub-interval. Equivalent to the sum of each deltaTime (although in ms) sent in each Status PDU during the test.¶

spduSeqNo: Status PDU sequence number (starting at 1). Used by the Load PDU sender to detect Status PDU loss (in the unloaded direction). The loss count is communicated back to the Load PDU receiver via spduSeqErr in subsequent Load PDUs.¶

subIntSeqNo: Sub-interval sequence number (starting at 1) that corresponds to the statistics provided in sisSav, for the last saved (completed) sub-interval.¶

sisSav: Sub-interval statistics saved (completed) for the most recent sub-interval (as designated by the subIntSeqNo).¶

clockDeltaMin: The minimum clock delta (difference) since the beginning of the test. Obtained by subtracting the send time of each Load PDU (lpduTime_sec/lpduTime_nsec) from the local time that it was received. This value is initialized with the first Load PDU received and is updated with each subsequent one to maintain a current (and continuously updated) minimum. If the end-point clocks are sufficiently synchronized, this will be the minimum one-way delay in milliseconds. Otherwise, this value may be negative (but still completely valid for one-way delay variation measurements).¶

rttMinimum (in Status PDU): The minimum "adjusted" RTT measured since the beginning of the test. See rttRespDelay regarding "adjusted" measurements. RTT is obtained by subtracting the copied spduTime_sec/spduTime_nsec in the received Load PDU from the local time at which it was received. This minimum SHALL be kept current (and continuously updated) via each Load PDU received with an updated spduTime_sec/spduTime_nsec. This value MUST be positive. Before an initial value can be established, and because zero is itself valid, it SHALL be set to STATUS_NORTT when communicated in the Status PDU.¶

rttSample: The most recent "adjusted" RTT delay variation measurement. See rttRespDelay regarding "adjusted" measurements. RTT delay variation is obtained by subtracting the current (and continuously updated) "adjusted" RTT minimum, communicated as rttMinimum (in Status PDU), from each "adjusted" RTT measurement (which is itself obtained by subtracting the copied spduTime_sec/spduTime_nsec in the received Load PDU from the local time at which it was received). Note that while one-way delay variation is measured for every Load PDU received, RTT delay variation is only sampled via the Status PDU sent and the very next Load PDU received with the corresponding updated spduTime_sec/spduTime_nsec. When a new value is unavailable (possibly due to packet loss), and because zero is itself valid, it SHALL be set to STATUS_NORTT when communicated in the Status PDU.¶

delayMinUpd: Boolean (0 or 1) indicating that the clockDeltaMin and/or rttMinimum (in Status PDU), as measured by the Load PDU receiver, has been updated.¶

tiDeltaTime/tiRxDatagrams/tiRxBytes: The trial interval time in microseconds, along with the received datagram and byte counts. Used to calculate the received traffic rate for the trial interval.¶

spduTime_sec/spduTime_nsec: The local transmit time of the Status PDU. Expected to be copied into spduTime_sec/spduTime_nsec in subsequent Load PDUs after being received by the Load PDU sender. Used for RTT measurements.¶

The authentication (and encryption) fields and their operation are as defined previously in Sections 5 and 6.¶

When a client or server prepares to send the Status PDU, it SHALL:¶

9.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.¶

13.1. Normative References

[FIPS-197]

National Institute of Standards and Technology, NIST., "Federal Information Processing Standards Publication 197 (FIPS-197), ADVANCED ENCRYPTION STANDARD (AES)", 26 November 2001, <https://nvlpubs.nist.gov/nistpubs/fips/nist.fips.197.pdf>.

[I-D.ietf-ippm-capacity-metric-method]

Morton, A. C., Geib, R., and L. Ciavattone, "Metrics and Methods for One-Way IP Capacity", Work in Progress, Internet-Draft, draft-ietf-ippm-capacity-metric-method-12, 9 June 2021, <https://datatracker.ietf.org/doc/html/draft-ietf-ippm-capacity-metric-method-12>.

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/info/rfc2119>.

[RFC2330]

Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, DOI 10.17487/RFC2330, May 1998, <https://www.rfc-editor.org/info/rfc2330>.

[RFC2681]

Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, DOI 10.17487/RFC2681, September 1999, <https://www.rfc-editor.org/info/rfc2681>.

[RFC6071]

Frankel, S. and S. Krishnan, "IP Security (IPsec) and Internet Key Exchange (IKE) Document Roadmap", RFC 6071, DOI 10.17487/RFC6071, February 2011, <https://www.rfc-editor.org/info/rfc6071>.

[RFC6234]

Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, DOI 10.17487/RFC6234, May 2011, <https://www.rfc-editor.org/info/rfc6234>.

[RFC6438]

Carpenter, B. and S. Amante, "Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels", RFC 6438, DOI 10.17487/RFC6438, November 2011, <https://www.rfc-editor.org/info/rfc6438>.

[RFC7210]

Housley, R., Polk, T., Hartman, S., and D. Zhang, "Database of Long-Lived Symmetric Cryptographic Keys", RFC 7210, DOI 10.17487/RFC7210, April 2014, <https://www.rfc-editor.org/info/rfc7210>.

[RFC7497]

Morton, A., "Rate Measurement Test Protocol Problem Statement and Requirements", RFC 7497, DOI 10.17487/RFC7497, April 2015, <https://www.rfc-editor.org/info/rfc7497>.

[RFC7680]

Almes, G., Kalidindi, S., Zekauskas, M., and A. Morton, Ed., "A One-Way Loss Metric for IP Performance Metrics (IPPM)", STD 82, RFC 7680, DOI 10.17487/RFC7680, January 2016, <https://www.rfc-editor.org/info/rfc7680>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8446]

Rescorla, E., "The Transport Layer Security (TLS) Protocol Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018, <https://www.rfc-editor.org/info/rfc8446>.

[RFC8468]

Morton, A., Fabini, J., Elkins, N., Ackermann, M., and V. Hegde, "IPv4, IPv6, and IPv4-IPv6 Coexistence: Updates for the IP Performance Metrics (IPPM) Framework", RFC 8468, DOI 10.17487/RFC8468, November 2018, <https://www.rfc-editor.org/info/rfc8468>.

[RFC9097]

Morton, A., Geib, R., and L. Ciavattone, "Metrics and Methods for One-Way IP Capacity", RFC 9097, DOI 10.17487/RFC9097, November 2021, <https://www.rfc-editor.org/info/rfc9097>.

[RFC9147]

Rescorla, E., Tschofenig, H., and N. Modadugu, "The Datagram Transport Layer Security (DTLS) Protocol Version 1.3", RFC 9147, DOI 10.17487/RFC9147, April 2022, <https://www.rfc-editor.org/info/rfc9147>.

13.2. Informative References

[CBC]

Dworkin, M., "NIST Special Publication 800-38A: Recommendation for Block Cipher Modes of Operation: Methods and Techniques, U.S. National Institute of Standards and Technology", December 2001, <csrc.nist.gov/publications/detail/sp/800-38a/final>.

[copycat]

Edleine, K., Kuhlewind, K., Trammell, B., and B. Donnet, "copycat: Testing Differential Treatment of New Transport Protocols in the Wild (ANRW '17)", 15 July 2017, <https://irtf.org/anrw/2017/anrw17-final5.pdf>.

[LS-SG12-A]

12, I. S., "LS - Harmonization of IP Capacity and Latency Parameters: Revision of Draft Rec. Y.1540 on IP packet transfer performance parameters and New Annex A with Lab Evaluation Plan", May 2019, <https://datatracker.ietf.org/liaison/1632/>.

[LS-SG12-B]

12, I. S., "LS on harmonization of IP Capacity and Latency Parameters: Consent of Draft Rec. Y.1540 on IP packet transfer performance parameters and New Annex A with Lab & Field Evaluation Plans", March 2019, <https://datatracker.ietf.org/liaison/1645/>.

[RFC2544]

Bradner, S. and J. McQuaid, "Benchmarking Methodology for Network Interconnect Devices", RFC 2544, DOI 10.17487/RFC2544, March 1999, <https://www.rfc-editor.org/info/rfc2544>.

[RFC3148]

Mathis, M. and M. Allman, "A Framework for Defining Empirical Bulk Transfer Capacity Metrics", RFC 3148, DOI 10.17487/RFC3148, July 2001, <https://www.rfc-editor.org/info/rfc3148>.

[RFC3610]

Whiting, D., Housley, R., and N. Ferguson, "Counter with CBC-MAC (CCM)", RFC 3610, DOI 10.17487/RFC3610, September 2003, <https://www.rfc-editor.org/info/rfc3610>.

[RFC4656]

Shalunov, S., Teitelbaum, B., Karp, A., Boote, J., and M. Zekauskas, "A One-way Active Measurement Protocol (OWAMP)", RFC 4656, DOI 10.17487/RFC4656, September 2006, <https://www.rfc-editor.org/info/rfc4656>.

[RFC5136]

Chimento, P. and J. Ishac, "Defining Network Capacity", RFC 5136, DOI 10.17487/RFC5136, February 2008, <https://www.rfc-editor.org/info/rfc5136>.

[RFC5357]

Hedayat, K., Krzanowski, R., Morton, A., Yum, K., and J. Babiarz, "A Two-Way Active Measurement Protocol (TWAMP)", RFC 5357, DOI 10.17487/RFC5357, October 2008, <https://www.rfc-editor.org/info/rfc5357>.

[RFC6815]

Bradner, S., Dubray, K., McQuaid, J., and A. Morton, "Applicability Statement for RFC 2544: Use on Production Networks Considered Harmful", RFC 6815, DOI 10.17487/RFC6815, November 2012, <https://www.rfc-editor.org/info/rfc6815>.

[RFC7312]

Fabini, J. and A. Morton, "Advanced Stream and Sampling Framework for IP Performance Metrics (IPPM)", RFC 7312, DOI 10.17487/RFC7312, August 2014, <https://www.rfc-editor.org/info/rfc7312>.

[RFC7594]

Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., Aitken, P., and A. Akhter, "A Framework for Large-Scale Measurement of Broadband Performance (LMAP)", RFC 7594, DOI 10.17487/RFC7594, September 2015, <https://www.rfc-editor.org/info/rfc7594>.

[RFC7799]

Morton, A., "Active and Passive Metrics and Methods (with Hybrid Types In-Between)", RFC 7799, DOI 10.17487/RFC7799, May 2016, <https://www.rfc-editor.org/info/rfc7799>.

[RFC8337]

Mathis, M. and A. Morton, "Model-Based Metrics for Bulk Transport Capacity", RFC 8337, DOI 10.17487/RFC8337, March 2018, <https://www.rfc-editor.org/info/rfc8337>.

[RFC8762]

Mirsky, G., Jun, G., Nydell, H., and R. Foote, "Simple Two-Way Active Measurement Protocol", RFC 8762, DOI 10.17487/RFC8762, March 2020, <https://www.rfc-editor.org/info/rfc8762>.

[RFC8972]

Mirsky, G., Min, X., Nydell, H., Foote, R., Masputra, A., and E. Ruffini, "Simple Two-Way Active Measurement Protocol Optional Extensions", RFC 8972, DOI 10.17487/RFC8972, January 2021, <https://www.rfc-editor.org/info/rfc8972>.

[TR-471]

Morton, A,, Editor., "Broadband Forum TR-471: IP Layer Capacity Metrics and Measurement, Issue 3", December 2022, <https://www.broadband-forum.org/technical/download/TR-471.pdf>.

[udpst]

udpst Project Collaborators, "UDP Speed Test Open Broadband project", December 2020, <https://github.com/BroadbandForum/obudpst>.

[Y.1540]

Y.1540, I. R., "Internet protocol data communication service - IP packet transfer and availability performance parameters", December 2019, <https://www.itu.int/rec/T-REC-Y.1540-201912-I/en>.

[Y.Sup60]

Morton, A., Rapporteur., "Recommendation Y.Sup60, (09/20) Interpreting ITU-T Y.1540 maximum IP-layer capacity measurements", 11 September 2020, <https://www.itu.int/rec/T-REC-Y.Sup60/en>.