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

From: Amelia Andersdotter <[email-masked]>
Date: Sun, 3 Nov 2019 20:46:45 +0100

Dear all,

Since this spring, I've had a conversation with Shivan about the
possibility of using differential privacy tools in QUIC to alleviate
privacy concerns with the spin bit. We were not able to establish any
immediate reason for differential privacy being an appropriate
additional tool for this purpose.

The resulting inquiry is this draft, which is now posted with a view to
gathering comments from all of you (we hope).

It will not be presented in Singapore, but we're hoping to develop it
over the upcoming months. Please reach out with any questions or comments!

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: 	[email-masked]
To: 	Shivan Sahib <[email-masked]>, Amelia Andersdotter
<[email-masked]>

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:
https://www.ietf.org/internet-drafts/draft-andersdotter-rrm-for-rrt-in-http3-00.txt
Status:
https://datatracker.ietf.org/doc/draft-andersdotter-rrm-for-rrt-in-http3/
Htmlized:
https://tools.ietf.org/html/draft-andersdotter-rrm-for-rrt-in-http3-00
Htmlized:
https://datatracker.ietf.org/doc/html/draft-andersdotter-rrm-for-rrt-in-http3

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 tools.ietf.org.

The IETF Secretariat

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 3 Nov 2019 21:46:03 +0000

Hiya,

I had a quick read...

> over the upcoming months. Please reach out with any questions or comments!

My main comment is to say thanks! It's great to see people
document paths-not-taken like this and in such detail.

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.

Cheers,
S.

---

From: Amelia Andersdotter <[email-masked]>
Date: Tue, 5 Nov 2019 11:37:53 +0100

Hey Stephen,

Thanks for your quick response!

> 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
differently:

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,

Amelia

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

ARTICLE19
www.article19.org

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