Terminology for Benchmarking Network-layer Traffic Control Mechanisms
RFC 4689
Revision differences
Document history
| Date | Rev. | By | Action |
|---|---|---|---|
|
2017-05-16
|
13 | (System) | Changed document authors from "Shobha Erramilli, Jerry Perser, Sumit Khurana" to "Shobha Erramilli, Jerry Perser, Sumit Khurana, Scott Poretsky" |
|
2015-10-14
|
13 | (System) | Notify list changed from bmwg-chairs@ietf.org to (None) |
|
2012-08-22
|
13 | (System) | post-migration administrative database adjustment to the No Objection position for Russ Housley |
|
2006-11-17
|
13 | Amy Vezza | State Changes to RFC Published from RFC Ed Queue by Amy Vezza |
|
2006-11-17
|
13 | Amy Vezza | [Note]: 'RFC 4689' added by Amy Vezza |
|
2006-11-08
|
13 | (System) | Request for Early review by SECDIR Completed. Reviewer: Tero Kivinen. |
|
2006-10-31
|
13 | (System) | RFC published |
|
2006-07-14
|
13 | Amy Vezza | State Changes to RFC Ed Queue from Approved-announcement sent by Amy Vezza |
|
2006-07-10
|
13 | Amy Vezza | IESG state changed to Approved-announcement sent |
|
2006-07-10
|
13 | Amy Vezza | IESG has approved the document |
|
2006-07-10
|
13 | Amy Vezza | Closed "Approve" ballot |
|
2006-07-10
|
13 | David Kessens | State Changes to Approved-announcement to be sent from IESG Evaluation::AD Followup by David Kessens |
|
2006-07-09
|
13 | Russ Housley | [Ballot Position Update] Position for Russ Housley has been changed to No Objection from Discuss by Russ Housley |
|
2006-06-27
|
13 | (System) | New version available: draft-ietf-bmwg-dsmterm-13.txt |
|
2006-05-26
|
13 | (System) | Removed from agenda for telechat - 2006-05-25 |
|
2006-05-25
|
13 | Amy Vezza | State Changes to IESG Evaluation::AD Followup from IESG Evaluation by Amy Vezza |
|
2006-05-25
|
13 | Lisa Dusseault | [Ballot Position Update] New position, No Objection, has been recorded for Lisa Dusseault by Lisa Dusseault |
|
2006-05-25
|
13 | Mark Townsley | [Ballot Position Update] New position, No Objection, has been recorded for Mark Townsley by Mark Townsley |
|
2006-05-25
|
13 | Jari Arkko | [Ballot comment] Nits: s/[BR98]/[Br98]/ Terms DUT and SUT should be opened up on first occurrence. |
|
2006-05-25
|
13 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko by Jari Arkko |
|
2006-05-25
|
13 | Yoshiko Fong | IANA Comments: As described in the IANA Considerations section, we understand this document to have NO IANA Actions. |
|
2006-05-24
|
13 | Cullen Jennings | [Ballot Position Update] New position, No Objection, has been recorded for Cullen Jennings by Cullen Jennings |
|
2006-05-24
|
13 | Dan Romascanu | [Ballot comment] 1. The last paragrah in the introduction section seems to be unrelated with the first three paragraphs. It mentions 'one of these two … [Ballot comment] 1. The last paragrah in the introduction section seems to be unrelated with the first three paragraphs. It mentions 'one of these two mechanisms' without the rest of the section defining what mechanisms are being discussed. 2. There is a need for an abbreviations section in order to ease readability 3. Sections 3.2.4, 3.2.5, 3.4.3.4 to 3.4.3.10, 3.4.4.4 to 3.4.4.10 define 'seconds' as units for latency and jitter. This does not seem to be granular enough and thus conflicts with Section 3.8 in RFC 1224 which requires that time units for latency for example be 'Time with fine enough units to distinguish between two events'. |
|
2006-05-24
|
13 | Dan Romascanu | [Ballot Position Update] New position, No Objection, has been recorded for Dan Romascanu by Dan Romascanu |
|
2006-05-24
|
13 | Yoshiko Fong | IANA Comments: As described in the IANA Considerations section, we understand this document to have NO IANA Actions. |
|
2006-05-23
|
13 | Russ Housley | [Ballot discuss] Based on a Security Directorate review by Tero Kivinen. This document defines terminology, so it does not really have any security … [Ballot discuss] Based on a Security Directorate review by Tero Kivinen. This document defines terminology, so it does not really have any security issues to cover. The security considerations section does warn against doing benchmarking on devices or systems connected to production networks. Perhaps it should also say that benchmarking services MUST be disabled by default, which would require a configuration change in order to perform benchmarking. This is real concern if these services enable amplification attacks. For example, send one packet, and get more than one packet back. The document uses MUST/SHOULD in situations that are not possible to verify whether it was followed or not. For example the section 2 says: "RFC 1242 ... SHOULD be consulted before attempting to make use of this document". This use of "SHOULD" ought to be changed to "should". There are several others that ought to be changed too. |
|
2006-05-23
|
13 | Russ Housley | [Ballot Position Update] New position, Discuss, has been recorded for Russ Housley by Russ Housley |
|
2006-05-23
|
13 | Magnus Westerlund | [Ballot comment] DUT/SUT are not spelled out at their first usage or in a abbrevations chapter. In general I think the document could become more … [Ballot comment] DUT/SUT are not spelled out at their first usage or in a abbrevations chapter. In general I think the document could become more readable if one actually wrote out abbrevations on their first usage. Even if they are obvious for a person skilled in the field. |
|
2006-05-23
|
13 | Magnus Westerlund | [Ballot comment] DUT/SUT are not spelled out at their first usage or in a abbrevations chapter. In general I think the document could become more … [Ballot comment] DUT/SUT are not spelled out at their first usage or in a abbrevations chapter. In general I think the document could become more readable if one actually wirte out abbrevations on their first usage. Even if they are obvious for a person skilled in the field. |
|
2006-05-23
|
13 | Lars Eggert | [Ballot Position Update] New position, No Objection, has been recorded for Lars Eggert by Lars Eggert |
|
2006-05-23
|
13 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund by Magnus Westerlund |
|
2006-05-18
|
13 | David Kessens | [Note]: 'Al Morton <acmorton@att.com> is the proto shepherd' added by David Kessens |
|
2006-05-18
|
13 | David Kessens | [Ballot Position Update] New position, Yes, has been recorded for David Kessens |
|
2006-05-18
|
13 | David Kessens | Ballot has been issued by David Kessens |
|
2006-05-18
|
13 | David Kessens | Created "Approve" ballot |
|
2006-05-18
|
13 | (System) | Ballot writeup text was added |
|
2006-05-18
|
13 | (System) | Last call text was added |
|
2006-05-18
|
13 | (System) | Ballot approval text was added |
|
2006-05-18
|
13 | David Kessens | Placed on agenda for telechat - 2006-05-25 by David Kessens |
|
2006-05-18
|
13 | David Kessens | State Changes to IESG Evaluation from Publication Requested by David Kessens |
|
2006-03-22
|
13 | Dinara Suleymanova | PROTO Write-up 1.a) Have the chairs personally reviewed this version of the Internet Draft (ID), and in particular, do they believe this ID is ready … PROTO Write-up 1.a) Have the chairs personally reviewed this version of the Internet Draft (ID), and in particular, do they believe this ID is ready to forward to the IESG for publication? Yes. Note that a few typos have crept into version 12 (in section 3.4.4.5, "Expect" --> "Expected") and there are two very minor nits, considering that this document is being edited as a flat file, with little formatting help: * There are 2 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Checking nits according to http://www.ietf.org/ietf/1id-guidelines.txt: - The page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 11) being 59 lines but these can be repaired along with future comments. 1.b) Has the document had adequate review from both key WG members and key non-WG members? Do you have any concerns about the depth or breadth of the reviews that have been performed? Yes, the reviews have been very complete over 5 WG Last Calls. Non-WG members have been consulted, and there are no known concerns. 1.c) Do you have concerns that the document needs more review from a particular (broader) perspective (e.g., security, operational complexity, someone familiar with AAA, etc.)? No. 1.d) Do you have any specific concerns/issues with this document that you believe the ADs and/or IESG should be aware of? For example, perhaps you are uncomfortable with certain parts of the document, or have concerns whether there really is a need for it. In any event, if your issues have been discussed in the WG and the WG has indicated it that it still wishes to advance the document, detail those concerns in the write-up. No, Co-Chair comments have been addressed. 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? This draft precipitated substantial comments from many WG members during its many WG Last Calls. The final comments were resolved as summarized here: http://www1.ietf.org/mail-archive/web/bmwg/current/msg00845.html (then, the primary editor left the group, and it took time to get another editor to correct the I-D nits issues) 1.f) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarise the areas of conflict in separate email to the Responsible Area Director. One of the former co-authors asked to have his name removed from the author list, following the declaration of consensus to name a particular metric "Maximum Lossless Forwarding Rate" instead of "Capacity". There was little or no support for "capacity" from others. There was a compromise to use the term "Forwarding Capacity". 1.g) Have the chairs verified that the document adheres to all of the ID nits? (see http://www.ietf.org/ID-Checklist.html). Two lines have >72 characters (1 nit), and there is one warning. The nit should not impact AD or IESG review. 1.h) Is the document split into normative and informative references? Are there normative references to IDs, where the IDs are not also ready for advancement or are otherwise in an unclear state? (note here that the RFC editor will not publish an RFC with normative references to IDs, it will delay publication until all such IDs are also ready for publication as RFCs.) Yes, the references are split and all the normative references are stable. 1.i) For Standards Track and BCP documents, the IESG approval announcement includes a write-up section with the following sections: The draft is Informational, as are all BMWG RFCs, but we provide the following summary: * Technical Summary This document describes terminology for the benchmarking of devices that implement traffic control based on IP precedence or Diffserv code point criteria. The terminology is to be applied to measurements made on the data plane to evaluate IP traffic control mechanisms. New terminology is needed because most existing measurements assume the absence of congestion and only a single per-hop- behavior. This document introduces several new terms that will allow measurements to be taken during periods of congestion. Another key difference from existing terminology is the definition of measurements as observed on egress as well as ingress of a device/system under test. Again, the existence of congestion requires the addition of egress measurements as well as those taken on ingress; without observing traffic leaving a device/system it is not possible to say whether traffic-control mechanisms effectively dealt with congestion. The principal measurements introduced in this document are vectors for rate, delay, and jitter, all of which can be observed with or without congestion of the DUT/SUT. * Working Group Summary This document is a product of the BMWG WG. The WG has consensus to publish this document as an Informational RFC. * Protocol Quality This document does not specify a protocol. 1.j) Please provide such a write-up. Recent examples can be found in the "protocol action" announcements for approved documents. (above) 1.k) Note: * The relevant information for the technical summary 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. * For the Working Group Summary: Was there anything in WG process that is worth noting? For example, was there controversy about particular points, decisions where consensus was particularly rough, etc. * For the protocol quality, useful information includes: + Are there existing implementations of the protocol? + Have a significant number of vendors indicated they plan to implement the specification? + Are there any reviewers that merit special mention as having done a thorough review (i.e., that resulted in important changes or a conclusion that the document had no substantive issues)? |
|
2006-03-22
|
13 | Dinara Suleymanova | Draft Added by Dinara Suleymanova in state Publication Requested |
|
2006-02-27
|
12 | (System) | New version available: draft-ietf-bmwg-dsmterm-12.txt |
|
2005-07-12
|
11 | (System) | New version available: draft-ietf-bmwg-dsmterm-11.txt |
|
2005-02-21
|
10 | (System) | New version available: draft-ietf-bmwg-dsmterm-10.txt |
|
2004-02-03
|
09 | (System) | New version available: draft-ietf-bmwg-dsmterm-09.txt |
|
2003-10-27
|
08 | (System) | New version available: draft-ietf-bmwg-dsmterm-08.txt |
|
2003-06-19
|
07 | (System) | New version available: draft-ietf-bmwg-dsmterm-07.txt |
|
2003-05-02
|
06 | (System) | New version available: draft-ietf-bmwg-dsmterm-06.txt |
|
2003-02-19
|
05 | (System) | New version available: draft-ietf-bmwg-dsmterm-05.txt |
|
2002-10-21
|
04 | (System) | New version available: draft-ietf-bmwg-dsmterm-04.txt |
|
2002-06-13
|
03 | (System) | New version available: draft-ietf-bmwg-dsmterm-03.txt |
|
2001-10-30
|
02 | (System) | New version available: draft-ietf-bmwg-dsmterm-02.txt |
|
2001-07-05
|
01 | (System) | New version available: draft-ietf-bmwg-dsmterm-01.txt |
|
2001-02-27
|
00 | (System) | New version available: draft-ietf-bmwg-dsmterm-00.txt |