private-octopus / picoquic

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

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

Open joergdeutschmann-i7 opened 4 months ago

joergdeutschmann-i7 commented 4 months ago

https://github.com/private-octopus/picoquic/blob/c306ab45c1c6ae528e2877d8d69e98e5405b832a/picoquictest/satellite_test.c#L91 picoquic allows the use of one-way delays. These are then also used for the samples. https://github.com/private-octopus/picoquic/blob/c306ab45c1c6ae528e2877d8d69e98e5405b832a/picoquic/cc_common.h#L46-L47 (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., https://github.com/private-octopus/picoquic/blob/c306ab45c1c6ae528e2877d8d69e98e5405b832a/picoquic/cubic.c#L273 We wonder if this could cause problems... 🤔

huitema commented 4 months ago

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.