This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

When done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
tsv-art@ietf.org if you reply to or forward this review.

Thank you for a well-written, well-organised, and clearly motivated draft. This is a well-specified mechanism that looks appropriate to the intended task. I have only a few transport-related comments.

§2.2.3: The mechanism to calculate T_max_c is fine, and I’m not suggesting a change, but I note that protocols such as TCP compute a retransmission timeout value that is similarly some multiple of the RTT, with a comparable magnitude. It might be helpful for the draft to discuss why such an existing protocol-specific value (e.g., Trto in TCP) was not adopted for T_max.

The delay bit mechanism presumably fails if the delay suddenly increases to more than T_max. Such temporary delay spikes can certainly occur in practise (e.g., I’ve seen them on poor-quality WiFi links). The draft would benefit from a discussion of the limitations of the mechanism in detecting edge cases such as this.

§3.5: The use of an unreported ECN-Echo counter looks appropriate for CE marks generated in response to ECT(0)-marked traffic following RFC 3168 that generate CE marks at a rate comparable to that of packet loss. However, flows using L4S marking with ECT(1), as described in RFC 9331, generate CE marks at a much higher rate. Would it make sense for the ECN-Echo Event Bit to either distinguish the two types of CE marking in reports, based on the ECT value of other packets in the flow, or to be restricted to CE marks generated in response to ECT(0)-marked packets?  Does the ECN-Echo counter produce usable results for L4S flows?

Section 6 suggests ways in which additional signals, as described in this draft, can be included in QUIC or TCP. While I agree that the approaches suggested could be plausible ways of carrying such additional signals, their inclusion here could be misinterpreted as specifying an approach rather than giving examples of possible approaches. It might be more appropriate to either remove this section, and leave the discussion of how to incorporate these signals into the protocols to the QUIC and TCPM working groups, or to limit the discussion of those protocols to noting that there are sufficient unused bits in their headers to allow these additional signals to be carried. 

In the entire draft, there’s an assumption that the paths taken by flows are stable, or at least traverse the same measurement point, for the duration of the measurements. It may be helpful to note this.

Regards
Colin