Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

RFC 9097 §8: Method of Measurement

The 49 Requirements of RFC 9097 §8, each quoted from the RFC with its state and the tests that prove it. Conformance explains the states.

StateRequirements
Tested37
Deviation6
Operational6

RFC9097-8-1

Tested

It is REQUIRED per the architecture of the method that two cooperating hosts operate in the roles of Src (test packet Sender) and Dst (Receiver) with a measured path and return path between them.

Note: Load Sender and Load Receiver.

Proving tests:

RFC9097-8-2

Tested

The duration of a test, Parameter I, MUST be constrained in a production network, since this is an active test method and it will likely cause congestion on the path from the Src host to the Dst host during a test.

Note: testIntTime’s maximum.

Proving tests:

RFC9097-8.1-1

Operational

The algorithm described in this section MUST NOT be used as a general Congestion Control Algorithm (CCA).

Note: RFC 9946 section 5.1 item 1 says the same.

RFC9097-8.1-2

Tested

A table SHALL be pre-built (by the test administrator), defining all the offered load rates that will be supported (R1 through Rn, in ascending order, corresponding to indexed rows in the table).

Note: Sending Rate Table.

Proving tests:

RFC9097-8.1-3

Deviation

It is RECOMMENDED that rates begin with 0.5 Mbps at index zero, use 1 Mbps at index one, and then continue in 1 Mbps increments to 1 Gbps.

Note: Sending Rate Table.

Recorded in row-zero-below-half-a-megabit.

RFC9097-8.1-4

Deviation

Above 1 Gbps, and up to 10 Gbps, it is RECOMMENDED that 100 Mbps increments be used.

Note: Sending Rate Table.

Recorded in table-steps-above-1-gbps.

RFC9097-8.1-5

Deviation

Above 10 Gbps, increments of 1 Gbps are RECOMMENDED.

Note: Sending Rate Table.

Recorded in table-steps-above-1-gbps.

RFC9097-8.1-L1

Tested

A higher initial IP-Layer Sender Bit Rate might be configured when the test operator is certain that the Maximum IP- Layer Capacity is well above the initial IP-Layer Sender Bit Rate and factors such as test duration and total test traffic play an important role.

Note: A Search Test may start at a requested srIndexConf row.

Proving tests:

RFC9097-8.1-6

Tested

The sending rate table SHOULD bracket the Maximum Capacity where it will make measurements, including constrained rates less than 500 kbps if applicable.

Note: Sending Rate Table.

Proving tests:

RFC9097-8.1-L2

Tested

Each rate is defined as datagrams of size ss, sent as a burst of count cc, each time interval tt (the default for tt is 100 microsec, a likely system tick interval).

Note: Sending Rate Structure: txInterval, udpPayload, burstSize.

Proving tests:

RFC9097-8.1-L3

Tested

While it is advantageous to use datagrams of as large a size as possible, it may be prudent to use a slightly smaller maximum that allows for secondary protocol headers and/or tunneling without resulting in IP-Layer fragmentation.

Note: Server MTU; the 1250-byte default (RFC9946-6.1-8).

Proving tests:

RFC9097-8.1-L4

Tested

At the beginning of a test, the Sender begins sending at rate R1 and the Receiver starts a feedback timer of duration FT (while awaiting inbound datagrams).

Note: Trial Interval.

Proving tests:

RFC9097-8.1-L5

Tested

As datagrams are received, they are checked for sequence number anomalies (loss, out-of-order, duplication, etc.) and the delay range is measured (one-way or round-trip).

Note: Sequence Errors and delay variation (useOwDelVar).

Proving tests:

RFC9097-8.1-L6

Tested

This information is accumulated until the feedback timer FT expires and a status feedback message is sent from the Receiver back to the Sender, to communicate this information.

Note: Status PDU.

Proving tests:

RFC9097-8.1-L7

Tested

The accumulated statistics are then reset by the Receiver for the next feedback interval.

Proving tests:

RFC9097-8.1-L8

Tested

As feedback messages are received back at the Sender, they are evaluated to determine how to adjust the current offered load rate (Rx).

Proving tests:

RFC9097-8.1-L9

Tested

If the feedback indicates that no sequence number anomalies were detected AND the delay range was below the lower threshold, the offered load rate is increased.

Note: Clean Interval.

Proving tests:

RFC9097-8.1-L10

Tested

If congestion has not been confirmed up to this point (see below for the method for declaring congestion), the offered load rate is increased by more than one rate setting (e.g., Rx+10).

Note: Fast Mode.

Proving tests:

RFC9097-8.1-L11

Tested

Conversely, if congestion has been previously confirmed, the offered load rate is only increased by one (Rx+1).

Note: Single-Step Mode.

Conformance Records: shallow-queue-search-alternates-at-the-bottleneck.

Proving tests:

RFC9097-8.1-L12

Tested

However, if a rate threshold above a high sending rate (such as 1 Gbps) is exceeded, the offered load rate is only increased by one (Rx+1) in any congestion state.

Conformance Records: fast-mode-stops-at-the-gigabit-row.

Proving tests:

RFC9097-8.1-L13

Tested

If the feedback indicates that sequence number anomalies were detected OR the delay range was above the upper threshold, the offered load rate is decreased.

Note: Errored Interval.

Proving tests:

RFC9097-8.1-7

Tested

The RECOMMENDED threshold values are 10 for sequence number gaps and 30 msec for lower and 90 msec for upper delay thresholds, respectively.

Note: seqErrThresh, lowThresh, upperThresh; RFC 9946 section 5.1 item 6.

Proving tests:

RFC9097-8.1-L14

Tested

Also, if congestion is now confirmed for the first time by the current feedback message being processed, then the offered load rate is decreased by more than one rate setting (e.g., Rx-30).

Note: Congestion Confirmed.

Proving tests:

RFC9097-8.1-L15

Tested

In all other cases, the offered load rate is only decreased by one (Rx-1).

Proving tests:

RFC9097-8.1-L16

Tested

If the feedback indicates that there were no sequence number anomalies AND the delay range was above the lower threshold but below the upper threshold, the offered load rate is not changed.

Note: Hold Interval.

Proving tests:

RFC9097-8.1-L17

Tested

Lastly, the method for inferring congestion is that there were sequence number anomalies AND/OR the delay range was above the upper threshold for three consecutive feedback intervals.

Note: Congestion; slowAdjThresh.

Proving tests:

RFC9097-8.1-8

Tested

The load rate adjustment algorithm MUST include timers that stop the test when received packet streams cease unexpectedly.

Note: ADR 0002; RFC 9946 section 5.1 item 7.

Proving tests:

RFC9097-8.1-9

Tested

The load packet timeout SHALL be reset to the configured value each time a load packet is received.

Note: ADR 0002; RFC 9946 section 5.1 item 8.

Proving tests:

RFC9097-8.1-10

Tested

If the timeout expires, the Receiver SHALL be closed and no further feedback sent.

Note: Load packet timeout. ADR 0002.

Proving tests:

RFC9097-8.1-11

Tested

The feedback message timeout SHALL be reset to the configured value each time a feedback message is received.

Note: ADR 0002; RFC 9946 section 5.1 item 9.

Proving tests:

RFC9097-8.1-12

Tested

If the timeout expires, the Sender SHALL be closed and no further load packets sent.

Note: The Status PDU timeout, RFC 9097’s “feedback message” timeout. ADR 0002.

Proving tests:

RFC9097-8.1-L18

Tested

If no status feedback messages arrive at the Sender for the interval greater than the Lost Status Backoff timeout:

Note: Lost Status Backoff: UDRT + (2+w)*FT, from the last message of any type received.

Proving tests:

RFC9097-8.1-L19

Tested

Beginning when the last message (of any type) was successfully received at the Sender:

Note: Lost Status Backoff timer start.

Proving tests:

RFC9097-8.1-13

Deviation

The offered load SHALL then be decreased, following the same process as when the feedback indicates the presence of one or more sequence number anomalies OR the delay range was above the upper threshold (as described above), with the same load rate adjustment algorithm variables in their current state.

Note: Lost Status Backoff.

Recorded in no-lost-status-backoff-upstream.

Conformance Records: lost-status-backoff-is-an-errored-interval.

Proving tests:

RFC9097-8.1-14

Tested

The RECOMMENDED initial value for w is 0, taking a Round-Trip Time (RTT) of less than FT into account.

Note: Lost Status Backoff.

Conformance Records: lost-status-backoff-initial-w.

Proving tests:

RFC9097-8.1-L20

Tested

A test with an RTT longer than FT is a valid reason to increase the initial value of w appropriately.

Note: Lost Status Backoff.

Conformance Records: lost-status-backoff-initial-w.

Proving tests:

RFC9097-8.1-15

Tested

Variable w SHALL be incremented by one whenever the Lost Status Backoff timeout is exceeded.

Note: Lost Status Backoff.

Proving tests:

RFC9097-8.1-L21

Tested

Also, if congestion is now confirmed for the first time by a Lost Status Backoff timeout, then the offered load rate is decreased by more than one rate setting (e.g., Rx-30).

Note: Lost Status Backoff.

Conformance Records: lost-status-backoff-is-an-errored-interval.

Proving tests:

RFC9097-8.1-L22

Tested

In all other cases, the offered load rate is only decreased by one (Rx-1).

Note: Lost Status Backoff.

Proving tests:

RFC9097-8.2-L1

Operational

It is of course necessary to calibrate the equipment performing the IP-Layer Capacity measurement, to ensure that the expected capacity can be measured accurately and that equipment choices (processing speed, interface bandwidth, etc.) are suitably matched to the measurement range.

Note: Deployment of the measurement hosts.

RFC9097-8.2-L2

Operational

Samples exhibiting supra-threshold packet losses or increasing queue occupation require a repeated search and/or test at a reduced fixed Sender rate for Qualification.

Note: The Operator repeats the Test; a Fixed-Rate Test serves for Qualification.

RFC9097-8.3-1

Operational

In general, it is RECOMMENDED to locate test endpoints as close to the intended measured link(s) as practical (for reasons of scale, this is not always possible; there is a limit on the number of test endpoints coming from many perspectives – for example, management and measurement traffic).

Note: Deployment of the measurement hosts.

RFC9097-8.3-2

Tested

The testing operator MUST set a value for the MaxHops Parameter, based on the expected path length.

Note: MaxHops setting; RFC 9946 section 10.

Proving tests:

RFC9097-8.3-3

Tested

Both load packets and status feedback messages MUST contain sequence numbers; this helps with measurements based on those packets.

Note: lpduSeqNo and spduSeqNo; RFC 9946 section 5.1 item 3.

Proving tests:

RFC9097-8.3-4

Deviation

Methods MUST be prepared to provide a short preamble transmission to activate on-demand communications access and to discard the preamble from subsequent test results.

Note: RFC 9946 defines no preamble; OB-UDPST’s JSON reports PreambleDuration 0.

Recorded in no-preamble-transmission.

RFC9097-8.3-5

Operational

If this condition is suspected, alternate configurations SHOULD be used.

Note: A shaper or policer whose burst size exceeds the Burst; the user changes the configuration.

RFC9097-8.3-L1

Tested

Each flow would be controlled using its own implementation of the load rate adjustment (search) algorithm.

Note: Each Test Connection of a Multi-Connection Test runs its own Load Rate Adjustment Algorithm.

Proving tests:

RFC9097-8.3-6

Deviation

The number of concurrent, independent tests of a path SHALL be limited to one.

Note: RFC 9946 section 4.2 says the same.

Recorded in tests-per-source-above-one.

Proving tests:

RFC9097-8.3-L2

Operational

As long as both IPv4 packets and IPv6 packets sent/received are standard-formed, this should be allowed (and the change in header size easily accounted for on a per-packet basis).

Note: Testing a v4-v6 transition mechanism; nothing in udpstp prevents it.

Proving tests: