From: Brian Trammell (IETF) <ietf@trammell.ch>
Message-Id: <BB87D8D0-DA01-4C0F-B557-2A728BF19A64@trammell.ch>
Content-Type: multipart/signed;
 boundary="Apple-Mail=_CCA9482D-B9C4-4C39-B94C-278DA1AD019A";
 protocol="application/pgp-signature"; micalg=pgp-sha256
Mime-Version: 1.0 (Mac OS X Mail 11.5 \(3445.9.1\))
Subject: Re: Spin bit decision
Date: Tue, 2 Oct 2018 16:45:11 +0200
In-Reply-To: <HE1PR0701MB2393CDB16819A54B33D22417E2E80@HE1PR0701MB2393.eurprd07.prod.outlook.com>
Cc: Lars Eggert <lars@eggert.org>,
 "alexandre.ferrieux@orange.com" <alexandre.ferrieux@orange.com>,
 "quic@ietf.org" <quic@ietf.org>
To: Marcus Ihlar <marcus.ihlar@ericsson.com>
References: <14531_1538460420_5BB30B04_14531_237_4_c0f3a391-9897-80b0-575b-aa73edad0d52@orange.com>
 <9A63F295-5DC5-4992-9A9C-A98F72C8430D@eggert.org>
 <22440_1538469028_5BB32CA4_22440_292_2_8e00a462-2bbf-acf0-1195-74269a0c2fbd@orange.com>
 <3E3DBC15-FE42-47CF-AF7A-1F2597ED2390@eggert.org>
 <HE1PR0701MB2393CDB16819A54B33D22417E2E80@HE1PR0701MB2393.eurprd07.prod.outlook.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/quic/ZMN0P6D3HrO7Ps2spv_Y1evYeXg>
Precedence: list


--Apple-Mail=_CCA9482D-B9C4-4C39-B94C-278DA1AD019A
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Hi Marcus, Lars, all,

> On 2 Oct 2018, at 13:44, Marcus Ihlar <marcus.ihlar@ericsson.com> =
wrote:
>=20

(=E2=80=A6note: not sure about any of the quoting below=E2=80=A6)

> so what fraction of spin-enabled QUIC traffic would be sufficient? =
Maybe just a ballpark number; 1%, 10%, 100%?
>=20
> MI: It=C2=B4s 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.
>> =46rom 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=E2=80=99re opting in, quictrace gives you all that the =
spin bit does and more, but I don=E2=80=99t see it as a reasonable =
replacement for the spin bit: first, =E2=80=9Csend me a trace=E2=80=9D =
scales way less well than automated =E2=80=9Clocking on=E2=80=9D 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=E2=80=99s 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=E2=80=A6)

I=E2=80=99m 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



--Apple-Mail=_CCA9482D-B9C4-4C39-B94C-278DA1AD019A
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
	filename=signature.asc
Content-Type: application/pgp-signature;
	name=signature.asc
Content-Description: Message signed with OpenPGP

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCAAdFiEEkCTSTp2bIB6fBRHIihK3vwvqRqMFAluzhHcACgkQihK3vwvq
RqPRTxAAyWCJQJ58sA+qTDskTpedP5XkZyqtevJKBhCSgXVKKOOw51akH3NhBFcg
z0gRSxbRHin4EcIWlghDaL7ee3gyVNxrKhIuJ5lFEC6Y3tITUgwhl8z3ORk38ymf
4FpGfxMiMLHPyS0ljd9s2sBeW2c7JpuJ4IGkFQGuKaZZhzuB4+mWdXpcPIVrYoBO
5zFOl5pu9baDqjVbSMN3Yj24xRtO6EoK2sxAlMd0Rs4mHWUoS+mc8tvA8B6AXXIs
nio9o6n75+mozhUhlQB0EjUv/e1N1sV7Lj1TSMP2JiREtSsiQYuKNSzZR2cMqkgm
6DXgP/BsYLAXcNNDYmx8X5fUT7J+6jzj/lB1bj7frfGn9zdJ5FZSH103c/kftvg9
sZrLmira3RkVKBm7X8s6RCzR5aYNCRBfsBYr4d3ulLbZKNxsJgsxZLlzEFo6iM1u
qVnZxQpTuW/V9jSgNxfe1dvvTKCkyJfwYce10MmnwbTkRyuglPyV8WSBJSdNZfXB
GZaYctcBZQkCYH3pXNuksAJbi6NQCrwoQQey1vulgruTGLwlhC6L7NvO1UMm04/A
6Q2CpjAIiK3vto2lhjcjUWytNprBm9V/0cCaVP1WNFFHq7d1U7sgEWYpyxvAfkUS
H79GNfbsN0UvVZH4CVbr0lEvXkis7GUqw1UbyJUrNp5ZhutpZ70=
=2oPo
-----END PGP SIGNATURE-----

--Apple-Mail=_CCA9482D-B9C4-4C39-B94C-278DA1AD019A--