A Proposed Media Delivery Index May 2005
Network Working Group J. Welch
Internet Draft IneoQuest Technologies
Intended Category: Informational J. Clark
Cisco Systems
May, 2005
A Proposed Media Delivery Index
draft-welch-mdi-01.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than a "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/lid-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
This memo provides information for the Internet community. It does
not specify an Internet standard. Distribution of this memo is
unlimited.
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Welch, Clark Expires November 2005 [Page 1]
A Proposed Media Delivery Index May 2005
Abstract
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 UDP-based 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.
1. Introduction
There has been considerable progress over the last several years in
the development of methods to provide for Quality of Service (QoS)
over packet switched networks to improve the delivery of Streaming
Media and other time and packet loss sensitive applications such as
[i1], [i5], [i6], [i7]. QoS is required for many practical networks
involving applications such as video transport to assure the
availability of network bandwidth by providing upper limits on the
number of flows admitted to a network as well as to bound the packet
jitter introduced by the network. These bounds are required to
dimension a receiver`s buffer to properly display the video in real
time without buffer overflow or underflow.
Now that large scale implementations of such networks based on RSVP
and Diffserv are undergoing trials [i3] and being specified by major
service providers for the transport of Streaming Media such as MPEG
video [i4], there is a need to easily diagnose issues and monitor the
real time effectiveness of networks employing these QoS methods or to
assess whether they are required. Furthermore, due to the significant
installed base of legacy networks without QoS methods, a delivery
system`s transitional solution may be comprised of both networks with
and without these methods thus increasing the difficulty in
characterizing the dynamic behavior of these networks.
The purpose of this memo is to describe a set of measurements that
can be used to derive a Media Delivery Index (MDI) which indicates
the instantaneous and longer term behavior of networks carrying
Streaming Media such as MPEG video.
Welch, Clark Expires November 2005 [Page 2]
A Proposed Media Delivery Index May 2005
While this memo addresses monitoring MPEG Transport Stream (TS)
packets [i8] over UDP, the general approach is expected to be
applicable to other Streaming Media and protocols.
2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [n14].
3. Media Delivery Index Overview
The MDI provides a relative indicator of needed buffer depths at the
consumer node due to packet jitter as well as an indication of lost
packets. By probing a UDP-based service network at various nodes and
under varying load conditions, it is possible to quickly identify
devices or locales which introduce significant jitter or packet loss
to the packet stream flow. By monitoring a network continuously,
deviations from nominal jitter or loss behavior can be used to
indicate an impending or ongoing fault condition such as excessive
load. It is believed that the MDI provides the necessary information
to detect all network induced impairments for streaming video or
voice over IP applications. Other parameters may be required to
troubleshoot and correct the impairments.
The MDI is updated at the termination of selected time intervals
spanning multiple packets which contain the Streaming Media (such as
transport stream packets in the MPEG-2 case.) The Maximums and
Minimums of the MDI component values are captured over a measurement
time. The measurement time may range from just long enough to
capture an anticipated network anomaly during a troubleshooting
exercise to indefinitely long for a long term monitoring or
logging application. The Maximums and Minimums may be obtained by
sampling the MIB with adequate frequency.
4. Media Delivery Index Components
The MDI consists of two components: the Delay Factor (DF) and the
Media Loss Rate (MLR).
4.1 Delay Factor
The Delay Factor is the maximum difference, observed at the end of
each media stream packet, between the arrival of media data and the
drain of media data, assuming the drain rate is the nominal constant
traffic rate for constant bit rate streams or the piece-wise computed
traffic rate of variable rate media stream packet data. The "drain
Welch, Clark Expires November 2005 [Page 3]
A Proposed Media Delivery Index May 2005
rate" here refers to the payload media rate; e.g., for a typical 3.75
Mb/s MPEG video Transport Stream (TS), the drain rate is 3.75 Mb/s --
the rate at which the payload is consumed (displayed) at a decoding
node. If, at the sample time, the number of bytes received equals
the number transmitted, the instantaneous flow rate balance will be
zero, however the minimum DF will be a line packet's worth of media
data as that is the minimum amount of data that must be buffered.
The DF is the maximum observed value of the flow rate imbalance.
This buffered media data in bytes is expressed in terms of how long,
in milliseconds, it would take to drain (or fill) this data at the
nominal traffic rate to obtain the DF. The DF value MUST be updated
and displayed at the end of a selected time interval. The selected
time interval is chosen to be long enough to sample a number of TS
packets and will, therefore, vary based on the nominal traffic rate.
The Delay Factor indicates how long a data stream must be buffered
(i.e. delayed) at its nominal bit rate to prevent packet loss.
Another perspective of this time is as a measure of the network
latency that must be induced from buffering that is required to
accommodate stream jitter and prevent loss. The DF`s max and min
over the measurement period MAY also be displayed to show the worst
case arrival time deviation, or jitter, relative to the nominal
traffic rate in a measurement period. It provides a dynamic flow
rate balance indication with its max and min showing the worst
excursions from balance. To arrive at a bounded DF, the long term
flow rate deviation (LFRD) must be 0, where LFRD is a running
deviation of flow rate from expected nominal traffic rate over a
measurement period. A large positive or negative LFRD usually
indicates a source flow failure or misconfiguration and would cause
the DF value to steadily increase from interval to interval.
The Delay Factor gives a hint of the minimum size of the buffer
required at the next downstream node. As a stream progresses, the
variation of the Delay Factor indicates packet bunching (jitter).
Greater DF values also indicate more network latency necessary to
deliver a stream due to the need to prefill a receive buffer before
beginning the drain to guarantee no underflow. The DF comprises a
fixed part based on packet size and a variable part based on the
various network component switch elements` buffer utilization that
comprise the switched network infrastructure [i2].
4.2 Media Loss Rate
The Media Loss Rate is the count of lost or out of order flow packets
over a selected time interval, where the flow packets are packets
carrying streaming application information. There may be zero or
more streaming packets in a single IP packet. For example, it is
common to carry seven 188 Byte MPEG Transport Stream packets in an IP
packet. In such a case, a single IP packet loss would result in 7
Welch, Clark Expires November 2005 [Page 4]
A Proposed Media Delivery Index May 2005
lost packets counted for the case where the 7 lost packets did not
include null packets. Including out of order packets is important as
many stream consumer type devices do not attempt to reorder packets
that are received out of order.
4.3 Media Delivery Index
Combining the Delay Factor and Media Loss Rate quantities for
presentation results in the MDI:
DF:MLR
Where:
DF is the Delay Factor
MLR is the Media Loss Rate
At a receiving node, knowing its nominal drain bit rate, the DF`s max
indicates the size of required buffer to accommodate packet jitter.
Or, in terms of Leaky Bucket [i9] parameters, DF indicates bucket
size b expressed in time to transmit bucket traffic b, at the given
nominal traffic rate, r.
4.4 MDI Application Examples
In the case where a known, well characterized receive node is
separated from the data source by unknown or less well characterized
nodes such as intermediate switch nodes, the MDI measured at
intermediate data links provides a relative indication of the
behavior of upstream traffic flows. DF difference indications
between one node and another in a data stream for a given constant
interval of calculation can indicate local areas of traffic
congestion or possibly misconfigured QoS flow specification(s)
leading to greater filling of measurement point local device buffers,
resultant flow rate deviations, and possible data loss.
For a given MDI, if DF is high and/or the DF Max-Min captured over a
significant measurement period is high, jitter has been detected but
the longer term, average flow rate may be nominal. This could be the
result of a transient flow upset due to a coincident traffic stream
unrelated to the flow of interest causing packet bunching. A high DF
may cause downstream buffer overflow or underflow or unacceptable
latency even in the absence of lost data.
Due to transient network failures or DF excursions, packets may be
lost within the network. The MLR component of the MDI shows this
condition.
Welch, Clark Expires November 2005 [Page 5]
A Proposed Media Delivery Index May 2005
Through automated or manual flow detection and identification and
subsequent MDI calculations for real time statistics on a flow, the
DF can indicate the dynamic deterioration or increasing burstiness of
a flow which can be used to anticipate a developing network operation
problem such as transient oversubscription. Such statistics can be
obtained for flows within network switches using available switch cpu
resources due to the minimal computational requirements needed for
small numbers of flows. Statistics for all flows present on, say, a
gigabit Ethernet network, will likely require dedicated hardware
facilities though these can be modest as buffer requirements and the
required calculations per flow are minimal. By equipping network
switches with MDI measurements, flow impairment issues can quickly be
identified, localized, and corrected. Until switches are so equipped
with appropriate hardware resources, dedicated hardware tools can
provide supplemental switch statistics by gaining access to switch
flows via mirror ports, link taps, or the like as a transition
strategy.
The MDI figure can also be used to characterize a flow decoder's
acceptable performance. For example, an MPEG decoder could be
characterized as tolerating a flow with a given maximum DF and MLR
for acceptable display performance (acceptable on-screen artifacts).
Network conditions such as Interior Gateway Protocol (IGP)
reconvergence might also be included in the flow tolerance resulting
in a higher quality user experience.
5. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of
RFC 3410 [i10].
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. MIB objects are generally
accessed through the Simple Network Management Protocol (SNMP).
Objects in the MIB are defined using the mechanisms defined in the
Structure of Management Information (SMI). This memo specifies a MIB
module that is compliant to the SMIv2, which is described in STD 58,
RFC 2578 [n11], STD 58, RFC 2579 [n12] and STD 58, RFC 2580 [n13].
5.1 MIB Overview
This MIB provides a set of objects required for the export of MDI
metrics of IP Streaming Media streams.
5.2 MIB Definitions
--
-- Media Stream Monitor MIB
Welch, Clark Expires November 2005 [Page 6]
A Proposed Media Delivery Index May 2005
--
MEDIA-MONITOR-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY,
OBJECT-TYPE,
Integer32,
Unsigned32,
mib-2,
NOTIFICATION-TYPE,
OBJECT-IDENTITY,
IpAddress
FROM SNMPv2-SMI -- RFC2578
DisplayString
FROM SNMPv2-TC
MODULE-COMPLIANCE, OBJECT-GROUP,
NOTIFICATION-GROUP
FROM SNMPv2-CONF; -- RFC2580
mediaMonitorMIB MODULE-IDENTITY
LAST-UPDATED "200404040000Z" -- 04 April 2004
ORGANIZATION " xx "
CONTACT-INFO
"IneoQuest Technologies, Inc.
Postal: 170 Forbes Boulevard
Mansfield, MA, 02048
Tel: +1 508 618 0312
E-mail: jim.welch@ineoquest.com"
DESCRIPTION
"The media Monitor MIB (MEDIA-MONITOR-MIB) provides
Metrics for Monitoring IP Streaming Media Flows."
-- Revision history
REVISION "200404040000Z" -- 04 April 2004
DESCRIPTION
"Initial version, published as RFC xxxx. (this RFC)"
::= { xxxx }
-- Top level structure of the MIB
mediaMonitorObjects OBJECT IDENTIFIER ::= { mediaMonitorMIB 1 }
ipMediaStreamMonitorTable OBJECT-TYPE
SYNTAX SEQUENCE OF IpMediaStreamMonitorEntry
Welch, Clark Expires November 2005 [Page 7]
A Proposed Media Delivery Index May 2005
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"IP Stream Monitor Table. This table is indexed by the
Stream Handle. This Table only shows the currently ACTIVE
Streams."
::= { mediaMonitorObjects 1 }
ipMediaStreamMonitorEntry OBJECT-TYPE
SYNTAX IpMediaStreamMonitorEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"IP Stream Monitor Table Entry."
INDEX { ipMediaStreamMonitorHandle }
::= { ipMediaStreamMonitorTable 1 }
IpMediaStreamMonitorEntry ::= SEQUENCE {
ipMediaStreamHandle
Unsigned32,
ipMediaStreamSourceIpAddress
IpAddress,
ipMediaStreamSourcePort
Unsigned32,
ipMediaStreamDestinationIpAddress
IpAddress,
ipMediaStreamDestinationPort
Unsigned32,
ipMediaStreamBitRate
Unsigned32,
ipMediaStreamInterval
Unsigned32,
ipMediaStreamStartTime
DisplayString,
ipMediaStreamMDIDelayFactor
Unsigned32,
ipMediaStreamMDILossRate
Unsigned32,
ipMediaStreamMDIDFThreshold
Unsigned32,
ipMediaStreamMDILRThreshold
Unsigned32,
ipMediaStreamMDIDFErrorIntervals
Unsigned32
ipMediaStreamMonitorMDIMLRErrorIntervals
Unsigned32
}
ipMediaStreamHandle OBJECT-TYPE
Welch, Clark Expires November 2005 [Page 8]
A Proposed Media Delivery Index May 2005
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Table is indexed by stream Handle. The table has one row
for each Media Stream detected from the Ip Interface. The
Stream Handle shall be a unique value for the life of the
stream."
::= { ipMediaStreamMonitorEntry 1 }
ipMediaStreamSourceIpAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Source IpAddress for the Stream indexed by the Stream
Handle."
::= { ipMediaStreamMonitorEntry 2 }
ipMediaStreamSourcePort OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The Source port for the Stream indexed by the Stream
Handle."
::= { ipMediaStreamMonitorEntry 3 }
ipMediaStreamDestinationIpAddress OBJECT-TYPE
SYNTAX IpAddress
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Destination IpAddress for the Stream indexed by the
Stream Handle."
::= { ipMediaStreamMonitorEntry 4 }
ipMediaStreamDestinationPort OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The Destination port for the Stream indexed by the
Stream Handle."
::= { ipMediaStreamMonitorEntry 5 }
ipMediaStreamBitRate OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
Welch, Clark Expires November 2005 [Page 9]
A Proposed Media Delivery Index May 2005
STATUS current
DESCRIPTION
"The nominal Bit Rate of the Media Stream in bits/second."
::= { ipMediaStreamMonitorEntry 6 }
ipMediaStreamInterval OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number indicates the minimum Interval in seconds for
a good MDI Measurement. The Interval is based on the
current Bit Rate of the Stream. The minimum interval
should be chosen such that at least 10 IP packets occur
per interval. This value defaults to 1 second and the
Interval is typically configured to 1 second unless the
above criteria is not met."
::= { ipMediaStreamMonitorEntry 7 }
ipMediaStreamStartTime OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The Timestamp shows the Real time at which the stream was
detected. The Timestamp format is YYYY/MM/DD/HH/MM/SS."
::= { ipMediaStreamMonitorEntry 8 }
ipMediaStreamMDIDelayFactor OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object displays the Media Delivery Index Delay
Factor parameter in units of milliseconds. This parameter
indicates the burstiness of the stream."
::= { ipMediaStreamMonitorEntry 9 }
ipMediaStreamMDILossRate OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"This object displays the Media Delivery Index Media Loss
Rate in packets/sec. This parameter indicates rate of
lost media packets of the of the stream."
::= { ipMediaStreamMonitorEntry 10 }
ipMediaStreamMDIDFThreshold OBJECT-TYPE
Welch, Clark Expires November 2005 [Page 10]
A Proposed Media Delivery Index May 2005
SYNTAX Unsigned32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The Threshold for Media Delivery Index Delay Factor in
milliSeconds. The default value is set to 0 indicating
that it is invalid until configured."
::= { ipMediaStreamMonitorEntry 11 }
ipMediaStreamMDILRThreshold OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The Threshold for Media Delivery Loss Rate
in Packets/second. The default value is set to 0xffffffff
indicating that it is invalid until configured."
::= { ipMediaStreamMonitorEntry 12 }
ipMediaStreamMDIDFErrorIntervals OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number indicates the number of MDI DF Threshold
(ipMediaStreamMonitorMDIDFThreshold) Crossed Intervals
during the life of a stream. This shall be 0 and invalid
until the MDI DF Thresholds are configured."
::= { ipMediaStreamMonitorEntry 13 }
ipMediaStreamMDIMLRErrorIntervals OBJECT-TYPE
SYNTAX Unsigned32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The number indicates the number of MDI MLR Threshold
(ipMediaStreamMDILRThreshold)Crossed Intervals
during the life of a stream. This shall be 0 and invalid
until the MDI MLR Thresholds are configured."
::= { ipMediaStreamMonitorEntry 14 }
END
6. Summary
The MDI combines the Delay Factor which indicates potential for
impending data loss and Media Loss Rate as the indicator of lost
Welch, Clark Expires November 2005 [Page 11]
A Proposed Media Delivery Index May 2005
data. By monitoring the DF and MLR and their min and max excursions
over a measurement period and at multiple strategic locations in a
network, traffic congestion or device impairments may be detected and
isolated for a network carrying Streaming Media content. The
included MIB provides a set of objects required for the export of MDI
metrics of IP Streaming Media streams.
7. Security Considerations
The measurements identified in this document do not directly affect
the security of a network or user. Actions taken in response to
these measurements which may affect the available bandwidth of the
network or availability of a service is out of scope for this
document.
Performing the measurements described in this document only requires
examination of payload header information such as MPEG transport
stream headers or RTP headers to determine nominal stream bit rate
and sequence number information. Content may be encrypted without
affecting these measurements. Therefore, content privacy is not
expected to be a concern.
8. Normative References
n1. K. McCloghrie, D. Perkins, J. Schoenwaelder, J. Case, J. Rose, M.
and S. Waldbusser, 'Structure of Management Information Version 2
(SMIv2)', STD 58, RFC 2578, April 1999.
n2. K. McCloghrie, D. Perkins, J. Schoenwaelder, J. Case, J. Rose, M.
and S. Waldbusser, 'Textual Conventions for SMIv2', STD 58, RFC
2579, April 1999.
n3. K. McCloghrie, D. Perkins, J. Schoenwaelder, J. Case, J. Rose, M.
and S. Waldbusser, 'Conformance Statements for SMIv2', STD 58, RFC
2580, April 1999.
n4. S. Bradner, 'Key words for use in RFCs to Indicate Requirement
Levels', BCP 14, RFC 2119, March 1997.
9. Informative References
i1. R. Braden et al., `Resource Reservation Protocol ` Version 1
Functional Specification`, RFC 2205, 1997.
i2. C. Partridge, `A Proposed Flow Specification`, RFC 1363, 1992.
i3. R. Fellman, `Hurdles to Overcome for Broadcast Quality Video
Delivery over IP` VidTranS 2002.
i4. CableLabs `PacketCable Dynamic Quality-of-Service Specification`,
PKT-SP-DQOS-I06-030415, 2003.
Welch, Clark Expires November 2005 [Page 12]
A Proposed Media Delivery Index May 2005
i5. S. Shenker, C. Partridge, R. Guerin, `Specification of Guaranteed
Quality of Service`, RFC 2212, 1997.
i6. J. Wroclawski, `Specification of the Controlled-Load Network
Element Service`, RFC 2211, 1997.
i7. R. Braden, D. Clark, S. Shenker, `Integrated Services in the
Internet Architecture: an Overview` RFC 1633, 1994.
i8. ISO/IEC 13818-1 (MPEG-2 Systems)
i9. V. Raisanen, `Implementing Service Quality in IP Networks`, John
Wiley & Sons Ltd., 2003.
i10. J. Case, R. Mundy, D. Partain, B. Stewart, 'Introduction and
Applicability Statements for Internet Standard Management
Framework', RFC 3410, 2002.
10. Acknowledgments
The authors gratefully acknowledge the contributions of Marc Todd and
Jesse Beeson of IneoQuest Technologies, Inc., Bill Trubey and John
Carlucci of Time Warner Cable, Nishith Sinha of Cox Communications,
Ken Chiquoine of SeaChange International, Phil Proulx of Bell Canada,
Dr Paul Stallard of TANDBERG Television, Gary Hughes of Broadbus
Technologies, Brad Medford of SBC Laboratories, John Roy of Adelphia
Communications, Cliff Mercer, PhD of Kasenna, Mathew Ho of Rogers
Cable, and Irl Duling of Optinel Systems for reviewing and evaluating
early drafts of this document and implementations for MDI.
11. Authors' Address
James Welch
IneoQuest Technologies, Inc
170 Forbes Blvd
Mansfield, Massachusetts 02048
508 618 0312
Jim.Welch@ineoquest.com
James Clark
Cisco Systems, Inc
500 Northridge Road
Suite 800
Atlanta, Georgia 30350
678 352 2726
jiclark@cisco.com
12. Copyright Notice
Copyright (C) The Internet Society (2005). This document is subject to
the rights, licenses and restrictions contained in BCP 78, and except
as set forth therein, the authors retain all their rights.
Welch, Clark Expires November 2005 [Page 13]
A Proposed Media Delivery Index May 2005
13. Disclaimer
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.'
14. Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the ISOC's procedures with respect to rights in ISOC Documents can
be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
TO BE DELETED BY THE RFC EDITOR UPON PUBLICATION:
Changes from draft-welch-mdi-00.txt:
Welch, Clark Expires November 2005 [Page 14]
A Proposed Media Delivery Index May 2005
* Added "MDI Application Examples" section
* Changed all occurrences of QOS to QoS and spelled it out the
first time it occurred.
*clarified Media Delivery Index Overview section describing need
for dejitter buffers and removed reference to latency.
*clarified Abstract section eliminating reference to constant bit
rate streams as it erroneously implies that the measurement does
not apply to variable bit rate streams.
*clarified how Maximums and Minimums may be obtained in the Media
Delivery Index Overview section.
*clarified DF description and "drain rate" term in Media Delivery
Index Components section
*updated IPR boilerplate in Status of this Memo section
*clarified language in Abstract section
*numbered sections in the document body
*clarified applicability of MDI to streaming applications besides
video
Welch, Clark Expires November 2005 [Page 15]