Responding to the DISCUSS only. On Thu, Jan 7, 2021, at 04:43, Robert Wilton via Datatracker wrote: > 1) It would be helpful to clarify what the expected behaviour is for an > implementation that chooses not to support the spin-bit. Does it just leave > the bit set as 0, or is it meant to follow the same behaviour as if spin-bit > is > supported but disabled?
The working group did not reach consensus on what an implementation should do, therefore the document does not say anything specific. Indeed, I will go further and say that we have pretty firm consensus on what is documented. We did get good information, based on implementation and experimental experience, that filtering out bad values was easy, even trivial. > 2) This may not be discuss worthy, but some of the spin bit behaviour is > inconsistently defined between the quic transport and quic manageability > drafts. As you correctly observe, the transport draft is authoritative in this regard. As the manageability draft is not yet finished, I would expect any inconsistencies to be addressed there. > But my two main discuss questions/comments relate to whether the spin-bit, as > specified in quic transport, achieves its goal. I appreciate that there are > individuals who don't think that it is required at all, conversely some > network > operators believe that they will lose vital information needed to help manage > their networks, and presumably we are trying to find a pragmatic compromise > between these two positions. I would not say compromise, but rather that this is a mechanism that we know is acceptable to (some) endpoint implementations and know to be valuable to (some) network operators. It is also optional (for both), relatively low cost to specify, implement, and deploy. > 1) I find it hard to understand why a server is allowed to independently > decide > whether or not to support the spin bit on a connection? Shouldn't the client > (or administrator of the client system) that opened the connection be able to > choose whether they want the RTT to be monitorable via the spin bit? What is > the reasoning for allowing the server (or server administrator) to be able to > independently be able to decide what is best for the client? The consensus of the working group is that active spinning must be made independently by either endpoint and that having an endpoint dictate the actions of its peer for this feature was not desirable. Hence the design as documented. > 2) In the case that the spin-bit is disabled, I don't understand the benefit > of > injecting a random spin bit value in each packet rather than always setting it > to a per connection random value. It seems that whether or not the randomness > is injected, it is expected to be feasible to extract the RTT for those > connections that are genuinely spinning the bit (or otherwise the spin bit is > entirely pointless), but it just seems to make it computationally harder to > extract the signal from the noise. Perhaps the goal here is reduce the > ability > for pervasive monitoring to occur, but that feels a bit like security through > obscurity. Randomness is an option, not a requirement. Some implementations just send 0 or 1 always. As previously noted, extracting signal from noise was proven to be relatively easy. This was, I believe, what convinced those who wanted to read the spin bit to accept the consensus position (though I can't speak for those people). > Some enlightenment for these questions would be appreciated. I hope that what enlightenment I was able to share suffices.
