Re: [quicwg/base-drafts] Moving text on spinbit into transport (#2364)

[Brian Trammell <[e-mail]>]

britram requested changes on this pull request.

This is good, modulo a few changes to 2119 language that I think better reflect BKK consensus.

> @@ -2818,6 +2825,44 @@ encoded as a single byte with the value 0x01.  An endpoint MAY treat the receipt
 of a frame type that uses a longer encoding than necessary as a connection error
 of type PROTOCOL_VIOLATION.
 
+## Latency Spin Bit {#spin-bit}
+
+The latency spin bit enables passive latency monitoring from observation points
+on the network path throughout the duration of a connection. The spin bit is
+only present in the short packet header, since it is possible to measure the
+initial RTT of a connection by observing the handshake. Therefore, the spin bit
+will appear after version negotiation and connection establishment are
+completed. On-path measurement and use of the Latency Spin Bit is further
+discussed in {{QUIC-MANAGEABILITY}}.
+
+The spin bit utilizes a single bit in the first byte of the short header. The
+location of the bit and procedures for how to set it by clients and servers are
+defined in {{short-header}}.
+
+Implementations MAY select to not implement the full spin bit functionality. In

I think I'd phrase this differently: "the spin bit is an optional feature. implementations that implement MUST implement it as specified in this document."

> +will appear after version negotiation and connection establishment are
+completed. On-path measurement and use of the Latency Spin Bit is further
+discussed in {{QUIC-MANAGEABILITY}}.
+
+The spin bit utilizes a single bit in the first byte of the short header. The
+location of the bit and procedures for how to set it by clients and servers are
+defined in {{short-header}}.
+
+Implementations MAY select to not implement the full spin bit functionality. In
+that case they are only REQUIRED to implement what is defined for the spin bit
+when it is disabled.
+
+Each endpoint unilaterally decides if the spin bit is enabled or disabled for a
+connection. Implementations SHOULD allow administrators of clients and servers
+to disable the spin bit either globally or on a per-connection basis. Even when
+the spin bit is not disabled by the administrator implementations SHOULD disable

IIRC consensus here sounded like MUST probabalistically disable, since we will want to provide cover traffic in the long term, not only for non-implementing endpoints but also for flows that decide to disable it. I'd justify the MUST because it affects the privacy properties of the wire image (however minimal the actual effect is)

```suggestion
the spin bit is not disabled by the administrator implementations MUST disable
```

> +discussed in {{QUIC-MANAGEABILITY}}.
+
+The spin bit utilizes a single bit in the first byte of the short header. The
+location of the bit and procedures for how to set it by clients and servers are
+defined in {{short-header}}.
+
+Implementations MAY select to not implement the full spin bit functionality. In
+that case they are only REQUIRED to implement what is defined for the spin bit
+when it is disabled.
+
+Each endpoint unilaterally decides if the spin bit is enabled or disabled for a
+connection. Implementations SHOULD allow administrators of clients and servers
+to disable the spin bit either globally or on a per-connection basis. Even when
+the spin bit is not disabled by the administrator implementations SHOULD disable
+the spin bit on a randomly chosen fraction of connections. However, connections
+may be configured to explicitly enable spinning, for example in the case of

in line with the SHOULD above, this isn't a may/MAY:

```suggestion
SHOULD be configurable to explicitly enable spinning, for example in the case of
```

> @@ -3948,8 +3993,33 @@ Fixed Bit:
 
 Spin Bit (S):
 
-: The sixth bit (0x20) of byte 0 is the Latency Spin Bit, set as described in
-  {{!SPIN=I-D.ietf-quic-spin-exp}}.
+: The third most significant bit (0x20) of byte 0 is the Latency Spin Bit.

+1 to this

> @@ -89,6 +89,13 @@ informative:
     target:
      "https://web.archive.org/web/20150315054838/http://ha.ckers.org/slowloris/"
 
+  QUIC-MANAGEABILITY:
+    title: "Manageability of the QUIC Transport Protocol"
+    author:
+      - ins: M. Kuehlewind

add `-ins: B. Trammell` as well 

-- 
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/2364#pullrequestreview-195914975