Skip to main content

Last Call Review of draft-ietf-bmwg-benchmarking-stateful-06

Request Review of draft-ietf-bmwg-benchmarking-stateful
Requested revision No specific revision (document currently at 09)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2024-05-22
Requested 2024-05-08
Authors Gábor Lencse , Keiichi Shima
I-D last updated 2024-05-20
Completed reviews Genart Last Call review of -06 by Robert Sparks (diff)
Secdir Last Call review of -06 by Alexey Melnikov (diff)
Opsdir Last Call review of -09 by Tim Chown
Tsvart Telechat review of -07 by Michael Scharf (diff)
Tsvart Last Call review of -06 by Michael Scharf (diff)
Assignment Reviewer Michael Scharf
State Completed
Request Last Call review on draft-ietf-bmwg-benchmarking-stateful by Transport Area Review Team Assigned
Posted at
Reviewed revision 06 (document currently at 09)
Result Ready w/issues
Completed 2024-05-20
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 if you reply to or forward this review.

The TSV-ART review for this informational document was requested with a
deadline of only 4 days during Pentecost holidays in Europe. As a result, this
TSV-ART review only represents a quick check.

At first sight, there are some issue related to transport protocols. They are
probably not hard to address in a revised draft:

- In section 8, the document assumes that HTTP(S) uses TCP. This is correct for
HTTP/1.x and HTTP/2, but not for HTTP/3, as HTTP/3 uses QUIC. The statement
regarding HTTP in Section 8 should be reworded.

- Section 4 should more precisely define what a "connection" is in the context
of the benchmark test. The text probably assumes "TCP connection" in a number
of places, but this should be made very explicit. Some use of the word
"connection" probably also applies to all transport protocols, including TCP
and UDP, but this is not always true. For instance, Section 4.8 ("Connection
Tear-Down") seems to focus only on TCP. In all descriptions of tests, it should
be made very clear what transport protocol is assumed.

- The document as a whole does not consider implications of use of QUIC. Given
the increasing share of QUIC in the total Internet traffic, this is somewhat
surprising. It could make sense to have at least some short discussion on the
impact of QUIC on the benchmarking, e.g., in section 8.

- The document only mentions TCP and UDP as Internet transport protocols. It
could make sense to at least mention somewhere other that other transport
protocols exist (SCTP, possibly also DCCP), possibly as a topic outside the
scope of the document. Similarly, issues resulting from multipath transport
(e.g., MPTCP) are not discussed in the document. That could be also stated

In general, I am not sure if it makes sense to use RFC2119/RFC8174 language in
such an informational document. At least in some cases the use of
RFC2119/RFC8174 language does not really affect interoperability. An example
would be Section 6.

Nit: s/athours/authors/ in Secion 8