[ippm] Intdir telechat review of draft-ietf-ippm-explicit-flow-measurements-03
Pascal Thubert via Datatracker <noreply@ietf.org> Thu, 11 May 2023 16:13 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 A6DDDC236F2F; Thu, 11 May 2023 09:13:47 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Pascal Thubert via Datatracker <noreply@ietf.org>
To: int-dir@ietf.org
Cc: draft-ietf-ippm-explicit-flow-measurements.all@ietf.org, ippm@ietf.org, last-call@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 10.2.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <168382162766.44973.5019639652654733869@ietfa.amsl.com>
Reply-To: Pascal Thubert <pthubert@cisco.com>
Date: Thu, 11 May 2023 09:13:47 -0700
Archived-At: <https://mailarchive.ietf.org/arch/msg/ippm/acqw4-3WgCeLS37hYdsMYOdauh8>
Subject: [ippm] Intdir telechat review of draft-ietf-ippm-explicit-flow-measurements-03
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: Thu, 11 May 2023 16:13:47 -0000
Reviewer: Pascal Thubert Review result: Ready with Nits I am an assigned INT directorate reviewer for draft-ietf-ippm-explicit-flow-measurements-03. These comments were written primarily for the benefit of the Internet Area Directors. Document editors and shepherd(s) should treat these comments just like they would treat comments from any other IETF contributors and resolve them along with any other Last Call comments that have been received. For more details on the INT Directorate, see https://datatracker.ietf.org/group/intdir/about/ <https://datatracker.ietf.org/group/intdir/about/>. Based on my review, if I was on the IESG I would ballot this document as NO OBJECTION. I found the document to be very clear and readable. A few minor grammar issues will be sorted out by the RFC editor better than I could. 2.2.4. Delay Measurement Using Delay Bit ... When the Delay bit is used, a passive observer can use delay samples directly and avoid inherent ambiguities in the calculation of the RTT as can be seen in Spin bit analysis. ... PT> If a reroute causes a brutal change, the observer should erealize that these are not n times T MAX in a raw but the new reality of the RTT. 2.2.4.1. RTT Measurement ... PT > is there a filter or something? Just one measure does not account for variations. See rfc 6298. ... 2.2.5. Observer's Algorithm An on-path observer maintains an internal per-flow variable to keep track of time at which the last delay sample has been observed. PT > the flow characterization must be part of the standard. eg 5 tuple, 6 tuple in IPv6. because the source and the observer must recognize the same thing as being one flow with one bit and one state. ... 3.1.3. Observer's Logic for Round Trip Loss Signal ... Generation Pause Reflection Pause ____________________ ______________ ____________________ ________ | | | | | 01 01 00 01 11 10 11 00 00 10 10 10 01 00 01 01 10 11 10 00 00 10 Figure 8: Round Trip Loss signal example PT> in the reflection, why is it that it's not the first 4 consecutive packets that are marked (why the 00 iun second position) ? ... 3.3. L Bit -- Loss Event Bit ... For protocols, such as TCP ([TCP]), that allow network devices to change data segmentation, it is possible that only a part of the packet is lost. In these cases, the sender must increment Unreported Loss counter by the fraction of the packet data lost (so Unreported Loss counter may become negative when a packet with L=1 is sent after a partial packet has been lost). PT> What is the intention? >From the network perspective a packet was discarded, whether it is a fragment does not seem that relevant. RED does not account for size does it? ... 3.3.1. End-To-End Loss The Loss Event bit allows an observer to estimate the end-to-end loss rate by counting packets with L bit value of 0 and 1 for a given flow. The end-to-end loss rate is the fraction of packets with L=1. PT> note that calling things rate means "over a period of time" (a rate is amount/s ). Seems you mean "ratio" instead of "rate" or really "probability" since yu use value in [0,1], in this and many places, right? Voila!
- [ippm] Intdir telechat review of draft-ietf-ippm-… Pascal Thubert via Datatracker
- Re: [ippm] Intdir telechat review of draft-ietf-i… Giuseppe Fioccola
- Re: [ippm] Intdir telechat review of draft-ietf-i… Pascal Thubert (pthubert)