Re: [bmwg] Comments for draft-ietf-bmwg-b2b-frame-00

["MORTON, ALFRED C (AL)" <[e-mail]>]

One place where   s/DUT/Test Device/
is needed, sorry!

... and the Test Device just kept increasing number of
frames until it reached and reported a number of frames that
corresponded to 30 seconds buffer time (impossible).


From: bmwg [mailto:[e-mail]] On Behalf Of MORTON, ALFRED C (AL)
Sent: Saturday, November 9, 2019 12:31 PM
To: Timothy Carlin <[e-mail]>; [e-mail]
Subject: Re: [bmwg] Comments for draft-ietf-bmwg-b2b-frame-00

***Security Advisory: This Message Originated Outside of AT&T ***
Reference http://cso.att.com/EmailSecurity/IDSP.html for more information.
Hi Tim,
Thanks for your comments; they are not too late as I
overlooked others and have a working version ready
for the Monday when Submission opens-up again.

Meanwhile, we can discuss here as necessary.
Please see below,
Al
(as a participant)

From: bmwg [mailto:[e-mail]] On Behalf Of Timothy Carlin
Sent: Friday, November 8, 2019 8:58 AM
To: [e-mail]<mailto:[e-mail]>
Subject: [bmwg] Comments for draft-ietf-bmwg-b2b-frame-00

Hi bmwg,

This is somewhat late for IETF 106 but I have just a few comments regarding draft-ietf-bmwg-b2b-frame-00.  I think this draft is well written and a valuable addition.

Best Regards,
Tim Carlin

* Section 3, item #2: re: "The Back-to-back Frame length reported for large frame sizes..." I'm not familiar with the experiment results, but it's not clear to me if "length" is referring to the number of frames, or the average size of those frames, or something else.  This may just be a misunderstanding on my part, ignore if that's the case!
[acm]
Length refers to the number of frames in the B2B stream (burst).
In the particular DUT & cases tested, the B2B frame rate
for large frames was less than the maximum packet header
processing rate, and the DUT just kept increasing number of
frames until it reached and reported a number of frames that
corresponded to 30 seconds buffer time (impossible).

I clarified the text.

* Section 3 excerpt: typo in parenthetical "cannot exceed the exceed"
   Further, if the Throughput tests of Section 26.1 of [RFC2544] are
   conducted as a prerequisite test, the number of frame sizes required
   for Back-to-back Frame Benchmarking can be reduced to one or more of
   the small frame sizes, or the results for large frame sizes can be
   noted as invalid in the results if tested anyway (these are the frame
   sizes for which the back-to-back frame rate cannot exceed the exceed
   the frame header processing rate of the DUT and no buffering occurs).

* Section 4 excerpt: typo "sender and recover"
   The Test Setup MUST be consistent with Figure 1 of [RFC2544], or
   Figure 2 when the tester's sender and recover are different devices.

[acm]
Thanks for those catches!