From nobody Tue Mar 16 06:48:10 2021 Return-Path: X-Original-To: explicit-meas@ietfa.amsl.com Delivered-To: explicit-meas@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3C09C3A0E48 for ; Tue, 16 Mar 2021 06:48:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.12 X-Spam-Level: X-Spam-Status: No, score=-2.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=telecomitalia.it Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kBrk4OfraOhj for ; Tue, 16 Mar 2021 06:47:58 -0700 (PDT) Received: from mx05.telecomitalia.it (mx05.telecomitalia.it [156.54.232.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EDAE93A0E4F for ; Tue, 16 Mar 2021 06:47:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; d=telecomitalia.it; s=selector1; c=relaxed/relaxed; q=dns/txt; i=@telecomitalia.it; t=1615902472; x=2479816072; h=MIME-Version:From:Date:Message-ID:Subject:To; bh=RCdQxLLMhxvFpcLB2xH50KW4aj9CW7stK1cSwRX9rtE=; b=hmllRBp3DvgV3Yhktn9bOQDi6axcYolSUu0lz2x6GFIXjSEMhiA7r0/qa85tpt0h mdo2FiFRaJCZ1Jgnvv+tgc+U5b8JbKx7ZCxUj1Xo4oXvg8cKUDLQ4i/gGYhsuSxC IaiDaUmJMEdFkd48+HF1Faag+pSzPcod9xHURnfRrNWJjheWg6aYU3CcNHYNGyC2 16KBueRsv0SLh+bHi7CKFY8GDa+bkCc4NXDjy8qLoJES8ItB2z6Rhju38hH1/zJv Dg86lfCKymtcIs6RbPlnoG+ayEsHJJ2DRse2CsH52QHusKLu/Wx/UbhMnLdcG5ZX d3LCWiuo5UxcENeIs1+D9w==; X-AuditID: 0a5a2d15-1c0eb700000050b6-0d-6050b7086a77 Received: from TELMBXC14BA020.telecomitalia.local ( [10.90.43.78]) by mx05.telecomitalia.it () with SMTP id F7.CA.20662.807B0506; Tue, 16 Mar 2021 14:47:52 +0100 (CET) From: Cociglio Mauro To: "IETF IPPM WG (ippm@ietf.org)" , "explicit-meas@ietf.org" CC: "quic@ietf.org" , "tsvwg@ietf.org" Thread-Topic: Comparing Alternate Marking and Explicit Flow Measurements (Spin bit, ...) Thread-Index: AdcaadL89WUw5nTMSaO6t2YHkK4COg== Content-Class: Date: Tue, 16 Mar 2021 13:47:51 +0000 Message-ID: <8f60ffc8e0fd4376ba911c03f5c43039@TELMBXD14BA020.telecomitalia.local> Accept-Language: it-IT, en-US Content-Language: it-IT X-MS-Has-Attach: X-MS-TNEF-Correlator: msip_labels: MSIP_Label_d6986fb0-3baa-42d2-89d5-89f9b25e6ac9_Enabled=true; MSIP_Label_d6986fb0-3baa-42d2-89d5-89f9b25e6ac9_SetDate=2021-03-16T13:47:41Z; MSIP_Label_d6986fb0-3baa-42d2-89d5-89f9b25e6ac9_Method=Standard; MSIP_Label_d6986fb0-3baa-42d2-89d5-89f9b25e6ac9_Name=Uso Interno; MSIP_Label_d6986fb0-3baa-42d2-89d5-89f9b25e6ac9_SiteId=6815f468-021c-48f2-a6b2-d65c8e979dfb; MSIP_Label_d6986fb0-3baa-42d2-89d5-89f9b25e6ac9_ActionId=50ed9e22-6867-47f8-99dd-40ec1c384e99; MSIP_Label_d6986fb0-3baa-42d2-89d5-89f9b25e6ac9_ContentBits=2 x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [79.54.27.13] x-ti-disclaimer: ADBanner Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrMKsWRmVeSWpSXmKPExsXCFaXtp8uxPSDB4HiDksWSDWeZLXoevAMS C7gtjr25y+bA4rFkyU+mAMaoBkabxLy8/JLEklSFlNTiZFsll8zi5JzEzNzUIgVHFyegZGqR kkJmiq2SmZJCQU5icmpual6JrVJiQUFqXoqSHZcCBrABKsvMU0jNS85PycxLt1XyDPbXtbAw tdQ1VLILLE0tLslXyE0tLk5MT8/MV0iYJ5pxe18XY8FkxYqO3fcZGxgPSHcxcnJICJhIrLu5 m6mLkYtDSGAlo8SUTX1MIAk2ATOJM1uesYHYIgLpEgfudbGC2MwCbhKTbi9hBrGFBUIl+pfs A4pzANVESSz5YQ1RriexbMkCqHI+iSmPW1hAbBYBVYldM4+BtfIKBErc3X0KrIZRQFZiwu5F jBD14hIvpp9gh7hNQGLJnvPMELaoxMvH/1hB7uQVWMgiMWfOFagiA4mtS/exgNwgISAvceZR FERYUuLw4U1sEDP1JG5MnQJla0ssW/ga6gZBiZMzn7BMYBSbheTUWUjOmIWkfRaS9llI2hcw sq5iFM2tMDDVK0nNSU3Oz80sSczJTNTLLNnECE4muqI7GLeteKN3iJGJg/EQowQHs5IIr2le QIIQb0piZVVqUX58UWlOavEhRh9gIE1klhJNzgems7ySeENTM1NzYyMzUwNTM0scwkrivEcm Ac0SSAcmr+zU1ILUIphxTBycUg1MDtYXsipf/Pl9UVtz64pT9pHsZ7OFznlPF5pk6+0Y3Bb7 t+xv1M0zSSkbxFau/jKvc5e1GiejyYKt8n9WzVv/S/fzjaUuCn8/9C+b/vuq0pw1+msv/haU kQ7lW3FWIPTMHH/htvWWi022inSfM3vZLrFxwQK1vEoHKdaaaJWlTi3v15vZ7ox+mRC+42Tt 1Z6ZJ7tsT3FuXieutpBr8mH55zXni09fU9Za3/BI6kSz3irfwNBo4eB4RUfTGreZZY4nnKoX aCjx8nJrbMxiWp5SUqKQuvKL1UufHWdeLJbN+R9qfG1x4J/OJf3Z2xli10wS9leyWCmvMPvr 4qqLKSpL3E2LV/Eo+lqy65lpssxXYinOSDTUYi4qTgQAOjEHQ8YDAAA= Archived-At: Subject: [Explicit-meas] Comparing Alternate Marking and Explicit Flow Measurements (Spin bit, ...) X-BeenThere: explicit-meas@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "This mailing list is intended for discussions relating to Explicit Flow Measurements Techniques." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Mar 2021 13:48:02 -0000 Hi. Last Friday during the IPPM meeting, =A0after the "Explicit Flow Measurement= s" draft presentation (https://tools.ietf.org/html/draft-mdt-ippm-explicit-f= low-measurements-01), Greg Mirsky raised an issue that I think is very impor= tant. The question is about differences and similarities between the two types of= production traffic packet marking for performance measurements, proposed in= IETF and initiated in the IPPM WG: Alternate Marking and Explicit Flow Meas= urements. The first technique known as Alternate Marking or AM/PM (Alternate Marking P= erformance Monitoring) is defined, in general terms, in RFC8321 (the point-t= o-point version) and RFC8889 (the multipoint version). It is essentially a Telco measurement, born to measure packet delay and loss= between the input and output of a network, or between 2 internal points of= the network, in order to identify and localize a problem. It is a network m= easure and it is the network operator that performs the marking by modifying= packets on the fly. The strength of this technique comes from the decoupling of marking and meas= urement. We can mark all traffic, using a fixed marking interval (typically= "big": from 1 second up to 5 minutes), then we decide what to measure based= on the resources I want to use. In case of packet loss measurement we can s= tart from a single packet counter for all traffic for each measurement point= (possibility described in RFC8889), to have a network measurement, to arriv= e to a counter for each point-to-point connection you want to monitor (as de= scribed in RFC8321). In order to obtain the measurement it is necessary to compare the data colle= cted from at least 2 measurement points (counters for packet loss, timestamp= s for delay). Then a "communication" between measurement points, or with a N= etwork Measurement Center, is needed. There are already commercial implementations of this technique (also for IPv= 4) and IETF drafts that are standardizing it for various protocols (IPv6, MP= LS, Segment Routing, BIER, ...). The Alternate Marking methodology is evolving into the draft "Big Data AltMa= rk" (https://tools.ietf.org/html/draft-c2f-ippm-big-data-alt-mark-01) that d= efines point-to-point flows measurements applying post processing to perform= ance data collected by sampling a single network multipoint flow. The second marking technique for performance monitoring of packet networks h= as been called Explicit Flow Measurements (EFM), and is more recent because= it's born with the Spin bit RTT measurement. And it came about primarily to= have an end-to-end performance measure, from the terminal, on which an appl= ication is running, to the server at the opposite end of the network. EFM ca= n be seen as complementary measures to Alternate Marking. It requires certain characteristics of the protocols to which it can be appl= ied, which are client-server, and it is particularly convenient for protocol= s that prevent the marking of packets on the fly (e.g. QUIC), because the ma= rking occurs only on the end-points of the connection. The disadvantage with respect to the previous technique is that it always wo= rks for client-server point-to-point connection, it is not possible to aggre= gate measurements saving on monitoring resources as described in RFC8889. Th= e advantage is that it can also work with a single monitoring point, even if= having more points enhances it and allows intradomain measurements. With a= single measurement point you can obtain end-to-end measures (Spin bit, Dela= y bit for delay and Loss bit, rT loss bit for packet loss) or end-to-observe= r measures (sQuare bit and Reflection bit for packet loss). End-to-observer= measurements and scalability considerations make it particularly convenient= to place a measurement point on the client (see https://tools.ietf.org/html= /draft-cnbf-ippm-user-devices-explicit-monitoring-01). Best Regards. Mauro _____________________ Mauro Cociglio TIM - Telecom Italia 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 pers= one indicate. La diffusione, copia o qualsiasi altra azione derivante dalla= conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbia= te ricevuto questo documento per errore siete cortesemente pregati di darne= immediata comunicazione al mittente e di provvedere alla sua distruzione, G= razie. This e-mail and any attachments is confidential and may contain privileged i= nformation intended for the addressee(s) only. Dissemination, copying, print= ing or use by anybody else is unauthorised. If you are not the intended reci= pient, 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 =E8 necessario.