[ippm] Re: Gorry Fairhurst's Discuss on draft-ietf-ippm-capacity-protocol-21: (with DISCUSS and COMMENT)

[Gorry Fairhurst <[e-mail]>]

On 03/07/2025 15:03, [e-mail] wrote:
>
> Hi Gorry,
>
> thanks for your fast review and proposed text.  V -23 should be 
> published before I leave office today.
>
> Two of your comments raised questions for me (please see below).
>
> Regards,
>
> Ruediger
>
> The following text is in 4.1, can we update this and move this to a 
> new section after 3.1
>
> [RG] Done. Please clarify, if the following sentence ending 2nd para 
> of this new section is complete:
>
> Measurements that generate traffic on shared paths (including wifi and 
> Internet paths)
> need to consider the impact on other traffic. For this reason, use of
> fixed rate flows is constrained to paths
>
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
That might be addressed in the other email thread.
>
> -------
>
> [GF] The text in Section 11.3.9 defines the following registry actions:
>    0-127                  IETF Review
>    128-239                First Come, First Served
>    240-249                Experimental
>    250-254                Private Use
> For me:
> 0-127 is clear, and the rules for expert review are being defined in 
> this I-D.
> 128-239 are very unclear to me.
> 250-254 Might be acceptable if scoped to meet the requirements here
> and permitted for use only in a controlled domain.
> I do not know what is actually intended. This needs discussion.
>
> [RG] That’s
> 11.3.9 Test Activation PDU Command Response Field Registry, the table 
> / registry actions are identical with
>
> 11.3.5.  Test Setup PDU Command Response Field Registry
>
> 11.3.6.  Test Activation PDU Command Request Registry
>
> [RG] AFAIK, the draft should specify the registry procedure for values 
> which aren’t assigned. That’s my first registry and my intent is to 
> leave space for development (I read into some other IPPM work to get 
> ideas). The proposal may be changed, if deemed necessary. Guidance is 
> appreciated.
>
There can three sub registries within the new registry, and you can 
pre-load values into each.

We decided there should be no FCFS part, because permenant assignments 
needed at least Expert Review, and I suggest are assigned based on

the "Specification Required" policy, review and approval by a designated expert of  RFC  8126.

 From my side it is OK to reserve a set of values for experimental use. 
You need to work with your AD to decide if the experimental range can 
also be constrained for local use.

Let's see where we have reached after the next revision and we can then 
recommend words.

Gorry

> *Von:*Gorry Fairhurst <[e-mail]>
> *Gesendet:* Mittwoch, 2. Juli 2025 16:38
> *An:* Geib, Rüdiger <[e-mail]>; [e-mail]
> *Cc:* [e-mail]; 
> [e-mail]; [e-mail]; [e-mail]; Gorry Fairhurst 
> <[e-mail]>
> *Betreff:* Re: AW: Gorry Fairhurst's Discuss on 
> draft-ietf-ippm-capacity-protocol-21: (with DISCUSS and COMMENT)
>
> On 02/07/2025 09:29, [e-mail] wrote:
>
>     Hi Gorry,
>
>     thanks for your comments. Please find replies marked [Authors] below. I've just posted  v -22 containing the suggested changes below, hopefully making some progress to clearing your DISCUSS. In some cases, I have trouble figuring out, what you expect. Suggesting text or a more detailed description of expected content would be appreciated.
>
>     Please note, I will be on vacation from/including Fri , 4.7.2025 until and including Mon 28.7.2025. I won't attend the Madrid IETF meeting.
>
>     Regards,
>
>     Ruediger
>
> Below is my reply after looking at the changes in -22 and suggestions 
> below, see [GF].
>
> Gorry
>
> ===
>
>     -----Ursprüngliche Nachricht-----
>
>     Von: Gorry Fairhurst via Datatracker<[e-mail]> <mailto:[e-mail]>
>
>     Gesendet: Donnerstag, 26. Juni 2025 13:08
>
>     An: The IESG<[e-mail]> <mailto:[e-mail]>
>
>     Cc:[e-mail];[e-mail];[e-mail];[e-mail];[e-mail]
>
>     Betreff: Gorry Fairhurst's Discuss on draft-ietf-ippm-capacity-protocol-21: (with DISCUSS and COMMENT)
>
>     Gorry Fairhurst has entered the following ballot position for
>
>     draft-ietf-ippm-capacity-protocol-21: 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 tohttps://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-capacity-protocol/
>
>     ----------------------------------------------------------------------
>
>     DISCUSS:
>
>     ----------------------------------------------------------------------
>
>     Thank you for this I-D that defines a method for measuring Network Capacity
>
>     metrics. The measurement flows generate Internet packet flows that are
>
>     rate-controlled. The primary concerns are about the use of Datagrams
>
>     (addressing and packet size), the security model, and the congestion control
>
>     functions. This is therefore a significant piece of transport work and there is
>
>     a much longer than a normal DISCUSS. I have updated my ballot below, where
>
>     resolutions have alreday been implemented in rev-21 and expect to clear the
>
>     remaining, after more discussion.
>
>     ----------------------
>
>     DISCUSS 2.2 At the end of Section 4.2:
>
>     To ensure readers are clear about the importance, I'd strongly recommend to add
>
>     a note stating that the described method is necessary also to avoid potentially
>
>     inducing congestion after there is a overload/loss on the control path.
>
>     [GF] One concern could be that the algorithm as specified can be used to mount
>
>     a DoS attack. That might be inevitable if it is not possible to put safeguards
>
>     to act to prevent this. That needs to be noted.
>
>     [Authors]: ADD in 4.3 (Security Mode Operations):
>
>     A load rate adjustment method matching Section 4.1 requirements is necessary also to    avoid potentially inducing congestion after there is an overload        or loss in general on the control path.
>
> [GF] This is a good direction, could I suggest:
>
> A load rate adjustment method needs to satisfy the requirements listed in Section 4.1. This is necessary also to avoid potentially inducing congestion after there is an overload or loss (including loss on the control path).
> [GF] The new test isn't clear, but heads in a good direction.
> OLD: This document specifies IETF's first active
> NEW: This document specifies an active
> ---
> The following text is in 4.1, can we update this and move this to a new sectio after 3.1
> OLD: While inducing
>     congestion (active capacity measurement requires that, the load rate
>     adjustment algorithm and the protocol specified by this document
>     limit the duration of his congestion and stop the test if sudden
>     impairments or a loss of connectivity in any or all directions occur.
> NEW:
> Active capacity measurement requires inducing intentional congestion. On paths
> where the capacity bottleneck is not shared with other flows, this
> self-congestion will be observed as loss and/or delay. However, when a
> path is shared by other flows, the measurment traffic can congest
> the bottleneck on the path and therefore can degrade the performance of other
> flows. Unrestricted use of the tool could lead to starvation and significant
> issues.
> Measurements that generate traffci on shared paths (including wifi and Internet paths)
> need to consider the impact on other traffic. For this reason, use of
> fixed rate flows is constrained to paths
> Concurrent tests that congest a common bottleneck will impair the measurement
> and result in additional congestions. Concurrent measurements
> to measure the maximum capacity on a single path are
> counterproductive. The number of concurrent, independent tests of a
> path SHALL be limited to one.
> A load rate adjustment algorithm (see section 4.1) is required to mitigate the impact of
> this congestion and to limit the duration of any congestion by terminating
> the test when sudden impairments or a loss of connectivity is detected.
> --------------
> This leaves 4.1 with:
> ---
> OLD:
>   New standard load rate adjustment algorithms for capacity measurement
>     MUST comply with the requirements specified by this this section.
> NEW:
> Load rate adjustment algorithms for capacity measurement
> MUST comply with the requirements specified by this section:
> ---
> OLD:
> MUST be reviewed by IETF experts
> NEW:
> MUST be reviewed by an IETF designated expert
> ---
> [GF] I am unsure about the following new words exactly, could we say something like:
> OLD:
>     Example measurement load rate adjustment algorithms fulfilling the
>     erquirements specified by theis sectiomn may be found in:
> NEW:
>     The following measurement load rate adjustment algorithms are
>     subject to these requitements:
> ---
> [GF] As a useful step, it would really help to number the requirements.
> 1. The measurement load rate adjustment algorithm described in this
>     section MUST NOT be used as a general Congestion Control Algorithm
>     (CCA).
> 2. This specification MUST only be for diagnostic and operations measurements.
> 3. Both, Load PDU messages and Status Feedback PDU messages MUST contain
>     sequence numbers to enable loss, duplication or reordering to be detected.
> 4. The default the nominal duration of a measurement interval at the Destination,
>     testIntTime (I in [RFC9097]), MUST be a value no more than 10 sec.
> 5. A high-speed mode to achieve high sending rates quickly MUST reduce
>     the measurement load below a level for which the first feedback
>     interval inferred "congestion" from the measurements....
> etc.
> I can't yet tell if these satisfy the conditions for safe deployment, but I do agree with the intent. We can discuss, but I would like to also discuss a good way forward with MED.
>
>     -----------------------
>
>     DISCUSS 2.4 In section 5.1. on the responsiveness (what CC experts often call
>
>     aggressive behaviour) of a flow: I note that the LOAD CONTROL as define uses a
>
>     statically configured watchdog interval -  which I think allows a flow to
>
>     contribute excess congestions for 3 seconds after this is detected, longer if
>
>     small levels of loss/congestion is not considered a trigger. For an arbitrary
>
>     path RTT this could be a large number of RTTs (e.g. 300 for a 10mS path). -
>
>     There are specific recommendations on the use of UDP that describe this case:
>
>     RFC 8085.
>
>     [GF] Please could you  add the following text after:
>
>     /The Method of Measurement discussed there deploys a feedback channel from the
>
>     receiver to control the sender's transmission rate in near-real-time./ NEW:
>
>     Section 8.1 of RFC 9097 specifies requirements for this method.
>
>     [Authors]: Thanks, Done.
>
> Thanks - this is now resolved.
>
>     -------------------------
>
>     DISCUSS Topics 3: How do we know the suitability of the specified rate
>
>     adaptation mechanisms?
>
>     DISCUSS 3.3  There seems little discussion of the risk to the network and other
>
>     flows when performing a fixed-rate test, or whether this is applicable usage
>
>     across an Internet path.
>
>     [GF] Please consider a separate discussion of this.
>
>     [Authors]: ADD
>
>     3.1. Fixed-Rate Testing
>
>     A network operator who's certain of the IP-Layer Capacity to be validated, may execute a fixed-rate test at the IP-Layer Capacity and avoid activating the measurement load rate adjustment algorithm (see section 8.1 of [RFC9097]).
>
>     Fixed-rate testing should only be activated for operation and maintenance purposes by operators within their network domain.
>
>     If a subscriber requests a diagnostic test from the network operator, this strongly implies that there is no certainty on the bottleneck capacity and initiating a UDP Speed Test based on the load adjustment algorithm is the preferred option. To protect against misuse, a client (and in general, a consumer) must not be able to initiate a fixed-rate test.A network operator may further conduct a fixed-rate test for stable measurement at the maximum determined by the load rate adjustment algorithm for debugging purposes.
>
> [GF] This is very close to what I hoped for, can I suggest we 
> introduce keywords and refine more like this:
>
> NEW:
>
> 3.1. Fixed-Rate Testing
> A network operator who is certain of the IP-Layer Capacity to be validated, can execute a fixed-rate test of the IP-Layer Capacity and avoid activating the measurement load rate adjustment algorithm (see section 8.1 of [RFC9097]). Fixed-rate testing SHOULD only be activated for operation and maintenance purposes by operators within their local network domain.
> If a subscriber requests a diagnostic test from the network operator, this strongly implies that there is no certainty on the bottleneck capacity and initiating a UDP Speed Test based on the load adjustment algorithm is RECOMMENDED.  To protect against misuse, a client (and in general, a consumer) MUST NOT be able to initiate a fixed-rate test. A network operator may further conduct a fixed-rate test for stable measurement at the maximum rate determined by the load rate adjustment algorithm for debugging purposes.
> ---
> I do expect this (or similar text from you) to resolve this.
>
>     -----------------------
>
>     DISCUSS Topics 4. Concurrent flows.
>
>     4.1 In section 9.0:
>
>         /It is obviously counterproductive to run more than one independent
>
>         and concurrent test/
>
>     - Is there a congestion control or DoS issue here, I think so, can we discuss
>
>     why the I-D says this is allowed without a mechanism to defend against this?
>
>     [GF] See DISCUSS 3.3.
>
>     [Authors] Please suggest a change or addition to the current text, which limits number of concurrent, independent tests to one (or point out somewhat more precise, what you mean by "a mechanism"):
>
>     It is obviously counterproductive to run more than one independent and concurrent test (regardless of the number of flows in the test stream) attempting to measure the maximum capacity on a single path. The number of concurrent, independent tests of a path SHALL be limited to one.
>
> [GF] I expect this will be resolved when the above changes were made.
>
>     ---
>
>     DISCUSS Topics 5. Definition of an IANA Registry for alternative rate control
>
>     algorithms.
>
>     The present I-D says: "Test Activation PDU Rate Adjustment Algo.  Registry"
>
>     Why should the IETF publish a registry for this protocol with a private space
>
>     and no overarching congestion control framework?
>
>     In 11.2.8, the present I-D says:
>
>         Value   Description             Reference
>
>         (Numeric)
>
>         ===================================================
>
>          A(n/a)  Not used                <this RFC>
>
>          B(0)    Rate algorithm Type B   <this RFC>
>
>          C(1)    Rate algorithm Type C   <this RFC>
>
>         Table 16: Initial Test Activation PDU Rate Adjustment Algo. values
>
>     ---
>
>     DISCUSS 5.3 RFC 9473 has provided guidance on the IETF process if this is being
>
>     considered for use on Internet paths. Why is the IETF standardising use of a
>
>     rate adjustment algorithm defined elsewhere, without bounding its over-arching
>
>     congestion control properties? Please explain how these methods were evaluated,
>
>     and by whom. How in the future will this be tested for congestion control and
>
>     how this will be maintained.
>
> [GF]   The implemented changes have resolved this issue.
>
>     ---
>
>     DISCUSS 5.4  What is the scope of use for a rate adjustment algorithm defined
>
>     as experimental. RFC 9473 provided guidance on this topic. Why is this not
>
>     scoped only for use in limited domains?
>
> [GF] The text in Section 11.3.9 defines the following registry actions:
>     0-127                  IETF Review
>     128-239                First Come, First Served
>     240-249                Experimental
>     250-254                Private Use
> For me:
> 0-127 is clear, and the rules for expert review are being defined in this I-D.
> 128-239 are very unclear to me.
> 250-254 Might be acceptable if scoped to meet the requirements here
> and permitted for use only in a controlled domain.
> I do not know what is actually intended. This needs discussion.
>
>     ---
>
>     DISCUSS Topics 6. How are new methods evaluated and specified?
>
>     I suggest discussion of how to provide IANA guidance for a new code point.
>
>     [Authors] All of these seem to be algo standard related. Draft text/ADD in section "Load Rate Adjustment Algorithm Requirements" (please suggest text or more precise proposals for changes, if we've missed a point):
>
>     This document specifies IETF's first active capacity measurement method using a load rate adjustment algorithm. While inducing congestion (active capacity measurement requires that), the load rate adjustment algorithm and the protocol specified by this document limit the duration of his congestion and stop the test if sudden impairments or a loss of connectivity in any or all directions occur.
>
> [GF] Comments above.
>
>     The requirements following below and the currently standardised load rate adjustment algorithms B [Y.1540Amd2] and C [TR-471] result from years of experiments and testing by the original authors. These tests were performed in Labs, but also in the Internet and covered a set of different fixed, broadband, mobile and wireless access types and technologies in different countries and continents. Feedback received by performance measurement experts was included, as well as changes resulting from the standardisation of [RFC9097] (reflected also in algorithm B [Y.1540Amd2], which updates a prior version of this algorithm).
>
>     New standard load rate adjustment algorithms for capacity measurement MUST comply with the requirements specified by this this section. New standard load rate adjustment algorithms for capacity measurement MUST be reviewed by IETF experts prior to assignment of a codepoint in the IETF Test Activation PDU Rate Adjustment Algorithm Registry
>
> [GF] Comments above.
>
>     ##########################
>
>     DISCUSS 6.1 Please see this text:
>
>       /On the other hand, the test configuration MAY use a fixed sending
>
>         rate requested by the client, using the field srIndexConf./
>
>     - A fixed rate test brings additional concerns, and I didn't find this
>
>     analysis. Is there a need to scope this as a non-default mode? Should it be
>
>     restricted to certain domains.
>
>     [GF] See DISCUSS 3.3.
>
>     [Authors]: see DISCUSS 3.3.
>
> [GF] Thought resolved, with the changes above.
>
>     ===############# End of [Authors] replies ############
>
>     ----------------------------------------------------------------------
>
>     COMMENT:
>
>     ----------------------------------------------------------------------
>
>     I have a number of non-blocking comments that I expect could be addressed in
>
>     the next revision of this I-D:
>
> <<snip>>
>
>     ===
>
> [GF] See also the comments below:
>
>     There are some additional NiTs that I noted in rev-21:
>
>     /erquirements/requirements/
>
>     /theis sectiomn may/this section can/
>
>     /PDU timeout which both stop/PDU timeout that both stop/
>
>     I agree with the requirement, but I see a problem that this directly follows
>
>     the discussion of the UDP checksum, but the word checksum could be confused
>
>     between the two. Could we insert a word before checksum here:, perhaps add the
>
>     word /PDU/ and a cross reference to section 5.2? /If a PDU sender is populating
>
>     the checkSum field,/
>
>     Similarly the keyword here could be confused, can we insert /PDU/ before
>
>     checksum here: / If checksum validation fails.../
>
>     Query: Ought this message to be rate-limited. i.e., "If sent, this message
>
>     SHOULD be rate limited to avoid exploitation as a DoS mechanism". /The
>
>     exception is for operations support: server         administrators are
>
>     permitted to send a Setup Response to support operations and troubleshooting./
>
>     Can this say a tiny bit more than this:
>
>     /note that not-ECT MUST be used./
>
>     NEW:
>
>     Note: This specification does not provide an ECN-capable transport, therefore
>
>     the sender SHALL set the ECN field to not_ECT./
>
>     ===
>
>     And finally, so we do not forget what was discuused, here are the currently
>
>     resolved DISCUSS positions:
>
>     ---
>
> <<snip>>
>