Re: [ippm] Tsvart telechat review of draft-ietf-ippm-explicit-flow-measurements-03
Giuseppe Fioccola <giuseppe.fioccola@huawei.com> Mon, 22 May 2023 14:04 UTC
Return-Path: <giuseppe.fioccola@huawei.com>
X-Original-To: ippm@ietfa.amsl.com
Delivered-To: ippm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 12606C151085; Mon, 22 May 2023 07:04:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H2=-0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NB4GHbdowS-n; Mon, 22 May 2023 07:04:02 -0700 (PDT)
Received: from frasgout.his.huawei.com (frasgout.his.huawei.com [185.176.79.56]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28382C15152E; Mon, 22 May 2023 07:04:02 -0700 (PDT)
Received: from frapeml500007.china.huawei.com (unknown [172.18.147.206]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4QPzb51BSZz689sn; Mon, 22 May 2023 21:59:29 +0800 (CST)
Received: from frapeml500006.china.huawei.com (7.182.85.219) by frapeml500007.china.huawei.com (7.182.85.172) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2507.23; Mon, 22 May 2023 16:03:58 +0200
Received: from frapeml500006.china.huawei.com ([7.182.85.219]) by frapeml500006.china.huawei.com ([7.182.85.219]) with mapi id 15.01.2507.023; Mon, 22 May 2023 16:03:58 +0200
From: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
To: Colin Perkins <csp@csperkins.org>, "tsv-art@ietf.org" <tsv-art@ietf.org>
CC: "draft-ietf-ippm-explicit-flow-measurements.all@ietf.org" <draft-ietf-ippm-explicit-flow-measurements.all@ietf.org>, "ippm@ietf.org" <ippm@ietf.org>, "last-call@ietf.org" <last-call@ietf.org>
Thread-Topic: Tsvart telechat review of draft-ietf-ippm-explicit-flow-measurements-03
Thread-Index: AQHZixwnLcZPstkzaE6pWjJfdnao6q9mDd4A
Date: Mon, 22 May 2023 14:03:58 +0000
Message-ID: <5f260ac07bdd4424866675c0b674258f@huawei.com>
References: <168458808616.25500.15425717808464643752@ietfa.amsl.com>
In-Reply-To: <168458808616.25500.15425717808464643752@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.203.246.60]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/qtj2hgNPglhb0Y6OcdIKZLhX2Mw>
Subject: Re: [ippm] Tsvart telechat review of draft-ietf-ippm-explicit-flow-measurements-03
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.39
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: Mon, 22 May 2023 14:04:04 -0000
Dear Colin, Thank you for your review. Please find my replies inline tagged as [GF]. Regards, Giuseppe -----Original Message----- From: Colin Perkins via Datatracker <noreply@ietf.org> Sent: Saturday, May 20, 2023 3:08 PM To: tsv-art@ietf.org Cc: draft-ietf-ippm-explicit-flow-measurements.all@ietf.org; ippm@ietf.org; last-call@ietf.org Subject: Tsvart telechat review of draft-ietf-ippm-explicit-flow-measurements-03 Reviewer: Colin Perkins Review result: Almost Ready This document has been reviewed as part of the transport area review team's ongoing effort to review key IETF documents. These comments were written primarily for the transport area directors, but are copied to the document's authors and WG to allow them to address any issues raised and also to the IETF discussion list for information. When done at the time of IETF Last Call, the authors should consider this review as part of the last-call comments they receive. Please always CC tsv-art@ietf.org if you reply to or forward this review. Thank you for a well-written, well-organised, and clearly motivated draft. This is a well-specified mechanism that looks appropriate to the intended task. I have only a few transport-related comments. [GF]: Thanks a lot. §2.2.3: The mechanism to calculate T_max_c is fine, and I’m not suggesting a change, but I note that protocols such as TCP compute a retransmission timeout value that is similarly some multiple of the RTT, with a comparable magnitude. It might be helpful for the draft to discuss why such an existing protocol-specific value (e.g., Trto in TCP) was not adopted for T_max. [GF]: We can surely mention that an implementation can use an existing protocol-specific value. Note that the draft does not suggest an existing protocol-specific value since it aims to be transport agnostic. It will be up to a possible specific proposed standard document to specify it. The delay bit mechanism presumably fails if the delay suddenly increases to more than T_max. Such temporary delay spikes can certainly occur in practise (e.g., I’ve seen them on poor-quality WiFi links). The draft would benefit from a discussion of the limitations of the mechanism in detecting edge cases such as this. [GF]: Yes, we can add further details and highlight this point as well. §3.5: The use of an unreported ECN-Echo counter looks appropriate for CE marks generated in response to ECT(0)-marked traffic following RFC 3168 that generate CE marks at a rate comparable to that of packet loss. However, flows using L4S marking with ECT(1), as described in RFC 9331, generate CE marks at a much higher rate. Would it make sense for the ECN-Echo Event Bit to either distinguish the two types of CE marking in reports, based on the ECT value of other packets in the flow, or to be restricted to CE marks generated in response to ECT(0)-marked packets? Does the ECN-Echo counter produce usable results for L4S flows? [GF]: This is a very interesting point. It would be a possible extension to consider. I suggest to add a reference to RFC 9331 and mention the possibility to handle the two types of CE marking in a possible implementation. Section 6 suggests ways in which additional signals, as described in this draft, can be included in QUIC or TCP. While I agree that the approaches suggested could be plausible ways of carrying such additional signals, their inclusion here could be misinterpreted as specifying an approach rather than giving examples of possible approaches. It might be more appropriate to either remove this section, and leave the discussion of how to incorporate these signals into the protocols to the QUIC and TCPM working groups, or to limit the discussion of those protocols to noting that there are sufficient unused bits in their headers to allow these additional signals to be carried. [GF]: Yes, we already agreed to revise section 6. In this regard, we will remove all the figures in section 6 and we will only mention in general that some experiments have been done with QUIC and TCP, but without specifying other information. In the entire draft, there’s an assumption that the paths taken by flows are stable, or at least traverse the same measurement point, for the duration of the measurements. It may be helpful to note this. [GF]: Ok, we will add a note on that. Regards Colin
- [ippm] Tsvart telechat review of draft-ietf-ippm-… Colin Perkins via Datatracker
- Re: [ippm] Tsvart telechat review of draft-ietf-i… Giuseppe Fioccola
- Re: [ippm] Tsvart telechat review of draft-ietf-i… Colin Perkins
- Re: [ippm] Tsvart telechat review of draft-ietf-i… Giuseppe Fioccola