One-way delay timestamps / RTTs vs. hard-coded constant values

[joergdeutschmann-i7]

picoquic/picoquictest/satellite_test.c

Line 91 in c306ab4

client_parameters.enable_time_stamp = 3;

picoquic allows the use of one-way delays. These are then also used for the samples.

picoquic/picoquic/cc_common.h

Lines 46 to 47 in c306ab4

	uint64_t samples[PICOQUIC_MIN_MAX_RTT_SCOPE];
	} picoquic_min_max_rtt_t;

(IMHO these are not RTTs any more, but one-way delays, but this is just a question of variable names.)
In other places, these one-way delays are then used for comparison with hard-coded RTT thresholds, e.g.,

picoquic/picoquic/cubic.c

Line 273 in c306ab4

if (cubic_state->rtt_filter.rtt_filtered_min > PICOQUIC_TARGET_SATELLITE_RTT) {

We wonder if this could cause problems... 🤔

[huitema]

Yes. It is a bit of a mess. And getting that right will be more urgent if we actually deploy multipath. There is a lot of confusion there, because the time measurements are used for both loss detection and congestion control or pacing. For loss detection, we use RACK. It relies primarily on out of order detection, and timer precision does not matter too much. But for congestion control, we need precision.