Re: [Pearg] Fwd: New Version Notification for draft-andersdotter-rrm-for-rrt-in-http3-00.txt

Amelia Andersdotter <> Tue, 05 November 2019 10:38 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A9A821208C4 for <>; Tue, 5 Nov 2019 02:38:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id ycS0hF2GAbQn for <>; Tue, 5 Nov 2019 02:38:13 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5C77B1208C1 for <>; Tue, 5 Nov 2019 02:38:12 -0800 (PST)
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from <>) id 1iRwDk-0002Kr-Mj; Tue, 05 Nov 2019 11:38:09 +0100
To: Stephen Farrell <>,
References: <> <> <>
From: Amelia Andersdotter <>
Autocrypt:; prefer-encrypt=mutual; keydata= mQINBFjWlnsBEAC+jUN+LJE+mmxEL8lHSrvg47xSBMb9GdtH1Jr8tRSxXiO6R5E+FydsfqkL sjO0dI3x/VnNBi/kgPFFWiAzDEwGTiR/C9b/Muo+xrY+it6e49N56LTPGezrY2dy5yo6VcLl 7UwGz3fIWiNIj7dvuoPMBoO1uacF073E+dqDM5CmNh6o+OrHW8zhUlC9hKgXCq+8XpZJw90H un1zsHF0sRDiurjfYaCcbdAGK9+th9378ed1ZvLVo5uBVQXdydl3eJkNCOELq7VOS7oxSliA uX5/nj9A4LjeeYXgNbwGfKrMjlffP0FcAcgfzg9seqDd1DEk9EVaUMTr32fbWOQHjinXSC7r Lw4xaNfoBebIe1M6z16Xg7+bXXCTdmJYcL9ugmkvT6tGnR12Pfoca1oBwXPvA0VIRi86kCSU D9qvZ3Vl07MKD2hsvFkGZJOQfEaYv5QLpCWv6RCjfDNC05IyMeSW4H18Fr/BoHX8FXHV3+9H LsbJQ/Zrofd/Cm+TKEmXLAtYc7iXvzV+mw3/u0VYqjEy/CRYa62Ah0NNNVIuswfRVIfx3UZo jX4y8j2Kh0jtUV5A4GGf8H3SzQ/cB0I7wTRHU9mCPVCtH6M26nPumL4Zr4D6uGnAmPf9xnlX lokOn2Qxf/mBldsL41PDbEpYhZvvn5kJ/Z9Qh7Fks/hfTbbJowARAQABtEFBbWVsaWEgQW5k ZXJzZG90dGVyIChUZWNobmljYWwgY29uc3VsdGFudCkgPGFtZWxpYUBhcnRpY2xlMTkub3Jn PokCVAQTAQgAPhYhBD1dtsq4UrmIBVpqb/7xwpS06AtVBQJZbJ97AhsjBQkJZgGABQsJCAcC BhUICQoLAgQWAgMBAh4BAheAAAoJEP7xwpS06AtVgrcQAJYg+mhDhui+9xNb9PuRJbelOI7J WlCjSycfaMi+rTJ9FjVKYIE9aug2VV486BZaeqMoOh5wjl61oeRTDHYG6HvhK4w8O/BVPsL0 8MEfYfpFevZmBsInEJypg0r7VJ/SeO9UyaFKUffgvLyiYwk7zJIgx5dHF5Vch0kTtRNc/Wbe 9MGfhl//1Ztl8GjGqzra7MwzaO12ctTDo7LIvXGqrpYm5g7+hRv3+KYVOJvlh4T4deAzNlX1 F/jj4cOYvJJxP2OMPZxoleQZSf63h0hWnKlQWX3UiUZY/M296V6niGDCQHX1q7oz9YWxwUun mNPltaPnTdvE51N98Q+hhrw39XowN0vYhfphaFNrf/crNKTB5Iqx62aAzYwqXQKlh6EtWAri 2rVB9vXxPv+1eL9t/Kga2JyCjmJVtYJxlZWceyW3EKjK+E7qjr1LHDFjV8ZbvN7QRTdjsuzR Ggz3ECba80Ij2/tASE8IXpT/Zb68NeSx3/nDXkIG13inSvGy8yNovzEADXsGO16GSx5Rool/ ECFhTYksMyM73FkvcpvXo6J+neyGEVKDx1Oy213KgTrAOrA+p2hMI2nX9sI5tvWms8XspwQ5 wtmzDribnZNQzpdrb45Chv56LjrKVer9tmraRq8Qe3mL6jXhMPWLim1OeAx6m3qBzKr3QxuG PdADCLHsuQINBFjWlnsBEADFjusaTo9W8VeWluCK/oJqyyyF1wMvou0ldfuoOpUZrOqsY67T M7yBqsv5COPVgAV+xp+axor5oHWxibd283w0Ok4dK6tvtNGwUqyDRlHtQ92DG/u4Tg5eOwrH NUn73/rfeBD9KhKAXcNKKPoccLgR8oQTXpO7eRo+0NI52pXQ6LdZ0wddYeTcHglsNKN1TK+C yYS7xfGolsZXXoBOKcyhfj/ckPFVIHWpGpEtcYWTZWvXgLprzHvpKzkzNyBwejaXE+bqCT2d Rl3omI/e2t3Vq33hFUUSAdxrFF29vMX/YsSnYqsFOIoayna+TRsDFAfZvbvHBOMckeJzvA8y Bdadw7CM08Uw8wqH7n9BA3oq//QpZJekPfrc2E9nM9H0d51T0uStLMbYDWdwxvfPA3p9z8L9 1vobt8bM/Jbhl9h+X2Yq9oBCiTI7b2izYd9FVG4BwBIdeh3bh9R9HExgRjF3XQ6uafT3pcVO PASdv9FRUYH1Va7QWQifoha0B7UXKx1OpX1Z6XR2NQ9KN2MvlwvBKdHtm6tBzUIFzW6D8vUO xiYKBA4fppJt/LJF4jsaCEyI/CVQnkC0yL5DKFOdigxTipwEL9Uc6r7VfR5OAGFd6vzuJFy+ j+/WhzaVT1oVYp6eQXh0bBtqqH2Mq9sAMnIjvaNYIKiQKgMa1Pa3OWQbQQARAQABiQI8BBgB CAAmFiEEPV22yrhSuYgFWmpv/vHClLToC1UFAljWlnsCGwwFCQlmAYAACgkQ/vHClLToC1Xn Rw//W4lzE8FddceKXGRwO/T1u4uzH9EjPCj+3/eHCrLI+h1m7QPyH1DrFAtZBoA6UoaF0+vI AJXM9/HI1FZ09EUdJr5X/+YREErFom4DbE1FK8fpK1/Hw2zI+7Xa8bVkmYrKhMGhi1Gq6Dtk sn/H4USdJL53ZPt10SVNK7H3w93Yp1GC4+0zWjfrsKfsHYZZr2SZyb5/gZlngfgaqiQLhIcP YmiU1GQi9QWkGxWRxk0YQXBwhekewvgltATxlRSCwguAi4uck9fAct9GGdpsshSOgAb9YIAn EV3EqaGnf0PknXp3vNHAZWrfM+RyuNdm2L5TjDU0rIrvyqGP3pR33cREGOAil5Sz2uFArmws Pt8VffbEXlf7qZqRBKaYeKt0qnxKMx1+e1JilVsfb8qtnAWAFDyR0HMlVj/dvGAmq/auPSOA UWRSnDRyT6rv/vXxrbkL4uxWax46qdpDhR15mS5MTng6b5b3Uox7xlveo/Sx71AdNf4goPvB /ntv0DiMuh+fmLGk3zrxs4Xd30Sx+qQwVaXR5xc5rgnF81wvfmuAOb2eP9mpD6DoabkpxC8f Lk17AK7Q1ZTgcZ+8XLRFnavdPrwCa9RU0BF53lJMSTPzyBcMwZ4sqA6Z5IRFVt7rEbSeeD8R Eiawo+FvVt9j0fKdNEBeaJ3WY5hlhNPcUXr4q1U=
Organization: ARTICLE19
Message-ID: <>
Date: Tue, 5 Nov 2019 11:37:53 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.2.0
MIME-Version: 1.0
In-Reply-To: <>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US-large
X-Virus-Scanned: by clamav at
X-Scan-Signature: acce7ce4444675d86ac1a19c5a5a969d
Archived-At: <>
Subject: Re: [Pearg] Fwd: New Version Notification for draft-andersdotter-rrm-for-rrt-in-http3-00.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Privacy Enhancements and Assessment Proposed RG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 05 Nov 2019 10:38:16 -0000

Hey Stephen,

Thanks for your quick response!

On 2019-11-03 22:46, Stephen Farrell wrote:
> I have one suggestion as you head towards finishing this
> work: if you were happy to generalise a bit more in your
> conclusions that could be useful - in particular if you
> could try characterise the kinds of IETF protocols (or
> features of those) that might or might not be suited for
> use of RRM, that could benefit the community.

I'll skirt the issue in the context of spin bit:

One way in which it might be applicable still in QUIC is that it should
be fairly possible to assign the parameters we describe (P, Q, R, m,
etc) in such a way that in Section 3.1.2, you end up in event C or D
(events which permit useful inferences on RRT and latency) about 1/8 of
the time.

This is already called for in Section 17.3.1 of the QUIC draft, but

Section 17.3.1 recommends that 1/8 of all connections to be subject to
measurement at any one time. As I understand this, you need somehow a
global view of all connections to make this happen.

RRM could make statistically useless 7/8 of all measurements made on a
single connection. It cannot really help on all connections in aggregate
because it is tied to a single connection (identified by the
IP-address), but it can obscure/delay measurement on a single connection.

I think Section 7.2 in RFC6973 is a really interesting reference point
here: To adapt Section 3.1.2 as described, you'd have to remove from the
client and server the ability to choose P, Q and R because you'd be
going for some long-run solution to the Markov chain. The QUIC draft
proposal, as far as I understand, requires that some central entity can
stochastically impose activation or de-activation on a client of the
spin bit, such that, on average, only 1/8 of clients have it turned on
at any time. Both of these solutions interfere with User Control! It's
somehow philosophical what you consider a worse interference: static
parameters that are set for a client in a standard procedure or
non-static parameters that are imposed on the client in operation.

Maybe someone who's more directly involved in the QUIC work could
reflect on this.

I'm still thinking about the situation in Section 3.2 - I expect it to
lead to a situation where most observations indicate far too short RTTs,
so you could ask, for instance, if taking only the top 1/8 of
measurements is an option? If you make observations for, say, 160
seconds, then the top 1/8 of measurements will /not/ be equivalent to
measurements taken under a period of 20 seconds (1/8 of 160).


I expect RRM to be applicable in situations where a property does not
need to be communicated exactly for some currently-in-use feature to
work. One idea could be the state of alt-svc when alt-svc is not used.
On the other hand, we could argue that the state should be cleared if it
is not used!

Possibly different judgments could be made for resource-contrained and
non-resource-constrained environments.

Will check some previous work. Thanks again for the feedback!

best regards,


> Cheers,
> S.
>> best regards,
>> Amelia
>> -------- Forwarded Message --------
>> Subject: 	New Version Notification for
>> draft-andersdotter-rrm-for-rrt-in-http3-00.txt
>> Date: 	Sun, 03 Nov 2019 11:42:01 -0800
>> From:
>> To: 	Shivan Sahib <>om>, Amelia Andersdotter
>> <>
>> A new version of I-D, draft-andersdotter-rrm-for-rrt-in-http3-00.txt
>> has been successfully submitted by Amelia Andersdotter and posted to the
>> IETF repository.
>> Name: draft-andersdotter-rrm-for-rrt-in-http3
>> Revision: 00
>> Title: Randomized Response Mechanisms in RRT Measurements for HTTP/3
>> Document date: 2019-11-03
>> Group: Individual Submission
>> Pages: 15
>> URL:
>> Status:
>> Htmlized:
>> Htmlized:
>> Abstract:
>> The latency spin bit is an optional feature included in the QUIC
>> transport protocol [I-D-QUIC]. It enables passive, on-path
>> observations for estimation of latency. This document presents the
>> results of an inquiry into the potential of using randomized response
>> mechanisms (RRM) to reduce privacy loss in latency measurements. It
>> concludes that RRM could be used to introduce choice for clients in
>> preserving privacy in latency measurements. But the trade-offs,
>> especially since the latency spin bit is already optional, do not
>> favour RRM.
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at
>> The IETF Secretariat

Amelia Andersdotter
Technical Consultant, Digital Programme
Chair, RCM TIG, IEEE 802.11


PGP: 3D5D B6CA B852 B988 055A 6A6F FEF1 C294 B4E8 0B55