Re: [quicwg/base-drafts] add draft-ietf-quic-spin-exp (#1286)

[Martin Thomson <[e-mail]>]

martinthomson approved this pull request.

This looks pretty good  I have a bunch of nits and cleanup notes, but I don't think that those need to be addressed before merging.

> ++-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+~~~~~
+{: #fig-short-header title="Short Header Format including proposed Spin Bit"}
+
+S: The Spin bit is set 0 or 1 depending on the stored spin value that is
+updated on packet reception as explained in {{spinbit}}.
+
+## Setting the Spin Bit on Outgoing Packets {#spinbit}
+
+Each endpoint, client and server, maintains a spin value, 0 or 1, for each
+QUIC connection, and sets the spin bit in the short header to the currently
+stored value when a packet with a short header is sent out. The spin value is
+initialized to 0 on both side, at the client as well as the server at
+connection start. Each endpoint also remembers the highest packet number seen
+from its peer on the connection. The spin value is then determined at each

I'd break a new paragraph after this period.

> +{: #fig-short-header title="Short Header Format including proposed Spin Bit"}
+
+S: The Spin bit is set 0 or 1 depending on the stored spin value that is
+updated on packet reception as explained in {{spinbit}}.
+
+## Setting the Spin Bit on Outgoing Packets {#spinbit}
+
+Each endpoint, client and server, maintains a spin value, 0 or 1, for each
+QUIC connection, and sets the spin bit in the short header to the currently
+stored value when a packet with a short header is sent out. The spin value is
+initialized to 0 on both side, at the client as well as the server at
+connection start. Each endpoint also remembers the highest packet number seen
+from its peer on the connection. The spin value is then determined at each
+endpoint as follows:
+
+* When it receives a packet from the client, if that packet has a short header

"it" here could be "server" and then the next "by the server" can be removed.  Same below.

> +
+* When it receives a packet from the server, if the packet has a short header
+  and if it increments the highest packet number seen by the client from the
+  server, it sets the spin value to the opposite of the spin bit in the
+  received packet.
+
+This procedure will cause the spin bit to change value in each direction once
+per round trip. Observation points can estimate the network latency by
+observing these changes in the latency spin bit, as described in {{usage}}.
+See {{?SPIN-BIT=I-D.trammell-quic-spin}} for further illustration of this
+mechanism in action.
+
+## Resetting Spin Value State
+
+Each client and server resets it spin value to zero when sending the first
+packet in a given with a new Connection ID. This reduces the risk that

s/in a given/  I think that we have stopped German-casing "connection ID" as well.

> +
+# Using the Spin Bit for Passive RTT Measurement {#usage}
+
+When 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.
+
+An observer can keep the largest observed packet number per flow, and reject
+edges that do not have a packet number that is larger than the last largest
+observed packet number.  This will detect spurious edges caused by reordering
+across an edge, which would lead to low RTT estimates, if not ignored.
+
+The packet number can be used to filter out high RTT estimates due to loss of
+an actual edge in a burst of lost packets. If the spin bit edge occurs after a

These are two different concepts and might benefit from being separated better (by the appropriate joining word, or by putting them in different paragraphs).

> +
+The packet number can be used to filter out high RTT estimates due to loss of
+an actual edge in a burst of lost packets. If the spin bit edge occurs after a
+long packet number gap, it should be rejected.
+
+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.
+
+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

"For example, when a sender spends time on processing or other tasks, the value measured using the spin bit includes that time in addition to the network 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.
+
+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. 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.

"Simple heuristics" suggests something that you might have something you could cite or write down.  If this is "apply whatever magic you deem appropriate and the techniques are diverse", then you might want to consider removing this sentence.

> +Specifically, this experimentation is intended to determine:
+
+- the impact of the addition of the latency spin bit on implementation and
+  specification complexity; and
+- the accuracy and value of the information derived from spin bit measurement
+  on live network traffic.
+
+The information generated by this experiment will be used by the QUIC working
+group as input to a decision about the standardization of the latency spin
+bit.
+
+This document describes a one-bit latency spin signal. A three-bit latency
+spin signal, which provides reordering, loss, and edge delay resistance even
+without cleartext packet numbers in the QUIC header, is described in
+{{?QUIC-SPIN=I-D.trammell-quic-spin}}; experimentation with this approach is
+also encouraged.

Not sure that we want to drag more bits into this.

> @@ -0,0 +1,247 @@
+---
+title: The QUIC Latency Spin Bit
+abbrev: QUIC Spin Bit
+docname: draft-ietf-quic-spin-exp-latest
+date:

Note for fixup, use `{DATE}`.

> +        ins: D. Gugelmann
+      -
+        ins: N. Brownlee
+    date: 2014-04
+
+
+--- abstract
+
+This document specifies the addition of a latency spin bit to the QUIC
+transport protocol and describes how to use it to measure end-to-end latency.
+
+--- middle
+
+# Introduction
+
+The QUIC transport protocol {{?QUIC-TRANS=I-D.ietf-quic-transport}} uses

Note for fixup: use definition of -transport citation from other drafts.

> +can be seen by on-path observers and used to estimate end-to-end latency,
+QUIC's wire image (see {{?WIRE-IMAGE=I-D.trammell-wire-image}}) currently does
+not expose any information that can be used for passive latency measurement
+techniques that rely on this information (e.g. {{CACM-TCP}}, {{TMA-QOF}}).
+
+This document adds an explicit signal
+for passive latency measurability to the QUIC short header: a "spin bit".
+Passive observation of the spin bit provides one RTT sample per RTT to passive
+observers of QUIC traffic. This document describes the mechanism, how it can
+be added to QUIC, and how it can be used by passive measurement facilities to
+generate RTT samples.
+
+## About This Document
+
+This document is maintained in the GitHub repository
+https://github.com/britram/draft-trammell-quic-spin, and the editor's copy is

Note for fixup: point to new location.

> +
+This document describes a one-bit latency spin signal. A three-bit latency
+spin signal, which provides reordering, loss, and edge delay resistance even
+without cleartext packet numbers in the QUIC header, is described in
+{{?QUIC-SPIN=I-D.trammell-quic-spin}}; experimentation with this approach is
+also encouraged.
+
+# IANA Considerations
+
+This document has no actions for IANA.
+
+# Security and Privacy Considerations
+
+The spin bit is intended to expose end-to-end RTT to observers along the path,
+so the privacy considerations for the latency spin bit are essentially the
+same as those for passive RTT measurement in general. However, it has been

Is there any work that could be cited here?

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/quicwg/base-drafts/pull/1286#pullrequestreview-111383402