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 409F1CA88227; Sun, 15 Mar 2026 09:51:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at ietf.org X-Spam-Flag: NO X-Spam-Score: -1.997 X-Spam-Level: X-Spam-Status: No, score=-1.997 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_VALIDITY_CERTIFIED_BLOCKED=0.001, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: mail2.ietf.org (amavisd-new); dkim=pass (2048-bit key) header.d=erg.abdn.ac.uk 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 t1J8iBRae7UR; Sun, 15 Mar 2026 09:51:30 -0700 (PDT) Received: from pegasus.erg.abdn.ac.uk (pegasus.erg.abdn.ac.uk [137.50.19.135]) by mail2.ietf.org (Postfix) with ESMTP id BF243CA88220; Sun, 15 Mar 2026 09:51:30 -0700 (PDT) Received: from [192.168.1.245] (fgrpf.plus.com [212.159.18.54]) by pegasus.erg.abdn.ac.uk (Postfix) with ESMTPSA id 8591A1B00120; Sun, 15 Mar 2026 16:51:17 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=erg.abdn.ac.uk; s=default; t=1773593484; bh=lmknkvh+hITsr3Sx169brztprjXircUhZBHkfQsQvdY=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=srQfGRguYqt0zO8WoC/AVvuNPC1JD3uub/JAbe3lFCKWsxLK2n9M6rXMKS7i8bCqe wA+VGtg/phc5EARjGfHprsVAbdkNPs33z7f5w0wIWi5gsf6S2UXB06JaLargralwPK OsFecUeTgeW7XKRFzIjNsa4g49abClkFcXfld6p7IXBbFQ4s1Xwy7OkBnN9lo2xZZb z/Hmqh/2TkTro9G3WB45+oEJNwoSpAy9eBXS7QOGD01rAOspWyVnaxbORHTlE+H0Ac Zt9qqCbm2FeIfAJM3nyXUhJ0fnQPTkFpNOJkxRRq07iB2MlD9dkcsmDZ7LC7c/pbZm wkDr0NabVkQEQ== Content-Type: multipart/alternative; boundary="------------GkPXiliEIe0AlJw7pE080hj3" Message-ID: Date: Sun, 15 Mar 2026 16:51:16 +0000 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Content-Language: en-GB To: Greg Mirsky References: <177185201977.2022033.14585945939255402557@dt-datatracker-6ff7c68975-7k42g> <65205cf4-7b8a-40ec-b708-52e1e534b595@erg.abdn.ac.uk> From: Gorry Fairhurst Organization: UNIVERSITY OF ABERDEEN In-Reply-To: Message-ID-Hash: 6FBMMT7A2BE5NJ6DVUGKS6JHTIW3AD43 X-Message-ID-Hash: 6FBMMT7A2BE5NJ6DVUGKS6JHTIW3AD43 X-MailFrom: gorry@erg.abdn.ac.uk 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: The IESG , draft-ietf-ippm-asymmetrical-pkts@ietf.org, ippm-chairs@ietf.org, ippm@ietf.org X-Mailman-Version: 3.3.9rc6 Precedence: list Subject: =?utf-8?q?=5Bippm=5D_Re=3A_Gorry_Fairhurst=27s_Discuss_on_draft-ietf-ippm-as?= =?utf-8?q?ymmetrical-pkts-11=3A_=28with_DISCUSS_and_COMMENT=29?= List-Id: IETF IP Performance Metrics Working Group Archived-At: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: This is a multi-part message in MIME format. --------------GkPXiliEIe0AlJw7pE080hj3 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit On 15/03/2026 16:23, Greg Mirsky wrote: > Hi Gorry, > Thank you for your thoughtful consideration of the proposed updates. > Please find my follow-up notes below, tagged GIM2>>. We've been > addressing DISCUSSes and COMMENTS received from other IESG reviewers > and included updates in the attached working version of the draft. I > also attached the diff that highlights all proposed updates up to date. > > Regards, > Greg > Great - thanks for this update, see below. > On Thu, Feb 26, 2026 at 11:50 AM Gorry Fairhurst > wrote: > > On 25/02/2026 21:13, Greg Mirsky wrote: >> Hi Gorry, >> thank you for your review and comments. Please find my notes >> below tagged GIM>>. I attached the working version of the draft >> and the diff highlighting proposed updates. >> >> Regards, >> Greg > > Greg, > > This looks like a good revision. I consider topics 1 and 2 are > resolved:  I see new text in the Security Considerations, thanks - > this addresses the issues relating to that section. > > On topic 3: I am unsure how Section 8.1 of [RFC9097] relates to > the specification and I expect something like that (or similar) > needs to be defined in this document: I would like to see included > a requirement to perform a specified rate control methiod in > section 3.1. > > GIM2>> As I understood DISCUSS #3, you have pointed out that reference > to Appendix A in RFC 9097 is insufficient as the normative definition > of the Load Rate Adjustment Algorithm is provided in Section 8.1 of > RFC 9097. And following on your suggestion, I propose the following > new text in Section 3.1: > NEW TEXT: >    A multicast network that uses an active performance measurement >    method for In-Service rate estimation MUST include a rate control >    mechanism that bounds and regulates the generation of measurement >    packets.  Because multicast replication can amplify probe traffic >    across the distribution tree, uncontrolled probe emission risks >    introducing congestion, altering traffic asymmetry, or otherwise >    perturbing the conditions being measured.  The rate control mechanism >    MUST ensure that probe traffic remains non-intrusive, predictable, >    and consistent with the operational characteristics of the multicast >    topology.  It SHOULD align probe generation behavior with the timing >    and packet selection semantics of the asymmetric-packet measurement >    method so that observations collected at receivers remain valid and >    comparable.  Implementations SHOULD provide operators with the >    ability to configure rate limits and pacing parameters that prevent >    excessive or uneven probe replication while still enabling >    statistically meaningful measurement samples. GF2: That's good, I think this provides some use requirements! > > Best wishes, > > Gorry > > P.S. It would also be really nice to see a proposal that addresses > or includes the text on the impact on an SLA in section 3.1.1 : > e.g. using the suggested text from [I-D.ietf-ippm-capacity-protocol]. > > I plan to clear my DISCUSS position when you submit this revision. Thanks also for taking care of my comments! Best wishes, Gorry >> >> On Mon, Feb 23, 2026 at 5:07 AM Gorry Fairhurst via Datatracker >> wrote: >> >> Gorry Fairhurst has entered the following ballot position for >> draft-ietf-ippm-asymmetrical-pkts-11: 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-asymmetrical-pkts/ >> >> >> >> ---------------------------------------------------------------------- >> DISCUSS: >> ---------------------------------------------------------------------- >> >> Thank you for preparing this document. >> >> Thank you for the work that has been put into this document. >> >> # DISCUSS Comments >> >> Please find below some blocking DISCUSS points (easy to >> address), some >> non-blocking COMMENT points/nits (replies would be >> appreciated even if only for >> my own education). >> >> As noted in >> https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/, >> a DISCUSS ballot is a request to have a discussion on the >> points below; I >> really think that the document would be improved with a >> change here, but can be >> convinced otherwise. I hope that this review helps to improve >> the document, and >> allow me to update my present position: >> >> ## (1) I understand the first part, was unsure what was >> intended by the "focus" >> in the following sentence: "Multicast traffic is also >> intrinsically >> asymmetrical, and focus on >>  the return path is usually limited." - please explain. >> >> GIM>> Thank you for the question. Would the following update make >> our point clear: >> OLD TEXT: >>    Multicast traffic is also intrinsically asymmetrical, and focus on >>    the return path is usually limited. >> NEW TEXT: >>    Multicast traffic is also intrinsically asymmetrical.  The >> upstream >>    (source-to-receiver) direction typically dominates, while the >> return >>    path receives limited attention because multicast communication is >>    primarily one-to-many and generates comparatively little >> downstream >>    or receiver-to-source traffic. >> >> >> ## (2) The document text identifies an issue, but I did not >> see a clear >> recommendation how this method would avoid or mitigate this: >> "Section 3.1.5 of >> [RFC8085] determines that a UDP >>  congestion control SHOULD respond quickly to experienced >> congestion >>  and account for loss rate and response time when choosing a >> new rate." >> * I understand that the method is to be used for testing, but >> there is no way >> to derive a new rate each RTT, and hence if inappropriately >> configured it still >> could result in significant loss/congestion to flows using >> the path that is >> being tested. I think this can be better articulated. * There >> is no operational >> guidance to suggest what to do if unexpected levels of >> loss/congestion are >> detected. * RFC7497 Paras 2 and 3 of Section 3 provides some >> text that could >> also be important. >> >> GIM>> Thank you for raising this issue and for pointing to >> Section 3 of RFC 7497 — I’ve added the reference. If the underlay >> network within the OAM domain is ECN‑capable, the >> Session‑Reflector may indeed receive STAMP test packets with the >> ECN field set to CE. As you noted, what constitutes “significant >> loss/congestion” can be case‑specific. In‑service capacity >> measurements can affect data flows, and our goal should be to >> make that clear to operators. Would the updated text address your >> concern? >> OLD TEXT: >>    When planning In-Service capacity measurement >>    operators SHOULD follow recommendations formulated in Section 7 of >>    [RFC7497].  Section 3.1.5 of [RFC8085] determines that a UDP >>    congestion control SHOULD respond quickly to experienced >> congestion >>    and account for loss rate and response time when choosing a >> new rate. >>    Appendix A of [RFC9097] offers sample pseudocode for a UDP >> load rate >>    adjustment algorithm with congestion control. >> NEW TEXT: >> When planning In-Service capacity measurement >>    operators SHOULD follow recommendations formulated in Sections >> 3 and >>    7 of [RFC7497].  If the underlay network is ECN-capable, a >> Session- >> >> >> >> Mirsky, et al.           Expires 29 August 2026             >>  [Page 12] >> >> Internet-Draft      Asymmetrical Traffic Using STAMP       >> February 2026 >> >> >>    Reflector may receive STAMP test packets with the ECN field >> marked as >>    Congestion Experienced (CE).  ECN markings provide an >> indication of >>    incipient congestion rather than packet loss. However, the >>    interpretation of what constitutes "significant congestion" >> and the >>    operational thresholds for reacting to ECN-CE depend on the >> specific >>    deployment, service objectives, and operator policy.  Operators >>    should be aware that In-Service capacity measurements may >> influence >>    congestion conditions, potentially contributing to ECN-CE >> marking in >>    the network.  Implementations and operational procedures SHOULD >>    ensure that the use of STAMP for In-Service measurement does not >>    unintentionally degrade data traffic or lead to >> misinterpretation of >>    ECN-related congestion signals.  Appropriate thresholds and >>    mitigation actions remain deployment-specific and SHOULD be >> guided by >>    operator policy and network performance objectives. >> >>    Furthermore, Section 3.1.5 of [RFC8085] determines that a UDP >>    congestion control SHOULD respond quickly to experienced >> congestion >>    and account for loss rate and response time when choosing a >> new rate. >>    And Section 8.1 of [RFC9097] specifies the load rate adjustment >>    algorithm with its sample pseudocode offered in Appendix A. >> >> >> ## (3) The text citing RFC9097 isn't sufficient to protect >> the path from >> excessive congestion: "Appendix A of [RFC9097] offers sample >> pseudocode for a >> UDP load rate >>  adjustment algorithm with congestion control." >> *  The present text only refers only to the pseudocode. This >> pseudocode is a >> helpful and so is a useful reference. However, I expect this >> to be insufficient >> to address the congestion control concerns. * The present >> text does not cite >> and require section 8.1 of RFC9097,  where the Load Rate >> Adjustment Algorithm >> is normatively defined. * This or similar sets of >> requirements could be a >> useful basis, can this be specified? >> >> GIM>> Thank you for pointing this out to us. Please check if the >> proposed updated reflects your recommendation. >> >> >> >> ---------------------------------------------------------------------- >> COMMENT: >> ---------------------------------------------------------------------- >> >> >> # Thanks to Lars Eggert for his TSVART review and to the >> editors for an update >> to address these comments. >> >> # COMMENTS (non-blocking). >> >> ## Section 3.1.1 >> This does not presently note the impact on the SLA. I note  >> be helpful to call >> this out in section 3.1.1 : e.g. (from >> [I-D.ietf-ippm-capacity-protocol]): >> "Service subscribers with limited data volumes who conduct >>        extensive capacity testing might experience the effects of >>        Service Provider controls on their service.  Testing >> with the >>        Service Provider's measurement hosts SHOULD be limited in >>        frequency and/or overall volume" >> - This could be a particularly important consideration when >> performing the >> tests described in this document. >> >> GIM>> Thank you for pointing to this consideration. Added the >> following text in Section 3.1.1: >> NEW TEXT: >>    A service subscriber performing extensive rate measurements on the >>    operational network, SHOULD consider the Consideration 6 in >>    Section 10 of [I-D.ietf-ippm-capacity-protocol]. >> >> >> Gorry Fairhurst >> >> >> > --------------GkPXiliEIe0AlJw7pE080hj3 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 15/03/2026 16:23, Greg Mirsky wrote:
Hi Gorry,
Thank you for your thoughtful consideration of the proposed updates. Please find my follow-up notes below, tagged GIM2>>. We've been addressing DISCUSSes and COMMENTS received from other IESG reviewers and included updates in the attached working version of the draft. I also attached the diff that highlights all proposed updates up to date.

Regards,
Greg

Great - thanks for this update, see below.

On Thu, Feb 26, 2026 at 11:50 AM Gorry Fairhurst <gorry@erg.abdn.ac.uk> wrote:
On 25/02/2026 21:13, Greg Mirsky wrote:
Hi Gorry,
thank you for your review and comments. Please find my notes below tagged GIM>>. I attached the working version of the draft and the diff highlighting proposed updates.

Regards,
Greg

Greg,

This looks like a good revision. I consider topics 1 and 2 are resolved:  I see new text in the Security Considerations, thanks - this addresses the issues relating to that section.

On topic 3: I am unsure how Section 8.1 of [RFC9097] relates to the specification and I expect something like that (or similar) needs to be defined in this document: I would like to see included a requirement to perform a specified rate control methiod in section 3.1. 

GIM2>> As I understood DISCUSS #3, you have pointed out that reference to Appendix A in RFC 9097 is insufficient as the normative definition of the Load Rate Adjustment Algorithm is provided in Section 8.1 of RFC 9097. And following on your suggestion, I propose the following new text in Section 3.1:
NEW TEXT:
   A multicast network that uses an active performance measurement
   method for In-Service rate estimation MUST include a rate control
   mechanism that bounds and regulates the generation of measurement
   packets.  Because multicast replication can amplify probe traffic
   across the distribution tree, uncontrolled probe emission risks
   introducing congestion, altering traffic asymmetry, or otherwise
   perturbing the conditions being measured.  The rate control mechanism
   MUST ensure that probe traffic remains non-intrusive, predictable,
   and consistent with the operational characteristics of the multicast
   topology.  It SHOULD align probe generation behavior with the timing
   and packet selection semantics of the asymmetric-packet measurement
   method so that observations collected at receivers remain valid and
   comparable.  Implementations SHOULD provide operators with the
   ability to configure rate limits and pacing parameters that prevent
   excessive or uneven probe replication while still enabling
   statistically meaningful measurement samples.
GF2: That's good, I think this provides some use requirements!

Best wishes,

Gorry

P.S. It would also be really nice to see a proposal that addresses or includes the text on the impact on an SLA in section 3.1.1 : e.g. using the suggested text  from [I-D.ietf-ippm-capacity-protocol].


I plan to clear my DISCUSS position when you submit this revision. Thanks also for taking care of my comments!

Best wishes,

Gorry


On Mon, Feb 23, 2026 at 5:07 AM Gorry Fairhurst via Datatracker <noreply@ietf.org> wrote:
Gorry Fairhurst has entered the following ballot position for
draft-ietf-ippm-asymmetrical-pkts-11: 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-asymmetrical-pkts/



----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you for preparing this document.

Thank you for the work that has been put into this document.

# DISCUSS Comments

Please find below some blocking DISCUSS points (easy to address), some
non-blocking COMMENT points/nits (replies would be appreciated even if only for
my own education).

As noted in
https://datatracker.ietf.org/doc/statement-iesg-handling-ballot-positions-20220121/,
a DISCUSS ballot is a request to have a discussion on the points below; I
really think that the document would be improved with a change here, but can be
convinced otherwise. I hope that this review helps to improve the document, and
allow me to update my present position:

## (1) I understand the first part, was unsure what was intended by the "focus"
in the following sentence: "Multicast traffic is also intrinsically
asymmetrical, and focus on
 the return path is usually limited." - please explain.
GIM>> Thank you for the question. Would the following update make our point clear:
OLD TEXT:
   Multicast traffic is also intrinsically asymmetrical, and focus on
   the return path is usually limited.
NEW TEXT:
   Multicast traffic is also intrinsically asymmetrical.  The upstream
   (source-to-receiver) direction typically dominates, while the return
   path receives limited attention because multicast communication is
   primarily one-to-many and generates comparatively little downstream
   or receiver-to-source traffic. 

## (2) The document text identifies an issue, but I did not see a clear
recommendation how this method would avoid or mitigate this: "Section 3.1.5 of
[RFC8085] determines that a UDP
 congestion control SHOULD respond quickly to experienced congestion
 and account for loss rate and response time when choosing a new rate."
* I understand that the method is to be used for testing, but there is no way
to derive a new rate each RTT, and hence if inappropriately configured it still
could result in significant loss/congestion to flows using the path that is
being tested. I think this can be better articulated. * There is no operational
guidance to suggest what to do if unexpected levels of loss/congestion are
detected. * RFC7497 Paras 2 and 3 of Section 3 provides some text that could
also be important.
GIM>> Thank you for raising this issue and for pointing to Section 3 of RFC 7497 — I’ve added the reference. If the underlay network within the OAM domain is ECN‑capable, the Session‑Reflector may indeed receive STAMP test packets with the ECN field set to CE. As you noted, what constitutes “significant loss/congestion” can be case‑specific. In‑service capacity measurements can affect data flows, and our goal should be to make that clear to operators. Would the updated text address your concern?
OLD TEXT:
   When planning In-Service capacity measurement
   operators SHOULD follow recommendations formulated in Section 7 of
   [RFC7497].  Section 3.1.5 of [RFC8085] determines that a UDP
   congestion control SHOULD respond quickly to experienced congestion
   and account for loss rate and response time when choosing a new rate.
   Appendix A of [RFC9097] offers sample pseudocode for a UDP load rate
   adjustment algorithm with congestion control.
NEW TEXT:
When planning In-Service capacity measurement
   operators SHOULD follow recommendations formulated in Sections 3 and
   7 of [RFC7497].  If the underlay network is ECN-capable, a Session-



Mirsky, et al.           Expires 29 August 2026                [Page 12]

Internet-Draft      Asymmetrical Traffic Using STAMP       February 2026


   Reflector may receive STAMP test packets with the ECN field marked as
   Congestion Experienced (CE).  ECN markings provide an indication of
   incipient congestion rather than packet loss.  However, the
   interpretation of what constitutes "significant congestion" and the
   operational thresholds for reacting to ECN-CE depend on the specific
   deployment, service objectives, and operator policy.  Operators
   should be aware that In-Service capacity measurements may influence
   congestion conditions, potentially contributing to ECN-CE marking in
   the network.  Implementations and operational procedures SHOULD
   ensure that the use of STAMP for In-Service measurement does not
   unintentionally degrade data traffic or lead to misinterpretation of
   ECN-related congestion signals.  Appropriate thresholds and
   mitigation actions remain deployment-specific and SHOULD be guided by
   operator policy and network performance objectives.

   Furthermore, Section 3.1.5 of [RFC8085] determines that a UDP
   congestion control SHOULD respond quickly to experienced congestion
   and account for loss rate and response time when choosing a new rate.
   And Section 8.1 of [RFC9097] specifies the load rate adjustment
   algorithm with its sample pseudocode offered in Appendix A.

## (3) The text citing RFC9097 isn't sufficient to protect the path from
excessive congestion: "Appendix A of [RFC9097] offers sample pseudocode for a
UDP load rate
 adjustment algorithm with congestion control."
*  The present text only refers only to the pseudocode. This pseudocode is a
helpful and so is a useful reference. However, I expect this to be insufficient
to address the congestion control concerns. * The present text does not cite
and require section 8.1 of RFC9097,  where the Load Rate Adjustment Algorithm
is normatively defined. * This or similar sets of requirements could be a
useful basis, can this be specified?
GIM>> Thank you for pointing this out to us. Please check if the proposed updated reflects your recommendation. 


----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------


# Thanks to Lars Eggert for his TSVART review and to the editors for an update
to address these comments.

# COMMENTS (non-blocking).

## Section 3.1.1
This does not presently note the impact on the SLA. I note  be helpful to call
this out in section 3.1.1 : e.g. (from [I-D.ietf-ippm-capacity-protocol]):
"Service subscribers with limited data volumes who conduct
       extensive capacity testing might experience the effects of
       Service Provider controls on their service.  Testing with the
       Service Provider's measurement hosts SHOULD be limited in
       frequency and/or overall volume"
- This could be a particularly important consideration when performing the
tests described in this document.
GIM>> Thank you for pointing to this consideration. Added the following text in Section 3.1.1:
NEW TEXT:
   A service subscriber performing extensive rate measurements on the
   operational network, SHOULD consider the Consideration 6 in
   Section 10 of [I-D.ietf-ippm-capacity-protocol]. 

Gorry Fairhurst





--------------GkPXiliEIe0AlJw7pE080hj3--