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

[Gorry Fairhurst <[e-mail]>]

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.

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


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