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 additional authentication during the Data phase: applicable only to the Status Feedback messages.¶
3. An OPTIONAL unauthenticated mode for all messages.¶
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.¶

The requirements below refer to the PDUs in the sections that follow, primarily the authUnixTime field and the authDigest field. 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 SHALL 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 dummy packet to the client with the ephemeral port selected by the server and communicated to the client in the Test Setup Response. The dummy packet 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 dummy packet operation 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 control (well-known) 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 uses the watchdog timeout (for a no-traffic warning) and a longer test termination timeout.¶

Note: In version 9 and 10, 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 message PDU SHALL be organized as follows:¶

        uint16_t controlId;   // Control ID = 0xACE1
        uint16_t protocolVer; // Protocol version = 10
        uint8_t cmdRequest;   // Command request (=1 for Request)
        uint8_t cmdResponse;  // Command response (=0 for Request)
        uint16_t maxBandwidth;// Required max. bit rate for the test
        uint16_t testPort;    // Test port on server  (=0 for Request)
        uint8_t modifierBitmap;// Modifier bitmap
        uint8_t authMode;     // Authentication mode (includes encryption)
        uint16_t testSessionId; // a pseudo-random number, see below.
        uint8_t keyId;        // localKeyName, the numeric key identifier
                                 in the shared Key table
        uint8_t reserved;     // reserved octet
        uint32_t authUnixTime;// Authentication time stamp
        unsigned char authDigest[AUTH_DIGEST_LENGTH] // 32 oct, also IV

Figure 1 Test Setup PDU with Request fields populated, others explained below¶

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          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  cmdRequest   | cmdResponse   |         maxBandwidth          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           testPort            |modifierBitmap |   authMode    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       testSessionId           |     keyId     |   reserved    |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         authUnixTime                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
|                                                               |
|                                                               |
|          authDigest[AUTH_DIGEST_LENGTH](256 bits)             |
|                               or                              |
| Initialization Vector (IV)(up to 256 bits, remaining bits MBZ)|
|                                                               |
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 2 Test Setup Message PDU Format¶

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 a configured limit.¶

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

0x01

Do not use Jumbo Frames above sending rates of 1Gbps¶

0x02

Use Traditional MTU (1500 bytes with IP-header)¶

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

testSessionId: This is a pseudo-random number used with authentication or encryption. The client SHALL select an identifier (ID) for the test session which is unlikely to match values used by other clients or previous sessions of the local client (e.g., the software's process ID or ephemeral source port number). Note: it is even more unlikely to have collisions between two clients that accidentaly choose the same testSessionID if the authUnixTime is also stored with the testSessionID as a pair.¶

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

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

0:

OPTIONAL unauthenticated mode¶

1:

REQUIRED authentication for Control phase¶

2:

OPTIONAL authentication for Data phase, in the Status Feedback PDU (added to Mode 1 requirements)¶

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

authDigest or Initialization Vector field: In Authenticated mode, this field contains the authDigest from the SHA-256 function. In Partial Encrypted mode, this field begins with the Initialization Vector (IV) bits and the remaining (unused) bits are MBZ.¶

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

        uint16_t controlId;   // Control ID = 0xACE1
        uint16_t protocolVer; // Protocol version = 10
        uint8_t cmdRequest;   // Command request = 2 (reply)
        uint8_t cmdResponse;  // Command response = <see table below>
        uint16_t maxBandwidth;// Required bandwidth
        uint16_t testPort;    // Test port on server(available port in Resp)
        uint8_t modifierBitmap;// Modifier bitmap (see table below)
        uint8_t authMode;     // Authentication mode
        uint16_t testSessionId;    // client-selected pseudo-random number
                                      for the test session
        uint8_t keyId;        // localKeyName, an index to the
                                 shared Key table
        uint8_t reserved;     // reserved octet
        uint32_t authUnixTime;// Authentication time stamp
        unsigned char authDigest[AUTH_DIGEST_LENGTH] //32 octets, also IV

cmdResponse Code Field: Command Server Response Codes (CSRP) (decimal)
CHSR_CRSP_NONE     0 = None (value used by client in Request)
CHSR_CRSP_ACKOK    1 = Acknowledgement
CHSR_CRSP_BADVER   2 = Bad Protocol Version
CHSR_CRSP_BADJS    3 = Invalid Jumbo datagram option
CHSR_CRSP_AUTHNC   4 = Unexpected Authentication in Setup Request
CHSR_CRSP_AUTHREQ  5 = Authentication missing in Setup Request
CHSR_CRSP_AUTHINV  6 = Invalid authentication method
CHSR_CRSP_AUTHFAIL 7 = Authentication failure
CHSR_CRSP_AUTHTIME 8 = Authentication time is invalid in Setup Request
CHSR_CRSP_NOMAXBW  9  = No Maximum test Bit rate specified
CHSR_CRSP_CAPEXC   10 = Server Maximum Bit rate exceeded
CHSR_CRSP_BADTMTU  11 = MTU option does not match Server

maxBandwidth Field MSB Code Bit:
CHSR_USDIR_BIT 0x8000 Bandwidth upstream direction bit, Set for Upstream

modifierBitmap Code Field: Setup
CHSR_JUMBO_STATUS    0x01 = set to use Jumbo datagram sizes above 1Gbps
CHSR_TRADITIONAL_MTU 0x02 = set to use datagrams for 1500 byte packets

Decimal values
2 = Bad Protocol Version
3 = Invalid Jumbo datagram option
5 = Authentication missing in Setup Request
4 = Unexpected Authentication in Setup Request
6 = Invalid authentication method (SHA-256 not used)
7 = Authentication failure (both shared secret and time)
8 = Authentication time is invalid in Setup Request (replay attack)
9  = No Maximum test Bit rate specified
10 = Server Maximum Bit rate exceeded
11 = MTU option does not match Server

        uint16_t controlId;   // Control ID = 0xACE1
        uint16_t protocolVer; // Protocol version = 10
        uint8_t cmdRequest;   // Command request = 2 (reply)
        uint8_t cmdResponse;  // Command response = 1 (ACK)
        uint16_t maxBandwidth;// Required bandwidth (added in v9)
        uint16_t testPort;    // Test port on server
                                 (available port in Response)
        uint8_t modifierBitmap;// Modifier bitmap (see table below)
        uint8_t authMode;     // Authentication mode
        uint16_t testSessionId;    // client-selected pseudo-random
                                      number for the test session
        uint8_t keyId;        // localKeyName, an index to the
                                 shared Key table
        uint8_t reserved;     // reserved octet
        uint32_t authUnixTime;// Authentication time stamp
        unsigned char authDigest[AUTH_DIGEST_LENGTH] // 32 octets
        uint8_t keyId;        // localKeyName, a numeric identifier of
                                 a key in the shared Key table
        uint8_t reserved;     // reserved octet
        uint32_t authUnixTime;// Authentication time stamp
        unsigned char authDigest[AUTH_DIGEST_LENGTH] //32 octets,also IV

    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          |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |  cmdRequest   | cmdResponse   |           reserved            |
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

5.3. Setup Response Processing at the Client

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

• process/validate the response message by checking the authDigest if operating in one of the Authenticated modes as prescribed in Section 4.2.2, or¶
• validate and decrypt the response message using the method prescribed in Section 4.2.4 if operating in the Partial Encryption mode,¶

and then proceed to evaluate the other fields in the protocol, beginning with the protocol version, the controlID (to validate the type of message, Test Setup), cmdRequest for the role of the message (SHOULD be 2, Test Setup Response), the maxBandwidth requested for the test (if in use), and the modifierBitmap for use of options such as Jumbo datagram status and traditional MTU (1500 bytes). The value in the authUnixTime field is a 32-bit time stamp and a 5 minute tolerance window (+/- 2.5 minutes) SHALL be used (if in one of the Authenticated or Encrypted modes) to distinguish a subsequent replay of a Test Setup Response. Replay of most other fields would remain valid if there was no authUnixTime field in the PDU, although the testSessionId MUST be unique as well. The authUnixTime is covered by the authDigest hash or encrypted, as specified earlier.¶

The authUnixTime field is expected to be MBZ in unauthenticated mode.¶

IF the cmdResponse value indicates an error (values >1) the client SHALL display/report a relevant message to the user or management process and exit. If the client receives a Command Server Response code (CRSP) that is not equal to one of the codes defined above, then the client MUST terminate the connection and terminate operation of the current Setup Request. If the Command Server Response code (CRSP) value indicates success (cmdResponse=1) 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.¶

6.1. Client Generates Test Activation Request

Upon a successful setup exchange, the client SHALL then compose and send the Test Activation Request to the UDP port number the server communicated in the Test Setup Response (the new ephemeral port, and not the well-known port).¶

The client SHALL compose Test Activation Request as follows:¶

        uint16_t controlId;          // Control ID = 0xACE2
        uint16_t protocolVer;        // Protocol version = 10
        uint8_t cmdRequest;          // Command request, 1 = upstream,
                                        2 = downstream
        uint8_t cmdResponse;         // Command response(set to 0 by client)
        uint16_t lowThresh;          // Low delay variation threshold
        uint16_t upperThresh;        // Upper delay variation threshold
        uint16_t trialInt;           // Status feedback/trial interval (ms)
        uint16_t testIntTime;        // Test interval time (sec) (duration, T)
        uint8_t subIntPeriod;        // Sub-interval period (sec)
        uint8_t ipTosByte;           // IP ToS byte for testing
        uint16_t srIndexConf;        // Configured sending rate index
                                        (see Note below)
        uint8_t useOwDelVar;         // Use one-way delay instead of RTT
        uint8_t highSpeedDelta;      // High-speed row adjustment delta
        uint16_t slowAdjThresh;      // Slow rate adjustment threshold
        uint16_t seqErrThresh;       // Sequence error threshold
        uint8_t ignoreOooDup;        // Ignore Out-of-Order/Duplicate
                                        datagrams
        uint8_t modifierBitmap;      // Modifier bitmap
        uint8_t rateAdjAlgo;         // Rate adjustment algo.
        uint8_t reserved1;           // reserved octet (alignment)
        MBZ 28 Octets
        uint16_t testSessionId; // a pseudo-random number, see below.
        uint8_t keyId;          // localKeyName, a numeric identifier of
                                   a key in the shared Key table
        uint8_t reserved2;      // reserved octet (alignment)
        uint32_t authUnixTime;  // Authentication time stamp
        unsigned char authDigest[AUTH_DIGEST_LENGTH] // 32 oct, also IV


Control Header Test Activation Command Request Values:
CHTA_CREQ_NONE      0 = No Request
CHTA_CREQ_TESTACTUS 1 = Request test in Upstream direction (client to
                        server, client in the role of sending test packets)
CHTA_CREQ_TESTACTDS 2 = Request test in Downstream direction (server to
                        client, client's role is receiving test packets)

modifierBitmap Code Field: Test Activation
CHTA_SRIDX_ISSTART 0x01 = Set when srIndexConf IS START rate for search
CHTA_RAND_PAYLOAD  0x02 = Set for RANDOMIZED UDP payload

rateAdjAlgo Values:
CHTA_RA_ALGO_B   = 0              // 0 = Algo. B, allows Algo. expansion
CHTA_RA_ALGO_MIN = CHTA_RA_ALGO_B // Limit check (with Algo B)
CHTA_RA_ALGO_MAX = CHTA_RA_ALGO_C// Limit check (with Algo C)

Control Header Test Activation Command Response Values:
CHTA_CRSP_NONE     0 = Used by client when making a Request
CHTA_CRSP_ACKOK    1 = Used by Server in affirmative Response
CHTA_CRSP_BADPARAM 2 = Used by Server to indicate an error;
                       bad parameter; reject;

Figure 7 Organization/Definitions of Client Test Activation Request¶

The content of many of the unique fields in Figure 7 is defined above, or defined in Section 4 of [RFC9097] and Appendix A of [RFC9097]. Additional definitions are given below.¶

srIndexConf

srIndexConf is the Send Rate table index of the configured fixed or starting send rate (depending on whether CHTA_SRIDX_ISSTART is cleared or set respectively).¶

The UDP PDU format of the Test Activation Request is 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          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  cmdRequest   | cmdResponse   |           lowThresh           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         upperThresh           |           trialInt            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         testIntTime           | subIntPeriod  |  ipTosByte    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         srIndexConf           |  useOwDelVar  |highSpeedDelta |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         slowAdjThresh         |         seqErrThresh          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | ignoreOooDup  |modifierBitmap |  rateAdjAlgo  |   reserved1   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                          MBZ (28 octets)                      .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       testSessionId           |     keyId     |   reserved2   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         authUnixTime                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   |                                                               |
   |          authDigest[AUTH_DIGEST_LENGTH](256 bits)             |
   |                               or                              |
   | Initialization Vector (IV)(up to 256 bits, remaining bits MBZ)|
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: The 28 MBZ octets are replaced by the Send Rate Structure
in a Test Activation Response for an upstream test.

Figure 8 Test Activation Request PDU Format¶

The client SHALL apply the configuration for¶

• testPort¶
• modifierBitmap¶
• authMode¶
• testSessionID¶
• keyID¶
• and the remaining fields are populated based on default values or command-line options¶

requested in the Test Setup Request and communicated/confirmed by the server in the Test Setup Response.¶

6.2. Server Processes Test Activation Request and Generates Response

After the server receives the Test Activation Request on the new connection, it MUST choose to accept, ignore or modify any of the test parameters.¶

        uint32_t txInterval1; // Transmit interval (us)
        uint32_t udpPayload1; // UDP payload (bytes)
        uint32_t burstSize1;  // UDP burst size per interval
        uint32_t txInterval2; // Transmit interval (us)
        uint32_t udpPayload2; // UDP payload (bytes)
        uint32_t burstSize2;  // UDP burst size per interval
        uint32_t udpAddon2;   // UDP add-on (bytes)

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-|-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          txInterval1                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          udpPayload1                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          burstSize1                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          txInterval2                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          udpPayload2                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          burstSize2                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          udpAdddon2                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

6.3. Client Processes Test Activation Response

When the client receives the Test Activation Response, it SHALL:¶

• process/validate the response message by checking the authDigest if operating in one of the Authenticated modes as prescribed in Section 4.2.2, or¶
• validate and decrypt the response message using the method prescribed in Section 4.2.4 if operating in the Partial Encryption mode,¶

and then proceed to evaluate the other fields in the protocol.¶

When the client receives the (vetted) Test Activation Response, it first checks the command response value.¶

If the client receives a Test Activation Command Response value that indicates an error, the client SHALL display/report a relevant message to the user or management process and exit.¶

If the client receives a Test Activation Command Response value that is not equal to one of the codes defined above, then the client MUST terminate the connection and terminate operation of the current Setup Request.¶

If the client receives a Test Activation Command Response value that indicates success (CHTA_CRSP_ACKOK) the client SHALL update its configuration to use any test parameters modified by the server.¶

Next, the client SHALL prepare its connection for either an upstream test with dual timers set to send load PDUs (based on the starting transmission parameters sent by the server), OR a downstream test with a single timer to send status PDUs at the specified interval.¶

Then, the client SHALL stop the test initiation timer, set a new time-out value for the watchdog timer and start the timer (to detect if the server goes quiet).¶

The connection is now ready for testing.¶

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 receiving the load PDUs and sending status messages to communicate the traffic measurements at the receiver (or to control the receiver).¶

The watchdog timer at the receiver SHALL be reset each time a test PDU is received. See non-graceful test stop in Section 8 for handling the watchdog/NOTRAFFIC time-out 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 based on the feedback in its received status 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 messages (and not referencing a sending rate table row). 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 adjustment algorithm which evaluates measurements, either its local measurements or the contents of received 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, low delay variation), resulting in sending rate increase.¶
2. When there are low impairments present (no sequence errors but higher levels of delay variation), so the same sending rate is retained.¶
3. When the impairment levels are above the thresholds set for this purpose and "congestion" is inferred, resulting in 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 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 below:¶

uint16_t srIndexConf; // Configured sending rate index¶

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

The Load PDU SHALL have the following format and field definitions:¶

        uint16_t loadId; // Load ID (=0xBEEF for the Load PDU)
        uint8_t testAction;  // Test action (= 0x00 normally,
                                until test stop)
        uint8_t rxStopped;   // Receive traffic stopped indicator (BOOL)
        uint32_t lpduSeqNo;  // Load PDU sequence number (starts at 1)
        uint16_t udpPayload; // UDP payload LENGTH (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

Test Action Codes
TEST_ACT_TEST  0  // normal
TEST_ACT_STOP1 1  // normal stop at end of test: server sends in STATUS or Test PDU
TEST_ACT_STOP2 2  // ACK of STOP1: sent by client in STATUS or Test PDU

The Test Load UDP PDU format is as follows (big-endian AB):¶

Figure 11 Load PDU Field Definitions¶

   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                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .         udpPayloadContent = udpPayload minus 28 octets        .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .

Figure 12 Load PDU Format¶

The field udpPayloadContent is all zeroes, all ones, or a pseudo random binary sequence.¶

7.2. Status PDU

The receiver SHALL send a Status PDU to the sender during a test at the configured feedback interval.¶

The watchdog timer at the test PDU sender SHALL be reset each time a Status PDU is received. See non-graceful test stop in Section 8 for handling the watchdog/NOTRAFFIC time-out 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 PDU SHALL have the following format and field definitions:¶

        uint16_t statusId;  // Status ID = 0xFEED
        uint8_t testAction; // Test action
        uint8_t rxStopped;  // Receive traffic stopped indicator (BOOL)
        uint32_t spduSeqNo; // Status PDU sequence number (starts at 1)
        //
        struct sendingRate srStruct; // Sending Rate Structure (28 octets)
        //
        uint32_t subIntSeqNo;      // Sub-interval sequence number
        struct subIntStats sisSav; // Sub-interval Saved Stats Structure
                                      (52 octets)
        //
        uint32_t seqErrLoss; // Loss sum
        uint32_t seqErrOoo;  // Out-of-Order sum
        uint32_t seqErrDup;  // Duplicate sum
        //
        uint32_t clockDeltaMin; // Clock delta minimum (either RTT
                                   or 1-way delay)
        uint32_t delayVarMin;   // Delay variation minimum
        uint32_t delayVarMax;   // Delay variation maximum
        uint32_t delayVarSum;   // Delay variation sum
        uint32_t delayVarCnt;   // Delay variation count
        uint32_t rttMinimum;    // Minimum round-trip time sampled
        uint32_t rttSample;     // Last round-trip time sample
        uint8_t delayMinUpd;    // Delay minimum(s) updated observed,
                                   communicated in both directions.
        uint8_t reserved2;      // (alignment)
        uint16_t reserved3;     // (alignment)
        //
        uint32_t tiDeltaTime;   // Trial interval time duration, usec
        uint32_t tiRxDatagrams; // Trial interval receive datagram count
        uint32_t tiRxBytes;     // Trial interval receive byte count
        //
        uint32_t spduTime_sec;  // Send time of this status PDU, sec
        uint32_t spduTime_nsec; // Send time of this status PDU, nanosec

Figure 13 Status PDU Field Definitions¶

The Status (UDP payload) PDUs format is 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          statusId             |   testAction  | rxStopped     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           spduSeqNo                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .               Sending Rate Structure (28 octets)              .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          subIntSeqNo                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .        Sub-interval Saved Stats Structure  (52 octets)        .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           seqErrLoss                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           seqErrOoo                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           seqErrDup                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         clockDeltaMin                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          delayVarMin                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          delayVarMax                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          delayVarSum                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          delayVarCnt                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          rttMinimum                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           rttSample                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |  delayMinUpd  |   reserved2   |           reserved3           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          tiDeltaTime                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         tiRxDatagrams                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           tiRxBytes                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         spduTime_sec                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         spduTime_nsec                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                   Authentication Fields (40 octets)           .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 14 Status PDU Format¶

Note that the Sending Rate Structure (28 octets) is defined in the Test Activation section.¶

More details on the Status PDU measurement fields are provided in [RFC9097].¶

Also note that the Sub-interval Saved Stats Structure (52 octets) SHALL be included (and populated as required when the server is in the receiver role in an upstream test) as defined below.¶

The Sub-interval saved statistics structure for received traffic measurements SHALL be organized and formatted as follows:¶

        uint32_t rxDatagrams; // Received datagrams
        uint32_t rxBytes;     // Received bytes
        uint32_t deltaTime;   // Time delta
        uint32_t seqErrLoss;  // Loss sum
        uint32_t seqErrOoo;   // Out-of-Order sum
        uint32_t seqErrDup;   // Duplicate sum
        uint32_t delayVarMin; // Delay variation minimum
        uint32_t delayVarMax; // Delay variation maximum
        uint32_t delayVarSum; // Delay variation sum
        uint32_t delayVarCnt; // Delay variation count
        uint32_t rttMinimum;  // Minimum round-trip time
        uint32_t rttMaximum;  // Maximum round-trip time
        uint32_t accumTime;   // Accumulated time
----------------------------------------------------------------------------

   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                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 15 Saved Interval Statistics Structure, Definitions and Format¶

Note that the 52 octet saved statistics structure above has slight differences from the 40 octets that follow in the status feedback PDU, particularly the time-related fields.¶

The Authentication (and Encryption) Fields appear at the end of the Status PDU and SHALL be organized as follows:¶

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       testSessionId           |     keyId     |   reserved4   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         authUnixTime                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                                                               |
   |                                                               |
   |          authDigest[AUTH_DIGEST_LENGTH](256 bits)             |
   |                               or                              |
   | Initialization Vector (IV)(up to 256 bits, remaining bits MBZ)|
   |                                                               |
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Figure 16 Organization of Authentication Field Format¶

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:¶

• add the authUnixTime and calculate the authDigest for the response message using the method prescribed in Section 4.2.2 if operating in one of the Authenticated modes, or¶
• add the authUnixTime and encrypt the request message using the method prescribed in Section 4.2.4 if operating in the Partial Encryption mode,¶

and then sends the Status PDU message to the other end-point.¶

Upon receiving a Status Feedback PDU which has been validated and vetted according to the mode of operation (Authenticated mode 2 or Partial Encryption mode 3), the server SHALL¶

• perform calculations required by the selected Load adjustment algorithm (see Appendix A of [RFC9097] or Annex B of [TR-471]) and adjust its sending rate, or¶
• signal that the client adjust its sending rate in its role as as sender (via the Status PDU Sending Rate Structure).¶

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

9.2. Running Code

This section is for the benefit of the Document Shepherd's form, and will be deleted prior to publication.¶

Much of the development of the method and comparisons with existing methods conducted at IETF Hackathons and elsewhere have been based on the example udpst Linux measurement tool (which is a working reference for further development) [udpst]. The current project:¶

• is a utility that can function as a client or server daemon¶
• requires a successful client-initiated setup handshake between cooperating hosts and allows firewalls to control inbound unsolicited UDP which either go to a control port [expected and w/authentication] or to ephemeral ports on the client and server that are only created as needed.¶
• permits firewalls protecting each host to continue to do their job normally. This aspect is similar to many other test utilities available. The firewall at the server will need to open a pin-hole for the control port, the dynamic ephemeral port in response to the "dummy packet" (or open a limited range of ephemeral ports) to complete the second control exchange: Test Activation, where the client communicates to the server on an ephemeral destination port *assigned by the server*.¶
• has Authentication modes that require a secret key included in the SHA-256 HMAC calculation which utilizes the OpenSSL HMAC macro (https://www.openssl.org/docs/man3.0/man3/HMAC.html).¶
• is written in C, and built with gcc (release 9.3) and its standard run-time libraries¶
• allows configuration of most of the parameters described in Sections 4 through 8.¶
• supports IPv4 and IPv6 address families.¶
• supports IP-layer packet marking.¶
• supports the upstream and downstream interface byte counter measurements at the client, and the results are available in the Text and JSON output at the end of a test.¶

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://www.ietf.org/archive/id/draft-ietf-ippm-capacity-metric-method-12.txt>.

[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

[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>.

[GCM]

Dworkin, M., "NIST Special Publication 800-38D: Recommendation for Block Cipher Modes of Operation: Galois/Counter Mode (GCM) and GMAC, U.S. National Institute of Standards and Technology", November 2007, <https://csrc.nist.gov/publications/detail/sp/800-38d/final>.

[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>.