Re: Spin bit decision

[Brian Trammell (IETF) <[e-mail]>]

Hi Marcus, Lars, all,

> On 2 Oct 2018, at 13:44, Marcus Ihlar <[e-mail]> wrote:
> 

(…note: not sure about any of the quoting below…)

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

In any situation other than 100% participation, I think it will be necessary to have client opt-in be exposed up to the user for intraflow diagnostics using the spin bit.

(yes, once you’re opting in, quictrace gives you all that the spin bit does and more, but I don’t see it as a reasonable replacement for the spin bit: first, “send me a trace” scales way less well than automated “locking on” to an available one-bit signal; second, just exposing RTT is somewhat less risky than exposing the full operation of the transport to a partially-trusted operator. quictrace seems more like a debugging tool than an operational diagnostics tool to me. It’s a very cool one, and one we really need to standardize, hopefully after stripping the protobuf cruft off of it, but these questions are IMO completely separate…)

I’m more optimistic than Marcus is with respect to the utility of the spin bit for aggregate (link / path-level) measurements even with small amounts of deployment. It is relatively easy for a midpoint to recognize whether the bit spins or not, and to make those RTT samples available to the aggregate sample (or aggregate baseline / residual) on demand. So for a given aggregate, as long as there's one available active flow, the spin bit provides good RTT samples. This points to even one part in a thousand being useful in the Internet core.

IMO (and this is an opinion; I don't think anyone will have enough data to answer this question for real before Bangkok), as you say one "hyperscalar" turning the spin bit on -- even probabalistically, e.g. as Apple did (still does?) during transition to ECN-by-default on the client side -- would provide more than enough signal on the paths between the access networks of its users (most of them) and the network(s) through which it provides its services.

This would also be the case if one of the top-N CDNs and one major browser vendor did so (again, probabilistic activation suffices). The larger the set of the server networks implementing, the more coverage one would have for access and core network paths.

Cheers,

Brian