Change:
necessarily includes any transport and application layer delay at both sides. <del> QUIC does not expose any acknowledgement or timestamping information in its wire image.  This makes passive measurement of more than one RTT sample per flow, or passive measurement of changes in RTT during a flow's lifetime, impossible in the general case. Changes to this behavior are currently under discussion: see https://github.com/quicwg/base-drafts/issues/631. </del> <ins> The spin bit experiment, detailed in QUIC-SPIN, provides an additional method to measure intraflow per-flow RTT.  When a QUIC flow is sending at full rate (i.e., neither application nor flow control limited), the latency spin bit described in that document changes value once per round-trip time (RTT).  An on-path observer can observe the time difference between edges in the spin bit signal in a single direction to measure one sample of end-to-end RTT.  Note that this measurement, as with passive RTT measurement for TCP, includes any transport protocol delay (e.g., delayed sending of acknowledgements) and/or application layer delay (e.g., waiting for a request to complete).  It therefore provides devices on path a good instantaneous estimate of the RTT as experienced by the application. A simple linear smoothing or moving minimum filter can be applied to the stream of RTT information to get a more stable estimate. An on-path observer that can see traffic in both directions (from client to server and from server to client) can also use the spin bit to measure "upstream" and "downstream" component RTT; i.e, the component of the end-to-end RTT attributable to the paths between the observer and the server and the observer and the client, respectively.  It does this by measuring the delay between a spin edge observed in the upstream direction and that observed in the downstream direction, and vice versa. Application-limited and flow-control-limited senders can have application and transport layer delay, respectively, that are much greater than network RTT.  Therefore, the spin bit provides network latency information only when the sender is neither application nor flow control limited.  When the sender is application-limited by periodic application traffic, where that period is longer than the RTT, measuring the spin bit provides information about the application period, not the RTT.  Simple heuristics based on the observed data rate per flow or changes in the RTT series can be used to reject bad RTT samples due to application or flow control limitation. Since the spin bit logic at each endpoint considers only samples on packets that advance the largest packet number seen, signal generation itself is resistant to reordering.  However, reordering can cause problems at an observer by causing spurious edge detection and therefore low RTT estimates, if reordering occurs across a spin bit flip in the stream.  This can be probabilistically mitigated by the observer also tracking the low-order bits of the packet number, and rejecting edges that appear out-of-order RFC4737. </ins> 3.7.

Discussion:
This PR takes text from to explain the on-path use of the latency spin bit. It is the manageability draft companion of the new .
I don't think we want to merge this until we have consensus that the spin bit itself is merged?
NAME fbc8490 changes this to point to the experiment (quic-spin-exp), not to the protocol, and to be clear that it's an experiment. It also pretends the VEC doesn't exist, since quic-spin-exp does so as well. If the experiment merges into the protocol, then we update this draft to point to it; if not, then the text changes in a subsequent draft to omit in-flow RTT.
To further clarify, the draft was mentioning that there is a discussion about the spin bit before. This PR mainly only now points to the respective draft. I think it is far to have this pointer in there for now.
Well, as long as you are prepared to possibly remove this, fine
The nice thing about Internet-Drafts is that they are endlessly mutable. :)