idnits 2.17.1 draft-andersdotter-rrm-for-rtt-in-quic-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 467: '... Implementations MUST allow administra...' RFC 2119 keyword, line 470: '...rator, endpoints MUST disable their us...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 14, 2020) is 1350 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '0' on line 230 == Missing Reference: 'X' is mentioned on line 513, but not defined Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Research Task Force A. Andersdotter 3 Internet-Draft CENTR 4 Intended status: Informational S. Sahib 5 Expires: February 15, 2021 Salesforce 6 August 14, 2020 8 An Investigation into Randomized Response Mechanisms in RTT Measurements 9 for QUIC 10 draft-andersdotter-rrm-for-rtt-in-quic-01 12 Abstract 14 The latency spin bit is an optional feature included in the QUIC 15 transport protocol, as standardized by the Internet Engineering Task 16 Force (IETF). It enables passive, on-path observations for 17 estimation of latency. This document presents the results of an 18 inquiry into the potential of using randomized response mechanisms 19 (RRM) to reduce privacy loss in latency measurements. It concludes 20 that RRM could be used to introduce choice for clients in preserving 21 privacy in latency measurements. But the trade-offs, especially 22 since the latency spin bit is already optional, do not favour RRM. 24 Status of This Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at https://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on February 15, 2021. 41 Copyright Notice 43 Copyright (c) 2020 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (https://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 59 2. Randomized Response Mechanisms . . . . . . . . . . . . . . . 2 60 3. Application to latency spin bit . . . . . . . . . . . . . . . 4 61 4. Spin bit assumptions . . . . . . . . . . . . . . . . . . . . 6 62 5. Model specification . . . . . . . . . . . . . . . . . . . . . 8 63 6. Simulation . . . . . . . . . . . . . . . . . . . . . . . . . 9 64 7. Edge transition RRM . . . . . . . . . . . . . . . . . . . . . 9 65 7.1. One and a half round-trip explained . . . . . . . . . . . 9 66 7.2. A closer look at the loop . . . . . . . . . . . . . . . . 10 67 7.3. Using model to restrict measurements . . . . . . . . . . 11 68 8. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 9. Informative References . . . . . . . . . . . . . . . . . . . 13 70 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 72 1. Introduction 74 At the IETF104 convening of the Privacy Enhancements and Assessments 75 Research Group (PEARG), a presentation on Differential Privacy 76 ([AA-CL]) gave rise to the idea of trying to apply randomized 77 response methods to the QUIC spin bit described in [TRAMMEL] and 78 [KUEHLEWIND]. The spin bit, now incorporated in Section 17.3.1 79 [I-D-QUIC], has generated controversy from a privacy perspective, 80 both in the Working Group meetings and on the QUIC email list. 81 Controversies were re-ignited through the publication of a Human 82 Rights Consideration in [TENOEVER-MARTINI] in 2019. Applying RRM is 83 an attempt to address two problems: the privacy loss incurred through 84 the spin bit, and considering the potential of using RRM to have more 85 than one bit assisting in latency measurement as per previous 86 proposals. 88 2. Randomized Response Mechanisms 90 Randomized response trials were originally suggested by social 91 scientist Stanley Warner to increase response rates in surveys on 92 sensitive topics, such as political affiliation or sexuality 93 [WARNER]. At the flip of a coin (or other random device), a survey 94 taker would answer the opposite question to the one that the survey 95 giver wanted to ask. For instance, if the survey giver wants to find 96 out whether a person has been affiliated with a communist group, the 97 survey taker would instead answer, at some fixed probability, whether 98 they had never been affiliated with a communist group. The effect is 99 the same as if the survey taker would give a false answer to the 100 survey question with some known probability. 102 This method provoked a flurry of statistical research throughout the 103 1970s and 80s, with statisticians considering a range of problems in 104 estimation and variance reduction for estimators in the presence of 105 noise on survey responses [RAO]. 107 Recently, randomized response mechanisms has again gained traction, 108 through the work of Cynthia Dwork et al on differential privacy 109 [DWORK] or mechanisms for statistical data collection over 110 (presumably large) user sets, such as [RAPPOR]. These developments 111 had led to renewed interest in randomized response mechanisms in the 112 statistical community, with text books [FOX] and handbooks [RAO] 113 covering a large range of possible situations where randomizing 114 responses over a set of outcomes on an individual respondent basis 115 may still enable useful inferences about the population to which the 116 individual belongs. 118 Randomized response trials were originally created for binary 119 environments: if a series of measurements have only two possible 120 outcomes (0 or 1, yes or no, true or false, for example), allowing 121 individual respondents to answer "falsely" at a predictable rate will 122 still preserve the ability to make inferences on the entire set of 123 respondents. The latency spin bit, being a bit, is a binary outcome 124 variable. Each time it is measured, the idea is that it can either 125 "truthfully" report its value as what it should be according to 126 [TRAMMEL], or it could, at some known rate or probability, report the 127 opposite value. 129 RRMs are easily illustrated for binary response problems. Let's take 130 as an example "Did you go to the last IETF meeting?" The answer to 131 this question is either yes or no. Let us suppose that 25% of all 132 responses are known to be false, and that 80% of all respondents 133 answered yes. Then 60% of the respondents who answered yes can be 134 assumed to have done so truthfully, while 5% of the respondents who 135 answered no have done so falsely. 65% of the respondents can 136 therefore be estimated to have actually attended the last IETF 137 meeting. 139 RRMs can also be applied to multiple choice questions. Estimation of 140 true proportions becomes more difficult as the number of possible 141 answers per question goes up. Further examples, including formulas 142 and calculations, can be found in [RAO] and [FOX]. 144 3. Application to latency spin bit 146 As described in [TRAMMEL], the latency spin bit is a mechanism for 147 measuring round-trip-times (RTT) in the QUIC protocol. The 148 investigation in this document relies on [TRAMMEL] for its 149 understanding of the basic operation of the latency spin bit, and in 150 particular the following paragraphs and figures from the document are 151 quoted to facilitate the description of RRM below: 153 [Begin quote] Initially, during connection establishment, no packets 154 with a spin bit are in flight, as shown in Figure 1. 156 +--------+ - - - - - +--------+ 157 | | --------> | | 158 | Client | | Server | 159 | | <-------- | | 160 +--------+ - - - - - +--------+ 162 Figure 1: Initial state, no spin bit between client and server 164 Either the server, the client, or both can begin sending packets with 165 short headers after connection establishment, as shown in Figure 2; 166 here, no spin edges are yet in transit. 168 +--------+ 0 0 - - - +--------+ 169 | | --------> | | 170 | Client | | Server | 171 | | <-------- | | 172 +--------+ - - 0 0 0 +--------+ 174 Figure 2: Client and server begin sending packets with spin 0 176 Once the server's first 0-marked packet arrives at the client, the 177 client sets its spin value to 1, and begins sending packets with the 178 spin bit set, as shown in Figure 3. The spin edge is now in transit 179 toward the server. 181 +--------+ 1 0 0 0 0 +--------+ 182 | | --------> | | 183 | Client | | Server | 184 | | <-------- | | 185 +--------+ 0 0 0 0 0 +--------+ 187 Figure 3: The bit begins spinning 189 Five ticks later, this packet arrives at the server, which takes its 190 spin value from it and reflects that value back on the next packet it 191 sends, as shown in Figure 4. The spin edge is now in transit toward 192 the client. 194 +--------+ 1 1 1 1 1 +--------+ 195 | | --------> | | 196 | Client | | Server | 197 | | <-------- | | 198 +--------+ 0 0 0 0 1 +--------+ 200 Figure 4: Server reflects the spin edge 202 Five ticks later, the 1-marked packet arrives at the client, which 203 inverts its spin value and sends the inverted value on the next 204 packet it sends, as shown in Figure 5. 206 obs. points X Y 207 +--------+ 0 1 1 1 1 +--------+ 208 | | --------> | | 209 | Client | | Server | 210 | | <-------- | | 211 +--------+ 1 1 1 1 1 +--------+ 212 Y 214 Figure 5: Client inverts the spin edge 216 [End quote] 218 In each iteration going from Figure 4 to Figure 5 a sequence of 0s or 219 1s the length of which is k0 for iteration 0, k1 for iteration 1, and 220 so forth, can be observed (by on-path observers X or Y in Figure 5). 222 The length of each sequence equals the amount of ticks required to 223 pass from the client back to the client. After observation n lengths 224 of such sequences, (k[0], ..., k[n]), an average can be taken over 225 k[j]. This average can be multiplied by the amount of time per tick 226 (a quantity which is assumed to be known) to get a value for the 227 round-trip time (RTT). 229 Applying randomized response mechanisms (RRMs) perturbs the observed 230 sequence lengths (k[0], ..., k[n]). The perturbation will have the 231 effect of lengthening, shortening, or making more arbitrary the 232 lengths of the sequences, thereby increasing the variance, or disable 233 the possibility, of an estimator of the true RTT value. 235 4. Spin bit assumptions 237 Deciding on a RRM scheme for RTT in QUIC requires a more explicitly 238 defined mechanism for changing the spin value (the value of the spin 239 bit being transmitted from the client or server) than presently is 240 the case in [TRAMMEL]. For instance, the way in which the server is 241 specified to change its spin value currently is: 243 "The server initializes its spin value to 0. When it receives a 244 packet from the client, if that packet has a short header and if it 245 increments the highest packet number seen by the server from the 246 client, it sets the spin value to the spin bit in the received 247 packet." (Section 2) 249 while the mechanism for changing the spin value in the client is 251 "The client initializes its spin value to 0. When it receives a 252 packet from the server, if the packet has a short header and if it 253 increments the highest packet number seen by the client from the 254 server, it sets the spin value to the opposite of the spin bit in the 255 received packet." (Section 2) 257 The goal of the designer in [TRAMMEL] is to cause the spin bit to 258 change its value once per round-trip. Our design goal is different. 259 We want to have the spin bit only sometimes change its value once per 260 round-trip, while it might other times change its value twice per 261 round-trip, or not at all. Additionally, we have the goal of 262 ensuring that we can exercise control over what percentage of round- 263 trips give useful measurements. To simultaneously fill all of those 264 requirements, we introduce the following additional constraints on 265 updating the spin value: 267 1. Client and server have an internal spin value (NV) which decides 268 the value of the next outgoing spin bit. 270 2. Clients and server keep track of the second-to-last incoming 271 spin bit (SLISB), and the last incoming spin bit (LISB). 273 3. The NV initializes to 0 at both the client and the server. 275 4. An inversion of the client's NV is triggered if SLISB and LISB 276 have different values. Notably, no comparison between the SLISB 277 or LISB and the NV is made. The value of the NV, which 278 determines the value of the next spin bit transmitted, is set 279 independently of the value of the SLISB and LISB. 281 5. An inversion does not happen with probability q, even when it 282 should. 284 6. A reflection of the server's NV is also triggered if SLISB and 285 LISB have different values. 287 7. A reflection does not happen with probability p, even when it 288 should. 290 8. In the absence of a triggering event, the NV does not change its 291 value and the client or server continue to transmit bits holding 292 the current NV value. 294 9. Client and server act independently of one another, so that 295 neither client or server have any way of determining whether the 296 other has reflected or inverted ``truthfully''. 298 10. A special case is the first time a spin bit is recorded by a 299 client or server (immediately after initialization). In this 300 case, the client and server both update the NV truthfully. 302 We illustrate these assumptions with a truth table for the client in 303 Figure 6 and for the server in Figure 7. 305 +----------+-------+------+-------------------+ 306 | NVclient | SLISB | LISB | NV'client | 307 +----------+-------+------+-------------------+ 308 | (0) | (-) | (0) | (1)* | 309 | 0 | 0 | 0 | 0 | 310 | 0 | 0 | 1 | 0(q) or 1(1-q) | 311 | 0 | 1 | 0 | 0(q) or 1(1-q) | 312 | 0 | 1 | 1 | 0 | 313 | 1 | 0 | 0 | 1 | 314 | 1 | 0 | 1 | 1(q) or 0(1-q) | 315 | 1 | 1 | 0 | 1(q) or 0(1-q) | 316 | 1 | 1 | 1 | 1 | 317 +----------+-------+------+-------------------+ 319 Figure 6: Client truth table for inversion of the client's internal 320 spin bit value NVclient. NV'client in the right-most column 321 constitutes a truthful inversion with probability (1-q) and a lying 322 inversion with probability q. * A special case is the firstround-trip 323 after initialization. 325 +----------+-------+------+----------------+ 326 | NVclient | SLISB | LISB | NV'client | 327 +----------+-------+------+----------------+ 328 | (0) | (-) | (0) | (0)* | 329 | 0 | 0 | 0 | 0 | 330 | 0 | 0 | 1 | 0(1-p) or 1(p) | 331 | 0 | 1 | 0 | 0(1-p) or 1(p) | 332 | 0 | 1 | 1 | 0 | 333 | 1 | 0 | 0 | 1 | 334 | 1 | 0 | 1 | 1(1-p) or 0(q) | 335 | 1 | 1 | 0 | 1(1-p) or 0(q) | 336 | 1 | 1 | 1 | 1 | 337 +----------+-------+------+----------------+ 339 Figure 7: Server truth table for reflection of the server's internal 340 spin bit value NVserver. * A special case is the firstround-trip 341 after initialization. 343 5. Model specification 345 There are two conceivable ways to achieve RRM for RTT measurements: 347 1. The reflection and/or inversion is not activated by the arrival 348 of an edge bit with some probability (``Edge transition RRM''), 349 or 351 2. the server or the client randomizes which bit it transmits at 352 each bit (``Each bit RRM''). 354 In particular, in QUIC25 draft [I-D-QUIC], section 17.1.3, a 355 randomization mechanism is called for that renders 7/8 of all spin 356 bit measurements non-useful for the purpose of inferring latency. 357 This encourages us to seek some mathematical solution that can at 358 least guarantee that 7/8 of all traffic streams to which a spin bit 359 is attached are not useful for RTT measurements. 361 6. Simulation 363 Simulation code for both cases discussed in this document ("RRM at 364 each bit" and "RRM at edge transition") and instructions are hosted 365 on GitHub [SIMULATION]. 367 7. Edge transition RRM 369 7.1. One and a half round-trip explained 371 Recall the assumptions in Section 4. Suppose that a round trip takes 372 2n time units. If we initialize spin bits at the client and server 373 to 0 (assumption 3), they will both see (SLISB, LISB)=(-,0) after n 374 time units, and an NV change is triggered (assumption 10). Now the 375 client maintains an NV value of 1 while the server sets its NV value 376 to 0. 378 The client now transmits spin bits valued 1 to the server, while the 379 server continues to transmit spin bits valued 0 to the client. After 380 another n time units (2n time units in total) the client sees a 381 (SLISB, LISB)-tuple valued (0,0), while the server will see a (SLISB, 382 LISB)-tuple (1,0) (assumption 2). This triggers an attempted 383 reflection by the server, meaning that its NV should be changed from 384 0 to 1 (assumption 6), while a change in the client NV (1) is not 385 triggered (assumption 4). Suppose that the server truthfully 386 reflects its NV to 1. Now the client continues to transmit 1s to the 387 server, while the server transmits 1s to the client. 389 After yet another n time units (3n time units in total) the server 390 will see the (SLISB, LISB)-tuple (1,1) and therefore do nothing 391 (assumption 8), while the client sees the tuple (0,1) and tries to 392 update its NV (assumption 4). If the client does not do this, so 393 that the client NV remains at 1, then the client will be transmitting 394 1s to the server and the server will be transmitting 1s to the 395 client. 397 After 4n time units, the (SLISB, LISB)-tuples seen by both the client 398 and the server will be (1,1), and both NVs will also be set to 1. 399 Consequently, the (lack of) NV updates after 3n time units have 400 landed us in the situation that there is no longer any possibility 401 for a (SLISB, LISB)-tuple to have different values, and we have ended 402 up in a loop. 404 This is encouraging, since a loop can be escaped by randomly re- 405 initializing the spin bit after some time that we can choose. 407 7.2. A closer look at the loop 409 As in the previous section, let the RTT be 2n time units. If 410 NV[client] = NV[server] at time n, and the NVs remain equal to each 411 other at time 2n, the process will be in a loop. If we describe the 412 four different combinations of NVs in the following way: 414 (NV[client], NV[server]) = (0,0), (1,0), (0,1) or (1,1) 416 then, in the example above (Section 7.1), we would have the following 417 sequence of transitions: 419 (0,0)[init] -> (1,0) -> (1,1) -> (1,1) \] 421 Referring back to the truth tables in Figure 6 and Figure 7, we can 422 work out how these transitions exactly happen. For example, the 423 transition (1,0) -> (1,1) can happen in the following two ways: 425 The client attempts to update NV[client] after receiving a triggering 426 (SLISB, LISB)-tuple but fails to invert or it does not receive a 427 triggering (SLISB, LISB)-tuple at all, while the server updates 428 NV[server] truthfully after receiving a triggering (SLISB, LISB)- 429 tuple. The server has one way of transitioning its NV from 0 to 1, 430 while the client has two ways of transitioning its NV from 1 to 1. 432 We know the probabilities that reflections or inversions will not 433 happen (assumptions 5 and 7 in Section 4), but also need to know when 434 a triggering (SLISB, LISB)-tuple will be received. A client receives 435 such a tuple at time kn if the server truthfully updated its NV at 436 time (k-1)n. In fact, a loop occurs as soon as the server does not 437 update its NV truthfully. A (SLISB, LISB)-tuple received by the 438 client will necessarily have the form 440 (NV[server,t=n(k-1)], NV[server,t=n(k-2)] 442 and an NV update is triggered only if this tuple contains two 443 different values. From assumption 10 in Section 4 we have that 445 NV[server,t=0] = NV[server,t=n] at t=0, n 447 and is updated only because NV[client] is updated at t=n by the same 448 assumption. The fact that they are equal means that necessarily 449 NV[client,t=2n] = NV[client,t=2n] 451 with NV[client,t] assuming a new value only if $NV[server,s] changes. 452 But if the server would lie once (and not update its NV), we get 454 NV[server,t=n(k-1)] = NV[server,t=nk] = NV[server,t=n(k+1)] 456 rendering the server unable to transmit values that can trigger an 457 update of the client NV value. 459 7.3. Using model to restrict measurements 461 With the insights from Section 7.2 we can choose p and q from 462 Section 4, and define some re-initialization criteria for the spin 463 bit, for an alternative mechanism to achieve the targets set out in 464 the QUIC spin bit specification in [I-D-QUIC]: 466 "Each endpoint unilaterally decides if the spin bit is enabled or 467 disabled for a connection. Implementations MUST allow administrators 468 of clients and servers to disable the spin bit either globally or on 469 a per-connection basis. Even when the spin bit is not disabled by 470 the administrator, endpoints MUST disable their use of the spin bit 471 for a random selection of at least one in every 16 network paths, or 472 for one in every 16 connection IDs. As each endpoint disables the 473 spin bit independently, this ensures that the spin bit signal is 474 disabled on approximately one in eight network paths." (sec. 17.3.1) 476 In order to estimate the round-trip time, an on-path observer needs 477 to have access to at least one full round-trip worth of passing spin 478 bits. The first such accessible round-trip after initialization is 479 the sequence of 1s transmitted by the client, if truthfully reflected 480 by the server with probability (1-p). The second such accessible 481 round-trip is the sequence of 0s that follow upon additionally 482 truthful inversions and reflections by the client and server 483 respectively. The cumulative probability of two accessible round- 484 trips is therefore (1-p)(1-q)(1-p), and in general 486 P[X round-trips are complete and measurable] = (1-p)^x (1-q)^(x-1) 488 From this we can derive the expected value 490 E[X] (1-p) S[x [(1-p)(1-q)]^(x-1) = (1-p)/((1-(1-p)(1-q))^2) 492 where S[.] is the sum over x. 494 By the specification quoted above, we want this to be approximately 495 equal to 7/8. A range of values for (p,q) can satisfy this 496 criterion, and, for instance, if the client always tells the truth 497 (i.e. q=0) then p=1/8, meaning that the server lies 1/8 of the time. 499 Once the client or server have lied for the first time, all future 500 spin bit values cannot be used for measuring round-trip time unless 501 the NV update process is re-initiated. This could be achieved 502 through the client arbitrarily updating its NV in contradiction with 503 assumption 8 of Section 4 after some period of time, which could be 504 chosen according to a geometric distribution of some expectation r. 505 However, in the time leading up to re-initialization the utility for 506 an on-path observer of recording the spin bit value is nil. 508 It follows that the actual proportion of useless measurements will be 509 far higher than the 1/8 that is specified in the draft. 511 A solution is to choose p, q so that the expected value of the number 512 of useful round-trip measurements is higher than 7/8. If we solve 513 for p, q when E[X] = 56/59, we would want the client to re-initiate 514 the NV update procedure after an average of 5 round-trip periods to 515 get an expected 56/64 = 7/8 useful measurements. This supposes, of 516 course, that the client has a way of establishing the approximate 517 round-trip time that is independent of the spin bit. 519 Additional privacy gains, or at least diminished availability of 520 useful RTT measurements, would be achieved by solving for an expected 521 value lower than 7/8. Since not all measurements are rendered 522 useless by applying RRM, there will eventually always be a time when 523 an on-path observer can make inferences about round-trip time. 525 8. Discussion 527 It is possible to apply to RRM to QUIC RTT measurements in a way 528 which delays estimation of RTT. However, it is unclear whether RRM 529 has advantages larger than already existing privacy mechanisms 530 included in the QUIC draft (such as making the spin bit optional, or 531 requiring that 1/8 of all streams are not measurable). The privacy 532 concern associated with a spin bit is that latency measurements will 533 enable inference of the location or distance of the device associated 534 with that particular IP address. But the whole point of differential 535 privacy mechanisms, including RRM, is using statistical methods to 536 ensure that data can be made more privacy-preserving while also 537 preserving the data utility. In the case of the spin bit, it is the 538 utility of the data that allegedly violates privacy, which means 539 differential privacy is an intuitively bad tool to address privacy 540 concerns. 542 The spin bit is associated with an IP address, which creates 543 linkability. Any differential privacy mechanism will not remove 544 linkability from the spin bit, and so preserves that angle of privacy 545 violation. 547 RRM could potentially be used to fulfill requirements from 548 [I-D-QUIC], sec. 17.3.1, in a slightly more flexible way than is 549 currently discussed at the IETF. In particular, the parameters p, q 550 and r could be adjusted to accommodate for any proportion of useful 551 measurements. If r is left for the client to decide, the client may 552 even have influence over the extent to which RTT measurements through 553 the QUIC spin bit is made more difficult (see e.g. [RFC6973], sec. 554 7.2). 556 In order to realize such advantages the functioning of the QUIC spin 557 bit does, however, need to be more stringently specified, in 558 particular in line with our suggestions in Section 4. 560 9. Informative References 562 [AA-CL] Andersdotter, A. and C. Laengstroem, "Differential Privacy 563 (PEARG, IETF104)", March 2019, 564 . 568 [DWORK] Roth, A. and C. Dwork, "The Algorithmic Foundations of 569 Differential Privacy", 2014, 570 . 573 [FOX] Fox, J., "Randomized Response and Related Methods: 574 Surveying Sensitive Data", February 2017. 576 [I-D-QUIC] 577 Iyengar, J. and M. Thomson, "QUIC: A UDP-Based Multiplexed 578 and Secure Transport", September 2019, 579 . 582 [KUEHLEWIND] 583 Kuehlewind, M. and B. Trammel, "The QUIC Latency Spin Bit 584 (draft-ietf-quic-spin-exp-01)", October 2018, 585 . 587 [RAO] Rao, T. and C. Rao, ""Review of Certain Recent Advances in 588 Randomized Response Techniques" in C.R. Rao (Ed.), 589 Handbook of Statistics, Elsevier B.V, Oxford (UK).", 2016. 591 [RAPPOR] Erlingsson, U., Korolova, A., and V. Pihur, "RAPPOR: 592 Randomized Aggregatable Privacy-Preserving Ordinal 593 Response", arXiv:1407.6981v2 [cs.CR]", 2014. 595 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Petersen, J., 596 Morris, J., Hansen, M., and R. Smith, "Privacy 597 Considerations for Internet Protocols", RFC 6973, 598 DOI 10.17487/RFC6973, July 2013, 599 . 601 [SIMULATION] 602 Sahib, S. and A. Andersdotter, 603 "https://github.com/ShivanKaul/draft-andersdotter-rrm-for- 604 rrt/tree/master/spinbit_simulation", November 2019, 605 . 608 [TENOEVER-MARTINI] 609 Martini, B. and N. Ten Oever, "QUIC Human Rights Review 610 (draft-martini-hrpc-quichr-00)", October 2018, 611 . 614 [TRAMMEL] Trammel, B., Boucadair, M., Even, R., Fioccola, G., 615 Fossati, T., Ihlar, M., Morton, A., and E. Stephan, 616 "Adding Explicit Passive Measurability of Two-Way Latency 617 to the QUIC Transport Protocol (draft-trammell-quic-spin- 618 03)", May 2018, . 621 [WARNER] Warner, S., ""Randomized response: a survey technique for 622 eliminating evasive answer bias." J. Am. Stat. Assoc. 60 623 (309), 63-69.", 1965. 625 Authors' Addresses 627 Amelia Andersdotter 628 CENTR 629 Rue Belliard 30 630 1040 Brussels 631 Belgium 633 Email: amelia.ietf@andersdotter.cc 634 Shivan Sahib 635 Salesforce 637 Email: shivankaulsahib@gmail.com