[ippm] Re: Gorry Fairhurst's Discuss on draft-ietf-ippm-asymmetrical-pkts-11: (with DISCUSS and COMMENT)

[Greg Mirsky <[e-mail]>]

Hi Gorry,
thank for your help in improving the document.

Hi Med,
Thank you for pointing out the change in the level of reference severity. I
updated it in -13:

Name:     draft-ietf-ippm-asymmetrical-pkts
Revision: 13
Title:    Performance Measurement with Asymmetrical Traffic Using Simple
Two-Way Active Measurement Protocol (STAMP)
Date:     2026-03-15
Group:    ippm
Pages:    20
URL:
https://www.ietf.org/archive/id/draft-ietf-ippm-asymmetrical-pkts-13.txt
Status:
https://datatracker.ietf.org/doc/draft-ietf-ippm-asymmetrical-pkts/
HTML:
https://www.ietf.org/archive/id/draft-ietf-ippm-asymmetrical-pkts-13.html
HTMLized:
https://datatracker.ietf.org/doc/html/draft-ietf-ippm-asymmetrical-pkts
Diff:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-ippm-asymmetrical-pkts-13

Regards,
Greg

On Sun, Mar 15, 2026 at 12:23 PM <[e-mail]> wrote:

> Hi Gorry/Greg, all,
>
>
>
> Thank you both.
>
>
>
> Please note that with the changes made to address discuss# 1 and 2 from
> Gorry (Section 4.1.1, in particular), draft-ietf-ippm-capacity-protocol has
> to be moved to be listed as normative. Greg please make that change as
> well. Thanks.
>
>
>
> Cheers,
>
> Med
>
>
>
> *De :* Gorry Fairhurst <[e-mail]>
> *Envoyé :* lundi 16 mars 2026 00:51
> *À :* Greg Mirsky <[e-mail]>
> *Cc :* The IESG <[e-mail]>;
> [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> *Objet :* Re: Gorry Fairhurst's Discuss on
> draft-ietf-ippm-asymmetrical-pkts-11: (with DISCUSS and COMMENT)
>
>
>
>
>
> 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 <[e-mail]>
> 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 <
> [e-mail]> 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
>
>
>
>
>
>
> ____________________________________________________________________________________________________________
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
>
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
>
>