Impact of hard-coded PICOQUIC_TARGET_SATELLITE_RTT

[joergdeutschmann-i7]

In picoquic, there is a hard-coded PICOQUIC_TARGET_SATELLITE_RTT of 610ms.

We wonder how this value was chosen:

picoquic/picoquic/cubic.c

Lines 273 to 274 in c306ab4

	if (cubic_state->rtt_filter.rtt_filtered_min > PICOQUIC_TARGET_SATELLITE_RTT) {
	correction = (double)PICOQUIC_TARGET_SATELLITE_RTT / (double)cubic_state->rtt_filter.rtt_filtered_min;

If cubic_state->rtt_filter.rtt_filtered_min is slightly above, e.g. 620ms, correction is calculated to ~1, i.e., the path_x->cwin is hardly changed.

picoquic/picoquic/cubic.c

Line 277 in c306ab4

correction = (double)PICOQUIC_TARGET_RENO_RTT / (double)cubic_state->rtt_filter.rtt_filtered_min;

If cubic_state->rtt_filter.rtt_filtered_min is slightly below, e.g. 600ms, correction is calculated to ~1/6. This results in a significant reduction of path_x->cwin.

Both cases seem possible -- consider a GEO terminal connecting to a nearby server (< 610ms) vs. a far-distant server (> 610ms).

[huitema]

The correction was meant to accelerate the growth of the window when the delay is large. The best I can say is that "it looked like a good idea at the time." Picoquic also implements two related ideas: the "safe resume" process to remember and reuse past conditions, and a version of chirping to detect the maximum observed data rate and use it as a target during slow start. It is entirely possible that the combination of safe resume and chirping reduces the need for pre-programmed delay thresholds.

I studied GEO transmissions for my doctorate, so I have a bit of emotional attachment there, but that was 40 years ago. It is possible that GEO satellite are becoming way less important, and that instead of the Geo delay we have to be concerned with a continuum of LEO, MEO, GEO, and then space communication.