search

private-octopus / picoquic

Minimal implementation of the QUIC protocol
MIT License
544 stars 161 forks source link

Impact of hard-coded PICOQUIC_TARGET_SATELLITE_RTT #1692

Open joergdeutschmann-i7 opened 4 months ago

joergdeutschmann-i7 commented 4 months ago

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

We wonder how this value was chosen:

https://github.com/private-octopus/picoquic/blob/c306ab45c1c6ae528e2877d8d69e98e5405b832a/picoquic/cubic.c#L273-L274 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.

https://github.com/private-octopus/picoquic/blob/c306ab45c1c6ae528e2877d8d69e98e5405b832a/picoquic/cubic.c#L277 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 commented 4 months ago

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.