Skip to main content

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