Re: Spin bit decision

[Lars Eggert <[e-mail]>]

Hi,

again, as an individual:

On 2018-10-2, at 11:28, [e-mail] wrote:
> Experience with debugging our networks in several countries shows that (1) all
> segments may misbehave, and (2) sample size is very often an issue, in that some
> problems are triggered by a non-obvious conjunction of parameters that is
> extremely sensitive to sampling bias. So, the more support for measurement, the
> better. TCP shines because clear headers are ubiquitous, not an opt-in debug
> mode, nor a randomly enabled feature in X% of flows.

so what fraction of spin-enabled QUIC traffic would be sufficient? Maybe just a ballpark number; 1%, 10%, 100%?

> May I ask why this question is key ? Are you envisioning a situation where v1
> would allow for the spin bit as a negotiated option instead of just requiring it
> ? Added complexity and inferior outcome: what is the motivation ?

The WG hasn't really discussed yet what requirements level any inclusion of the spin bit into the main spec would have, and there could obviously be different levels of requirement for clients and servers.

But irrespective of what - if anything - the spec chooses to say, deployed implementations can obviously choose to do whatever they wish, since the spin bit is not affecting interoperability at all.

So for the spin bit to fulfill its intended purpose, at least some client deployments and at least some server deployments that spin and echo the bit are required. Enough on both sides so that a sufficient fraction of the traffic is spinning (which is what my first question was about.) 

Lars