[ippm] Éric Vyncke's Yes on draft-ietf-ippm-rfc8321bis-03: (with COMMENT)
Éric Vyncke via Datatracker <noreply@ietf.org> Fri, 26 August 2022 06:00 UTC
Return-Path: <noreply@ietf.org>
X-Original-To: ippm@ietf.org
Delivered-To: ippm@ietfa.amsl.com
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DE120C14CE28; Thu, 25 Aug 2022 23:00:29 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Éric Vyncke via Datatracker <noreply@ietf.org>
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
X-Test-IDTracker: no
X-IETF-IDTracker: 8.14.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: Éric Vyncke <evyncke@cisco.com>
Message-ID: <166149362990.33806.3013073188809622294@ietfa.amsl.com>
Date: Thu, 25 Aug 2022 23:00:29 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/7dgKFP2tDOzkuaBKrJkKO8TdtUk>
Subject: [ippm] Éric Vyncke's Yes on draft-ietf-ippm-rfc8321bis-03: (with COMMENT)
X-BeenThere: ippm@ietf.org
X-Mailman-Version: 2.1.39
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, 26 Aug 2022 06:00:30 -0000
Éric Vyncke has entered the following ballot position for draft-ietf-ippm-rfc8321bis-03: Yes 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/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # Éric Vyncke, INT AD, comments for draft-ietf-ippm-rfc8321bis-02 CC @evyncke Thank you for the work put into this document and for addressing my previous DISCUSS and most of the COMMENTs. Those are kept below for archiving and not for action. 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 ## Previous DISCUSS (kept for archiving) 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? ## Previous COMMENTS (kept for archiving) ### 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). ### 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). ### 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. ### 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). ### 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 ? ### 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" ;-) Moreover, the description is rather opaque, e.g., some examples would be welcome. ### Section 4.3 telemetry Is there a YANG model specified (or under specification) for data collection ? ### 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 ;-) ### 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 ? ### Section 6 fragmentation Should there be a note about: * IPv6 routers never fragment * use of DF bit for IPv4 ## NITS ### Capitalized Passive Unsure whether "Passive" needs to be capitalized in the text. ### 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) ## 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 Yes on draft-ietf-ippm-rfc83… Éric Vyncke via Datatracker