[ippm] Opsdir last call review of draft-ietf-ippm-explicit-flow-measurements-03

[Tim Chown via Datatracker <[e-mail]>]

Reviewer: Tim Chown
Review result: Ready

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