Hi,
first of all thanks for the many comments received.
As jointly agreed at the time with the chairs of the IPPM, QUIC and TSWG WGs, 
this draft is general and its purpose is to describe only the measurement 
methodologies in a protocol independent way. In order to describe their 
application to a certain protocol, it was agreed to present a specific draft in 
the related WG.
So to give an example, with regard to the COAP protocol, this was done by 
submitting a draft in the CORE WG. See 
https://datatracker.ietf.org/doc/draft-ietf-core-coap-pm/
Therefore, with regard to the QUIC protocol, we will prepare a draft to be 
presented in the QUIC WG which will address the issues highlighted in this 
thread and details related to the possible future implementation.

As for this draft 
https://datatracker.ietf.org/doc/draft-ietf-ippm-explicit-flow-measurements , 
we will write a new version of it where the section 6 will be placed in a draft 
appendix and renamed to Experimental Examples.
In this way (we hope) it will be clear that we are talking about experiments 
made, and that they must not be interpreted as implementation.

If the other co-authors agree, we can proceed to make a new version of the 
draft.

Massimo (and the co-authors in CC)


From: Tommy Pauly tpa...@apple.com<mailto:tpa...@apple.com>
Date: ven 12 mag 2023 14:02 UTC
Subject: Re: [ippm] QUIC concerns relating to 
draft-ietf-ippm-explicit-flow-measurements

Agreed, although I see a lot of this work as input to future versions of a 
protocol (QUIC or otherwise) that could allocate bits like QUICv1 did for the 
spin bit. The IPPM document essentially is a zoo of the various ways bits could 
be used for spin-bit style uses, such that future protocols and protocol 
versions could decide to implement one. In the meantime, I agree that the 
application to QUICv1 is more for experimental demonstrations than something 
you could have arbitrary middle boxes assume support for by default.

Tommy

> On May 11, 2023, at 4:50 PM, Christian Huitema <huit...@huitema.net> wrote:
>
>
> On 5/11/2023 3:53 PM, Martin Thomson wrote:
>> On Fri, May 12, 2023, at 01:21, Christian Huitema wrote:
>>> Igor is right. In fact, the "square bit" that he describes is
>>> implemented in Picoquic, under an option negotiation.
>> It's not about whether endpoints could negotiate something that allows the 
>> use of these bits, it's about whether measurement systems are able to rely 
>> on that happening.
>> It's quite possible that some extension could be negotiated that creates a 
>> signal in these bits.  OK, so now you can deploy a measurement system that 
>> relies on that.  Most bits will be random, but some proportion will have the 
>> signal.  Enter statistical methods and you can recover some signal.
>> Well...almost.  This works until someone else decides to negotiate the use 
>> of those bits for carrying a different signal.  Now you have a harder 
>> statistical problem to solve.  Maybe you can boost your adaptation by 
>> observing connection initiation and looking for clients that advertise a 
>> certain version and set of transport parameters.
>>> The probability that these measurement features be turned on by default
>>> is extremely low, and the draft should be very explicit about it,
>>> including a description of the privacy/measurement tradeoff.
>> This is really the point of all this.
>
> That. Which means that at a minimum the IPPM draft should discuss the issue: 
> needle of measurement in a haystack of noise. It might work sometimes, such 
> as when debugging the end to end path between two well known IP addresses, or 
> when knowing the specific connection IDs used by the system participating in 
> the measurement. It might perhaps work if the connection last long enough to 
> distinguish the IPPM pattern from a random pattern. But as you say, the 
> general case is almost impossible.
>
> -- Christian Huitema
>



Gruppo TIM - Uso Interno - Tutti i diritti riservati.

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone 
indicate. La diffusione, copia o qualsiasi altra azione derivante dalla 
conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate 
ricevuto questo documento per errore siete cortesemente pregati di darne 
immediata comunicazione al mittente e di provvedere alla sua distruzione, 
Grazie. 

This e-mail and any attachments is confidential and may contain privileged 
information intended for the addressee(s) only. Dissemination, copying, 
printing or use by anybody else is unauthorised. If you are not the intended 
recipient, please delete this message and any attachments and advise the sender 
by return e-mail, Thanks.

Rispetta l'ambiente. Non stampare questa mail se non è necessario.

Reply via email to