Re: [quicwg/base-drafts] Updated spinbit text (#2564)

[mirjak <[e-mail]>]

mirjak requested changes on this pull request.



> +is available 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 is an OPTIONAL feature of QUIC. A QUIC stack that chooses to
+support the spin bit MUST implement it as specified in this document.
+
+Each endpoint unilaterally decides if the spin bit is enabled or disabled for a
+connection. Implementations MUST 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 MUST disable
+the spin bit on a randomly chosen fraction of connections. The random selection
+process SHOULD be designed such that on average the spin bit is disabled for at
+least one eighth of network paths. The selection process should be externally
+unpredictable but consistent for any given combination of source and destination
+address and port. The selection process performed at the beginning of the

Should it be consistent for address/port forever? Is this restriction actually needed...? What's the reasoning for this? 

> +the spin bit on a randomly chosen fraction of connections. The random selection
+process SHOULD be designed such that on average the spin bit is disabled for at
+least one eighth of network paths. The selection process should be externally
+unpredictable but consistent for any given combination of source and destination
+address and port. The selection process performed at the beginning of the
+connection SHOULD be applied for all paths used by the connection.
+
+In case multiple connections share the same five-tuple, i.e. same source and
+destination IP address and UDP port the setting of the spin bit needs to be
+coordinated across all connections to ensure a clear signal to any on path
+measurement point, however that might not be feasible.
+
+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.

I this we should recommend to set to the same value for the whole connection. That's easier to implement, easier to cope with in the network, and I don't see a benefit of randomly setting it on a per-packet basis for the endpoint.

> +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 short header packet that increments the highest
+packet number seen by the server from the client, it sets the spin value to be
+equal to the spin bit in the received packet.
+
+When a client receives a short header packet that increments the highest
+packet number seen by the client from the server, it sets the spin value to the
+inverse of the spin bit in the received packet.
+

Maybe add a sentence, explaining why this is done, e.g. "With this mechanism, the server reflects the spin value received, while the client 'spins' it after one RTT. On network observers can measure the time between two spin bit toggle events and thereby estimate the end-to-end RTT of a connection, e.g. for network monitoring purposes."

-- 
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/2564#pullrequestreview-221170219