[Last-Call] Tsvart telechat review of draft-ietf-ippm-explicit-flow-measurements-03

[Colin Perkins via Datatracker <[e-mail]>]

Reviewer: Colin Perkins
Review result: Almost Ready

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
[e-mail] 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