Hi,

I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG.  These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review.  Document editors and WG chairs should treat these comments just like any other last call comments.

The document has very minor nits, and is pretty much Ready.

This draft proposes the use of specific bits for the purposes of marking traffic to support passively estimating round trip time (delay) and loss between two endpoints supporting the mechanisms described in the document.  The approach is designed with encrypted transport protocols in mind.

The document is well-structured.  Some of the more detailed descriptions of the use of the bits, particularly the later sections on the R and Q bits were a little hard to follow, but overall the quality is good. Some of the use of language hints at author(s) for whom English is not their first language, some minor improvement would be desirable before submission towards publication, to save effort for the RFC Editor.

Overall the proposed use of the bits seems reasonable, and potentially useful. It is not clear what implementations are available or tested as yet, there is only one mention of a part implementation by Christian Huitema. The draft talks of what a QUIC implementation would need to do, implying there is as yet not one available. However, given the document’s Informational status this is less of a concern.

The summary of approaches at the end is very useful.

Some use case discussion might be useful, especially for an informational document. Maybe include a couple of extremes, one a intra-DC, one for large scale data transfers over 100G+ paths from Europe to the US; these might require quite different “tuning” of the techniques and bits (considering train sizes, counters, etc)?

General comments:

“Explicit Host-to-Network Flow Measurement Techniques” is perhaps not the best name, or most indicative of the approach. Is it explicit? Is it host to network or client to server? 

Perhaps emphasise more in the abstract and introduction (and even the title) that the approach is passive.  And maybe that the methods don’t necessarily, or even generally, cover all packets in a flow.  

The AltMark drafts are now published - RFC 9341, 9342, 9343.

Specific comments:

The draft suggests which bits could be used for TCP and QUIC implementations, in particular using reserved bits at the end of Section 1, but is not a Standards Track document, so cannot specifically reserve bits.

Section 2.2 - maybe some scenarios would prefer application measurement; maybe the draft should state the approach is designed for network delays, not full end-to-end delays.

In 2.2.3 I suppose the 100ms needs to be a value big enough that it is worse than the likely worst case. This would be different for the scenarios I mentioned above.

In 2.2.4.1 “endpoints” aren’t defined.  Are they nodes, or unique port/IP tuples? Given the title says “flow”, presumably the latter.

In 2.2.5 is it worth mentioning cases where an observer might not see both flows?  Use of ECMP, or other asymmetric routing in particular.  The client should still see everything g, but an observer’s mileage may vary.

In 3.1.1 and the end of 3.1.2 these trains could be quite large, thinking of how many packets are in flight on a 30Gbps data transfer flow over a 100ms path.  The example at the end of 3.1.3 is of 5 packets.

WRT 3.5, I started musing over ECN as another “measurement” bit somewhere in Section 2, nice to see it discussed here.

Tim