Internet DRAFT - draft-andersdotter-rrm-for-rtt-in-quic
draft-andersdotter-rrm-for-rtt-in-quic
Internet Research Task Force A. Andersdotter
Internet-Draft CENTR
Intended status: Informational S. Sahib
Expires: February 15, 2021 Salesforce
August 14, 2020
An Investigation into Randomized Response Mechanisms in RTT Measurements
for QUIC
draft-andersdotter-rrm-for-rtt-in-quic-01
Abstract
The latency spin bit is an optional feature included in the QUIC
transport protocol, as standardized by the Internet Engineering Task
Force (IETF). 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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on February 15, 2021.
Copyright Notice
Copyright (c) 2020 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of
Andersdotter & Sahib Expires February 15, 2021 [Page 1]
Internet-Draft rrm-for-rtt-in-quic August 2020
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Randomized Response Mechanisms . . . . . . . . . . . . . . . 2
3. Application to latency spin bit . . . . . . . . . . . . . . . 4
4. Spin bit assumptions . . . . . . . . . . . . . . . . . . . . 6
5. Model specification . . . . . . . . . . . . . . . . . . . . . 8
6. Simulation . . . . . . . . . . . . . . . . . . . . . . . . . 9
7. Edge transition RRM . . . . . . . . . . . . . . . . . . . . . 9
7.1. One and a half round-trip explained . . . . . . . . . . . 9
7.2. A closer look at the loop . . . . . . . . . . . . . . . . 10
7.3. Using model to restrict measurements . . . . . . . . . . 11
8. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 12
9. Informative References . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction
At the IETF104 convening of the Privacy Enhancements and Assessments
Research Group (PEARG), a presentation on Differential Privacy
([AA-CL]) gave rise to the idea of trying to apply randomized
response methods to the QUIC spin bit described in [TRAMMEL] and
[KUEHLEWIND]. The spin bit, now incorporated in Section 17.3.1
[I-D-QUIC], has generated controversy from a privacy perspective,
both in the Working Group meetings and on the QUIC email list.
Controversies were re-ignited through the publication of a Human
Rights Consideration in [TENOEVER-MARTINI] in 2019. Applying RRM is
an attempt to address two problems: the privacy loss incurred through
the spin bit, and considering the potential of using RRM to have more
than one bit assisting in latency measurement as per previous
proposals.
2. Randomized Response Mechanisms
Randomized response trials were originally suggested by social
scientist Stanley Warner to increase response rates in surveys on
sensitive topics, such as political affiliation or sexuality
[WARNER]. At the flip of a coin (or other random device), a survey
taker would answer the opposite question to the one that the survey
giver wanted to ask. For instance, if the survey giver wants to find
out whether a person has been affiliated with a communist group, the
Andersdotter & Sahib Expires February 15, 2021 [Page 2]
Internet-Draft rrm-for-rtt-in-quic August 2020
survey taker would instead answer, at some fixed probability, whether
they had never been affiliated with a communist group. The effect is
the same as if the survey taker would give a false answer to the
survey question with some known probability.
This method provoked a flurry of statistical research throughout the
1970s and 80s, with statisticians considering a range of problems in
estimation and variance reduction for estimators in the presence of
noise on survey responses [RAO].
Recently, randomized response mechanisms has again gained traction,
through the work of Cynthia Dwork et al on differential privacy
[DWORK] or mechanisms for statistical data collection over
(presumably large) user sets, such as [RAPPOR]. These developments
had led to renewed interest in randomized response mechanisms in the
statistical community, with text books [FOX] and handbooks [RAO]
covering a large range of possible situations where randomizing
responses over a set of outcomes on an individual respondent basis
may still enable useful inferences about the population to which the
individual belongs.
Randomized response trials were originally created for binary
environments: if a series of measurements have only two possible
outcomes (0 or 1, yes or no, true or false, for example), allowing
individual respondents to answer "falsely" at a predictable rate will
still preserve the ability to make inferences on the entire set of
respondents. The latency spin bit, being a bit, is a binary outcome
variable. Each time it is measured, the idea is that it can either
"truthfully" report its value as what it should be according to
[TRAMMEL], or it could, at some known rate or probability, report the
opposite value.
RRMs are easily illustrated for binary response problems. Let's take
as an example "Did you go to the last IETF meeting?" The answer to
this question is either yes or no. Let us suppose that 25% of all
responses are known to be false, and that 80% of all respondents
answered yes. Then 60% of the respondents who answered yes can be
assumed to have done so truthfully, while 5% of the respondents who
answered no have done so falsely. 65% of the respondents can
therefore be estimated to have actually attended the last IETF
meeting.
RRMs can also be applied to multiple choice questions. Estimation of
true proportions becomes more difficult as the number of possible
answers per question goes up. Further examples, including formulas
and calculations, can be found in [RAO] and [FOX].
Andersdotter & Sahib Expires February 15, 2021 [Page 3]
Internet-Draft rrm-for-rtt-in-quic August 2020
3. Application to latency spin bit
As described in [TRAMMEL], the latency spin bit is a mechanism for
measuring round-trip-times (RTT) in the QUIC protocol. The
investigation in this document relies on [TRAMMEL] for its
understanding of the basic operation of the latency spin bit, and in
particular the following paragraphs and figures from the document are
quoted to facilitate the description of RRM below:
[Begin quote] Initially, during connection establishment, no packets
with a spin bit are in flight, as shown in Figure 1.
+--------+ - - - - - +--------+
| | --------> | |
| Client | | Server |
| | <-------- | |
+--------+ - - - - - +--------+
Figure 1: Initial state, no spin bit between client and server
Either the server, the client, or both can begin sending packets with
short headers after connection establishment, as shown in Figure 2;
here, no spin edges are yet in transit.
+--------+ 0 0 - - - +--------+
| | --------> | |
| Client | | Server |
| | <-------- | |
+--------+ - - 0 0 0 +--------+
Figure 2: Client and server begin sending packets with spin 0
Once the server's first 0-marked packet arrives at the client, the
client sets its spin value to 1, and begins sending packets with the
spin bit set, as shown in Figure 3. The spin edge is now in transit
toward the server.
Andersdotter & Sahib Expires February 15, 2021 [Page 4]
Internet-Draft rrm-for-rtt-in-quic August 2020
+--------+ 1 0 0 0 0 +--------+
| | --------> | |
| Client | | Server |
| | <-------- | |
+--------+ 0 0 0 0 0 +--------+
Figure 3: The bit begins spinning
Five ticks later, this packet arrives at the server, which takes its
spin value from it and reflects that value back on the next packet it
sends, as shown in Figure 4. The spin edge is now in transit toward
the client.
+--------+ 1 1 1 1 1 +--------+
| | --------> | |
| Client | | Server |
| | <-------- | |
+--------+ 0 0 0 0 1 +--------+
Figure 4: Server reflects the spin edge
Five ticks later, the 1-marked packet arrives at the client, which
inverts its spin value and sends the inverted value on the next
packet it sends, as shown in Figure 5.
obs. points X Y
+--------+ 0 1 1 1 1 +--------+
| | --------> | |
| Client | | Server |
| | <-------- | |
+--------+ 1 1 1 1 1 +--------+
Y
Figure 5: Client inverts the spin edge
[End quote]
In each iteration going from Figure 4 to Figure 5 a sequence of 0s or
1s the length of which is k0 for iteration 0, k1 for iteration 1, and
so forth, can be observed (by on-path observers X or Y in Figure 5).
Andersdotter & Sahib Expires February 15, 2021 [Page 5]
Internet-Draft rrm-for-rtt-in-quic August 2020
The length of each sequence equals the amount of ticks required to
pass from the client back to the client. After observation n lengths
of such sequences, (k[0], ..., k[n]), an average can be taken over
k[j]. This average can be multiplied by the amount of time per tick
(a quantity which is assumed to be known) to get a value for the
round-trip time (RTT).
Applying randomized response mechanisms (RRMs) perturbs the observed
sequence lengths (k[0], ..., k[n]). The perturbation will have the
effect of lengthening, shortening, or making more arbitrary the
lengths of the sequences, thereby increasing the variance, or disable
the possibility, of an estimator of the true RTT value.
4. Spin bit assumptions
Deciding on a RRM scheme for RTT in QUIC requires a more explicitly
defined mechanism for changing the spin value (the value of the spin
bit being transmitted from the client or server) than presently is
the case in [TRAMMEL]. For instance, the way in which the server is
specified to change its spin value currently is:
"The server initializes its spin value to 0. When it receives a
packet from the client, if that packet has a short header and if it
increments the highest packet number seen by the server from the
client, it sets the spin value to the spin bit in the received
packet." (Section 2)
while the mechanism for changing the spin value in the client is
"The client initializes its spin value to 0. When it receives a
packet from the server, if the packet has a short header and if it
increments the highest packet number seen by the client from the
server, it sets the spin value to the opposite of the spin bit in the
received packet." (Section 2)
The goal of the designer in [TRAMMEL] is to cause the spin bit to
change its value once per round-trip. Our design goal is different.
We want to have the spin bit only sometimes change its value once per
round-trip, while it might other times change its value twice per
round-trip, or not at all. Additionally, we have the goal of
ensuring that we can exercise control over what percentage of round-
trips give useful measurements. To simultaneously fill all of those
requirements, we introduce the following additional constraints on
updating the spin value:
1. Client and server have an internal spin value (NV) which decides
the value of the next outgoing spin bit.
Andersdotter & Sahib Expires February 15, 2021 [Page 6]
Internet-Draft rrm-for-rtt-in-quic August 2020
2. Clients and server keep track of the second-to-last incoming
spin bit (SLISB), and the last incoming spin bit (LISB).
3. The NV initializes to 0 at both the client and the server.
4. An inversion of the client's NV is triggered if SLISB and LISB
have different values. Notably, no comparison between the SLISB
or LISB and the NV is made. The value of the NV, which
determines the value of the next spin bit transmitted, is set
independently of the value of the SLISB and LISB.
5. An inversion does not happen with probability q, even when it
should.
6. A reflection of the server's NV is also triggered if SLISB and
LISB have different values.
7. A reflection does not happen with probability p, even when it
should.
8. In the absence of a triggering event, the NV does not change its
value and the client or server continue to transmit bits holding
the current NV value.
9. Client and server act independently of one another, so that
neither client or server have any way of determining whether the
other has reflected or inverted ``truthfully''.
10. A special case is the first time a spin bit is recorded by a
client or server (immediately after initialization). In this
case, the client and server both update the NV truthfully.
We illustrate these assumptions with a truth table for the client in
Figure 6 and for the server in Figure 7.
Andersdotter & Sahib Expires February 15, 2021 [Page 7]
Internet-Draft rrm-for-rtt-in-quic August 2020
+----------+-------+------+-------------------+
| NVclient | SLISB | LISB | NV'client |
+----------+-------+------+-------------------+
| (0) | (-) | (0) | (1)* |
| 0 | 0 | 0 | 0 |
| 0 | 0 | 1 | 0(q) or 1(1-q) |
| 0 | 1 | 0 | 0(q) or 1(1-q) |
| 0 | 1 | 1 | 0 |
| 1 | 0 | 0 | 1 |
| 1 | 0 | 1 | 1(q) or 0(1-q) |
| 1 | 1 | 0 | 1(q) or 0(1-q) |
| 1 | 1 | 1 | 1 |
+----------+-------+------+-------------------+
Figure 6: Client truth table for inversion of the client's internal
spin bit value NVclient. NV'client in the right-most column
constitutes a truthful inversion with probability (1-q) and a lying
inversion with probability q. * A special case is the firstround-trip
after initialization.
+----------+-------+------+----------------+
| NVclient | SLISB | LISB | NV'client |
+----------+-------+------+----------------+
| (0) | (-) | (0) | (0)* |
| 0 | 0 | 0 | 0 |
| 0 | 0 | 1 | 0(1-p) or 1(p) |
| 0 | 1 | 0 | 0(1-p) or 1(p) |
| 0 | 1 | 1 | 0 |
| 1 | 0 | 0 | 1 |
| 1 | 0 | 1 | 1(1-p) or 0(q) |
| 1 | 1 | 0 | 1(1-p) or 0(q) |
| 1 | 1 | 1 | 1 |
+----------+-------+------+----------------+
Figure 7: Server truth table for reflection of the server's internal
spin bit value NVserver. * A special case is the firstround-trip
after initialization.
5. Model specification
There are two conceivable ways to achieve RRM for RTT measurements:
1. The reflection and/or inversion is not activated by the arrival
of an edge bit with some probability (``Edge transition RRM''),
or
2. the server or the client randomizes which bit it transmits at
each bit (``Each bit RRM'').
Andersdotter & Sahib Expires February 15, 2021 [Page 8]
Internet-Draft rrm-for-rtt-in-quic August 2020
In particular, in QUIC25 draft [I-D-QUIC], section 17.1.3, a
randomization mechanism is called for that renders 7/8 of all spin
bit measurements non-useful for the purpose of inferring latency.
This encourages us to seek some mathematical solution that can at
least guarantee that 7/8 of all traffic streams to which a spin bit
is attached are not useful for RTT measurements.
6. Simulation
Simulation code for both cases discussed in this document ("RRM at
each bit" and "RRM at edge transition") and instructions are hosted
on GitHub [SIMULATION].
7. Edge transition RRM
7.1. One and a half round-trip explained
Recall the assumptions in Section 4. Suppose that a round trip takes
2n time units. If we initialize spin bits at the client and server
to 0 (assumption 3), they will both see (SLISB, LISB)=(-,0) after n
time units, and an NV change is triggered (assumption 10). Now the
client maintains an NV value of 1 while the server sets its NV value
to 0.
The client now transmits spin bits valued 1 to the server, while the
server continues to transmit spin bits valued 0 to the client. After
another n time units (2n time units in total) the client sees a
(SLISB, LISB)-tuple valued (0,0), while the server will see a (SLISB,
LISB)-tuple (1,0) (assumption 2). This triggers an attempted
reflection by the server, meaning that its NV should be changed from
0 to 1 (assumption 6), while a change in the client NV (1) is not
triggered (assumption 4). Suppose that the server truthfully
reflects its NV to 1. Now the client continues to transmit 1s to the
server, while the server transmits 1s to the client.
After yet another n time units (3n time units in total) the server
will see the (SLISB, LISB)-tuple (1,1) and therefore do nothing
(assumption 8), while the client sees the tuple (0,1) and tries to
update its NV (assumption 4). If the client does not do this, so
that the client NV remains at 1, then the client will be transmitting
1s to the server and the server will be transmitting 1s to the
client.
After 4n time units, the (SLISB, LISB)-tuples seen by both the client
and the server will be (1,1), and both NVs will also be set to 1.
Consequently, the (lack of) NV updates after 3n time units have
landed us in the situation that there is no longer any possibility
Andersdotter & Sahib Expires February 15, 2021 [Page 9]
Internet-Draft rrm-for-rtt-in-quic August 2020
for a (SLISB, LISB)-tuple to have different values, and we have ended
up in a loop.
This is encouraging, since a loop can be escaped by randomly re-
initializing the spin bit after some time that we can choose.
7.2. A closer look at the loop
As in the previous section, let the RTT be 2n time units. If
NV[client] = NV[server] at time n, and the NVs remain equal to each
other at time 2n, the process will be in a loop. If we describe the
four different combinations of NVs in the following way:
(NV[client], NV[server]) = (0,0), (1,0), (0,1) or (1,1)
then, in the example above (Section 7.1), we would have the following
sequence of transitions:
(0,0)[init] -> (1,0) -> (1,1) -> (1,1) \]
Referring back to the truth tables in Figure 6 and Figure 7, we can
work out how these transitions exactly happen. For example, the
transition (1,0) -> (1,1) can happen in the following two ways:
The client attempts to update NV[client] after receiving a triggering
(SLISB, LISB)-tuple but fails to invert or it does not receive a
triggering (SLISB, LISB)-tuple at all, while the server updates
NV[server] truthfully after receiving a triggering (SLISB, LISB)-
tuple. The server has one way of transitioning its NV from 0 to 1,
while the client has two ways of transitioning its NV from 1 to 1.
We know the probabilities that reflections or inversions will not
happen (assumptions 5 and 7 in Section 4), but also need to know when
a triggering (SLISB, LISB)-tuple will be received. A client receives
such a tuple at time kn if the server truthfully updated its NV at
time (k-1)n. In fact, a loop occurs as soon as the server does not
update its NV truthfully. A (SLISB, LISB)-tuple received by the
client will necessarily have the form
(NV[server,t=n(k-1)], NV[server,t=n(k-2)]
and an NV update is triggered only if this tuple contains two
different values. From assumption 10 in Section 4 we have that
NV[server,t=0] = NV[server,t=n] at t=0, n
and is updated only because NV[client] is updated at t=n by the same
assumption. The fact that they are equal means that necessarily
Andersdotter & Sahib Expires February 15, 2021 [Page 10]
Internet-Draft rrm-for-rtt-in-quic August 2020
NV[client,t=2n] = NV[client,t=2n]
with NV[client,t] assuming a new value only if $NV[server,s] changes.
But if the server would lie once (and not update its NV), we get
NV[server,t=n(k-1)] = NV[server,t=nk] = NV[server,t=n(k+1)]
rendering the server unable to transmit values that can trigger an
update of the client NV value.
7.3. Using model to restrict measurements
With the insights from Section 7.2 we can choose p and q from
Section 4, and define some re-initialization criteria for the spin
bit, for an alternative mechanism to achieve the targets set out in
the QUIC spin bit specification in [I-D-QUIC]:
"Each endpoint unilaterally decides if the spin bit is enabled or
disabled for a connection. Implementations MUST allow administrators
of clients and servers to disable the spin bit either globally or on
a per-connection basis. Even when the spin bit is not disabled by
the administrator, endpoints MUST disable their use of the spin bit
for a random selection of at least one in every 16 network paths, or
for one in every 16 connection IDs. As each endpoint disables the
spin bit independently, this ensures that the spin bit signal is
disabled on approximately one in eight network paths." (sec. 17.3.1)
In order to estimate the round-trip time, an on-path observer needs
to have access to at least one full round-trip worth of passing spin
bits. The first such accessible round-trip after initialization is
the sequence of 1s transmitted by the client, if truthfully reflected
by the server with probability (1-p). The second such accessible
round-trip is the sequence of 0s that follow upon additionally
truthful inversions and reflections by the client and server
respectively. The cumulative probability of two accessible round-
trips is therefore (1-p)(1-q)(1-p), and in general
P[X round-trips are complete and measurable] = (1-p)^x (1-q)^(x-1)
From this we can derive the expected value
E[X] (1-p) S[x [(1-p)(1-q)]^(x-1) = (1-p)/((1-(1-p)(1-q))^2)
where S[.] is the sum over x.
By the specification quoted above, we want this to be approximately
equal to 7/8. A range of values for (p,q) can satisfy this
Andersdotter & Sahib Expires February 15, 2021 [Page 11]
Internet-Draft rrm-for-rtt-in-quic August 2020
criterion, and, for instance, if the client always tells the truth
(i.e. q=0) then p=1/8, meaning that the server lies 1/8 of the time.
Once the client or server have lied for the first time, all future
spin bit values cannot be used for measuring round-trip time unless
the NV update process is re-initiated. This could be achieved
through the client arbitrarily updating its NV in contradiction with
assumption 8 of Section 4 after some period of time, which could be
chosen according to a geometric distribution of some expectation r.
However, in the time leading up to re-initialization the utility for
an on-path observer of recording the spin bit value is nil.
It follows that the actual proportion of useless measurements will be
far higher than the 1/8 that is specified in the draft.
A solution is to choose p, q so that the expected value of the number
of useful round-trip measurements is higher than 7/8. If we solve
for p, q when E[X] = 56/59, we would want the client to re-initiate
the NV update procedure after an average of 5 round-trip periods to
get an expected 56/64 = 7/8 useful measurements. This supposes, of
course, that the client has a way of establishing the approximate
round-trip time that is independent of the spin bit.
Additional privacy gains, or at least diminished availability of
useful RTT measurements, would be achieved by solving for an expected
value lower than 7/8. Since not all measurements are rendered
useless by applying RRM, there will eventually always be a time when
an on-path observer can make inferences about round-trip time.
8. Discussion
It is possible to apply to RRM to QUIC RTT measurements in a way
which delays estimation of RTT. However, it is unclear whether RRM
has advantages larger than already existing privacy mechanisms
included in the QUIC draft (such as making the spin bit optional, or
requiring that 1/8 of all streams are not measurable). The privacy
concern associated with a spin bit is that latency measurements will
enable inference of the location or distance of the device associated
with that particular IP address. But the whole point of differential
privacy mechanisms, including RRM, is using statistical methods to
ensure that data can be made more privacy-preserving while also
preserving the data utility. In the case of the spin bit, it is the
utility of the data that allegedly violates privacy, which means
differential privacy is an intuitively bad tool to address privacy
concerns.
The spin bit is associated with an IP address, which creates
linkability. Any differential privacy mechanism will not remove
Andersdotter & Sahib Expires February 15, 2021 [Page 12]
Internet-Draft rrm-for-rtt-in-quic August 2020
linkability from the spin bit, and so preserves that angle of privacy
violation.
RRM could potentially be used to fulfill requirements from
[I-D-QUIC], sec. 17.3.1, in a slightly more flexible way than is
currently discussed at the IETF. In particular, the parameters p, q
and r could be adjusted to accommodate for any proportion of useful
measurements. If r is left for the client to decide, the client may
even have influence over the extent to which RTT measurements through
the QUIC spin bit is made more difficult (see e.g. [RFC6973], sec.
7.2).
In order to realize such advantages the functioning of the QUIC spin
bit does, however, need to be more stringently specified, in
particular in line with our suggestions in Section 4.
9. Informative References
[AA-CL] Andersdotter, A. and C. Laengstroem, "Differential Privacy
(PEARG, IETF104)", March 2019,
<https://datatracker.ietf.org/meeting/104/materials/
slides-104-pearg-amelia-christoffer-differential-privacy-
00>.
[DWORK] Roth, A. and C. Dwork, "The Algorithmic Foundations of
Differential Privacy", 2014,
<https://www.cis.upenn.edu/~aaroth/Papers/
privacybook.pdf>.
[FOX] Fox, J., "Randomized Response and Related Methods:
Surveying Sensitive Data", February 2017.
[I-D-QUIC]
Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed
and Secure Transport", September 2019,
<https://tools.ietf.org/html/draft-ietf-quic-transport-
23>.
[KUEHLEWIND]
Kuehlewind, M. and B. Trammel, "The QUIC Latency Spin Bit
(draft-ietf-quic-spin-exp-01)", October 2018,
<https://tools.ietf.org/html/draft-ietf-quic-spin-exp-01>.
[RAO] Rao, T. and C. Rao, ""Review of Certain Recent Advances in
Randomized Response Techniques" in C.R. Rao (Ed.),
Handbook of Statistics, Elsevier B.V, Oxford (UK).", 2016.
Andersdotter & Sahib Expires February 15, 2021 [Page 13]
Internet-Draft rrm-for-rtt-in-quic August 2020
[RAPPOR] Erlingsson, U., Korolova, A., and V. Pihur, "RAPPOR:
Randomized Aggregatable Privacy-Preserving Ordinal
Response", arXiv:1407.6981v2 [cs.CR]", 2014.
[RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Petersen, J.,
Morris, J., Hansen, M., and R. Smith, "Privacy
Considerations for Internet Protocols", RFC 6973,
DOI 10.17487/RFC6973, July 2013,
<https://www.rfc-editor.org/info/rfc6973>.
[SIMULATION]
Sahib, S. and A. Andersdotter,
"https://github.com/ShivanKaul/draft-andersdotter-rrm-for-
rrt/tree/master/spinbit_simulation", November 2019,
<https://github.com/ShivanKaul/draft-andersdotter-rrm-for-
rrt/tree/master/spinbit_simulation>.
[TENOEVER-MARTINI]
Martini, B. and N. Ten Oever, "QUIC Human Rights Review
(draft-martini-hrpc-quichr-00)", October 2018,
<https://tools.ietf.org/html/draft-martini-hrpc-quichr-
00>.
[TRAMMEL] Trammel, B., Boucadair, M., Even, R., Fioccola, G.,
Fossati, T., Ihlar, M., Morton, A., and E. Stephan,
"Adding Explicit Passive Measurability of Two-Way Latency
to the QUIC Transport Protocol (draft-trammell-quic-spin-
03)", May 2018, <https://www.ietf.org/archive/id/draft-
trammell-quic-spin-03.txt>.
[WARNER] Warner, S., ""Randomized response: a survey technique for
eliminating evasive answer bias." J. Am. Stat. Assoc. 60
(309), 63-69.", 1965.
Authors' Addresses
Amelia Andersdotter
CENTR
Rue Belliard 30
1040 Brussels
Belgium
Email: amelia.ietf@andersdotter.cc
Andersdotter & Sahib Expires February 15, 2021 [Page 14]
Internet-Draft rrm-for-rtt-in-quic August 2020
Shivan Sahib
Salesforce
Email: shivankaulsahib@gmail.com
Andersdotter & Sahib Expires February 15, 2021 [Page 15]
