Technical Summary
This memo defines a Media Delivery Index (MDI) measurement which can
be used as a diagnostic tool or a quality indicator for monitoring a
network intended to deliver applications such as streaming media MPEG
video and Voice over IP or other arrival time and packet loss
sensitive information. It provides an indication of traffic jitter,
a measure of deviation from nominal flow rates, and a data loss at-a-
glance measure for a particular flow. For instance, the MDI may be
used as a reference in characterizing and comparing networks carrying
UDP streaming media. Included is a set of managed objects for SNMP-
based management of IP media streams for which an MDI measurement is
obtained.
The Media Delivery Index measurement and MIB defined in this memo is
intended for Information only.
Working Group Summary
This document is not the product of a current IETF WG.
So the AD review concentrated on checking for conflict/overlap.
Allison and I did check with people (Magnus Westerlund and Dan
Romascanu) who are active in AVT, RMONMIB and related WGs and
technology.
In AVT WG this work seem very similar to what has been done in
RFC 3611 (RTCP XR). The metrics are slightly different but most
of the information could probably be determined using the
appropriate RTCP XR reports.
There is ongoing work in AVT to define a MIB for these measurements.
There are also a proposal to update and possibly extend these RTCP XR
measurements to include also Video measurements in addition to the
general and VoIP metrics that exist, see
draft-ietf-avt-rtcpxr-bis-00.txt which expired this month.
In terms of Metrics, the document seems to possibly be underspecifying
metrics, and it seems that Metrics definition work might benefit from
work that has already been done in IPPM WG.
In the MIB module, there is at least one object duplicating information
from another standard MIB modules ipMediaStreamBitRate has similar
semantics with ifSpeed from RFC 2863.
Protocol Quality
When reviewing for possible conflict/overlap with current IETF work,
it was also noted that there are (serious) MIB issues (a Comment has
been recorded by Bert in the I-D tracker, suggesting that the MIB
be reviewed against the MIB review guidelines, that it be checked
for valid/proper SYNTAX and that it be made complete, all before
publication as RFC).
There were also concerns if this spec is written well enough.
The metrics are under-defined. It seems impossible to implement these
metrics as their definitions are to unspecific. Measuring periods are
missing, quantization, etc.
Note to RFC Editor
From RFC 3932 section 3, bullet 2.
The IESG thinks that this work is related to IETF work done in the
AVT and IPPM WGs, but this does not prevent publishing.
Please add the IESG Note (see below) on the front page.
Please also look at the COMMENTs recorded in the I-D tracker,
because there are serious technical issues that you may want
to discuss with the author/submitter and that you probably want
to be fixed before publication.
IESG Note
This RFC is not a candidate for any level of Internet
Standard. There are IETF standards which are highly
applicable to the space defined by this document as
its applicability, in particular, RFCs 3393 and 3611,
and there is ongoing IETF work in these areas as
well. The IETF also notes that the decision to
publish this RFC is not based on IETF review for such
things as security, congestion control, MIB fitness, or
inappropriate interaction with deployed protocols.
The RFC Editor has chosen to publish this document at
its discretion. Readers of this document should
exercise caution in evaluating its value for
implementation and deployment.
See RFC 3932 for more information.
IANA Note
IANA probably has to assign a OID to the MIB module
(once it is fixed) so that it can be compiled.
It should not be an OID under mib-2. Under experimental
would be fine, or under the submitters vendor ID would
be fine (in which case the submitter should do so, and
IANA/RFC-Editor only need to verify the proper vendor ID
(i.e. OID under enterprises) is used).