[ippm] John Scudder's No Objection on draft-ietf-ippm-explicit-flow-measurements-03: (with COMMENT)
John Scudder via Datatracker <noreply@ietf.org> Wed, 24 May 2023 21:34 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 7045FC151B1C; Wed, 24 May 2023 14:34:09 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: John Scudder via Datatracker <noreply@ietf.org>
To: The IESG <iesg@ietf.org>
Cc: draft-ietf-ippm-explicit-flow-measurements@ietf.org, ippm-chairs@ietf.org, ippm@ietf.org, marcus.ihlar@ericsson.com, marcus.ihlar@ericsson.com
X-Test-IDTracker: no
X-IETF-IDTracker: 10.4.0
Auto-Submitted: auto-generated
Precedence: bulk
Reply-To: John Scudder <jgs@juniper.net>
Message-ID: <168496404944.21984.14328246653038787134@ietfa.amsl.com>
Date: Wed, 24 May 2023 14:34:09 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/a3NPnXAB4f5QTyu8n8IBlR4fRsc>
Subject: [ippm] John Scudder's No Objection on draft-ietf-ippm-explicit-flow-measurements-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: Wed, 24 May 2023 21:34:09 -0000
John Scudder has entered the following ballot position for draft-ietf-ippm-explicit-flow-measurements-03: No Objection 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-explicit-flow-measurements/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- # John Scudder, RTG AD, comments for draft-ietf-ippm-explicit-flow-measurements-03 CC @jgscudder Thanks for this document. While I am not sufficiently expert in the subject area to give it a deep review, I trust this has been done by others. I do have a few questions and comments that I hope may help, below. I support Jim Guichard's DISCUSS position. ## COMMENT ### Section 1 the encrypted transport-layer headers (e.g. QUIC, TCP). Since when are TCP headers encrypted? ### Section 3.1 There is a list of bullet items that talk about "by setting the T bit", e.g. * the client selects, generates and consequently transmits a first train of packets, by setting the T bit to 1; The way the sentence is constructed, it literally means "the client causes the train of packets to be generated and transmitted by means of setting the T bit to 1". I doubt that's what you mean. Possibly you mean something like "it sets the T bit to 1 to identify packets in this train"? ### Section 3.1.2 The reflection counter is first introduced by mentioning that the reflection counter is unlocked to start counting incoming marked packets that will be reflected later; This makes for a rather bumpy experience for the first-time reader. I suggest introducing this counter somehow before referencing it. You might also mention that as part of initialization, the reflection counter is locked. I also have a hard time being sure I've understood this correctly: The generation token counter should be capped to limit the effects of a subsequent sudden reduction in the other endpoint's packet rate that could prevent that endpoint from reflecting collected packets. The most conservative cap value is 1. I presume "capped" is used in the normal sense of not being allowed to exceed a certain value. I guess yes, 1 is a conservative value in a way, after all the only lower value is zero and that wouldn't make a lot of sense. As written the text has the odor of recommending the value of 1 without actually doing so, it's just that "conservative" sounds like approval in this context. Is all of that intentional? ### Section 3.3 Surely "IP/IPv6" is the wrong terminology -- should be either "IP" (meaning, IPv4 or IPv6) or "IPv4/IPv6"? ### Section 3.3 Concerning the Unreported Loss counter you have, If the protocol is able to rescind the loss determination later, a positive Unreported Loss counter may be decremented due to the rescission, but it should not become negative due to the rescission. and later, (so Unreported Loss counter may become negative when a packet with L=1 is sent after a partial packet has been lost) Is my conclusion correct, that negative values are permitted and should be supported, but only in the latter case and not the former? ## NITS ### Section 3.5, Section 4 s/this draft/this document/ ### Section 7 s/gleamed/gleaned/ ## 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] John Scudder's No Objection on draft-ietf-… John Scudder via Datatracker
- Re: [ippm] John Scudder's No Objection on draft-i… Giuseppe Fioccola