Skip to main content

Hash and Stuffing: Overlooked Factors in Network Device Benchmarking
RFC 4814

Revision differences

Document history

Date Rev. By Action
2015-10-14
08 (System) Notify list changed from bmwg-chairs@ietf.org to (None)
2012-08-22
08 (System) post-migration administrative database adjustment to the No Objection position for Sam Hartman
2012-08-22
08 (System) post-migration administrative database adjustment to the No Objection position for Brian Carpenter
2007-04-02
08 Amy Vezza State Changes to RFC Published from RFC Ed Queue by Amy Vezza
2007-04-02
08 Amy Vezza [Note]: 'RFC 4814' added by Amy Vezza
2007-03-29
08 (System) RFC published
2007-01-29
08 (System) IANA Action state changed to No IC from In Progress
2007-01-14
08 Amy Vezza State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza
2007-01-11
08 (System) IANA Action state changed to In Progress
2007-01-10
08 Amy Vezza IESG state changed to Approved-announcement sent
2007-01-10
08 Amy Vezza IESG has approved the document
2007-01-10
08 Amy Vezza Closed "Approve" ballot
2007-01-09
08 David Kessens State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by David Kessens
2007-01-03
08 Brian Carpenter [Ballot Position Update] Position for Brian Carpenter has been changed to No Objection from Discuss by Brian Carpenter
2007-01-02
08 (System) Sub state has been changed to AD Follow up from New Id Needed
2007-01-02
08 (System) New version available: draft-ietf-bmwg-hash-stuffing-08.txt
2006-12-30
08 David Kessens State Changes to IESG Evaluation::Revised ID Needed from IESG Evaluation::AD Followup by David Kessens
2006-12-30
08 David Kessens Revised ID needed for Brian's DISCUSS. Changes already agreed upon by Brian and authors.
2006-12-15
08 Amy Vezza State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza
2006-12-15
08 (System) Removed from agenda for telechat - 2006-12-14
2006-12-14
08 (System) [Ballot Position Update] Position for Sam Hartman has been changed to No Objection from Discuss by IESG Secretary
2006-12-14
08 Lisa Dusseault [Ballot Position Update] New position, No Objection, has been recorded by Lisa Dusseault
2006-12-14
08 Ross Callon [Ballot Position Update] New position, No Objection, has been recorded by Ross Callon
2006-12-14
08 Magnus Westerlund [Ballot Position Update] New position, No Objection, has been recorded by Magnus Westerlund
2006-12-14
08 Dan Romascanu [Ballot Position Update] New position, No Objection, has been recorded by Dan Romascanu
2006-12-13
08 Mark Townsley [Ballot Position Update] New position, No Objection, has been recorded by Mark Townsley
2006-12-13
08 Ted Hardie [Ballot Position Update] New position, No Objection, has been recorded by Ted Hardie
2006-12-13
08 Jari Arkko [Ballot Position Update] New position, No Objection, has been recorded by Jari Arkko
2006-12-13
08 Yoshiko Fong Correction:

The previous comment was NOT last Call, but Evaluation.

Apologies.
2006-12-13
08 Yoshiko Fong IANA Last Call Comment:

As described in the IANA Considerations section, we understand
this document to have NO IANA Actions.
2006-12-12
08 Sam Hartman
[Ballot discuss]
As I understand the link-layer discussion in this document, it
advocates the use of non-locally-administored MAC addresses that may
belong to vendors not …
[Ballot discuss]
As I understand the link-layer discussion in this document, it
advocates the use of non-locally-administored MAC addresses that may
belong to vendors not involved in the test without approval of those
vendors.  Is this consistent with IEEE 802.1?  I do understand that
this is probably what we actually want to do; I even understand why we
think it is a good idea.  But if it is not clearly within what is
allowed by IEEE specs we should run this section by them for review.
2006-12-12
08 Sam Hartman [Ballot Position Update] New position, Discuss, has been recorded by Sam Hartman
2006-12-12
08 Brian Carpenter
[Ballot comment]
Minor points from Gen-ART review by Joel Halpern:

        In section 4.2, in describing how to create the MAC address, …
[Ballot comment]
Minor points from Gen-ART review by Joel Halpern:

        In section 4.2, in describing how to create the MAC address, the upper byte is anded with 0xFC to clear the global/local and unicast/multicast bit so that the address will be a global multicast.  there are two minor issues here:
    Using a global MAC address construct from a random number and a port number is probably appropriate, but violates the standard.  It would probably be a good idea to acknowledge this fact, and explain why global (rather than local) addresses need to be used.
    The text refers to the two bits that are being controlled as the "high order two bits of that byte."  While those are the first two bits that will be clocked out over the ethernet, they are not the "high order" bits in most peoples understanding of the term.
2006-12-12
08 Brian Carpenter
[Ballot discuss]
Hopefully these are easy to fix (from Gen-ART review by Joel Halpern):

In the MPLS recommendation, it is recommended that labels be uniformly …
[Ballot discuss]
Hopefully these are easy to fix (from Gen-ART review by Joel Halpern):

In the MPLS recommendation, it is recommended that labels be uniformly distributed between 0 and 2^20.  Given that the labels 0-15  are reserved for special function, and often have special processing or discarding, it strikes me that test equipment may well get unexpected results if it randomly attempts to use those for normal operations.  I would recommend checking the the MPLS standards as to the current reserved range, and making sure the random assignment stays out of that.

...the IPv4 address used as samples in Appendix C are not RFC 3330 documentation values (192.0.2.0/24).  Similarly, the IPv6 example does not use the IPv6 documentation block assigned by RFC 3849 (2001:DB8::/32)
2006-12-12
08 Brian Carpenter [Ballot Position Update] New position, Discuss, has been recorded by Brian Carpenter
2006-12-11
08 Russ Housley [Ballot Position Update] New position, No Objection, has been recorded by Russ Housley
2006-12-11
08 Lars Eggert [Ballot Position Update] New position, No Objection, has been recorded by Lars Eggert
2006-12-11
08 Lars Eggert
[Ballot comment]
I don't see why this document should use RFC2119 terms anywhere.


Section 4.5., paragraph 3:
>    In addition, it may be desirable …
[Ballot comment]
I don't see why this document should use RFC2119 terms anywhere.


Section 4.5., paragraph 3:
>    In addition, it may be desirable to pick pseudorandom values from a
>    selected pool of numbers.  Many services identify themselves through
>    use of reserved destination port numbers between 1 and 1023
>    inclusive.  Unless specific port numbers are required, it is
>    RECOMMENDED to pick randomly distributed destination port numbers
>    between these lower and upper boundaries.

  The IANA registered ports extend to 49151, which should be the default
  upper bound.


Section 8.2., paragraph 0:
> 8.2.  Informative References

  Nit: All three are uncited.


Appendix C., paragraph 2:
>          | Source IP            | 192.168.13.1-192.168.13.254 |
>          | Destination IP        |        192.168.1.10        |

    Should use 192.0.2.0/24 - the block assigned as "TEST-NET" for use
    in documentation and example code.


Appendix D., paragraph 2:
>          | Source IP            | DEAD:0:0:1::1-DEAD:0:0:1::FF |
>          | Destination IP      |        DEAD:0:0:2::10        |

    Should use 2001:DB8::/32 - the block assigned as "TEST-NET" for use
    in documentation and example code.
2006-12-07
08 David Kessens [Ballot Position Update] New position, Yes, has been recorded for David Kessens
2006-12-07
08 David Kessens Ballot has been issued by David Kessens
2006-12-07
08 David Kessens Created "Approve" ballot
2006-12-07
08 (System) Ballot writeup text was added
2006-12-07
08 (System) Last call text was added
2006-12-07
08 (System) Ballot approval text was added
2006-12-07
08 David Kessens [Note]: 'Al Morton is the Document Shepherd' added by David Kessens
2006-12-07
08 David Kessens State Changes to IESG Evaluation from Publication Requested by David Kessens
2006-12-07
08 David Kessens Placed on agenda for telechat - 2006-12-14 by David Kessens
2006-12-06
08 Dinara Suleymanova
PROTO Write-up

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, …
PROTO Write-up

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?
Al Morton is the Document Shepherd.
He has reviewed this version of the draft and believes it is ready for
publication.
There is one typo in the Acknowledgements section:
Dan Romascanu's name is misspelled.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?
Yes, the document benefited from extensive WG commentary prior to and
during 3 WGLC, with the 4th WGLC passing quietly.
We requested an early Security Directorate Review. Joe Salowey and Jeffrey
Altman reviewed version 05 of the draft and provided some comments.
No concerns about the depth or breadth of the reviews.

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?
No.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here.
No.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?
As stated above, WG review has been extensive and many people have commented
and had their concerns addressed.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarize the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)
No.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?
The boilerplate and automated nits check-out fine.
The draft conforms to the I-D guidelines in all the following ways:
- Use of network byte order in diagrams
- Content of the IANA considerations section
- Proper split of Normative/Informative references
(the Informative References are bibliographical)
- Meaningful abstract
- Meaningful security considerations
- Proper values for example addresses, names, numbers
- Proper references, particularly to non-IETF documents
- No text that will be outdated after publication
- No Protocol issues (ipv4 specificity, congestion, internationalization,
proper specification of data to be checksummed, etc)


(1.h) Has the document split its references into normative and
informative?
Yes
Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state?
No
If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]?
No
If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggested a
reasonable name for the new registry? See
[I-D.narten-iana-considerations-rfc2434bis]. If the document
describes an Expert Review process has Shepherd conferred with
the Responsible Area Director so that the IESG can appoint the
needed Expert during the IESG Evaluation?
This document makes no requests of IANA.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?
NA

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Writeup? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary
Relevant content can frequently be found in the abstract
and/or introduction of the document. If not, this may be
an indication that there are deficiencies in the abstract
or introduction.

Test engineers take pains to declare all factors that affect a given
measurement, including intended load, packet length, test duration,
and traffic orientation. However, current benchmarking practice
overlooks two factors that have a profound impact on test results.
First, existing methodologies do not require the reporting of
addresses or other test traffic contents, even though these fields
can affect test results. Second, "stuff" bits and bytes inserted in
test traffic by some link-layer technologies add significant and
variable overhead, which in turn affects test results. This document
describes the effects of these factors; recommends guidelines for
test traffic contents; and offers formulas for determining the
probability of bit- and byte-stuffing in test traffic.

Working Group Summary
Was there anything in WG process that is worth noting? For
example, was there controversy about particular points or
were there decisions where the consensus was particularly
rough?
From the initial work proposal through the final WG Last Call, there was
wide agreement that this work was important for BMWG in that it added key
testing considerations to our body of literature.

Document Quality
Are there existing implementations of the protocol? Have a
significant number of vendors indicated their plan to
implement the specification? Are there any reviewers that
merit special mention as having done a thorough review,
e.g., one that resulted in important changes or a
conclusion that the document had no substantive issues? If
there was a MIB Doctor, Media Type or other expert review,
what was its course (briefly)? In the case of a Media Type
review, on what date was the request posted?
All BMWG RFCs are Informational, but they are implemented by
test equipment vendors and cited in trade publications and advertisements.
The Acknowledgements recognize individuals who have done careful reviews.
There is one publicly reported implementation, and others reported to
be in progress.

Personnel
Who is the Document Shepherd for this document?
Al Morton
Who is the Responsible Area Director?
David Kessens
2006-12-06
08 Dinara Suleymanova Draft Added by Dinara Suleymanova in state Publication Requested
2006-11-22
07 (System) New version available: draft-ietf-bmwg-hash-stuffing-07.txt
2006-11-08
08 (System) Request for Early review by SECDIR Completed. Reviewer: Jeffrey Altman.
2006-11-08
08 (System) Request for Early review by SECDIR Completed. Reviewer: Joseph Salowey.
2006-09-29
06 (System) New version available: draft-ietf-bmwg-hash-stuffing-06.txt
2006-02-10
05 (System) New version available: draft-ietf-bmwg-hash-stuffing-05.txt
2005-10-10
04 (System) New version available: draft-ietf-bmwg-hash-stuffing-04.txt
2005-06-22
03 (System) New version available: draft-ietf-bmwg-hash-stuffing-03.txt
2005-02-16
02 (System) New version available: draft-ietf-bmwg-hash-stuffing-02.txt
2004-10-22
01 (System) New version available: draft-ietf-bmwg-hash-stuffing-01.txt
2004-07-16
00 (System) New version available: draft-ietf-bmwg-hash-stuffing-00.txt