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.

This draft updates the back-to-back frame testing procedure in RFC 2544 to take account of experience.

The draft is in good shape, with one notable exception in Section 5.2:

   The duration of the trial MUST be at least 2 seconds, to allow DUT
   buffers to deplete.

That duration of 2 seconds has been carried forward from RFC 2544 without change.  A 2 second duration may have been sufficient to deplete buffers in 1999, but that is no longer reliably the case.  For example, on-site measurement of the network for the 2020 Linux Conference in Australia indicated a  at least 1.6 seconds of buffering, as indicated by Figure 1 at https://blog.apnic.net/2020/01/22/bufferbloat-may-be-solved-but-its-not-over-yet/, which is slide 6 in from the complete slide deck at: https://blog.apnic.net/2020/01/22/bufferbloat-may-be-solved-but-its-not-over-yet/ .  Experience with bufferbloat suggests that one network device was primarily responsible.  Also, see slide 14 in that slide deck.

That 1.6 seconds measured on an actual network is entirely too close to 2 seconds for confidence that buffers will be depleted in any tested device.  Hence, the 2 second minimum duration ought to be increased by at least a factor of 10.  I'd suggest changing it to 30 seconds or 60 seconds as convenient round numbers, and providing the rationale that increased buffering in WiFi devices, e.g., home "routers," as indicated by experience with bufferbloat measurements, is the reason for the increased duration.