How are the two directions aggregated

[moeller0]

According to the current spec:

"Thus, we recommend testing uplink and downlink sequentially.
Parallel testing is considered a future extension."

Load is generated sequentially for both directions, which implies that there should be two sets of delay measurements. Section "4.2.1. Aggregating the Measurements" however does not tackle how to aggregate these measurements for the two directions.
Real live links can and do show latency-under-load increases that differ between the two directions, here is an example from a VDSL2 link, showing the gping results towards (the heavily anycasted) 8.8.8.8 during a speedtest that sequentially saturated both directions:
https://forum.openwrt.org/uploads/default/original/3X/8/0/804455ac122f5cf58cebba52c6d6286f6fae75ad.jpeg

It should be clear that the invoked delay differs noticeable between both parts of the speedtest and hence both would give noticeably different RPM results as well. Leading to the question whether averaging all of the would be the best aggregate here or averaging for both directions and then reporting the smaller of the two?

Or simply switch to measure during bi-directionally saturating load (potentially after first deducing the number of required flows per uni-directional tests and then using these numbers during the actual delay data collection step).

[LPardue]

+1 I find the specification too vague to perform a calculation and have more than 1/3 confidence that I did it the correct way. It would be great to consider the calculation some more, and make it really clear what people are expected to do.