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

[Gorry Fairhurst <[e-mail]>]

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
>>
>>
>>
>