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

[Amelia Andersdotter <[e-mail]>]

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


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

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