"generally lacks required precision" well, generally, you combine measurement vectors to obtain required precision.
I also maintain that you can get all the information you need from active measurement, and that adding leaks to live traffic just so you can save that active measurement overhead is irresponsible.
could just not ever set the spin bit.
That works until middleboxes start requiring that the spin bit is set. As I commented in the earlier discussion linked above:
"You do know that someone somewhere is going to make a middlebox that just drops a packet unless that bit flipped in the precise sequence that the middlebox developer believed was the correct one, right?
Then someone proposes an enhancement to QUIC which happens to change the sequence of the flips (perhaps some multipath thing, or an enhancement in the way it treats reordered packets), and it breaks... "
A router or other node in the network that's just moving these packets can't decrypt them, so it can't tell the "ACK of the numbered packet". The spin bit lets such a node estimate the round trip time anyway because it will "spin" between set and unset on each round trip.
I think you get this information for free as part of TCP.
I imagine that it won't work at all when you combine something like 3G (with random periods of hundreds of milliseconds of no packets delivered and them all queueing up), with a little packet reordering.
The 'spin' will end up measuring half, 1/3, or 1/4 the original RTT. The issue won't resolve until the connection ends up idle for at least 1 RTT.
On the upside it probably doesn't need to work on 3G anyways. The reason being if your spins are out of order and coming in 300ms chunks you probably aren't worried about troubleshooting the latency anymore, you've been made aware the connection is never going to be high quality, that the delay is low-300ms depending on chunking interval, and that you have packet reordering.