Re: [ippm] Éric Vyncke's Discuss on draft-ietf-ippm-rfc8321bis-02: (with DISCUSS and COMMENT)
Giuseppe Fioccola <giuseppe.fioccola@huawei.com> Mon, 29 August 2022 06:19 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 30E6AC1522DF; Sun, 28 Aug 2022 23:19:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.908
X-Spam-Level:
X-Spam-Status: No, score=-6.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 zJPH31Y97w0w; Sun, 28 Aug 2022 23:19:15 -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 B28F3C14CF0F; Sun, 28 Aug 2022 23:19:14 -0700 (PDT)
Received: from fraeml715-chm.china.huawei.com (unknown [172.18.147.226]) by frasgout.his.huawei.com (SkyGuard) with ESMTP id 4MGKtY35nKz6802G; Mon, 29 Aug 2022 14:15:33 +0800 (CST)
Received: from fraeml714-chm.china.huawei.com (10.206.15.33) by fraeml715-chm.china.huawei.com (10.206.15.34) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2375.31; Mon, 29 Aug 2022 08:19:11 +0200
Received: from fraeml714-chm.china.huawei.com ([10.206.15.33]) by fraeml714-chm.china.huawei.com ([10.206.15.33]) with mapi id 15.01.2375.031; Mon, 29 Aug 2022 08:19:11 +0200
From: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>
To: "Eric Vyncke (evyncke)" <evyncke@cisco.com>, The IESG <iesg@ietf.org>
CC: "draft-ietf-ippm-rfc8321bis@ietf.org" <draft-ietf-ippm-rfc8321bis@ietf.org>, "ippm-chairs@ietf.org" <ippm-chairs@ietf.org>, "ippm@ietf.org" <ippm@ietf.org>, "tpauly@apple.com" <tpauly@apple.com>, "tim@qacafe.com" <tim@qacafe.com>
Thread-Topic: Éric Vyncke's Discuss on draft-ietf-ippm-rfc8321bis-02: (with DISCUSS and COMMENT)
Thread-Index: AQHYleoVEB2KJzWvQkO0WAQ90hUA4q165SzwgABBjgCAAlpEUIAAPFaAgENb54CAAypSwA==
Date: Mon, 29 Aug 2022 06:19:11 +0000
Message-ID: <f0c7cc3f16b1428d928abb1a2d064125@huawei.com>
References: <165762855099.5113.11581456984129573315@ietfa.amsl.com> <0e1348c33d16408dae9646b335b77b91@huawei.com> <B38D3C68-F1EC-4E2B-9333-1BD9EBE621FA@cisco.com> <8308d720dde048908fe944efbbf90c95@huawei.com> <2F0EF72A-AE47-42DF-A4D2-4B195AC17777@cisco.com> <EF9B69F6-804F-44D8-9532-B8C0AA3AB3AB@cisco.com>
In-Reply-To: <EF9B69F6-804F-44D8-9532-B8C0AA3AB3AB@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.48.130.74]
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/Bj_EYeSIwVxLIfkj8okOxZZp5V8>
Subject: Re: [ippm] Éric Vyncke's Discuss on draft-ietf-ippm-rfc8321bis-02: (with DISCUSS and COMMENT)
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, 29 Aug 2022 06:19:16 -0000
Hi Eric, Thank you for your review. Regards, Giuseppe -----Original Message----- From: Eric Vyncke (evyncke) <evyncke@cisco.com> Sent: Friday, August 26, 2022 8:05 AM To: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>; The IESG <iesg@ietf.org> Cc: draft-ietf-ippm-rfc8321bis@ietf.org; ippm-chairs@ietf.org; ippm@ietf.org; tpauly@apple.com; tim@qacafe.com Subject: Re: Éric Vyncke's Discuss on draft-ietf-ippm-rfc8321bis-02: (with DISCUSS and COMMENT) Giuseppe, And of course, with the IETF week and some vacations, I forgot about this... Thanks Martin for yesterday reminder. I have now cleared my DISCUSS. Please accept my apologies for the delay. BTW, never hesitate to contact me if I am holding a blocking position for more than a week when you think that the latest revision addresses the problem. Regards -éric On 14/07/2022, 11:26, "Eric Vyncke (evyncke)" <evyncke@cisco.com> wrote: Thank you again Giuseppe, Once the I-D submissions are re-opened, I am clearing my DISCUSS -éric On 14/07/2022, 10:46, "Giuseppe Fioccola" <giuseppe.fioccola@huawei.com> wrote: Hi Eric, Please see my replies inline as [GF] Regards, Giuseppe -----Original Message----- From: Eric Vyncke (evyncke) <evyncke@cisco.com> Sent: Thursday, July 14, 2022 8:24 AM To: Giuseppe Fioccola <giuseppe.fioccola@huawei.com>; The IESG <iesg@ietf.org> Cc: draft-ietf-ippm-rfc8321bis@ietf.org; ippm-chairs@ietf.org; ippm@ietf.org; tpauly@apple.com; tim@qacafe.com Subject: Re: Éric Vyncke's Discuss on draft-ietf-ippm-rfc8321bis-02: (with DISCUSS and COMMENT) Hello Giuseppe, Thank you for your reply, please see below EV> Regards -éric On 12/07/2022, 18:58, "Giuseppe Fioccola" <giuseppe.fioccola@huawei.com> wrote: Hi Eric, Thank you for your revision. Please find my answers inline tagged as [GF]. I plan to address your comments in the next version. Best Regards, Giuseppe -----Original Message----- From: Éric Vyncke via Datatracker <noreply@ietf.org> Sent: Tuesday, July 12, 2022 2:23 PM To: The IESG <iesg@ietf.org> Cc: draft-ietf-ippm-rfc8321bis@ietf.org; ippm-chairs@ietf.org; ippm@ietf.org; tpauly@apple.com; tpauly@apple.com; tim@qacafe.com Subject: Éric Vyncke's Discuss on draft-ietf-ippm-rfc8321bis-02: (with DISCUSS and COMMENT) Éric Vyncke has entered the following ballot position for draft-ietf-ippm-rfc8321bis-02: Discuss When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ for more information about how to handle DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-ippm-rfc8321bis/ ---------------------------------------------------------------------- DISCUSS: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-ippm-rfc8321bis-02 CC @evyncke Thank you for the work put into this document. Please find below one blocking DISCUSS points (easy to address), some non-blocking COMMENT points (but replies would be appreciated even if only for my own education), and some nits. Please note that Tim Winters is the Internet directorate reviewer (at my request) and you may want to consider this int-dir review as well when Tim will complete the review (no need to wait for it though): https://datatracker.ietf.org/doc/draft-ietf-ippm-rfc8321bis/reviewrequest/16061/ Special thanks to Tommy Pauly for the shepherd's detailed write-up including the WG consensus and the justification of the intended status. I hope that this review helps to improve the document, Regards, -éric ## DISCUSS As noted in https://www.ietf.org/blog/handling-iesg-ballot-positions/, a DISCUSS ballot is a request to have a discussion on the following topics: ### Section 5 Unsure whether I understand correctly: ``` Color switching is the reference for all the network devices, and the only requirement to be achieved is that all network devices have to recognize the right batch along the path. ``` Why do *all network devices* have to recognize the right batch? Isn't this transparent for them? [GF]: I can surely replace "all network devices" with "all network devices acting as measurement points" and further specify that they "have to recognize the right batch along the path in order to get and correlate the related information of counters and timestamps" EV> this would indeed address my concern and I will clear my DISCUSS once the text is uploaded [GF]: Sure, I'm working on a new version but I have to wait the reopening of the submission tool ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- ## COMMENTS ### Roman's DISCUSS Just to let you know that I support Roman Danyliw's DISCUSS point. But, I also wonder why there is a recommendation to use this method only within controlled domains (except to falsify measurements). [GF]: Yes, I will address Roman Danyliw's DISCUSS point in the next version. As per IOAM, the recommendation is for security and privacy concerns. EV> OK, thanks [GF]: Ok ### Changes of reference types between RFC 8321 and the -bis What is the reason why some references (e.g., RFC 3393) moved from the normative (in RFC 8321) to the informative section (in this document). [GF]: For RFC 3393 (and RFC7679 and RFC7680), it can still be a normative reference as per RFC 8321. EV> this would seem more logical, thanks [GF]: Ok ### Section 1 ``` RFC 7799 [RFC7799] defines Passive and Hybrid Methods of Measurement. In particular, Passive Methods of Measurement are based solely on observations of an undisturbed and unmodified packet stream of interest; Hybrid Methods are Methods of Measurement that use a combination of Active Methods and Passive Methods. ``` This short summary would benefit of an "active methods" definition. [GF]: I can also add it. EV> thanks [GF]: Ok ### Section 3.1 In `A safe choice is to wait L/2 time units`, some experimental feedbacks or a theoretical reasoning would be welcome. (I am not a transport expert, but a packet delayed a lot is probably worse than a packet loss). [GF]: I can probably add a reference to section 5 here. Indeed, in section 5, it is clearly defined the available counting interval and it takes into account the clock accuracy and the network delay. EV> indeed, good idea [GF]: Ok ### Section 3.2.1.1 using the mean Just wondering whether the authors have experimented with other statistical metrics, e.g., the median (more 'complex' to compute of course) or taking into account the standard deviation ? Also, what is the impact of the arrival rate distribution on using the mean ? [GF]: We only experimented the mean calculation especially because it is possible to update the average timestamp for each packet received. The arrival rate has impacts on the calculation indeed we highlight in the draft that it can be resource consuming in some cases. EV> ack [GF]: Ok ### Section 3.2.2 While this section answers my previous comment, may I suggest moving the description of "double-marking" earlier in the flow ? It now appears "out of the blue" ;-) [GF]: I have to think about this point. We now describe the single marking and then the double marking and it seems reasonable. EV> up to you [GF]: Ok Moreover, the description is rather opaque, e.g., some examples would be welcome. [GF]: Ok, I will try to include more details. EV> thanks [GF]: Ok ### Section 4.3 telemetry Is there a YANG model specified (or under specification) for data collection ? [GF]: This is a next step I have in mind. EV> ack [GF]: I just noticed a new draft on this: https://datatracker.ietf.org/doc/draft-wang-ippm-alt-mark-yang/ ### Section 5 ``` Additionally, in practice, besides clock errors, packet reordering is also very common in a packet network due to equal-cost multipath (ECMP). ``` Unsure whether ECMP really causes a "very common packet re-ordering". Suggest to s/very common/common/ at least ;-) [GF]: Ok I will do. I meant that different paths to reach the same destination is one of the reason for reordering. EV> sure but the current text was looking pretty bad for ECMP __ [GF]: I will revise and explain better ### Section 5 bound ``` The network delay between the network devices can be represented as a data set and 99.7% of the samples are within 3 standard deviation of the average ``` Does the above assume a specific packet distribution ? [GF]: Yes, it is assumed a normal distribution. EV> then probably worth stating this assumption [GF]: Ok, I will clearly state it ### Section 6 fragmentation Should there be a note about: * IPv6 routers never fragment * use of DF bit for IPv4 [GF]: Ok ## NITS ### Capitalized Passive Unsure whether "Passive" needs to be capitalized in the text. [GF]: I will check and replace it. ### Section 3.2 s/There are three alternatives, as described hereinafter./There are three methodologies, as described hereinafter./ ? (notably because there can only be *TWO* alternatives AFAIK) [GF]: You are right. I will fix it. ## Notes This review is in the ["IETF Comments" Markdown format][ICMF], You can use the [`ietf-comments` tool][ICT] to automatically convert this review into individual GitHub issues. [ICMF]: https://github.com/mnot/ietf-comments/blob/main/format.md [ICT]: https://github.com/mnot/ietf-comments
- [ippm] Éric Vyncke's Discuss on draft-ietf-ippm-r… Éric Vyncke via Datatracker
- Re: [ippm] Éric Vyncke's Discuss on draft-ietf-ip… Giuseppe Fioccola
- Re: [ippm] Éric Vyncke's Discuss on draft-ietf-ip… Eric Vyncke (evyncke)
- Re: [ippm] Éric Vyncke's Discuss on draft-ietf-ip… Giuseppe Fioccola
- Re: [ippm] Éric Vyncke's Discuss on draft-ietf-ip… Eric Vyncke (evyncke)
- Re: [ippm] Éric Vyncke's Discuss on draft-ietf-ip… Eric Vyncke (evyncke)
- Re: [ippm] Éric Vyncke's Discuss on draft-ietf-ip… Giuseppe Fioccola