Draft: draft-ietf-quic-manageability

Commentary: Merge / update based on text from spin - exp draft + new subsections for spin based RTT measurement and initial RTT measurement + new text on disabled spin bit 
 Includes PR and address 
 merging , though this needs some 80col cleanup ( will fix in subsequent commit ) 
 Review and update text in -manageability to reflect BKK spin bit consensus : single spin bit is in the protocol spec now endpoints may opt out ( discuss why ; this is for any reason , not just proxies as suggested in ) , endpoints should probabilistically out out to provide cover for endpoints opting out 
 I am working on this . 
 what about having a privacy consideration section ? 
 I 'm not sure this fits in the scope of the document : can you say more about what you propose to be in this section ? The -manageability document is meant to be an independent user 's guide to the wire image , so information on the spin bit here will be more about how to measure it , not additional guidelines on how to generate it and when not to ( though such text might belong in -applicability ) Please coordinate with who will also be proposing text on spin measurement to bring over from draft - ietf - quic - spin - exp . 
 see PR 
 closed by merge of and 
 drive by
Paragraph (version B):
latency spin bit: the third most significant bit of first octet.
However, the is only used in short packet headers.  There it will
be set alternatingly to 0 or 1 by the endpoints such that tracking
edge transistions can be used to passively monitor the connection
RTT, see spin-usage for further details.
Paragraph (version A):
spin bit: the spin bit supports passive measurement of RTT, and is
present on QUIC short packet headers.  See sec-rtt.
Paragraph (version A):
Round-trip time of QUIC flows can be inferred by observation once per
flow, during the handshake, as in passive TCP measurement; this
requires parsing of the QUIC packet header and recognition of the
handshake, as illustrated in handshake.  It can also be inferred
during the flow's lifetime, if the endpoints use the spin bit
facility described below and in QUIC-SPIN.
Paragraph (version B):
Round-trip time of QUIC flows can be inferred by observation once per
flow, during the handshake, as in passive TCP measurement; this
requires parsing of the QUIC packet header and recognition of the
handshake, as illustrated in handshake.  It can also be inferred
during the flow's lifetime, if the endpoints use the spin bit
facility described below and in QUIC-TRANSPORT, section 17.3.1.
Paragraph (version A):
The spin bit 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 on short
header packets 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.
Paragraph (version B):
The spin bit provides an additional method to measure per-flow RTT
from observation points on the network path throughout the duration
of a connection.  Endpoint participation in spin bit signaling is
optional in QUIC.  That is, while its location is fixed in this
version of QUIC, an endpoint can unilaterally choose to not support
"spinning" the bit.  Use of the spin bit for RTT measurement by
devices on path is only possible when both endpoints enable it.  Some
endpoints may disable use of the the spin bit by default, others only
in specific deployment scenarios, e.g. for servers and clients where
the RTT would reveal the presence of a VPN or proxy.  In order to not
make these connections identifiable based on the usage of the spin
bit, it is recommended that all endpoints disable "spinning" randomly
for at least one eighth of connections, even if otherwise enabled by
default.  An endpoint not participating in spin bit signaling for a
given connection can use a fixed spin value for the duration of the
connection, or can set the bit randomly on each packet sent.
Paragraph (version B):
When in use and a QUIC flow sends data continuously, the latency spin
bit in each direction changes value once per round-trip time (RTT).
An on-path observer can observe the time difference between edges
(changes from 1 to 0 or 0 to 1) in the spin bit signal in a single
direction to measure one sample of end-to-end RTT.
Paragraph (version B):
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
response to be generated).  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.
Paragraph (version B):
However, application-limited and flow-control-limited senders can
have application and transport layer delay, respectively, that are
much greater than network RTT.  When the sender is application-
limited and e.g. only sends small amount of periodic application
traffic, where that period is longer than the RTT, measuring the spin
bit provides information about the application period, not the
network RTT.
Paragraph (version B):
Since the spin bit logic at each endpoint considers only samples from
packets that advance the largest packet number, 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.
Paragraph (version B):
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 lost
or reordered edges in the spin signal, as well as application or flow
control limitation; for example, QoF TMA-QOF rejects component RTTs
significantly higher than RTTs over the history of the flow.  These
heuristics may use the handshake RTT as an initial RTT estimate for a
given flow.  Usually such heuristics would also detect if the spin is
either constant or randomly set for a connection.
Paragraph (version A):
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.
Paragraph (version A):
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.