rfc9946v3.txt   rfc9946.txt 
skipping to change at line 408 skipping to change at line 408
adjustment algorithm for debugging purposes. This may be valuable adjustment algorithm for debugging purposes. This may be valuable
for post-installation or post-repair verification. for post-installation or post-repair verification.
3.2. Handling of and Safeguards Required by Self-Induced Congestion 3.2. Handling of and Safeguards Required by Self-Induced Congestion
Active capacity measurement requires inducing intentional congestion. Active capacity measurement requires inducing intentional congestion.
On paths where the capacity bottleneck is not shared with other On paths where the capacity bottleneck is not shared with other
flows, this self-congestion will be observed as loss and/or delay. flows, this self-congestion will be observed as loss and/or delay.
However, when a path is shared by other flows, the measurement However, when a path is shared by other flows, the measurement
traffic can congest the bottleneck on the path and therefore degrade traffic can congest the bottleneck on the path and therefore degrade
the performance of other flows. Unrestricted use of the tool could the performance of other flows. Unrestricted use of UDPSTP could
lead to traffic starvation and significant issues. lead to traffic starvation and significant issues.
Measurements that generate traffic on shared paths (including Wi-Fi Measurements that generate traffic on shared paths (including Wi-Fi
and Internet paths) need to consider the impact on other traffic. and Internet paths) need to consider the impact on other traffic.
Fixed-rate testing operates without congestion control and therefore Fixed-rate testing operates without congestion control and therefore
must not be executed over other operators' network segments. Fixed- must not be executed over other operators' network segments. Fixed-
rate testing, therefore, is limited to paths within a domain entirely rate testing, therefore, is limited to paths within a domain entirely
managed and operated section-wise and end-to-end by the network managed and operated section-wise and end-to-end by the network
operator performing the measurement. When the risks of disruption to operator performing the measurement. When the risks of disruption to
other flows has been considered, testing could be extended to include other flows has been considered, testing could be extended to include
skipping to change at line 839 skipping to change at line 839
cannot itself reject. cannot itself reject.
* Pre-filtering of incorrectly addressed destination packets, before * Pre-filtering of incorrectly addressed destination packets, before
responding to a source address. responding to a source address.
All of the PDUs exchanged between the client and server support an All of the PDUs exchanged between the client and server support an
optional header checksum that covers the various fields in the UDPSTP optional header checksum that covers the various fields in the UDPSTP
PDU (excluding the payload content of the Load PDU and, to be clear, PDU (excluding the payload content of the Load PDU and, to be clear,
also the IP and UDP headers). The calculation is the same as the also the IP and UDP headers). The calculation is the same as the
16-bit one's complement Internet checksum used in the IPv4 packet 16-bit one's complement Internet checksum used in the IPv4 packet
Header Chesksum specification (see Section 3.1 of [RFC0791]). This Header Checksum specification (see Section 3.1 of [RFC0791]). This
checksum is intended for environments where UDP data integrity may be checksum is intended for environments where UDP data integrity may be
uncertain. This includes situations where the standard UDP checksum uncertain. This includes situations where the standard UDP checksum
is not verified upon reception or a nonstandard network API is in use is not verified upon reception or a nonstandard network API is in use
(things typically done to improve performance on low-end devices). (things typically done to improve performance on low-end devices).
However, all UDPSTP datagrams transmitted via IPv4 or IPv6 SHALL However, all UDPSTP datagrams transmitted via IPv4 or IPv6 SHALL
include a standard UDP checksum to protect other potential recipients include a standard UDP checksum to protect other potential recipients
to whom a corrupted packet may be delivered. In the case of a to whom a corrupted packet may be delivered. In the case of a
nonstandard network API, one option to reduce processing overhead may nonstandard network API, one option to reduce processing overhead may
be to restrict testing to only utilize a payload content of all zeros be to restrict testing to only utilize a payload content of all zeros
so that the UDP checksum calculation need not include it for Load so that the UDP checksum calculation need not include it for Load
skipping to change at line 955 skipping to change at line 955
...) that is common to all connections of a single test. It is ...) that is common to all connections of a single test. It is
used by clients/servers to associate separate connections with a used by clients/servers to associate separate connections with a
single multi-connection test. single multi-connection test.
cmdRequest: A one-octet field set to CHSR_CREQ_SETUPREQ to indicate cmdRequest: A one-octet field set to CHSR_CREQ_SETUPREQ to indicate
a Setup Request message. Note that CHSR_CREQ_NONE remains unused. a Setup Request message. Note that CHSR_CREQ_NONE remains unused.
cmdResponse: A one-octet field. All Request PDUs always have a cmdResponse: A one-octet field. All Request PDUs always have a
Command Response of XXXX_CRSP_NONE. Command Response of XXXX_CRSP_NONE.
maxBandwith: A two-octet field. A non-zero value of this field maxBandwidth: A two-octet field. A non-zero value of this field
specifies the maximum bit rate the client expects to send or specifies the maximum bit rate the client expects to send or
receive during the requested test in Mbps. The server compares receive during the requested test in Mbps. The server compares
this value to its currently available configured limit for test this value to its currently available configured limit for test
admission control. This field MAY be used to rate-limit the admission control. This field MAY be used to rate-limit the
maximum rate the server should attempt. The maxBandwidth field's maximum rate the server should attempt. The maxBandwidth field's
most significant bit, the CHSR_USDIR_BIT, is set to 0 by default most significant bit, the CHSR_USDIR_BIT, is set to 0 by default
to indicate "downstream" and has to be set to 1 to indicate to indicate "downstream" and has to be set to 1 to indicate
"upstream". "upstream".
testPort: A two-octet field set to zero in the Test Setup Request testPort: A two-octet field set to zero in the Test Setup Request
skipping to change at line 1782 skipping to change at line 1782
watchdog timeout expiration at each endpoint. Note that the watchdog watchdog timeout expiration at each endpoint. Note that the watchdog
timer's purpose is to detect a connection failure or a massive timer's purpose is to detect a connection failure or a massive
congestion condition only. congestion condition only.
When the server is sending Load PDUs in the role of sender, it SHALL When the server is sending Load PDUs in the role of sender, it SHALL
use the transmission parameters directly from the Sending Rate use the transmission parameters directly from the Sending Rate
Table via the index that is currently selected (which was indirectly Table via the index that is currently selected (which was indirectly
based on the feedback in its received Status Feedback messages). based on the feedback in its received Status Feedback messages).
However, when the client is sending Load PDUs in the role of sender, However, when the client is sending Load PDUs in the role of sender,
it SHALL use the discreet transmission parameters that were it SHALL use the discrete transmission parameters that were
communicated by the server in its periodic Status Feedback messages communicated by the server in its periodic Status Feedback messages
(and not referencing a Sending Rate Table directly). This approach (and not referencing a Sending Rate Table directly). This approach
allows the server to control the individual sending rates as well as 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 algorithm used to decide when and how to adjust the rate.
The server uses a load rate adjustment algorithm that evaluates The server uses a load rate adjustment algorithm that evaluates
measurements taken locally at the Load PDU receiver. When the client measurements taken locally at the Load PDU receiver. When the client
is the receiver, the information is communicated to the server via is the receiver, the information is communicated to the server via
periodic Status Feedback messages. When the server is the receiver, periodic Status Feedback messages. When the server is the receiver,
the information is used directly (although it is also communicated to the information is used directly (although it is also communicated to
skipping to change at line 2149 skipping to change at line 2149
rttVarMinimum/rttVarMaximum (in sisSav): Two four-octet fields rttVarMinimum/rttVarMaximum (in sisSav): Two four-octet fields
populated by the minimum and maximum RTT delay variation populated by the minimum and maximum RTT delay variation
(rttVarSample) in the Sub-Interval designated by the (rttVarSample) in the Sub-Interval designated by the
subIntSeqNo. subIntSeqNo.
accumTime: The accumulated time of the test in ms, based on the accumTime: The accumulated time of the test in ms, based on the
duration of each Sub-Interval. Equivalent to the sum of each duration of each Sub-Interval. Equivalent to the sum of each
deltaTime (although in ms) sent in each Status PDU during the deltaTime (although in ms) sent in each Status PDU during the
test. test.
clockDeltaMin: A four-octet field indicating the minimum clock clockDeltaMin: A four-octet field indicating the minimum clock delta
delta (difference) since the beginning of the test. Obtained (difference) since the beginning of the test. Obtained by
by subtracting the send time of each Load PDU (lpduTime_sec/ subtracting the send time of each Load PDU (lpduTime_sec/
lpduTime_nsec) from the local time that it was received. This lpduTime_nsec) from the local time that it was received. This
value is initialized with the first Load PDU received and is value is initialized with the first Load PDU received and is
updated with each subsequent one to maintain a current (and updated with each subsequent one to maintain a current (and
continuously updated) minimum. If the endpoint clocks are continuously updated) minimum. If the endpoint clocks are
sufficiently synchronized, this will be the minimum one-way sufficiently synchronized, this will be the minimum one-way delay
delay in ms. Otherwise, this value may be negative but still in ms. Otherwise, this value may be negative but still valid for
valid for one-way delay variation measurements for the default one-way delay variation measurements for the default test duration
test duration (default is 10 seconds). If the test duration is (default is 10 seconds). If the test duration is extended to a
extended to a range of minutes, where significant clock drift range of minutes, where significant clock drift can occur,
can occur, synchronized (or at least well-disciplined) clocks synchronized (or at least well-disciplined) clocks may be
may be required. required.
rttMinimum (in Status PDU): A four-octet field indicating the rttMinimum (in Status PDU): A four-octet field indicating the
minimum "adjusted" RTT measured since the beginning of the minimum "adjusted" RTT measured since the beginning of the test.
test. See rttRespDelay (Section 7.1) regarding "adjusted" See rttRespDelay (Section 7.1) regarding "adjusted" measurements.
measurements. RTT is obtained by subtracting the copied RTT is obtained by subtracting the copied spduTime_sec/
spduTime_sec/spduTime_nsec in the received Load PDU from the spduTime_nsec in the received Load PDU from the local time at
local time at which it was received. This minimum SHALL be which it was received. This minimum SHALL be kept current (and
kept current (and continuously updated) via each Load PDU continuously updated) via each Load PDU received with an updated
received with an updated spduTime_sec/spduTime_nsec. This spduTime_sec/spduTime_nsec. This value MUST be positive. Before
value MUST be positive. Before an initial value can be an initial value can be established, and because zero is itself
established, and because zero is itself valid, it SHALL be set valid, it SHALL be set to STATUS_NODEL when communicated in the
to STATUS_NODEL when communicated in the Status PDU. Status PDU.
rttVarSample: A four-octet field indicating the most recent rttVarSample: A four-octet field indicating the most recent
"adjusted" RTT delay variation measurement. See rttRespDelay "adjusted" RTT delay variation measurement. See rttRespDelay
(Section 7.1) regarding "adjusted" measurements. RTT delay (Section 7.1) regarding "adjusted" measurements. RTT delay
variation is obtained by subtracting the current (and variation is obtained by subtracting the current (and continuously
continuously updated) "adjusted" RTT minimum, communicated as updated) "adjusted" RTT minimum, communicated as rttMinimum (in
rttMinimum (in Status PDU), from each "adjusted" RTT Status PDU), from each "adjusted" RTT measurement (which is itself
measurement (which is itself obtained by subtracting the copied obtained by subtracting the copied spduTime_sec/spduTime_nsec in
spduTime_sec/spduTime_nsec in the received Load PDU from the the received Load PDU from the local time at which it was
local time at which it was received). Note that while one-way received). Note that while one-way delay variation is measured
delay variation is measured for every Load PDU received, RTT for every Load PDU received, RTT delay variation is only sampled
delay variation is only sampled via the Status PDU sent and the via the Status PDU sent and the very next Load PDU received with
very next Load PDU received with the corresponding updated the corresponding updated spduTime_sec/spduTime_nsec. When a new
spduTime_sec/spduTime_nsec. When a new value is unavailable value is unavailable (possibly due to packet loss), and because
(possibly due to packet loss), and because zero is itself zero is itself valid, it SHALL be set to STATUS_NODEL when
valid, it SHALL be set to STATUS_NODEL when communicated in the communicated in the Status PDU.
Status PDU.
delayMinUpd: A one-octet field. Boolean, 0 or 1, indicating that delayMinUpd: A one-octet field. Boolean, 0 or 1, indicating that
the clockDeltaMin and/or rttMinimum (in Status PDU), as the clockDeltaMin and/or rttMinimum (in Status PDU), as measured
measured by the Load PDU receiver, has been updated. by the Load PDU receiver, has been updated.
tiDeltaTime/tiRxDatagrams/tiRxBytes: Three four-octet fields tiDeltaTime/tiRxDatagrams/tiRxBytes: Three four-octet fields
populated by the trial interval time in us, along with the populated by the trial interval time in us, along with the
received datagram and byte counts. Used to calculate the received datagram and byte counts. Used to calculate the received
received traffic rate for the trial interval. traffic rate for the trial interval.
spduTime_sec/spduTime_nsec: Two four-octet fields containing the spduTime_sec/spduTime_nsec: Two four-octet fields containing the
local transmit time of the Status PDU. Expected to be copied local transmit time of the Status PDU. Expected to be copied into
into spduTime_sec/spduTime_nsec in subsequent Load PDUs after spduTime_sec/spduTime_nsec in subsequent Load PDUs after being
being received by the Load PDU sender. Used for RTT received by the Load PDU sender. Used for RTT measurements.
measurements.
authMode: Same as in Section 5.1. authMode: Same as in Section 5.1.
authUnixTime: Same as in Section 5.1. authUnixTime: Same as in Section 5.1.
authDigest: Same as in Section 5.1. authDigest: Same as in Section 5.1.
keyId: Same as in Section 5.1. keyId: Same as in Section 5.1.
reservedAuth1: Same as in Section 5.1. reservedAuth1: Same as in Section 5.1.
checkSum: Same as in Section 5.1. checkSum: Same as in Section 5.1.
The Status Feedback message PDU (as well as the included Sub-Interval The Status Feedback message PDU (as well as the included Sub-Interval
statistics structure) SHALL be organized as follows: statistics structure) SHALL be organized as follows:
<CODE BEGINS> <CODE BEGINS>
// //
// Sub-Interval statistics structure for received traffic information // Sub-Interval statistics structure for received traffic information
// //
#pragma pack(push, 1)
struct subIntStats { struct subIntStats {
uint32_t rxDatagrams; // Received datagrams uint32_t rxDatagrams; // Received datagrams
uint64_t rxBytes; // Received bytes (64 bits) uint64_t rxBytes; // Received bytes (64 bits)
uint32_t deltaTime; // Time delta (us) uint32_t deltaTime; // Time delta (us)
uint32_t seqErrLoss; // Loss sum uint32_t seqErrLoss; // Loss sum
uint32_t seqErrOoo; // Out-of-order sum uint32_t seqErrOoo; // Out-of-order sum
uint32_t seqErrDup; // Duplicate sum uint32_t seqErrDup; // Duplicate sum
uint32_t delayVarMin; // Delay variation minimum (ms) uint32_t delayVarMin; // Delay variation minimum (ms)
uint32_t delayVarMax; // Delay variation maximum (ms) uint32_t delayVarMax; // Delay variation maximum (ms)
uint32_t delayVarSum; // Delay variation sum (ms) uint32_t delayVarSum; // Delay variation sum (ms)
uint32_t delayVarCnt; // Delay variation count uint32_t delayVarCnt; // Delay variation count
uint32_t rttMinimum; // Minimum round-trip time (ms) uint32_t rttVarMinimum; // Minimum RTT variation (ms)
uint32_t rttMaximum; // Maximum round-trip time (ms) uint32_t rttVarMaximum; // Maximum RTT variation (ms)
uint32_t accumTime; // Accumulated time (ms) uint32_t accumTime; // Accumulated time (ms)
}; };
#pragma pack(pop)
// //
// Status Feedback header for UDP payload of status PDUs // Status Feedback header for UDP payload of status PDUs
// //
struct statusHdr { struct statusHdr {
#define STATUS_ID 0xFEED #define STATUS_ID 0xFEED
uint16_t pduId; // PDU ID uint16_t pduId; // PDU ID
uint8_t testAction; // Test action uint8_t testAction; // Test action
uint8_t rxStopped; // Receive traffic stopped (BOOL) uint8_t rxStopped; // Receive traffic stopped (BOOL)
uint32_t spduSeqNo; // Status PDU sequence number uint32_t spduSeqNo; // Status PDU sequence number
struct sendingRate srStruct; // Sending Rate structure struct sendingRate srStruct; // Sending Rate structure
 End of changes. 19 change blocks. 
76 lines changed or deleted 76 lines changed or added

This html diff was produced by rfcdiff 1.48.