[tsvwg] Comparing Alternate Marking and Explicit Flow Measurements (Spin bit, ...)

Cociglio Mauro <mauro.cociglio@telecomitalia.it> Tue, 16 March 2021 13:48 UTC

Return-Path: <mauro.cociglio@telecomitalia.it>
X-Original-To: tsvwg@ietfa.amsl.com
Delivered-To: tsvwg@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 7CC533A0E48 for <tsvwg@ietfa.amsl.com>; Tue, 16 Mar 2021 06:48:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.12
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 ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id YlG2iMQKZm7s for <tsvwg@ietfa.amsl.com>; Tue, 16 Mar 2021 06:47:57 -0700 (PDT)
Received: from mx05.telecomitalia.it (mx05.telecomitalia.it []) (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 33F193A0E4B for <tsvwg@ietf.org>; 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 ( []) by mx05.telecomitalia.it () with SMTP id F7.CA.20662.807B0506; Tue, 16 Mar 2021 14:47:52 +0100 (CET)
From: Cociglio Mauro <mauro.cociglio@telecomitalia.it>
To: "IETF IPPM WG (ippm@ietf.org)" <ippm@ietf.org>, "explicit-meas@ietf.org" <explicit-meas@ietf.org>
CC: "quic@ietf.org" <quic@ietf.org>, "tsvwg@ietf.org" <tsvwg@ietf.org>
Thread-Topic: Comparing Alternate Marking and Explicit Flow Measurements (Spin bit, ...)
Thread-Index: AdcaadL89WUw5nTMSaO6t2YHkK4COg==
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
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: []
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: <https://mailarchive.ietf.org/arch/msg/tsvwg/9Qk7NybEFcGKri47MMZBT782VGM>
Subject: [tsvwg] Comparing Alternate Marking and Explicit Flow Measurements (Spin bit, ...)
X-BeenThere: tsvwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Transport Area Working Group <tsvwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/tsvwg/>
List-Post: <mailto:tsvwg@ietf.org>
List-Help: <mailto:tsvwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tsvwg>, <mailto:tsvwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Mar 2021 13:48:02 -0000

Last Friday during the IPPM meeting,  after the "Explicit Flow Measurements" draft presentation (https://tools.ietf.org/html/draft-mdt-ippm-explicit-flow-measurements-01), Greg Mirsky raised an issue that I think is very important.
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 Measurements.

The first technique known as Alternate Marking or AM/PM (Alternate Marking Performance Monitoring) is defined, in general terms, in RFC8321 (the point-to-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 measure 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 measurement. 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 start from a single packet counter for all traffic for each measurement point (possibility described in RFC8889), to have a network measurement, to arrive to a counter for each point-to-point connection you want to monitor (as described in RFC8321).
In order to obtain the measurement it is necessary to compare the data collected from at least 2 measurement points (counters for packet loss, timestamps for delay). Then a "communication" between measurement points, or with a Network Measurement Center, is needed.
There are already commercial implementations of this technique (also for IPv4) and IETF drafts that are standardizing it for various protocols (IPv6, MPLS, Segment Routing, BIER, ...).
The Alternate Marking methodology is evolving into the draft "Big Data AltMark" (https://tools.ietf.org/html/draft-c2f-ippm-big-data-alt-mark-01) that defines point-to-point flows measurements applying post processing to performance data collected by sampling a single network multipoint flow.

The second marking technique for performance monitoring of packet networks has 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 application is running, to the server at the opposite end of the network. EFM can be seen as complementary measures to Alternate Marking.
It requires certain characteristics of the protocols to which it can be applied, which are client-server, and it is particularly convenient for protocols that prevent the marking of packets on the fly (e.g. QUIC), because the marking occurs only on the end-points of the connection.
The disadvantage with respect to the previous technique is that it always works for client-server point-to-point connection, it is not possible to aggregate measurements saving on monitoring resources as described in RFC8889. The 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, Delay bit for delay and Loss bit, rT loss bit for packet loss) or end-to-observer 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 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 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.