Hi Martin, Mauro, All, Let me also highlight that draft-mdt-ippm-explicit-flow-measurements is informational and, similarly to the experimental RFC 8321 and RFC 8889, it describes different alternatives for performance measurement. Then, a future standards track specification can pick up the most suitable method.
To address the comment of Martin, I would suggest to add a new final section titled, for instance, "Report on the Operational Experiment and Deployment", where it can be possible to include the current experiments and existing deployments and also give suggestions and guidance for the implementation. In this way, developers can get more information when they read the draft. Regards, Giuseppe -----Original Message----- From: Explicit-meas <[email protected]> On Behalf Of Cociglio Mauro Sent: Thursday, July 29, 2021 11:01 AM To: [email protected]; IETF IPPM WG <[email protected]> Cc: [email protected]; [email protected]; [email protected]; Jan Rüth <[email protected]>; [email protected] Subject: [Explicit-meas] Which bits to use for explicit performance measurements? Hi Martin and All. I would like to answer your question from yesterday IPPM session in a more detailed way. If I understood well your question is: "Which bits, at the end, we suggest to use among all those proposed in the draft for explicit performance measures?" (https://datatracker.ietf.org/doc/html/draft-mdt-ippm-explicit-flow-measurements-02) Taking for granted that the usable space consists of 3 bits I would say to use 1 bit for RTT and 2 bits for Packet Loss. Starting from the results of Aachen University ANRW paper (https://arxiv.org/pdf/2106.13710.pdf) we can say that, for Packet Loss, 1 bit is not enough: . T-bit is not a so accurate measurement. . Q-bit is not an end-to-end measure. . L-bit does not allow the localization of the impairment. So the best proposition, in our opinion, is to use 2 bits. The 1st is definitely the Q-bit, coupled either with L-bit or with R-bit. The L-bit is very accurate and works well even with short sessions, but it is a signal of the losses recorded by the protocol, not an independent measure. If you want a protocol independent measurement you need to use R-bit, which even with some limitations in the case of short sessions (it needs to wait for the completion of a Q period on one side of the connection before reflecting it on the other) has proven to work quite well. We now come to RTT measurement, considering in particular the QUIC protocol, where there is already a standardized bit, even if not mandatory, on this measure. The Spin bit, albeit with some limitations in case of impairments (in particular out-of-sequence) and the fact that it "mixes" the application delay with the network delay, has proved to work quite well. The problem is that, up to now, it has not been implemented and in the QUIC traffic on the network it is not present. It is a question of understanding the reasons for this fact. If the issue of privacy is the main problem, the proposal of the D-bit, in the version with Hidden RTT, could be considered for the next version of QUIC protocol. BR. Mauro _____________________ Mauro Cociglio TIM - CI.TIS.IPT Via G. Reiss Romoli, 274 10148 - Torino (Italy) Tel.: +390112285028 Mobile: +393357669751 _____________________ 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. -- Explicit-meas mailing list [email protected] https://www.ietf.org/mailman/listinfo/explicit-meas
