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

[Gorry Fairhurst via Datatracker <[e-mail]>]

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.

## (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.

## (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?


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

Gorry Fairhurst