Skip to main content

Last Call Review of draft-ietf-bmwg-b2b-frame-03
review-ietf-bmwg-b2b-frame-03-tsvart-lc-black-2020-11-24-00

Request Review of draft-ietf-bmwg-b2b-frame
Requested revision No specific revision (document currently at 04)
Type Last Call Review
Team Transport Area Review Team (tsvart)
Deadline 2020-12-04
Requested 2020-11-20
Authors Al Morton
I-D last updated 2020-11-24
Completed reviews Secdir Telechat review of -03 by Mališa Vučinić (diff)
Tsvart Last Call review of -03 by David L. Black (diff)
Assignment Reviewer David L. Black
State Completed
Request Last Call review on draft-ietf-bmwg-b2b-frame by Transport Area Review Team Assigned
Posted at https://mailarchive.ietf.org/arch/msg/tsv-art/41ahYzkTpOkiOgdg2MtuEktRl0A
Reviewed revision 03 (document currently at 04)
Result Ready w/issues
Completed 2020-11-24
review-ietf-bmwg-b2b-frame-03-tsvart-lc-black-2020-11-24-00
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.