Proposed text for RTT computation and ACK_MP scheduling #217
Conversation
| lower than the 600ms that would be measured if the ACK_MP came over | ||
| the satellite channel, but it is still the right value for computing | ||
| for example the PTO timeout: if an ACK_MP is not received after more | ||
| than 350ms, either the data packet or its ACK_MP were probably lost. |
There was a problem hiding this comment.
However, I'm not sure about this. In this examples you assume that the terrestrial path will used in a stable way for ACK. In the paragraph above you say if different path are used which is a different case. So if I send half my ACK over each pass, I will see an average RTT of 475ms which is too low for those ACKs that are sent over the satellite path.
There was a problem hiding this comment.
Commenting on this PR after the merge: in the example that you cite, the smoothed RTT will actually be very close to the RTT via the shortest path + maybe 1 ACK delay. ACK_MP frames are redondant. If you send ACK alternately on short and long path, the ACK on the short path will arrive before the one on the long path. When the ACK on the long path arrives, its "highest" packet will already have been acked as part of a range carried on the short path, so it will not contribute to RTT computation.
There was a problem hiding this comment.
Only if you send ACKs multiple time per RTT and the latency difference between the path is large.
So maybe we should rather not make any default recommendations but just explain the problems and non-problems in different alternatives...?
(btw. which merge are you talking about? This PR is not merged yet)
There was a problem hiding this comment.
Merge: I was mislead by the PR search feature. Sorry.
General idea:
1- loss detection will be mostly triggered by the ACK sent on the shortest return path, because with RACK most loss detection is triggered by packet number comparisons, not by timers. That means losses are detected faster if enough ACK travel on the shortest return path, which tends to improve performance quite a bit.
2- ACKing packets faster leads to lower memory utilisation, as packets get out of the retransmit queue faster.
3- Still, we need timer measurements to compute the PTO and deal with the loss of the "last packet". Just feeding all RTT samples into the algorithms works, because the combination of SmoothedRTT and RTTvar will capture both the characteristics of the paths and whatever algorithm is implemented by the peer. The PTO formula incorporates both average and variance, and thus the PTO ends up making sense.
There was a problem hiding this comment.
From RFC 9002:
PTO = smoothed_rtt + max(4*rttvar, kGranularity) + max_ack_delay
draft-ietf-quic-multipath.md
Outdated
| for example the PTO timeout: if an ACK_MP is not received after more | ||
| than 350ms, either the data packet or its ACK_MP were probably lost. | ||
|
|
||
| In general, using the algorithm above will provide good results, |
There was a problem hiding this comment.
Should probably say "computing smoothedRTT and RTTvar per section 5.3 of RFC9002 regardless of the path on which MP_ACK are received". But that's a handful, so maybe:
"The simplest implementation is to compute smoothedRTT and RTTvar per section 5.3 of RFC9002 regardless of the path on which MP_ACKs are received. This algorithm will provide good results,"
There was a problem hiding this comment.
Latest commit fixes that, hopefully.
| packets. As noted in {{compute-rtt}} the values computed using | ||
| the standard algorithm reflect both the characteristics of the | ||
| path and the scheduling algorithm of ACK_MP frames. The estimates will converge | ||
| faster if the scheduling strategy is stable, but besides that |
There was a problem hiding this comment.
Not sure if convergence is the right term here. I think it might actually not work if you keep using multiple paths for ACKs.
There was a problem hiding this comment.
I think "convergence" generally means that the algorithm has produced results that reflect the current network state, and that the smoothed RTT and RTTvar values will reflect that.
There was a problem hiding this comment.
Just pushed a fix in the latest commit.
fixes #132
This proposed text updates the discussion of RTT computation and ACK_MP scheduling in the Example section, which is not normative. The proposed text reflects the discussion during the working group meeting in Yokohama, and aligns with the apparent consensus that emerged during the discussion.