Current Meeting Report
Slides
2.7.4 IP Performance Metrics (ippm)
NOTE: This charter is a snapshot of the 52nd IETF Meeting in Salt Lake City, Utah USA. It
may now be out-of-date. Last Modified:
13-Nov-01
Chair(s):
Merike Kaeo <kaeo@merike.com>
Matthew Zekauskas <matt@advanced.org>
Transport Area Director(s):
Scott Bradner <sob@harvard.edu>
Allison Mankin <mankin@isi.edu>
Transport Area Advisor:
Allison Mankin <mankin@isi.edu>
Mailing Lists:
General Discussion:ippm@advanced.org
To Subscribe: ippm-request@advanced.org
Archive: http://www.advanced.org/IPPM/archive/
Description of Working Group:
The IPPM WG will develop a set of standard metrics that can be applied
to the quality, performance, and reliability of Internet data delivery
services. These metrics will be designed such that they can be
performed by network operators, end users, or independent testing
groups. It is important that the metrics not represent a value
judgement
(i.e. define "good" and "bad"), but rather provide unbiased
quantitative
measures of performance.
Functions peripheral to Internet data delivery services, such as
NOC/NIC services, are beyond the scope of this working group.
The IPPM WG will define specific metrics, cultivate technology for the
accurate measurement and documentation of these metrics, and promote
the sharing of effective tools and procedures for measuring these
metrics. It will also offer a forum for sharing information about the
implementation and application of these metrics, but actual
implementations and applications are understood to be beyond the scope
of this working group.
Goals and Milestones:
| Oct 97 | | Submit drafts of standard metrics for connectivity and treno-bulk-throughput. |
| Nov 97 | | Submit a framework document describing terms and notions used in the IPPM effort, and the creation of metrics by the working group to IESG for publication as an Informational RFC. |
| Feb 98 | | Submit documents on delay and loss to IESG for publication as Informational RFCs. |
| Apr 98 | | Submit a document on connectivity to IESG for publication as an Informational RFC. |
| Sep 98 | | Submit a document on bulk-throughput to IESG for publication as an Informational RFC. |
Internet-Drafts:
Request For Comments:
| RFC | Status | Title |
|
| RFC2330 | | Framework for IP Performance Metrics |
| RFC2678 | E | IPPM Metrics for Measuring Connectivity |
| RFC2679 | PS | A One-way Delay Metric for IPPM |
| RFC2680 | PS | A One-way Packet Loss Metric for IPPM |
| RFC2681 | PS | A Round-trip Delay Metric for IPPM |
| RFC3148 | | A Framework for Defining Empirical Bulk Transfer
Capacity Metrics |
Current Meeting Report
Minutes of the IP Performance Metrics WG (ippm)
Wednesday, 12 December 2001, 13:00 - 14:00
===================================================
The meeting was chaired by the working group chairs, Matt Zekauskas and Merike Kaeo. Al Morton took notes, which were edited into these minutes by the chairs.
AGENDA
1. Agenda bashing
2. Summarizing latest radical revision of npmps draft as per the I-D
3. Practical experience with the IPDV draft
4. One-way Active Measurements Protocol Requirements
5. IPPM metric management needs
6. Discussion on charter/milestones/potential new work
IETF home page: http://www.ietf.org/html.charters/ippm-charter.html
IPPM home page: http://www.advanced.org/IPPM/
2. Summarizing latest radical revision of npmps draft
-- Al Morton, AT&T
Al Morton presented an update on the latest revision of the npmps draft. A poll of the audience showed that only 5 people had read the new draft. Al mentioned that the first 3 pages are the most important and would like to get agreement on the modifications made to get this latest revision. No comments were made. Al remarked that no negative comments was very positive; a few audience members (that attended this meeting and previous meetings) have been vocal, so this is a significant step forward.
Matt said a last call will be issued on the mailing list for this document.
3. Practical experience with the IPDV draft
-- Henk Uijterwaal, RIPE NCC
Henk Uijterwaal presented practical experience with IPDV to answer the question 'can we measure something useful with it?' He showed examples of measures of delay variation (peaks and distributions) on different paths for 1 week periods. Two of the examples showed effects that cannot (easily) be seen in plots of the absolute delay between hosts. A longer write up is being prepared for PAM2002. He also looked at experimental errors and concluded that this was not really an issue - it only comes up when restarting the time-keeping processes. Henk's conclusion is that the draft is useful and ready to go. No comments were made.
Matt stated that last call will go out on this document soon.
4. One-way Active Measurements Protocol Requirements
- Stanislav Shalunov
Stanislav Shalunov presented an update of the OWAMP requirements draft stating that most changes were editorial. The two main points were: name change from OWDP to OWAMP and a new section to explain why requirement for only 2 specific packet types (DSCP and PHB). The one major change was the 'accept' byte which had 2 responses. The intention is to later define error codes when there is more implementation experience since it's not yet clear what the error codes should be. For now, the protocol specification is virtually frozen since we are waiting for requirements document to proceed.
A discussion followed clarifying the name change -- the protocol draft is still called owdp, One-way Delay Protocol, but that is due to having initial draft name and how the IETF secretariat keeps track of documents. The intent is to modify the name to One-Way Active Measurement Protocol to reflect the fact that other one-way metrics may be measured with this protocol.
There was a question from the floor asking if the protocol precludes anything but Poisson streams. The answer was that it supports Poisson but intent is to extend it when other metrics are standardized in the future.
An issue was raised of having measurement capability identification in the control protocol. In particular, if you ask for a capability, and the response is "not supported", it is important to know why. For example, you don't want to have to probe to find capabilities, especially if the capability was dependant on traffic or time of day. There was a discussion about how difficult this would be if the results were machine-readable. A compromise was suggested: allow an arbitrary text field that could explain the probe's capabilities to someone trying to configure a system.
Another comment from the floor was made in reference to operating systems and having different constraints on different devices. The reply was that constraints are the same -- the protocol needs to be implemented in general purpose and other hardware. The comment was clarified to say that the requirements document appears to take into account UNIX system specifics; either the document should be extended to other OS and hardware specifics or the references should be removed.
The last comment from the floor was advice to avoid having a huge number of tests which start together, to avoid oscillation in network, especially with respect to any future periodic streams. The reply was that this should be sufficiently handled by randomizing start times (which is specified in the NPMPS draft). Not destroying the network is definitely a requirement.
5. IPPM metric management needs
-- Emile Stephan, France Telecom
Finally, Emile Stephan presented his view of the requirements for management of IPPM measurements - in particular, a proposal to both control and report measurements using a MIB.
This section was prefaced by Matt explaining that the chairs had read the draft and thought it was similar to work proposed in RMONMIB. At Monday's RMONMIB meeting, this work was discussed; the conclusion was that the proposed IPPM MIB had little or no relationship to the work on TPM-MIB (transport performance measurement) and SSPM-MIB (synthetic source performance measurement) within RMONMIB because the RMON work focused on understanding characteristics specifically tied to an application, not general transport characteristics. The recommendation from RMONMIB was that if IPPM chose to work on this MIB, it should work with RMONMIB to create a common metrics registry; the TPM draft, in particular, has some reference to IPPM documents so a common registry would be useful. The RMONMIB chair also mentioned that he felt the MIB's structure could use some work. [The IPPM chairs interpreted this as that the control and data portions should be separated. A email exchange after the meeting clarified that one reason for splitting control and data is that usually the optimal indexing is never the same for both and it leads to simpler access control and better modularity.]
Emile emphasized that a reason to specify the MIB is to permit different devices to perform control and measurement and get metric measurement results. Essentially to have many separate domains, each having potentially different access capabilities to the measurement information.
In general, the MIB would allow for both the control and reporting of IPPM measurements. It has an emphasis on flexibility of measurement types, and also to flexibly report - to allow a customer of your network to have his own view of the measurements taken. Matt asked who thought this was a really bad idea - no hands. He asked how many had read the document - about 8 hands.
There were two comments from the floor. First, the MIB was a good idea, and appropriate for results but security is a concern. Second, we now have 2 requirement documents and perhaps we should finish the one-way protocol requirements document before we think about a MIB that contains control information.
6. Discussion on charter/milestones/potential new work
Discussion on Emile's topic was cut off, and we did not get to further discuss the charter since the meeting had to adjourn for MEGACO to start. The chairs asked that further discussion be taken to the mailing list.
Slides
Agenda
Network Performance Measurement with Periodic Streams
First experiences with the IP Delay Variation Metric