Return-Path: X-Original-To: ippm@mail2.ietf.org Delivered-To: ippm@mail2.ietf.org Received: from localhost (localhost [127.0.0.1]) by mail2.ietf.org (Postfix) with ESMTP id 0EAC5B8FCD6F for ; Tue, 17 Feb 2026 12:13:11 -0800 (PST) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail2.ietf.org ([166.84.6.31]) by localhost (mail2.ietf.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cHt0UTAkf85I for ; Tue, 17 Feb 2026 12:13:10 -0800 (PST) Received: from mail-pj1-x102a.google.com (mail-pj1-x102a.google.com [IPv6:2607:f8b0:4864:20::102a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature ECDSA (P-256) server-digest SHA256) (No client certificate requested) by mail2.ietf.org (Postfix) with ESMTPS id 5A6C9B8FCD4D for ; Tue, 17 Feb 2026 12:13:10 -0800 (PST) Received: by mail-pj1-x102a.google.com with SMTP id 98e67ed59e1d1-3530e7b3dc2so4098971a91.3 for ; Tue, 17 Feb 2026 12:13:10 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1771359189; cv=none; d=google.com; s=arc-20240605; b=M5GDdxyG8mwdoleF08JBZGUTrvM6i8qXr70biOh1IL6KFOGTgjOWPq05gVlVzzLHHn /l5ODFR8Rn1fHj5AqVD+oN9W4YMXX77pwYq6ue8T8057YJnUz2VWNarBDRpz1oXF+SRc Ob9o2s+9Z7zw9SYu+tY5nezq3f6W302PIXsMNNXDryqLBGQcWQBGP5PuuBvbrOSd/XL1 f4DD2StMHrXKv83KLgyqikMCsY9UoPREtGE6XSbPhS2SRuUEsyH14QyRqbfWYqbKgGwm VadrPtJhkgttGR7BPld8ayEfi8p10NVMhjuDWDiuiQ1Om0sXR32lDZMbot99lKdsGi0g Ah9g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20240605; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:dkim-signature; bh=h3X5kby2xnSjhbh9lg1vsPMqnqNCNt3Ay/D4+A00Eo8=; fh=ax1ts6N+/3YJvri6DGzPWJtqpbDR5tbJasFzuRPhgRs=; b=Yi1fdaJ5H0kVGQM0oLVKhyoAzBMFAkKpH7ZR2lJksp0f0NBileM7AN5AiYFri7qDkE FDs2Y+uIHSZYEu2XGP8NQbQIlsMIhYa70H1JwLbiG76O6HTi542ZGoDJ5eoWDcpz6isf jh0yHQjDnpVmllPofACbL9eNJ791lyfCSBWogN4TU1iONob4gfoKPSBeO02pBH7Ivr/0 Tr2U9JrA5ltgHdgPk3pR2wD3kVG87uAO+xdVHhqZlGfdqJFGLShoeWKnCbVPSc195970 pHP66jVqOYewKm4QbYcwCiNWeuihFFDZszbXy4A1Pm1cyJncGO+sst9rT5zVD/LCku1n UAUg==; darn=ietf.org ARC-Authentication-Results: i=1; mx.google.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1771359189; x=1771963989; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=h3X5kby2xnSjhbh9lg1vsPMqnqNCNt3Ay/D4+A00Eo8=; b=dT6IUnJPBbuIjAefDqHhlfd8XmtFqA/T2WXFhAmHhb7AHBoHEHrvhx02bOAvduuWZx 0yMhL1Ur3WDUIZlOaqS1BSJJzZQl8yjQ7FTs9SntDdilj3f3oKWoHILHWUh0XcG8CTcK gmToQ2/mB0CHTN2thXaMTLLKl1GSVtVaBO00fR11/6kxh1gfCQJH7es2mEuD0BdpbW3Y IqUd3RxL9ij9wbWvN0ivzZtwLIK0AEhJGtU66zOvmcEEDbSIhF5jQ+KnEHCq/Lf8quXO xuJrav24U94GUq0/W9g+44qZop5fTp+xYfHrXKI+euviJiJM5THhMvYjJQz0HNMlbjjU a1Hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1771359189; x=1771963989; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-gg:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=h3X5kby2xnSjhbh9lg1vsPMqnqNCNt3Ay/D4+A00Eo8=; b=hY1EdrEDRRxWHpizEqv1aQbZNDDR9OjKnYDacWMMpgUV2cIiNijyCtmsuE4LR7cLfy Qbbh8vHH1/DrciRxHQydnfCwFn750eDHpccVYCSBzjrhHMtzVt63kHH4IDP3dDXVuXtL lEEXl4gupAgRymuz+qn0+Bo2icaaO1+GS4malmw7KE96uv/fXsy7Ol453q2sJ7wrn3UH Q14ZN2t9fAxkl74Tht40cE+KRrw9FLpD2+F3UbARzbx/WRIwW+FRTkwLrrlBRQLVwCt8 oGOCHoDrZ+p8RkQV13yHzXORqI+3JVHJrvwWO5u9SYg3h6N5dLrp4xKvEIGSQAoMs0GV 0kOQ== X-Forwarded-Encrypted: i=1; AJvYcCVS5qFCjwAHRHNusxpv57dopTnMlyl+BudyWJjDW1mP4PmxKl309WLGm3PDoMb+PlnO5bss@ietf.org X-Gm-Message-State: AOJu0YyLsGLlILyj4po7oYxBgCO801S7L9tFYtb/ftzEcv5oZZBVfpFU k47AVm8W3rKCBDZRJ9bdNGLCRYlbEZWvh9N+unxDifENUAes8e245e0UrlC8vHeYmoMFuIrbkHa 7fCwbJPHVVPavree4wyy7nlaiIBh1hRpFEA== X-Gm-Gg: AZuq6aKqaPKDjaZBXRMxsDvIxJKLHjrB86fO3Jf2GveCB94DipxF1QoR2lvMRHTIMxU vAA9cEjuaU7MO/EX+03qRa7c4PRgMV7qrTSTRF5Eu5JhDYfeMiMR9+FUkqGiA5sZ2zewAGSBx68 toay/wXHc9CsRwG7HSqPx5A+GINwKLLZbZJ6YVu1heTz4on9++Og6WuF4gYkfKJU/rgPbJW4g7Y WVW9py9nDEW28oCt5TyGrr0DTZMX20ffF48bf4ihbVP7B5fdA4GsaKwiU2Wind9G7arTNDBZ+Lx 4hO3qeuFaUhtWAVFARlVQ1ugcG1PwQSj4FztX+XVeJsNx2K4BMM= X-Received: by 2002:a17:90b:55c5:b0:356:3cfd:3ed5 with SMTP id 98e67ed59e1d1-356aad3cbe4mr15246311a91.18.1771359189419; Tue, 17 Feb 2026 12:13:09 -0800 (PST) MIME-Version: 1.0 References: <177080819119.1482130.10558965595956643532@dt-datatracker-6bcfd44575-g5gjh> In-Reply-To: From: Greg Mirsky Date: Tue, 17 Feb 2026 12:12:59 -0800 X-Gm-Features: AaiRm531cFg7CF-eW9ZGYJf0r_cAm4abbJC2MUwvklPd84clw0FgZqEyq0-OZtY Message-ID: To: Christer Holmberg Content-Type: multipart/alternative; boundary="000000000000414852064b0ab36b" Message-ID-Hash: PRGMGVD5DSUMZCIGEXXRNKCGXESW4FNR X-Message-ID-Hash: PRGMGVD5DSUMZCIGEXXRNKCGXESW4FNR X-MailFrom: gregimirsky@gmail.com X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-ippm.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: "gen-art@ietf.org" , "draft-ietf-ippm-asymmetrical-pkts.all@ietf.org" , "ippm@ietf.org" , "last-call@ietf.org" X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5Bippm=5D_Re=3A_draft-ietf-ippm-asymmetrical-pkts-10_ietf_last_ca?= =?utf-8?q?ll_Genart_review?= List-Id: IETF IP Performance Metrics Working Group Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --000000000000414852064b0ab36b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you, Christer, for your kind consideration of the proposed update. We'll upload the new version before the submission deadline for IETF-125. Regards, Greg On Tue, Feb 17, 2026 at 12:12=E2=80=AFAM Christer Holmberg < christer.holmberg@ericsson.com> wrote: > Hi Greg, > > I am fine with your suggestions. Thank You for addressing my comments. > > Regards, > > Christer > > > -----Original Message----- > > From: Greg Mirsky > > Sent: Tuesday, 17 February 2026 7.50 > > To: Christer Holmberg > > Cc: gen-art@ietf.org; draft-ietf-ippm-asymmetrical-pkts.all@ietf.org; > > ippm@ietf.org; last-call@ietf.org > > Subject: Re: draft-ietf-ippm-asymmetrical-pkts-10 ietf last call Genart > review > > > > Hi Christer, > > thank you for your kind consideration of our work and the helpful > > suggestions. Please find my notes below tagged GIM>>. > > > > Regards, > > Greg > > > > On Wed, Feb 11, 2026 at 3:09=E2=80=AFAM Christer Holmberg via Datatrack= er > > > wrote: > > > > > > Document: draft-ietf-ippm-asymmetrical-pkts > > Title: Performance Measurement with Asymmetrical Traffic Using > > Simple Two-Way > > Active Measurement Protocol (STAMP) Reviewer: Christer Holmberg > > Review result: > > Ready with Nits > > > > I am the assigned Gen-ART reviewer for this draft. The General Ar= ea > > Review Team (Gen-ART) reviews all IETF documents being processed > > by the IESG for the IETF Chair. Please treat these comments just > > like any other last call comments. > > > > For more information, please see the FAQ at > > > > > > ietf.org%2Fen%2Fgroup%2Fgen%2FGenArtFAQ&data=3D05%7C02%7Cchrister. > > holmberg%40ericsson.com%7C6bec1ce3ca9346fbdb9608de6de86fff%7C92 > > e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639069042237916777 > > %7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAu > > MDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C > > %7C%7C&sdata=3D11Cc5nJRzgGBU5TujBupGNMAmAfXZgLouYEnkpKUPtA%3D > > &reserved=3D0> >. > > > > Document: draft-ietf-ippm-asymmetrical-pkts-10 > > Reviewer: Christer Holmberg > > Review Date: 2026-02-11 > > IETF LC End Date: 2026-02-18 > > IESG Telechat date: Not scheduled for a telechat > > > > Summary: The document is well written, and easy to understand. I > > only have a > > couple of editorial comments that I would like the authors to > address. > > > > Major issues: N/A > > > > Minor issues: N/A > > > > Nits/editorial comments: > > > > Q1: > > > > The Abstract is far too long. I think it would be enough with > something > > like: > > > > "This document specifies an optional extension to the Simple Two- > > way > > Active Measurement Protocol (STAMP) to control the length and/or > > number of packets sent by a Session-Reflector in response to a > single > > test packet from the Session-Sender during a STAMP test session. > > This supports cases where a Session-Reflector responding with > > Asymmetrical Packets would ensure a closer approximation between > > active performance measurements and the conditions experienced by > > monitored application." > > > > > > GIM>> Indeed, the Abstract is better when it is not too wordly. At the > same > > time, it would be helpful to a reader if terms used in the Abstract are > well- > > known. "Asymmetrical packets", in fact, is the term introduced in this > > document. Perhaps is slightly different version of the Abstract would b= e > > acceptable: > > NEW TEXT: > > This document defines an optional STAMP extension that allows a > > Session-Reflector to send packets whose length or quantity differs > > from those sent by the Session-Sender. While standard STAMP > > exchanges packets symmetrically, some measurement scenarios benefit > > from asymmetric response packets to better reflect real application > > conditions. This extension enables the Session-Reflector to send > > packets of different sizes and/or additional packets not tied one- > > for-one to incoming test packets. The document also analyzes > > challenges in multicast performance monitoring and specifies STAMP > > procedures to improve measurement efficiency and reduce network > > > > impact. > > > > > > Q2: > > > > In the Introduction, I suggest to put the current 1st chapter to > the > > end. First > > describe what the draft does, and then how it does it. > > > > > > GIM>> The first paragraph references RFC 7497, the Rate Measurement Tes= t > > Protocol Problem Statement and Requirements, in which the case for > > asymmetrical performance measurement is formulated. The second paragrap= h > > of the Introduction introduces "asymmetrical packets". Third paragraph = - > > refers to specific challenges of performance measurement, including rat= e > > measurement, in a multicast environment. Considering that, would > > maintaining the existing sequence of paragraphs be acceptable? > --000000000000414852064b0ab36b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you, Christer, for your kind consideration of the pr= oposed=C2=A0update. We'll upload the new version before the submission = deadline for IETF-125.

Regards,
Greg

On Tue, Feb 17, 2026 at 12:12=E2=80=AFAM Christer Holmber= g <christer.holmberg@e= ricsson.com> wrote:
Hi Greg,

I am fine with your suggestions. Thank You for addressing my comments.

Regards,

Christer

> -----Original Message-----
> From: Greg Mirsky <gregimirsky@gmail.com>
> Sent: Tuesday, 17 February 2026 7.50
> To: Christer Holmberg <christer.holmberg@ericsson.com>
> Cc: gen-art@ietf= .org; draft-ietf-ippm-asymmetrical-pkts.all@ietf.org;
> ippm@ietf.org; = last-call@ietf.org<= /a>
> Subject: Re: draft-ietf-ippm-asymmetrical-pkts-10 ietf last call Genar= t review
>
> Hi Christer,
> thank you for your kind consideration of our work and the helpful
> suggestions. Please find my notes below tagged GIM>>.
>
> Regards,
> Greg
>
> On Wed, Feb 11, 2026 at 3:09=E2=80=AFAM Christer Holmberg via Datatrac= ker
> <noreply@ietf= .org <mailto:n= oreply@ietf.org> > wrote:
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Document: draft-ietf-ippm-asymmetrical-pkts<= br> >=C2=A0 =C2=A0 =C2=A0 =C2=A0Title: Performance Measurement with Asymmetr= ical Traffic Using
> Simple Two-Way
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Active Measurement Protocol (STAMP) Reviewer= : Christer Holmberg
> Review result:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Ready with Nits
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0I am the assigned Gen-ART reviewer for this = draft. The General Area
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Review Team (Gen-ART) reviews all IETF docum= ents being processed
>=C2=A0 =C2=A0 =C2=A0 =C2=A0by the IESG for the IETF Chair.=C2=A0 Please= treat these comments just
>=C2=A0 =C2=A0 =C2=A0 =C2=A0like any other last call comments.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0For more information, please see the FAQ at<= br> >
>=C2=A0 =C2=A0 =C2=A0 =C2=A0<https://wiki.ietf.org= /en/group/gen/GenArtFAQ
> <https://eur02.safel= inks.protection.outlook.com/?url=3Dhttps%3A%2F%2Fwiki.
> ietf.= org%2Fen%2Fgroup%2Fgen%2FGenArtFAQ&data=3D05%7C02%7Cchrister.
> holmberg%40ericsson.com%7C6bec1ce3ca9346fbdb9608de6de86fff%7C92
> e84cebfbfd47abbe52080c6b87953f%7C0%7C0%7C639069042237916777
> %7CUnknown%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAu
> MDAwMCIsIlAiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C
> %7C%7C&sdata=3D11Cc5nJRzgGBU5TujBupGNMAmAfXZgLouYEnkpKUPtA%3D
> &reserved=3D0> >.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Document: draft-ietf-ippm-asymmetrical-pkts-= 10
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Reviewer: Christer Holmberg
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Review Date: 2026-02-11
>=C2=A0 =C2=A0 =C2=A0 =C2=A0IETF LC End Date: 2026-02-18
>=C2=A0 =C2=A0 =C2=A0 =C2=A0IESG Telechat date: Not scheduled for a tele= chat
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Summary: The document is well written, and e= asy to understand. I
> only have a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0couple of editorial comments that I would li= ke the authors to address.
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Major issues: N/A
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Minor issues: N/A
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Nits/editorial comments:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Q1:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0The Abstract is far too long. I think it wou= ld be enough with something
> like:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0"This document specifies an optional ex= tension to the Simple Two-
> way
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Active Measurement Protocol (STAMP) to contr= ol the length and/or
>=C2=A0 =C2=A0 =C2=A0 =C2=A0number of packets sent by a Session-Reflecto= r in response to a single
>=C2=A0 =C2=A0 =C2=A0 =C2=A0test packet from the Session-Sender during a= STAMP test session.
>=C2=A0 =C2=A0 =C2=A0 =C2=A0This supports cases where a Session-Reflecto= r responding with
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Asymmetrical Packets would ensure a closer a= pproximation between
>=C2=A0 =C2=A0 =C2=A0 =C2=A0active performance measurements and the cond= itions experienced by
>=C2=A0 =C2=A0 =C2=A0 =C2=A0monitored application."
>
>
> GIM>> Indeed, the Abstract is better when it is not too wordly. = At the same
> time, it would be helpful to a reader if terms used in the Abstract ar= e well-
> known. "Asymmetrical packets", in fact, is the term introduc= ed in this
> document. Perhaps is slightly different version of the Abstract would = be
> acceptable:
> NEW TEXT:
>=C2=A0 =C2=A0 This document defines an optional STAMP extension that al= lows a
>=C2=A0 =C2=A0 Session-Reflector to send packets whose length or quantit= y differs
>=C2=A0 =C2=A0 from those sent by the Session-Sender.=C2=A0 While standa= rd STAMP
>=C2=A0 =C2=A0 exchanges packets symmetrically, some measurement scenari= os benefit
>=C2=A0 =C2=A0 from asymmetric response packets to better reflect real a= pplication
>=C2=A0 =C2=A0 conditions.=C2=A0 This extension enables the Session-Refl= ector to send
>=C2=A0 =C2=A0 packets of different sizes and/or additional packets not = tied one-
>=C2=A0 =C2=A0 for-one to incoming test packets.=C2=A0 The document also= analyzes
>=C2=A0 =C2=A0 challenges in multicast performance monitoring and specif= ies STAMP
>=C2=A0 =C2=A0 procedures to improve measurement efficiency and reduce n= etwork
>
>=C2=A0 =C2=A0 impact.
>
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0Q2:
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0In the Introduction, I suggest to put the cu= rrent 1st chapter to the
> end. First
>=C2=A0 =C2=A0 =C2=A0 =C2=A0describe what the draft does, and then how i= t does it.
>
>
> GIM>> The first paragraph references RFC 7497, the Rate Measurem= ent Test
> Protocol Problem Statement and Requirements, in which the case for
> asymmetrical performance measurement is formulated. The second paragra= ph
> of the Introduction introduces "asymmetrical packets". Third= paragraph -
> refers to specific challenges of performance measurement, including ra= te
> measurement, in a multicast environment. Considering that, would
> maintaining the existing sequence of paragraphs be acceptable?
--000000000000414852064b0ab36b--