Reviewer: Michael Scharf
Review result: Ready with Issues
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@xxxxxxxx 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
explicitly.
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
--
last-call mailing list -- last-call@xxxxxxxx
To unsubscribe send an email to last-call-leave@xxxxxxxx
