[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bmwg] Review/comments on version 2 of IPv6 benchmarking draft



Below are my comments on version 2 of the IPv6 Benchmarking Methodology
draft.  Most recommended changes are grammatical in nature.

Bill Cerveny

Last Call Review Template

I-D Title(s): IPv6 Benchmarking Methodology
Filename(s):draft-ietf-bmwg-meth-02.txt
Reviewer Name: Bill Cerveny
Date: August 10, 2007

Please organize your comments in the following categories below.

Review Summary:

Overall:

   * Does/Do the draft(s) provide clear identification of the
     scope of work? E.g., is the class of device, system, or
     service being characterized clearly articulated.

Yes


   * If a terminology memo, are the measurement areas clearly
     defined or otherwise cited?  

Yes

Is the working set of
     supporting terminology sufficient and correct?  
Yes

To your
     knowledge, are the areas of the memo that may conflict
     with other bodies of work? Are there any measurements or
     terminology that are superfluous?  Are any missing?

No
   * If a methodology memo, does the methodology AND its
     corresponding terminology adequately define a benchmarking
     solution for its application area? Do the methodologies present
     sufficient detail for the experimental control of the benchmarks?

Yes


   * If neither a terminology or methodology, does the offered
     memo offer complementary information important to the use
     or application of the related benchmarking solution?


   * Do you feel there are undocumented limitations or caveats to
     the benchmarking solution being proposed?  If so, please
     describe.

No


   * Does the memo attempt to define acceptance criteria for
     any of the benchmark areas?


Technical Content:  (Accuracy, Completeness of coverage)

   Are definitions accurate? Is the terminology offered relevant?

Yes

   To your knowledge, are there technical areas that are erroneous?
   Are there questionable technical areas that need to be re-examined
   or otherwise scrutinized.

Not to my knowledge

   Does the solution adequately address IPv6?

Yes


   Do you feel the memo(s) being offered are technically mature enough
   for advancement to informational RFC?

Yes


Clarity and Utility:

  If you had a need, would you utilize the benchmarking solutions
  advocated by this and its related memos?  If not, why?

Yes


Conformance to BMWG principles: (see BMWG charter)
http://www.ietf.cnri.reston.va.us/html.charters/bmwg-charter.html


  Do you have confidence that the benchmarks, as explicitly
  defined, will yield consistent results if repeated on the
  same device (DUT/SUT), multiple times for a given test condition.
  If not, cite benchmark(s) and issue(s).

Yes


  Do you have confidence that the benchmarks, if executed for a
  given test condition, utilizing the documented methodology
  on multiple test infrastructure (e.g., test equipment), would
  yield correct and consistent results on the same DUT/SUT?
  (Said differently, are the benchmark's methodology written
  with enough exacting detail, that benchmark implementation
  differences do not yield a difference in the measured quantities?)
  If not, cite benchmark(s) and issue(s).
 
Yes


  Do you feel that the benchmarks form a basis of comparison between
  implementations of quantity being characterized? (I.e., are the
  benchmarks suitable for comparing solutions from different vendors.)

Yes


  If not, cite benchmarks and issues.


  For those benchmarks cited above, do you feel that the benchmarks,
  as specified, have universal applicability for the given
  behavior being characterized?  (i.e., benchmarks might not form
  a basis for cross-vendor comparison, can be used universally
  in a different role.)



Editorial Comments:
(includes any deficiencies noted w.r.t. I-D Nits, spelling, & grammar)

Bill's preface: Some of the changes are merely my preference ... for
example I tried to delete use of words I thought were unnecessary, such
as "that" or "the"


Page header: Title of document is "IPv6 Benchmarking Methodology".
However, page headers say "IPv6 Performance Benchmarking"

Abstract:

Consider changing first sentence to something like (removed
capitalization,
reworded):

The benchmarking methodologies defined in RFC2544 [8] are IP version
independent.  However, RFC2544 does not address some of the unique
attributes
of IPv6.

Next sentence (added punctuation):

This document provides additional benchmarking guidelines, which in
conjunction with RFC2544, lead to a more complete and realistic
evaluation
of the IPv6 performance of network elements.

Section 1:

Second paragraph, last sentence (rewording, shortened)

These recommendations are defined within the RFC2544 framework and
complement the test and result analysis procedures as described in
RFC2544.

Section 3:

I think you need to change references to section 7, not section 6.

s/for each evaluated device it is/for each evaluated device, it is/
(punctuation)

s/Test execution and the results/Test execution and results/

Section 4:

s/are the same as the ones/are the same as those/

s/Single-port testing is used in measuring per interface/Single-port
testing measures per-interface/

s/multi-port testing is used to measure/multi-port testing measures/

s/data that might be recommended to be collected/data collected/

s/scenarios assume the test traffic/scenarios assume test traffic/

s/and the IPv6 source and destination/and IPv6 source and destination/

Section 5:

s/The traffic used/Traffic used/

s/traffic in all of its aspects/traffic/

The sentence "Ethernet in all of its types has become the most commonly
deployed
interface ..." seems to imply that Ethernet is an interface -- consider
rewording.

s/selection of addresses for the test traffic/selection of addresses for
test traffic/

s/into either one of the following/into either of the following/

s/additional data with respect to the performance/additional data
regarding the performance/

s/The IPv6 source and destination addresses for the test/IPv6 source and
destination addresses for test/

s/If the network element/If network element/

s/the tests SHOULD focus/tests SHOULD focus/

s/The IPv6 source and destination addresses/IPv6 source and destination
addresses/

s/They can be selected from/Extension header types can be selected from/

s/Encapsulation Security Payload header/Encapsulating security payload
(ESP) header/

s/Considering that extension/Since extension/

s/Unlike the other/Unlike other/

s/the DUT but/the DUT, but/

s/Hop-by-hop/hop-by-hop/ (multiple instances)

s/extension headers but/extension headers, but/

s/traffic with the Hop-by-hop/traffic with hop-by-hop/

s/The tests with traffic/Tests with traffic/

s/The chain should also exclude/This chain should exclude/

s/chain recommended to be used in testing/chain recommended for testing/

s/smallest frame size both types of traffic/smallest frame size of both
types of traffic/

s/it is likely that the/it is likely the/

s/extension headers related performance impact/performance impact
related to extension headers/

Section 6:

Consider rewording first paragraph, second sentence as follows:

The conditions defined in RFC2544 section 11 are common to IPv4 and
IPv6, except that IPv6
does not employ layer 2 or 3 broadcast frames.

lower-case: Frames -> frames

s/The filter definitions however must/The filter definitions must/

Regarding statement "which are an important architecture component of
IPv6." at end of last sentence
in section 6.2 ... hasn't this already been established earlier?

s/(DA) are IPv6./(DA) are IPv6 addresses/

s/must parse through the extension headers in order to reach/must parse
through extension headers to reach/

s/for example, the upper/for example, upper/

s/For these reasons, to/To/

New paragraph before "The upper layers protocols listed above ..."

s/recommended selection however they/recommended selection. However,
they/

Not sure if the below changes what you were attempting to say, but it is
unclear as is in my opinion:

Suggested changed first paragraph of 6.2.2:

Based on RFC2544 recomendations, two types of tests are executed when
evaluating performance in the presence of modifiers: One with a single
filter and another with 25 filters.  The example filters are illustrated
using the IPv6 documentation prefix [10]
2001:DB8::.

I'm puzzled about your heading of "Example of 25 filters" ... is it
intended there will be 25 filter lines in the final document?

Section 7:

Second paragraph, second sentence, consider changing to:

The tests recommended by RFC2544 MUST be repeated for both IPv6 traffic
without extension headers and for IPv6 traffic with one or multiple
extension headers. ("both" might
be deletable here)

Phrase "... performance of platforms forwarding both types of traffic."
Perhaps we will always be testing "forwarding" but would "processing" be
a more appropriate
word if there are cases where the DUT is not forwarding traffic??

s/it is important for IPv6 enabled platforms to not/it is important that
IPv6-enabled platforms not/

s/to cover the co-existence/to cover co-existence/

Sentence "A minimum requirement is to cover ..." seems really awkward to
me.  Consider rewording.

s/The subsequent sections describe each/Subsequent sections each
describe/

Lower-case: Back-to-Back -> back-to-back

Section 10:

s/This document is addressing/This document addresses/

_______________________________________________
bmwg mailing list
bmwg at ietf.org
https://www1.ietf.org/mailman/listinfo/bmwg