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 |