The current version of picoquic includes a complex estimator of the path rtt. In the multipath scenarios, it tries to evaluate the one-way delays for each path direction, based on acknowledgements received on multiple paths and also on time stamps. The algorithm is supposedly an approximation of a Kalman filter, but the approximation is not very stable and sometimes results in negative delays.
During the discussion of the multipath draft, the working group agreed that just using the "natural" algorithm works well enough: whatever the path of the ACK, receiving them provides an indication of how long the sender should wait for an ACK before starting the PTO algorithm. The suggestion is thus to replace the complex estimation by a simpler one.
There is a little issue tied to multipath. If the ack used to come back on a low RTT path and that path suddenly disappears, the estimation of MIN RTT becomes invalid and should be reset. That information ought to be passed to congestion control algorithms, so they could adapt to the new value.
The simulations and experiences show another failure mode. If ACKs are frequent, the successive samples are strongly correlated. Feeding them in the exponential averaging estimator causes the estimator to quickly track the sample values, while the RTT VAR estimate quickly drives to zero. This leads to underestimating potential delay variations, and thus spurious timeouts. If we revisit the delay algorithm, it would be good to also address that issue. One extreme measure would be to take only one sample per RTT. Another would be to increase the averaging factor if acks are too frequent. For example, instead of taking "beta=1/4", one could use "beta=1/4*n", where n is the number of ACKs per RTT -- a number that could be estimated in its own way, at the end of each RTT. Yet another would be to compute average, min and max for the epoch.
huitema
commented
1 year ago
The current version of picoquic includes a complex estimator of the path rtt. In the multipath scenarios, it tries to evaluate the one-way delays for each path direction, based on acknowledgements received on multiple paths and also on time stamps. The algorithm is supposedly an approximation of a Kalman filter, but the approximation is not very stable and sometimes results in negative delays.
During the discussion of the multipath draft, the working group agreed that just using the "natural" algorithm works well enough: whatever the path of the ACK, receiving them provides an indication of how long the sender should wait for an ACK before starting the PTO algorithm. The suggestion is thus to replace the complex estimation by a simpler one.
There is a little issue tied to multipath. If the ack used to come back on a low RTT path and that path suddenly disappears, the estimation of MIN RTT becomes invalid and should be reset. That information ought to be passed to congestion control algorithms, so they could adapt to the new value.
The simulations and experiences show another failure mode. If ACKs are frequent, the successive samples are strongly correlated. Feeding them in the exponential averaging estimator causes the estimator to quickly track the sample values, while the RTT VAR estimate quickly drives to zero. This leads to underestimating potential delay variations, and thus spurious timeouts. If we revisit the delay algorithm, it would be good to also address that issue. One extreme measure would be to take only one sample per RTT. Another would be to increase the averaging factor if acks are too frequent. For example, instead of taking "beta=1/4", one could use "beta=1/4*n", where n is the number of ACKs per RTT -- a number that could be estimated in its own way, at the end of each RTT. Yet another would be to compute average, min and max for the epoch.