RE: Spin bit decision

[Marcus Ihlar <[e-mail]>]

Hi,

-----Original Message-----
From: QUIC <[e-mail]> On Behalf Of Lars Eggert
Sent: den 2 oktober 2018 13:00
To: [e-mail]
Cc: IETF QUIC WG <[e-mail]>
Subject: Re: Spin bit decision

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%?

MI: It´s a difficult question to answer as there are different uses of the spin information ranging from active troubleshooting sessions for a small set of subscribers to passive monitoring on a large scale e.g for KPI dashboards.
>From a spin consumer perspective the bigger the fraction the better of course, but the pain thresholds would be different from usecase to usecase.
The active troubleshooting case would require either that a very large portion of traffic is spin-enabled or that it would be possible for a user to selectively enable the functionality.
The large scale monitoring case would likely be useful even if  only a few % of flows are spin-enabled.

> 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