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

[Lars Eggert <[e-mail]>]

larseggert requested changes on this pull request.



> @@ -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

will appear -> is available

> @@ -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

Pick a consistent capitalization (Latency Spin Bit or latency spin bit) and use it consistently

> @@ -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

Agree, too. Would use the 2119 OPTIONAL capitalization

> @@ -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

So: "The spin bit is an OPTIONAL feature of QUIC. A QUIC stack that chooses to support the spin bit MUST implement it as specified in this document."

> +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 uses 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

There's several layers here that all influence on whether spin is used for a connection. This doesn't fully come out in the current text.

First, since the entire spin functionality is OPTIONAL, either a client or a server or both can simply choose to not even implement it. When such an endpoint is communicating, spin will never be used.

Second, even if both stacks implement the OPTIONAL spin functionality, the system/stack administrator and/or the application implementor MAY still globally disable the spin functionality for the stack and/or an app.

Third, even if spin functionality is globally enabled, an app implementor MAY still disable it for some of the connections. (Or enable it for some.)

Fourth, if at this point spin is enabled for a given connection, we had consensus that the QUIC stack MUST internally and probabilistically disable spin with some likelihood (I remember 1/8th?) to guarantee some "cover traffic".

> +
+The spin bit uses 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
+could be configured to explicitly enable spinning, for example in the case of
+explicit customer support and debugging.

I'm not sure we had consensus for that, because if an app (erroneously) enables spin for all connections using this API, there would be no cover traffic, and we required there to always be some non-spin traffic. 

> @@ -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.
+
+: When the spin bit is disabled, endpoints MAY set the spin bit to any value,

Agreed

> -: 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.
+
+: When the spin bit is disabled, endpoints MAY set the spin bit to any value,
+and MUST accept any incoming value. It is RECOMMENDED that they
+set the spin bit to a random value either chosen independently for each packet,
+or chosen independently for each path and kept constant for that path.
+
+: If the spin bit is enabled for the connection, the endpoint maintains a spin
+value 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 in the endpoint at connection start.  Each endpoint also
+remembers the highest packet number seen from its peer on the connection.
+
+: When a server receives a packet from a client, if that packet has a short

Simply say "when a server receives a short-header packet"?

> +and MUST accept any incoming value. It is RECOMMENDED that they
+set the spin bit to a random value either chosen independently for each packet,
+or chosen independently for each path and kept constant for that path.
+
+: If the spin bit is enabled for the connection, the endpoint maintains a spin
+value 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 in the endpoint at connection start.  Each endpoint also
+remembers the highest packet number seen from its peer on the connection.
+
+: When a server receives a packet from a client, if that packet has a short
+header and if it increments the highest packet number seen by the server from
+the client, the server sets the spin value to the value observed in the spin bit
+in the received packet.
+
+: When a client receives a packet from a server, if the packet has a short

Ditto

-- 
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-219902387