[ippm] Comments on draft-ietf-ippm-explicit-flow-measurements-00

Ike Kunze <Ike.Kunze@comsys.rwth-aachen.de> Fri, 18 March 2022 15:48 UTC

Return-Path: <Ike.Kunze@comsys.rwth-aachen.de>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost []) by ietfa.amsl.com (Postfix) with ESMTP id 33E483A0BD8 for <ippm@ietfa.amsl.com>; Fri, 18 Mar 2022 08:48:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id 3oE90JbmALoP for <ippm@ietfa.amsl.com>; Fri, 18 Mar 2022 08:48:52 -0700 (PDT)
Received: from mail-out-1a.itc.rwth-aachen.de (mail-out-1a.itc.rwth-aachen.de [IPv6:2a00:8a60:1:e501::5:44]) (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 73A113A0A73 for <ippm@ietf.org>; Fri, 18 Mar 2022 08:48:51 -0700 (PDT)
IronPort-Data: A9a23:AyYlCaubcoe4vDCwb4+qQ6f8QufnVMxcMUV32f8akzHdYApBsoF/q tZmKT/VPf3bYjbxKtt/bo6z/EoDv8OBnYMyHQU9/yAzFC8RgMeUXt7xwmUcns+xBpCZEBg3v 512hv3odp1coqr0/0/1WlTZhSAgk/nOH9IQMcacUsxLbVYMpBwJ1FQyw4bVvqYy2YLjW1jU6 YuoyyHiEAbNNwBcYzp8B52r9UsHUMTa4Fv0aXRnOJinFHeH/5UkJMp3yZOZdhMUcaEIdgKOf Nsv+Znilo/v10p3Von1wu6TnnoiGdY+NSDW4pZftjPLbhJq/kTe2Y5jXBYQhNs+Zzihx7hMJ NtxWZOYUSQJIIryyO0hfRgBECRyDLB+1K/ePi3q2SCT5xWun3rEx/R1EFpwNood4fdsR3tR6 fxdITkGbh2Fwe67qF65YrA32YJ5dpetZdhZ4CgIITLxVJ7KRbjiQKiMxsJezjoYjcdLBufFI dAGdToqZR3LYxBJfFsaYH47tLv43SWvKmcwRFS9i4Uq+HnTyy1K173jHtv8eoLJZf9NtxPNz o7B1yGjav0AD/Se0SKA2nOhmuGJmjn0ML/+D5W89+V2mxuYwWkIGQZQT0Snobywg0W+VtQZJ 0F8FjcSkJXePXeDFrHVNyBUalbd1vLAc7K8y9EH1Tw=
IronPort-HdrOrdr: A9a23:n/w8eKFVjf7Nk/gHpLqFqZHXdLJyesId70hD6qkvc20zTiXIrb HLoB1E726QtN9wYgBa6K290ci7MDLhHPtOkPYs1NiZLXzbUQGTTb2KkrGSiQEIdxeOhtK1lp 0QPpSWceeAQmSS1PyKrjVQcOxQgOVvkprY8ds2pk0FJWoLGtgQlXYEe3im/1VNNXF77PwCZe mhD6J81lydkB8sH7WG7xc+Lpr+T6CiruOrXffTPW9Q1OGX5gnH1FYOeCL24v7caV5yKHUZm1 QtXzaJhZlKz5mAu1ThPhfonuNrcRLapqogOCV6sLlcFtxEsHfgWK1RH6Sfpz48ve3qyHtCqq iOnz4Qe91u8H3YY23wuxv/12DboXMTwk6n0EOCj3P/rYjlVCs3YvAxx75kTg==
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.90,192,1643670000"; d="scan'208,217";a="4834812"
Received: from lists.comsys.rwth-aachen.de ([]) by mail-in-1a.itc.rwth-aachen.de with ESMTP; 18 Mar 2022 16:48:48 +0100
Received: from hermes-mbx.win.comsys.rwth-aachen.de (hermes-mbx.win.comsys.rwth-aachen.de []) by lists.comsys.rwth-aachen.de (Postfix) with ESMTPS id 740BDC0026 for <ippm@ietf.org>; Fri, 18 Mar 2022 16:48:47 +0100 (CET)
Received: from APOLLON-MBX.win.comsys.rwth-aachen.de (2a00:8a60:1014:0:a1ef:323a:315:dca7) by HERMES-MBX.win.comsys.rwth-aachen.de (2a00:8a60:1014:0:dce8:101c:a3f0:7884) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2308.15; Fri, 18 Mar 2022 16:48:47 +0100
Received: from HERMES-MBX.win.comsys.rwth-aachen.de (2a00:8a60:1014:0:a93e:263f:c058:3079) by APOLLON-MBX.win.comsys.rwth-aachen.de (2a00:8a60:1014:0:a1ef:323a:315:dca7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2375.12; Fri, 18 Mar 2022 16:48:46 +0100
Received: from HERMES-MBX.win.comsys.rwth-aachen.de ([fe80::dce8:101c:a3f0:7884]) by HERMES-MBX.win.comsys.rwth-aachen.de ([fe80::dce8:101c:a3f0:7884%12]) with mapi id 15.01.2308.015; Fri, 18 Mar 2022 16:48:46 +0100
From: Ike Kunze <Ike.Kunze@comsys.rwth-aachen.de>
To: "ippm@ietf.org" <ippm@ietf.org>
Thread-Topic: Comments on draft-ietf-ippm-explicit-flow-measurements-00
Thread-Index: AQHYOt+nl5Uwav6ptEKpYcsL7mxprA==
Date: Fri, 18 Mar 2022 15:48:46 +0000
Message-ID: <121B3179-60F7-410D-B8BC-EFC321E5DE83@comsys.rwth-aachen.de>
Accept-Language: de-DE, en-US
Content-Language: en-US
x-originating-ip: [2a00:8a60:1014:113:2::1000]
Content-Type: multipart/alternative; boundary="_000_121B317960F7410DB8BCEFC321E5DE83comsysrwthaachende_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/0mYXDiHqYhSw3Ypv9Dz2p4QLuM0>
Subject: [ippm] Comments on draft-ietf-ippm-explicit-flow-measurements-00
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: IETF IP Performance Metrics Working Group <ippm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ippm>, <mailto:ippm-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ippm/>
List-Post: <mailto:ippm@ietf.org>
List-Help: <mailto:ippm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ippm>, <mailto:ippm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 18 Mar 2022 15:48:57 -0000

Hi all,

in my mail supporting adoption of the efm draft, I mentioned that "the descriptions of the approaches could be a bit more precise”.
In the past weeks, I have discussed these aspects with Mauro, Massimo, and Fabio and would like to quickly summarize my main “concerns” here so that (hopefully) everyone can profit.

To me, the exact behavior when updating the R block length if a new Q block has been completed during the R block transmission is not entirely clear.
While the text on this is technically correct, I believe that it could be beneficial to explicitly describe the behavior, e.g., when the new R block length is shorter than the previous one.

I believe that the description of the T-Bit could profit from a more detailed presentation of two aspects:

First, I misinterpreted that the generation token counter is reset each time a new generation phase starts.
This then led to several additional false inferences.
Consequently, I think that the description of the concrete behavior of the generation token counter could be more precise.

Second, the concrete choice of “2 spin bit periods” for the T-Bit phases (in connection with the misinterpretation of the generation token counter) again led to
several false inferences on my part.
Thus, I think that some discussion on why this phase length is chosen might be beneficial to avoid such misinformed reasoning.

Additionally, the T-Bit algorithm is currently presented once at a semi-high-level at the start of Section 4.1 and then again in Section 4.1.2.
This made me jump between the sections several times as it is not obvious which part contains which information.
My suggestion would be to either (i) merge the two parts or to (ii) make the description at the start of 4.1 more general so that it is clear that it is only intended as a rough overview and not as potentially containing critical implementation aspects.
That could help so that all information is found in one place and one place only.

General comment:
In addition to these aspects directly concerning two of the mechanisms, I also have a more high-level proposal regarding the structure of the loss bit section.
In Section 4, the combination of L+Q comes as Section 4.4. after the T, Q and L Bits have been presented.
The R-Bit is then presented in Sec 4.5 and the combination of R+Q in subsection of 4.5.1.
I think it would be cleaner if all of the loss bits would be presented first.
The different possible combinations could then be presented in a joint Section 4.5.
In my opinion, this would make it easier to fully grasp the different possible combinations and, especially, allow for a sensible comparison between the possibilities.

Hope this helps!