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 9946 §8: Test Load Stream Transmission and Measurement Status Feedback Messages

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

StateRequirements
Tested55
Deviation2

RFC9946-8.1-1

Tested

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.

Note: srStruct in the Status PDU. Sizes are IPv4-based and an IPv6 Load Sender subtracts 20 bytes (ADR 0004).

Conformance Records: ipv4-based-sending-rate-structure-sizes.

Proving tests:

RFC9946-8.1-2

Tested

When a Load PDU is received, the receiver SHALL do the following: 1. Verify that the size of the message is greater than or equal to the ‘struct loadHdr’ size shown in Figure 9. 2. Validate the checksum for the Load PDU header portion of the total message (as described in Section 5.6) if the optional checkSum field is being utilized. 3. Confirm that the PDU ID is 0xBEEF (Load PDU).

Proving tests:

RFC9946-8.1-3

Tested

If any of the above checks fail, the message SHALL be considered invalid.

Conformance Records: undefined-flags-are-invalid.

Proving tests:

RFC9946-8.1-4

Tested

The watchdog timer at the receiver SHALL be reset each time a valid Load PDU is received (which includes verification of the checkSum, if in use).

Note: Timeouts per ADR 0002.

Conformance Records: receive-timeout-is-final.

Proving tests:

RFC9946-8.1-5

Tested

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

Proving tests:

RFC9946-8.1-6

Deviation

However, when the client is sending Load PDUs in the role of sender, it SHALL use the discrete transmission parameters that were communicated by the server in its periodic Status Feedback messages (and not referencing a Sending Rate Table directly).

Note: srStruct in the Status PDU.

Recorded in sending-rate-structure-sanity-limits, client-keeps-to-its-max-bandwidth.

Conformance Records: ipv4-based-sending-rate-structure-sizes, random-size-flag, sending-rate-structure-only-from-test-status-pdus.

Proving tests:

RFC9946-8.1-7

Tested

The threshold of consecutive feedback intervals SHALL be configurable with a default of 3 intervals.

Note: Fast Mode of algorithm B; slowAdjThresh field (Section 7.1).

Proving tests:

RFC9946-8.1-8

Tested

An OPTIONAL load rate adjustment algorithm (designated C) has been defined in [TR-471].

Note: rateAdjAlgo C (Section 12.3.8).

Proving tests:

RFC9946-8.1-9

Tested

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

Note: Fixed-Rate Tests.

Proving tests:

RFC9946-8.1-10

Tested

The client MAY communicate the desired fixed rate in its Test Activation Request.

Note: srIndexConf without CHTA_SRIDX_ISSTART.

Proving tests:

RFC9946-8.1-11

Tested

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

Note: Figure 8, the Load PDU layout, follows.

Proving tests:

RFC9946-8.1-12

Tested

All outgoing Load or Status PDUs SHALL continue to assert this indication until traffic is received again, or the test is terminated.

Note: rxStopped field.

Conformance Records: receive-timeout-is-final.

Proving tests:

RFC9946-8.1-13

Tested

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

Note: Figure 9’s struct loadHdr follows.

Proving tests:

RFC9946-8.1-L1

Tested

The default algorithm (B; see [Y.1540]) 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.

Note: Load Rate Adjustment Algorithm; its requirements are in Section 5.1.

Proving tests:

RFC9946-8.1-L2

Tested

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.

Note: Fast Mode of algorithm B.

Proving tests:

RFC9946-8.1-L3

Tested

The single-step mode continues after the first inference of “congestion” from measured impairments.

Note: Algorithm B; algorithm C may make a Fast-Mode Retry.

Proving tests:

RFC9946-8.1-L4

Tested

Boolean, 0 or 1, used to indicate to the remote endpoint that local receive traffic (either Load or Status PDUs) has stopped.

Note: rxStopped field.

Proving tests:

RFC9946-8.1-L5

Tested

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

Note: rxStopped field; record rx-stopped-from-half-the-timeout and ADR 0002.

Conformance Records: rx-stopped-from-half-the-timeout.

Proving tests:

RFC9946-8.1-L6

Tested

A four-octet field indicating the Load PDU sequence number (starting at 1).

Note: lpduSeqNo field.

Proving tests:

RFC9946-8.1-L7

Tested

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

Note: udpPayload field.

Conformance Records: received-bytes-from-datagram-length.

Proving tests:

RFC9946-8.1-L8

Tested

This is determined by the Status PDU sequence number (spduSeqNo) in the most recently received Status PDU.

Note: spduSeqErr field.

Conformance Records: spdu-seq-err-is-the-gap-before-the-latest.

Proving tests:

RFC9946-8.1-L9

Tested

Two four-octet fields containing a copy of the most recent spduTime_sec/spduTime_nsec from the last Status PDU received.

Note: spduTime_sec/spduTime_nsec fields of the Load PDU.

Proving tests:

RFC9946-8.1-L10

Tested

Two four-octet fields containing the local send time of the Load PDU.

Note: lpduTime_sec/lpduTime_nsec fields.

Conformance Records: lpdu-time-per-burst.

Proving tests:

RFC9946-8.1-L11

Tested

On the Load PDU sender, it is the number of ms 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).

Note: rttRespDelay field.

Proving tests:

RFC9946-8.1-L12

Tested

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.

Note: rttRespDelay field.

Conformance Records: rtt-sample-rules.

Proving tests:

RFC9946-8.1-L13

Tested

The checksum does not cover the payload content.

Note: checkSum field of the Load PDU.

Proving tests:

RFC9946-8.1-L14

Tested

The calculation is done as the very last step of building the PDU header, with the checkSum field set to zero.

Note: checkSum field of the Load PDU.

Proving tests:

RFC9946-8.1-L15

Tested

All zeroes, all ones, or a pseudorandom binary sequence.

Note: Payload Content; randomized with the Test Activation modifier bit 0x02 (Section 12.3.7).

Proving tests:

RFC9946-8.2-1

Tested

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

Note: The “feedback interval” is the Trial Interval, trialInt.

Conformance Records: status-pdu-grid-from-first-load-pdu.

Proving tests:

RFC9946-8.2-2

Tested

In these cases, the Status PDU SHALL NOT be sent.

Note: Before the first Load PDU arrives.

Proving tests:

RFC9946-8.2-3

Tested

When the Load PDU sender receives a Status PDU message, it SHALL first follow the Message Verification Procedure listed in Section 6.2, Paragraph 2.

Proving tests:

RFC9946-8.2-4

Tested

The watchdog timer at the Load PDU sender SHALL be reset each time a valid Status PDU is received (which includes verification of the checkSum and/or authDigest, if in use).

Note: Timeouts per ADR 0002.

Conformance Records: stale-status-pdus-count-only-as-heard.

Proving tests:

RFC9946-8.2-5

Tested

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

Note: Figure 10, the Status PDU layout, follows.

Proving tests:

RFC9946-8.2-6

Tested

Both sets of statistics SHALL always be populated by the Load PDU receiver, regardless of role (client or server).

Note: sisSav and the Trial Interval fields.

Proving tests:

RFC9946-8.2-7

Tested

This minimum SHALL be kept current (and continuously updated) via each Load PDU received with an updated spduTime_sec/spduTime_nsec.

Note: rttMinimum field.

Proving tests:

RFC9946-8.2-8

Deviation

This value MUST be positive.

Note: rttMinimum field.

Recorded in rtt-minimum-may-be-zero.

RFC9946-8.2-9

Tested

Before an initial value can be established, and because zero is itself valid, it SHALL be set to STATUS_NODEL when communicated in the Status PDU.

Note: rttMinimum field.

Proving tests:

RFC9946-8.2-10

Tested

When a new value is unavailable (possibly due to packet loss), and because zero is itself valid, it SHALL be set to STATUS_NODEL when communicated in the Status PDU.

Note: rttVarSample field.

Proving tests:

RFC9946-8.2-11

Tested

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

Note: Figure 11’s struct subIntStats and struct statusHdr follow.

Proving tests:

RFC9946-8.2-L1

Tested

The authentication and checkSum fields follow the same methodology as with the Setup Request and Response.

Note: Status PDU; Section 6.1.

Proving tests:

RFC9946-8.2-L2

Tested

A four-octet field containing the Status PDU sequence number (starting at 1).

Note: spduSeqNo field.

Conformance Records: stale-status-pdus-count-only-as-heard.

Proving tests:

RFC9946-8.2-L3

Tested

A four-octet field containing the Sub-Interval sequence number (starting at 1) that corresponds to the statistics provided in sisSav, for the last saved (completed) Sub-Interval.

Note: subIntSeqNo field.

Conformance Records: sub-interval-boundaries.

Proving tests:

RFC9946-8.2-L4

Tested

seqErrOoo and seqErrDup are realized by comparing sequence numbers.

Proving tests:

RFC9946-8.2-L5

Tested

A lookback list of the last n sequence numbers received is used as the basis.

Note: seqErrOoo and seqErrDup.

Proving tests:

RFC9946-8.2-L6

Tested

Each Load PDU sequence number is checked against this lookback.

Note: seqErrOoo and seqErrDup.

Proving tests:

RFC9946-8.2-L7

Tested

The number n may depend on the implementation and on typical characteristics of environments, where UDPSTP is deployed (like mobile networks or Wi-Fi).

Note: Lookback length.

Proving tests:

RFC9946-8.2-L8

Tested

Currently, a default sequence number interval of n=32 has been chosen.

Note: Lookback length.

Proving tests:

RFC9946-8.2-L9

Tested

Specifically for seqErrOoo, each successively received higher seqno sets the next-expected seqno to seqno+1, and anything below that is considered out of order (i.e., delayed).

Conformance Records: late-load-pdu-decrement-in-its-own-interval, lpdu-seq-no-modulo-2-32.

Proving tests:

RFC9946-8.2-L10

Tested

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.

Note: delayVarMin/delayVarMax/delayVarSum/delayVarCnt fields.

Conformance Records: ms-rounding-half-up.

Proving tests:

RFC9946-8.2-L11

Tested

Equivalent to the sum of each deltaTime (although in ms) sent in each Status PDU during the test.

Note: accumTime field.

Conformance Records: sub-interval-boundaries.

Proving tests:

RFC9946-8.2-L12

Tested

Obtained by subtracting the send time of each Load PDU (lpduTime_sec/ lpduTime_nsec) from the local time that it was received.

Note: clockDeltaMin field.

Proving tests:

RFC9946-8.2-L13

Tested

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.

Note: clockDeltaMin field.

Proving tests:

RFC9946-8.2-L14

Tested

Otherwise, this value may be negative but still valid for one-way delay variation measurements for the default test duration (default is 10 seconds).

Note: clockDeltaMin field; the RFC gives no encoding for a negative value.

Conformance Records: clock-delta-min-encoding.

Proving tests:

RFC9946-8.2-L15

Tested

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.

Note: rttMinimum field; adjusted by rttRespDelay (RFC9946-8.1-L12).

Conformance Records: rtt-sample-rules.

Proving tests:

RFC9946-8.2-L16

Tested

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: rttVarSample field.

Proving tests:

RFC9946-8.2-L17

Tested

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.

Note: rttVarSample field.

Proving tests:

RFC9946-8.2-L18

Tested

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

Note: delayMinUpd field.

Proving tests: